Gun: Revisit project structure and code

[bkniffler]

I've been looking into gun since the beginning and while it matured a lot on features and ease of use, I'm still super puzzled on understanding the codebase. I might be a bit spoiled by modern libraries embracing typescript, lerna and yarn workspaces; but I feel like gun could get more users to contribute if the project had a clearer structure.

So, what do you think about trying to revisit the structure and separate the code into different packages, all inside the main gun repository (monorepository). We could have gun, gun-server, axe, sea etc. (babel did a great job on converting to monorepo structure: https://github.com/babel/babel/tree/master/packages). Maybe we could rewrite gun with typescript. Maybe we could lessen the use of globals. Maybe we could remove compiled files from the repo and put them onto CDN, GitHub releases, NPM. Maybe we could add .npmignore to not publish example and test folders.

I know, all of this would take some effort, but in the end I'm pretty sure it is worth it.

[mitra42]

I also think one of the barriers to using and working with Gun is the ways it differs from convention, with little benefit except a potentially smaller load size (fewer dependencies).

@amark has some strong opinions for some of the choices made, in terms of making it supposedly easier for new coders, though I think the barriers for experienced coders more than make up for this advantage. For example - not handling errors in conventional ways in callbacks.

[bkniffler]

I agree. As someone who has been into coding for a long time, the codebase seems kinda confusing, and I'm pretty sure its even more confusing for new coders. Variables could have more clear names, linting/prettier could help a ton in improving consistency, and what the heck does this even do (root.now = {$:1})[as.now = at.id] = ev; :(

I mean, the whole library is absolutely genius (I think we all agree on that), but I'd love to understand better what's going on under the hood.

[mitra42]

Exactly - I can figure out that statement above, with two side-effect assignments, but it requires far more thought than necessarily, with a result that its going to get broken by someone who doesn't understand it (and certainly any code submitted to me that did that would be rejected just because its both opaque and uncommented)

[mitra42]

Note - there is one point I've come around to Mark's ideas on, and that's going back to callbacks from Promises. He said that a lot of people had told him they'd done that, I didn't believe it, but have done so myself now :-)

[steve-vincent]

I do agree with @bkniffler that a pseudo code summary of the gun.js structure (or perhaps more in-line comments) could be useful.
I started looking through gun.js to try and understand (maybe suggest enhancements) but quickly realized my web-ui javascript skills are way inadequate to understand something that elegant. :-) I aim to study it more and understand regardless...

[amark]

@bkniffler thanks for the compliments.

The code is different, yes.

• It is written from a physics/math paradigm. Best luck is to port (can be done in 30 min, several people have already done it in several hours) the protocol - but warning! The further down the rabbit hole you go, the more you discover yourself writing this type of code in the first place. ;) This is a mind thing, not a language thing.

• It is written from a Performance Testing paradigm. Despite popular brain washing by Google, transpilers and even the JIT/compiler itself don't have the same optimization according to our tests with PTSD.

I also did a talk on PANIC the other month at Internet Archive, which is the load testing & distributed systems tester.

The code is the way it is for very good reasons - I'd be happy to explain more (there might be an old old old readthesource.io podcast still around) if somebody wants to invite me to do a tech talk at a conference on it.

The good news is you don't need to hear my explanation or trust me, the numbers are what matters, and sorry I'm not gonna rewrite code (it doesn't make what the code does any simpler to understand) to something that gives end users a worse experience and would be harder for me to understand or maintain.

Closing as this isn't a bug (most bugs in people using GUN these days are actually coming from RAD, which I'd be more than happy to hand off to others even if the style is changed). Happy to have you repost this onto StackOverflow if you copy answers over (something like "Why is GUN's code so compact?" would be a good Q).