In the Ruby ecosystem, Rails will get you very far. In Python, Django will do the same. PHP –> Laravel. Scala –> Play.
JS does not have an equivalent, and the community seems to actively dislike the approach. That's fine, a monolithic framework approach isn't always the best option, but in the Node ecosystem it's not even an option on the table.
Perhaps because Express & Koa were "good enough" there never was a large enough momentum behind say SailJS to make it work. Nevertheless my experience with ORMs or scaffold generators has been that I always feel they are one custom use case away from turning from time-savers to time-sinks. When you write your own SQL and implement your own models/services or whatever abstraction you decide to use, you get a much deeper understanding of what is going on than just trusting your framework to do it for you. And is that good or bad? That is certainly a topic for debate.
This is interesting to me, because Ruby has Sinatra (and others) that compare well to Express/Koa. Python has Flask which is very popular, as well as a number of fantastic alternatives. These ecosystems have very mature, well designed, small web frameworks, but still people choose the larger frameworks in these ecosystems, and all of the frameworks get good maintenance.
I wonder if it's a cultural thing in the JS ecosystem. Maybe the ease of publishing a package creates a race to the bottom in terms of package scope, which makes it so difficult to sustain larger more all-encompassing packages.
I've worked with Ruby+Rails/Sinatra/Cuba, Python+Flask/Django/Bottle/Sanic, and Node+Express, and when I was in the Node ecosystem I sometimes really wanted that Rails/Django equivalent – not always, but the lack of it would cause me to avoid Node for large backend projects.
If you need complex relationship models, ObjectionJS sits on top and will auto-manage relationship tables and all that nasty stuff for you.
I'd echo the sentiments of the other developers here. Building a backend or full-stack app in Node is painful at every step of the journey. You're writing basically everything by hand, while using sub-standard orms and route handlers.
I've decided I like React enough to continue using it. But I'll be sticking to Rails for the backend.
It's not clear to me why people make this choice with node when after you choose it you are left to solve solved problems from scratch. Chosing node is the explicit choice to enter an ecosystem that does not have good cohesive solutions to basic problems. To do things that could be done easily with a framework like rails the very hard way.
My point was indeed that there is no real Rails equivalent in the Node ecosystem. Something mature which is supported by a large community over many years. Django, Spring Boot, Laravel, Phoenix play such a role in each of their language.
In Node you have to come with your own set of libraries, structure and convention, which is not the most efficient way to start and maintain a project. I agree that more senior programmers might avoid most of the common mistakes, but still you might spend time discussing little details such as structure and conventions. Frameworks such as Rails make at least some of those discussions irrelevant and allow you to quickly move on.
That was the entire point.
Deno is not a framework.
As in building frameworks on top of Deno, like Express/Koa/etc are built on top of Node; Node is not a framework either
There was some initial burden I admit with NodeJS but I have at least got to the productive plateau (with TypeScript). Once you figure out the pattern that works for you, it gets simpler. The inventing part is what drives most developers crazy, and it did for me too. It's perhaps too non-restrictive but well, hopefully there's somebody in your company showing you the right way. And you don't want to install every basic package by hand? But have them already included? You understand that adds quite a bit of bloat to projects that have no need for eg CORS or body-parser. And "code hacked together" is only a problem with bad programmers, you can get working and secure code with NodeJS, it just needs thought put into it. And yes, Rails has advantage with this but I think you made that argument clear.
Instead of making the argument "NodeJS is bad" you should aim that at the frameworks of NodeJS. SailJS was a good attempt at Rails but it's way too restrictive with its patterns (and sadly the documentation is not good). Deno looks promising and I hope people will be building better frameworks on top of that.