Thanks for the comment but I'm going to provide a hard rebuttal: 1) You assume t...

atombender · on Dec 5, 2015

My main point is that it's impossible to reconcile your lofty claims about Gun with, frankly, the unreadable mess you have in your repo.

It doesn't matter if your ideas are great. You keep putting Gun forward as a kind of shiny, superior successor to Riak, Cassandra and CouchDB, which I'm afraid only makes you look foolish.

You seem to have done the branding before you did the code. First you need to demonstrate solid, mature code. Then you can try competing with the big boys.

A detailed critique of your code would take a lot of effort, but I've made some notes [1]. I find the code to be unreadable and full of bad code smell. With all the mutation and callbacks and events and what not going on, it's just too hard to tell how the code is intended to flow. I don't see a clean API, even an internal one, nor I see a clean structure. It needs a lot of cleanup [2].

When talking about code, it's rarely just aesthetic. My philosophy is that if one can't even manage the trivially superficial aspects of code (formatting, structuring files, naming variables, and so on), it's not worth talking about its inner workings.

Sorry if this comes across as terribly harsh, but I hope you can see I'm trying to be constructive.

---

[1] A few examples:

* Your code is littered with arbitrary console.log() statements that have no actual utility. They look the kind of temporary logging I insert whenever I need to trace a difficult behaviour.

* No code is documented, aside from childish comments like:

    } // IT WORKS!!!!!!

* Lots of what looks like global state.

* Lots of anonymously named variables like r, u, n.

* Big chunks of commented-out code (e.g., in radix.js).

* Lots of what looks like test data. Are you telling me this is part of the project?

    rad('user/marknadal', {'#': 'asdf'});

* Lots of mutation. E.g., in s3.js you get some kind of event and then you modify the inputs.

* Syntax formatting is inconsistent and shoddy.

* require() calls in the middle of code.

* You have a test folder, but it's barely got any actual tests. You do have at least one commented-out test in the middle of everything (list.js, line 25).

[2] You may want to look into replacing callbacks with promises, and restructure it using more classical ES6-based OO, as opposed to the prototype-based, lexically-scoped style you're using now.

marknadal · on Dec 5, 2015

If we can find some common ground that we can measure I think that would help this discussion. In my previous post I proposed that we check my claims with whether gun works or not. These were my claims:

Claim 1. That gun is realtime. Claim 2. That gun is offline-first. Claim 3. That gun is a graph database. Claim 4. That gun is decentralized.

I then linked to the follow 1min video ( https://youtu.be/-i-11T5ZI9o ) to back up my claims 1&2&3. Either I am cheating/lying in the video, or gun does as I claim. Which is true?

Then, after whether the above has been verified we can move onto the next issues (which you addressed, but ignored the earlier). Next up, I would agree that GUN is not production ready and therefore wouldn't be appropriate to stack up against Riak, Cassandra, and CouchDB. I will agree with you there. But this is merely a matter of time (we're already working on a battle suite test, hopefully getting Jepsen set up, etc.) and unfortunately it is important to do evangelism while you are developing a system so you can have beta testers. We need that. So please help out! Find bugs and problems, report them. :)

Third, regarding code I don't think we'll be able to find common ground (other than the fact that we are already doing a rewrite, which suggests we agree to some degree). Why? Because I'm not one of those ES6 fan-loving Promise-everything boys. I'm not sure if you are or not, but your comment seemed suggestive of that direction. This won't lead to a fruitful discussion, because it is again a subjective view of the aesthetics of code (I find single character variables as easier to logically understand and maintain, for instance. This makes most people balk, but why? Because I am not an app developer I do not know what people are going to use the data for. I'm a tool developer, which follows more the work and lines of mathematics... `x` is a variable! It could be an integer, a float, or whatever else. This again is a personal preference so please don't downvote me for my personal coding style.)

If you choose not to use GUN because you disagree with my coding style, that is your choice and saddens me. But I will be very strong: please do not use that as an excuse to dismiss my claims. My claims can be checked and verified and I have backed them up.