[lopatin]

It's less of a language issue and more of a framework/ecosystem issue, which is what I think the original commenter meant. The Node.js community is much more fragmented than Python. At least when it comes to web frameworks. Everyone has their own Node framework. Old ones often end up getting deprecated and neglected. So I think that's what people are referring to when they say that Node.js is an unproductive ecosystem. You end up spending way more time on the Github issues page of your framework than you would for the frameworks of other languages (Python, Go, ...) where, for the most part, the tools just work.

[pfooti]

For a kind of boring CRUD application you've got two major framwork issues: server and ORM. Node has a pretty vibrant bunch of app server libraries to choose from, ranging from simple but broadly-used (express) to highly-optimized and well-supported (hapi) to pretty esoteric (koa). There are others as well, but those three frameworks all get the job done exposing routes, templating HTML, and dealing with middleware-style abstraction layers to hook in your business logic. Personally, I dig hapi.js.

The problem with the node.js ecosystem that I see is in the ORM world. There exist ORM frameworks (waterline, bookshelf, etc), but they're a bit less actively-supported, a bit more kludgy, and that area is (subjectively to me) more likely to be a pain point. When I have issues on the back end, I end up having to write some custom SQL to fix them (which is easy enough, but hardly elegant). I rarely have framework-level problems with the stuff hapi.js is in charge of. As an example, I typically use bookshelf as a starting point for ORM stuff, but rolled my own hasmany and migrations code because I was unsatisfied with what bookshelf provided. Not a big deal, but also not standardized. I guess that may be one reason people end up using mongo - mongoose is a pretty handy library. I prefer postgres, so I'm stuck with my hybrid of raw SQL extending more generic ORM models.

I previewed sails.js a while ago when I was jumping into node from RoR (mainly so I could live in the dangerous world of websockets), and it was the all-in-one, monolithic nature of the framework that I found off-putting. Sails at the time didn't support hmabtm relationships at all, and it was going to be pretty difficult to lever in the business logic I needed to support on the back end (view permissions on both sides of the join). I ended up enjoying the decoupled app / orm framework model, since it meant I had more mix-and-match flexibility.

Ultimately, there's definitely no one true batteries included framework to do the entirety of a CRUD application in node.js (although who knows, one may emerge), but I'm enjoying the fragmentation's flipside: mix-and-match stuff, and lots of little libraries that just do one thing.

[qaq]

There is a simple reason hapi, kraken etc. are built by large entities that have complex backends and are not really calling storage layer directly from node and even if they did they would not have used ORM. So they have 0 incentive to bake it in into the framework. At the other end of the spectrum are former "front-enders" lacking background to develop decent ORM :)

[mikermcneil]

https://github.com/mikermcneil/waterline2/blob/master/Introd...

^^ after spending several man years of effort on the subject, that's the inevitable boundary in ORM development, IMHO. It was this that made me realize that we needed to be focused on providing a better, cleaner way to allow running custom queries using a declarative, database-agnostic syntax, rather than focusing on implementing even-deeper support for xD/A queries.

Also I don't mean to nitpick, but I'm hearing a lot of negativity towards Waterline from a couple of the commenters in this thread, and I'm not clear on how it lines up with specific, actionable criticism that I or the rest of the core team can do anything about. I get that having to use a framework or stack for work when you aren't excited about it is horrible (it was originally how I felt about Grails and Hibernate when I was using them every day in 2011).

But I think it's important to keep in mind that this is always "compared to what". The Java ecosystem has had years to develop tools for working with data, and it certainly still provides more mature utilities out of the box than you're going to get as someone new to the Node world, even today. But I firmly believe in the power and flexibility of JavaScript-- not because it's a good language or anything-- but because we all had to learn it to do front-end development in the browser. And so will the next generation of developers.

Whether we like it or not, Node.js is here to stay. And for me, that's a tremendously exciting thought. A future with the world sharing a common programming language is a goal worth fighting for. It's a future that dramatically lowers the barrier to entry to full stack web development, and vastly expands the pool of people willing and able to contribute to free and open-source technology.

Hang in there :)