I use Node at one of my employers, and Rails at the other.
It is much easier to switch between them than I first expected. I can quite easily use the idiomatic patterns in either framework. But there are obviously very large differences in the two stacks. The most important that come to mind:
- Rails is much more "batteries included". No need to decide what ORM, queue, mailer, remote storage, etc you want to use for the new project. You just use the built in solution. And you place the files in a pre-defined location. That makes it really easy to onboard new people, because they are familiar with the file structure. On the other hand, for Node projects, you can mix and match your components, and use simpler structures for side projects, and more complex structures (including tools like Nx) for more complicated projects.
- The Rails ORM is much more powerful than the Node counterparts. I think it helps, that the ORM is built into Rails, so everyone contributes to the same product. For Node, it feels as if there are many ORMs that are 70% done, but don't cover important cases. One of them is fast but a bit buggy, one is slow but has the ability to deal with schema migrations, one is old and works well but does not support TypeScript.
- Documentation of Node frameworks, for example NestJS, seems to be updated quicker than the Rails counterparts. For Rails, especially when Turbo was released, there was a kind of vacuum regarding the documentation. The docs for Turbo did explain the basics, but it was very very difficult to get it working with the official docs. Once blog posts started to pop up, it became much easier. Projects like Nest seem to have much more detailed documentation for their components.
All in all, I do prefer Rails tbh. The DRY principle that the framework follows makes sure that you don't have to edit 8 files when adding a new database column. This makes development much faster and in my opinion less error prone.
> Rails is much more "batteries included". No need to decide what ORM, queue, mailer, remote storage, etc you want to use for the new project. You just use the built in solution.
One important aspect of this that I think isn't well-understood in the JS ecosystem is that existence of standard "blessed" solutions means that the rest of the ecosystem can be built around them, especially tooling. With JS and Node, every time there's a new fancy framework, you have to wait for IDEs to catch up to give you any kind of convenience above and beyond just typing code. I was just looking at test frameworks the other day, and the state of IDE integration (with stuff like e.g. Test Explorer in VSCode) is appalling even for well-established ones like Mocha. Ruby guys don't have to rewrite everything every two years, so their tools tend to be much more polished in that regard.
It is much easier to switch between them than I first expected. I can quite easily use the idiomatic patterns in either framework. But there are obviously very large differences in the two stacks. The most important that come to mind:
- Rails is much more "batteries included". No need to decide what ORM, queue, mailer, remote storage, etc you want to use for the new project. You just use the built in solution. And you place the files in a pre-defined location. That makes it really easy to onboard new people, because they are familiar with the file structure. On the other hand, for Node projects, you can mix and match your components, and use simpler structures for side projects, and more complex structures (including tools like Nx) for more complicated projects.
- The Rails ORM is much more powerful than the Node counterparts. I think it helps, that the ORM is built into Rails, so everyone contributes to the same product. For Node, it feels as if there are many ORMs that are 70% done, but don't cover important cases. One of them is fast but a bit buggy, one is slow but has the ability to deal with schema migrations, one is old and works well but does not support TypeScript.
- Documentation of Node frameworks, for example NestJS, seems to be updated quicker than the Rails counterparts. For Rails, especially when Turbo was released, there was a kind of vacuum regarding the documentation. The docs for Turbo did explain the basics, but it was very very difficult to get it working with the official docs. Once blog posts started to pop up, it became much easier. Projects like Nest seem to have much more detailed documentation for their components.
All in all, I do prefer Rails tbh. The DRY principle that the framework follows makes sure that you don't have to edit 8 files when adding a new database column. This makes development much faster and in my opinion less error prone.