4 ms·

What you're missing (at least with Node.js/Javascript) is that Node does not aim to be Rails. Node doesn't aim to have one correct way of doing one thing as Rai

What you're missing (at least with Node.js/Javascript) is that Node does not aim to be Rails. Node doesn't aim to have one correct way of doing one thing as Rails often does. Yes, there are best practices, but Node aims to give the developer the freedom to do things as they need to. The result of this is that, yes, development of your standard CRUD app is probably not as fast as it would be with Rails. Also, moving from project to project is not as easy as it would be with Rails. But the advantage is that, if you have good developers who are good at architecting (a big if), you architecture will better reflect the problem at hand.

erikpukinskis 10y ago
No, I'm aware of that. I love Node and npm and UNIX and I use only small single purpose modules and its amazing. But I am effectively a research engineer. And honestly, if you want your company to run on Node, you need to be a research engineer too, because "which infrastructure should we use?" is an open question in the world you describe. Compare to Rails, where you start of with OK infrastructure by default. That's not better, it just means you can hire a random person off the street and they're on the same page as you. If you want to keep a team of 50 JavaScript developers on the same page you need a really strong culture. Or just say "Use Ember and Express, end of story". But at that point you no longer have the "developer freedom" you correctly cite as the core selling point of Node. And by "on the same page" I mean "we both have a similar understanding of a sensible default way to transport persist text fields from an HTML form". Put 10 JavaScript programmers in a room and you'll get 8 different approaches.
wtbob 10y ago
> Node doesn't aim to have one correct way of doing one thing as Rails often does. Or any correct way of doing one thing, starting with the language (JavaScript) and moving on from there …
matwood 10y ago
> The result of this is that, yes, development of your standard CRUD app is probably not as fast as it would be with Rails. Also, moving from project to project is not as easy as it would be with Rails. But the advantage is that, if you have good developers who are good at architecting (a big if), you architecture will better reflect the problem at hand. And if you just want something to work quickly, Rails wins. JS encourages developers to spend days and weeks on picking each part of a framework for an MVP that may go nowhere. Rails is no longer the new shiny and it has moved into the 'get shit done' category of developer tools.

erikpukinskis 10y ago

No, I'm aware of that. I love Node and npm and UNIX and I use only small single purpose modules and its amazing. But I am effectively a research engineer. And honestly, if you want your company to run on Node, you need to be a research engineer too, because "which infrastructure should we use?" is an open question in the world you describe. Compare to Rails, where you start of with OK infrastructure by default. That's not better, it just means you can hire a random person off the street and they're on the same page as you. If you want to keep a team of 50 JavaScript developers on the same page you need a really strong culture. Or just say "Use Ember and Express, end of story". But at that point you no longer have the "developer freedom" you correctly cite as the core selling point of Node. And by "on the same page" I mean "we both have a similar understanding of a sensible default way to transport persist text fields from an HTML form". Put 10 JavaScript programmers in a room and you'll get 8 different approaches.

wtbob 10y ago

> Node doesn't aim to have one correct way of doing one thing as Rails often does. Or any correct way of doing one thing, starting with the language (JavaScript) and moving on from there …

matwood 10y ago

> The result of this is that, yes, development of your standard CRUD app is probably not as fast as it would be with Rails. Also, moving from project to project is not as easy as it would be with Rails. But the advantage is that, if you have good developers who are good at architecting (a big if), you architecture will better reflect the problem at hand. And if you just want something to work quickly, Rails wins. JS encourages developers to spend days and weeks on picking each part of a framework for an MVP that may go nowhere. Rails is no longer the new shiny and it has moved into the 'get shit done' category of developer tools.