[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.