[clintonb]

No, he and others used to more complete (for lack of a better term) frameworks are looking for the Django/Rails equivalent in Node.js. I got my first taste of Node.js development a few months ago (https://engineering.edx.org/serverless-984cee7797e1) and found it confusing that so much of what I take for granted in Django is kinda all over the place in Node.js. The one that stood out to me was internationalization (i18n). In Django, I mark my strings, run a couple commands to extract/compile translations, and I'm pretty much done. The most popular options for Node.js involved writing a crawler for my site. It makes no sense me that folks are writing crawlers when the static text is on the disk, marked up, waiting to be parsed.

The diversity of the Node.js ecosystem is great because there is clear change and innovation. It's bad, however, because some of that innovation is simply taking things done by other frameworks and poorly implementing them in libraries or other frameworks. The lack of general consensus potentially hurts adoption by those of us who work with Django/Rails and perpetuates the myth of the JS world changing every hour/day/week.

[always_good]

I think you're guilty of the trope that everything should be ported to Node/Javascript.

More likely is that the people who want the features of Django/Rails just use Django/Rails, so there's no goldrush to recreate them in Node nor a monolithic community around the attempts so far.

The Node ecosystem is like the Clojure ecosystem: all-inclusive frameworks just aren't as popular as library composition.

[bigtunacan]

It could just as easily be said that you are guilty of assuming all Node developers want a million tiny modules and all of the decision making overhead that goes with it.

Express is a nice small framework and is good for some things. Sometimes though you really want a monolith. If you are a Node developer there isn’t a clear choice for this.

I actually enjoy Sails, but I can see some decisions they’ve made that probably aren’t attractive to new developers (such as still using Grunt by default).

Waterline is nice as an ORM on the surface, but you run into walls as your queries become significantly complex.

[clintonb]

Nope. I want well-defined best practices that make it easy for me to focus on the real engineering challenges rather than boilerplate. The issue I have is that there are numerous, sometimes conflicting, methods of solving the same problems that, in the Django/Rails worlds have one generally-accepted solution. As I mentioned earlier, there are numerous methods of solving i18n and it isn't clear which is "the best." A framework is a potential solution to this problem. Simply getting folks to all align on supporting a few libraries is also a solution. The challenge, of course, is that my "best" isn't the same as your "best," thus we end up with conflicting solutions.