[juliendc]

I've a bunch of small Rails apps running on Heroku and I've to say that I'm impressed by the relevance of the new features in the latest Rails releases. Action Text, Active Storage and Action Cable are solving common and painful issues in any web app.

I've recently built a web app with Node and the time we spent solving problems which have already been solved a thousand times is astonishing. Things like picking an ORM, having a proper database migration system, running a test suite. It's actually quite depressing when you come from Rails where everything is working coherently out of the box.

The fact that there is no standards in the Node ecosystem make it a bit more painful. You have to carefully choose between many different libraries to solve your problem. Some of them are in TypeScript, other still use callbacks, etc. We basically had to glue together many libraries to get something working. All those hours could have been spent building the actual product and delivering value to our customers.

Hope they will ship many more releases!

[freehunter]

I've been trying to use NodeJS after using Rails for years and it's just such a terrible experience. I don't want to install every basic package by hand and generate every model and view and controller by hand. This is basic boilerplate nonsense that made Rails so popular 15 years ago, and NodeJS throws away every lesson we learned from Rails.

React is okay as a front-end but without a full stack framework, the current state of Javascript is like stepping back into 20 year old PHP development, where everyone just hacks together anything they can find with no structure, no convention, and no security.

[tekkk]

Like others have mentioned, this is an apple vs orange comparison. Ruby & Rails is not the same as NodeJS. A popular framework which you probably used with NodeJS is Express, that as its documentation states tries to be a minimal framework for creating NodeJS servers. I agree that something like Rails has its own benefits, but I can't really take seriously this type of complaining when it's directed at the wrong thing. You're complaining about frameworks, not NodeJS the runtime. And NodeJS is not fixed to some specific framework that forces you to do things in one way. And thank god for that.

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.

[juliendc]

I can totally relate on this.

In the end I think Rails and Node have different purposes. I would still use Node for proxy-style servers. Something with a small and focused scope which has to scale.

For business intensive apps with a large scope, Rails-like frameworks are still way more productive and robust even if they are less trendy for the moment.

The current frontend state is another story indeed. Frameworks like Ember tried to bring the same Rails-like structure to the frontend world but it isn't as popular and trendy as React for whatever reason. I think it's very costly for frontend teams to reinvent a coherent structure, convention etc for every new project. At least React has brought the same way of thinking in the frontend industry.

[martinlev]

Definitely agree with this. I have been switching from developing in ruby into Node 2 years ago as I thought this was "the new thing" for web apps. Now I just want to move away from Node. Large scale Node applications looks like 20 years ago, copy and paste all over the place, cheap libraries, no developer happiness, you have to reinvent the wheels, etc.

[burk96]

Speaking of PHP, I'm really enjoying using Laravel as of late. I'm not super experienced in web development, but the Laravel experience is my favorite so far. The Laracasts tutorial series is also top-notch. I really wish other projects had official video tutorials like them.

[specialist]

Completely differently origin stories.

nodejs is JavaScript bindings for libev. http://software.schmorp.de/pkg/libev.html

Other comments listed npm modules with Rails equivalents, so I won't repeat.

The one thing I got out of nodejs is becoming reacquainted with working closer to the metal. Minimalism for some HTTP endpoints (what the kids call REST) can be fun.

Rails, PHP, nodejs et al, J2EE, etc. I've got no dog in this fight. Each is uniquely terrible. I hate them all.

[siquick]

Have a look at Sails.js. While not perfect, its highly influenced by Rails

https://sailsjs.com/

[earthboundkid]

I basically agree, but there are some people fighting the good fight against Node's awful ecosystem.

- Parcel is like if Webpack were a build system and not a programming language to create a build system with. - Vue has good set of solutions. Nuxt is a nice version of "here's what you're probably going to want, already glued together." - If Deno ever becomes a thing, it will be cool.

It feels like maybe if we're lucky, in five years, there will be an ecosystem for modern JS that doesn't suck.

[z3t4]

It's too bad that Node.JS is mostly used as a scaffolding and glue language for web frameworks, while where it really shines is as a replacement for a systems language. You sacrifice 4x performance to get better safety, less development time, easier code, easier deployment, and a more open and friendly ecosystem.

[winrid]

You're comparing a runtime environment to a framework.

Use Angular on the client and something server side in Node and you're set.

Use Typescript and you'll be able to refactor easily too.

Nobody uses just React+Express w/o TS for something serious.

[sbmthakur]

I think it's better to compare Loopback/Express with Rails instead of NodeJS.

[ollita7]

Hi how are? Why dont you give a try on kiwi serve. Its a framewrok I develop t work with node in a better way.

You can check here www.kiwi-server.com.

Of course It's open source

[aledalgrande]

The main pain with Node, if you come from outside, is being able to know which modules are well supported, and will be for the years coming.

As an example, I spent quite a long time investigating ORM libraries for relational DBs, and the projects that were half dead were the majority.

Knex was suggested by everyone, but at that time the project leadership was changing so the future was uncertain. I settled on Sequelize, which had most of the functionality, but several points did not make sense:

- the documentation is hard to search

- I had to create a PR for sequelize-cli (separate module, that is not recommended for production!) to get the same functionality of `rails db:create`

- the syntax was changed to use Op instead of strings for security, in a minor version

- the way associations are defined is weird at best

- no support for ES6 in the cli, so all migrations are ES5

Etc.

And this is just for an API server. I looked into the frontend part and it was so much work.

I am still using Node for server processes when I have to, but I wouldn't recommend it over Rails. The way you can generate a simple app that does something useful, configure it and deploy it to Heroku in few hours is unchallenged.

[zawerf]

> know which modules are well supported, and will be for the years coming

Doesn't matter if you're coming from outside or not, no one can predict the future.

For example winston was probably the most recommended logging library (14k stars) and was a good recommendation at one point. But then they decided to do a rewrite for v3 which introduced a ton of bugs and incompatibilities. I spent several days trying to get it to log in the old format and failed and ended up downgrading back to v2.

This is a recurring theme in the js ecosystem (another example is react-router which is just a huge piece of shit and no one should depend on it despite its 37k stars).

[fyfy18]

I had this issue recently where I wanted to revive an old side project I worked on a few years ago. The front-end was written with React + Redux + Webpack, which I assumed I would still be able to get running today, but it ended up turning into dependency hell (even though there were version numbers in the package.json, npm doesn't lock to those versions?!?).

The backend was written in Go, and I just ran go build and it worked without problems. The fact that it just worked without me having to change anything shows how important backwards compatibility is to that community.

The past few weeks I've been working on a backend Typescript project, and the number of packages I've seen that don't use semver or any similar versioning system makes me cringe. I even saw one that wore this as a badge of honour in their README :s If you release a library and you don't have a sensible versioning system, you are just making life harder for your users. (I'd argue for a CHANGELOG too - the GitHub releases section doesn't count)

[lhnz]

FYI, if you want a decent Postgres client, check out `slonik` [0]. It doesn't support migrations, but there are other tools for that [1].

[0] https://github.com/gajus/slonik

[1] https://github.com/mmkal/slonik-tools

[chaostheory]

Node's main problem is that the only real dominant framework is express, a Sinatra like framework. Other than that there's so many redundant libraries and frameworks, that it's hard not to suffer from the paradox of choice, which eats up a lot of time. It's a bit easier though if you limit yourself to using Typescript based frameworks; less choices.

[truth_seeker]

Following are the alternatives :-

Action text in RoR <=> DraftJS (Isomorphic ReactJS plugin with server side rendering), Froala (compatible with most of SPA frameworks)

Active Record in RoR <=> SequelizeJS (ORM), Slonik(Non-ORM, my recommendation) in NodeJS

Action Cable in RoR <=> WS, Socket.io 2.0 (recommended)

DraftJS - https://github.com/facebook/draft-js

Froala - https://www.froala.com/wysiwyg-editor

SequelizeJS - https://sequelize.org/master/

Slonik - https://github.com/gajus/slonik

WS - https://github.com/websockets/ws

Socket.io - https://socket.io/

[Cort3z]

Node.js is not equivalent of Rails. Rails is a framework, while Node.js is a runtime. Node.js is equivalent of MRI.

[anm89]

Everybody is aware of this. The point is why would you choose the node ecosystem for any complex task when it forces you to manually solve all of the things Rails does for free. It's insane for a project of any complexity except for very specialized cases.

Put another way, you're exactly right, it is apples to oranges, or a better analogy might be a Porsche to a Pontiac. Why would you ever choose the thing which is inferior in almost every way?

[WhitneyLand]

There’a an architectural lesson to be learned/recalled here for “hardcore” developers.

I didn’t realize that Github ran mostly on Rails until this article and was kind of surprised given the scale of the site and Rails reputation for performance.

It’s a great reminder of architecture/design truism: if your site is not inherently performance bottlenecked, then you problably shouldn’t let language or framework performance be the sole deciding factor in choosing or whether to migrate to a platform. Unless we’re talking about >= order of magnitude difference, or a site whose user experience is being limited by performance. Perf and scalability are just one factor.

Pragmatism across many factors with perf/scale being one, and making yourself as blind as possible to technology religion, biases, personal investments, and digging beyond simplistic conventional wisdom (rails has perf issues), looks to remain a core ability for making arch decisions.

Experience can actually be a negative: I wouldn’t have a problem developing efficiently in node or coming up with an alternative to migrations for example.

But what I can or cannot ramp up on quickly the fastest is likely irrelevant and maybe detrimental when considering what’s best for a project as a whole.

Seeing comments here about productively gains from specific Rails features, and another comment saying they can’t imagine living without migrations as a built in feature, just seem like great reminders of how important it is to try and avoid making decisions relative to the experience or needs of only one or a few people.

It seems like good tech arch decisions need to consider DX issues enough to seem very similar to good UX decisions, the primary contrast being the users have very different stories and requirement scenarios.

[ChefboyOG]

As someone who did their first "serious" web development with Node, but has worked for the last year at a Rails shop, I still love Node for my personal projects, but much prefer Rails for anything that requires collaboration.

Ryan Dahl has a speech about his regrets with Node, and most of them center around the way code is managed.

IME, the sloppiness to how code is managed in Node, combined with the lack of conventions/dominant Rails-esque framework in the Javascript ecosystem, leads to codebases where no one is sure how or why something is set up the way it is.

As annoyed as I sometimes get with Rails' forced conventions or auto-magic abstractions, the beauty is that they are consistent. With a team full of experienced Rails engineers, you can pretty much guarantee that multiple people on your team can explain the "why" behind something quickly. This is a massive productivity save, especially when you're ramping up.

[jamil7]

My two cents is the sweet spot for node is as an auxiliarily tool rather than a whole web app framework. For instance adding some realtime functionality to an existing app, as a server renderer for SPAs or some microservice glue. The community has resisted large rails-like frameworks from the beginning and I think it just shouldn't be used this way.

[tsotpsstt]

Well, I don't believe rich text editing and websockets are that common to be included in Rails by default. I can't find any excuse for not distributing those features as separate gems. It's not that hard to add "gem actiontext" to the Gemfile and run "bundle install" if you're one of that 1-2% who needs WYSIWYG.

[freehunter]

I don't have any numbers to back it up but I believe you're wildly underestimating the number of Rails projects that need WYSIWYG editing. The state of WYSIWYG editors in Rails is so unacceptably poor that I'm glad they're bundling it out of the box. It's kind of like Microsoft making their own laptops, because every other Windows laptop of the time was undeniably junk.

[geospeck]

You can choose to skip them

  rails new app_name --skip-action-cable --skip-action-text etc...

Most of these libraries can be skipped, just type:

  rails new -h  see all the options

Edit: in case you decide later on that you need them you can install them as you described with `gem actiontext` etc...

[pmontra]

Of all the Rails projects I've been working on in the the last 15 years (all of them) probably only two needed rich text editing. One of them is the only Rails project I'm working on now. We're not changing the editor (ckeditor) but I could start a new project with the new default. I wouldn't mind installing it as a separate gem.

[hrdwdmrbl]

You're right about Node, but I think it's a bit apples to oranges because they're suited to different use-cases. Rails is great for mostly static sites. Node is great for mostly dynamic sites. It's almost as simple as that.

[cutler]

Whilst Node and Rails certainly have different niches the distinction between static and dynamic sites is lost on me. Both are written in dynamically-typed languages and both produce HTTP responses dynamically. What's the basis of your Rails = static sites assertion?

[wolco]

If the site is static you only requre html files. A server side language like Rails would only be used to create dynamic sites.