5 ms·

Why did NodeJS take off on the backend while Rails was still popular? I'll never understand it.

zarzavat 2y ago
Google hired all the best JIT engineers and set them to work on v8. If you want better performance you'd have to choose an AOT compiled language.
- Lio 2y ago
  That seems like a meme from 10 years ago. I don’t think that’s really true anymore is it? I mean Truffle Ruby is as fast as V8 already and MRI yJIT and jRuby are catching up fast. It could also be argued that JVM is the gold standard JIT. I think that shows that Google doesn’t have a monopoly on great JIT engineers.
  - masklinn 2y ago
    > I mean Truffle Ruby is as fast as V8 already v8 and node are 15 years old. That's when this actually mattered and js on the backend took off.
  - attractivechaos 2y ago
    > Truffle Ruby is as fast as V8 already and MRI yJIT and jRuby are catching up fast According to which benchmark? At my hand [1], node is ~60% faster than TruffleRuby and over an order of magnitude faster than yjit v3.3.0. [1] https://github.com/attractivechaos/plb2?tab=readme-ov-file#appendix-timing-on-apple-m1-macbook-pro https://github.com/attractivechaos/plb2?tab=readme-ov-file#a...
- neonsunset 2y ago
  OpenJDK HotSpot and .NET RyuJIT both produce much faster code :) And the latter lets you operate on the same level of abstraction as Rust and C++ compilers do.
  - dismalaf 2y ago
    > OpenJDK HotSpot and .NET RyuJIT both produce much faster code :) For dynamic languages? Stuff like Clojure, JRuby, Boo, are definitely not faster than V8 JavaScript...
- petre 2y ago
  Google also made Dart which is better than Js in every regard.
fastball 2y ago
Using the same language to write your frontend and backend is desirable for many people / teams.
- t-writescode 2y ago
  To add, front-end developers and other people that learned in Javascript (because a web browser is something everyone has, turns out it's a pretty great runtime environment, has live editing with dev tools, etc. It's honestly a fantastic way to 'get into programming) could write the icky backend code to make their slick websites, SPAs and games have internet-based savestate
- malthaus 2y ago
  but why does that language have to be one as braindead as javascript. path-dependency is the root of all evil.
  - fastball 2y ago
    Because nobody championed another language for the browser. Good news is we have WASM now, so you can write backend and frontend code in basically whatever language you want.
briandear 2y ago
Because of the JavaScript Everywhere crowd. When you have a hammer, everything looks like a problem for JavaScript.
- psychoslave 2y ago
  To be fair, js interpreters are available out of the box in all digital devices out there that embed a browser. That's a huge deal, as far as portability is concerned. That said you do have things like https://opalrb.com/ https://opalrb.com/
- wiseowise 2y ago
  God forbid we reuse knowledge instead of drudging lives through never ending learning of same concepts with different syntax’s and 10x costs for supporting every special native snowflake toolchain.
  - ericb 2y ago
    If that's the goal, the problem itself has been re-implemented by the Javascript ecosystem.
  - xigoi 2y ago
    That’s why you use a language where the build tool of choice changes every month?
  - blandflakes 2y ago
    And of course the right way to do that is to take an extremely mediocre, rushed, incomplete language that is currently constrained to the browser, and make it run everywhere else, ironically having to reinvent many wheels and re-learn very old lessons the hard way along the way. Mission "reuse knowledge" is a hearty failure in node.js-land.
    - deleted 2y ago
      [deleted]
  - never_inline 2y ago
Tainnor 2y ago
nonblocking IO
ninkendo 2y ago
People say frontend/backend parity, and that’s true, but I also remember there was a time in 2011 or so where single thread/async was this new hot thing. Nginx was starting to get popular and overtake Apache on installs, and people were enamored with its performance and idea of “no blocking, ever” and “callbacks for everything”, which the nginx codebase sorta takes to the extreme. The c10k problem and all that. When JavaScript got a good engine in v8, Node was lauded as this way to do what nginx was doing, but automatically and by default: you simply couldn’t write blocking code so waiting on I/O will never bottleneck your incoming connections. Maximum concurrency because your web server could go right back to serving the next request concurrently while any I/O was happening. But no “real” multithreading so you didn’t have to worry about mutexes or anything. I remember being slightly jealous of that as a Rails developer, because webrick/unicorn/etc had a worker pool and every worker could only handle one request at a time, and fixing that could only happen if everything was async, which it basically wasn’t. JavaScript becoming a popular language in its own right due to frontend was certainly the most important factor, but it wasn’t the only one.
- loloquwowndueo 2y ago
  “Node makes it impossible to write blocking code” reminds me of this classic and hilarious piece by Ted Dziuba: http://widgetsandshit.com/teddziuba/2011/10/node-js-is-cancer.html http://widgetsandshit.com/teddziuba/2011/10/node-js-is-cance...
  - petre 2y ago
    Heh, he's so right in every regard although I use Node. Worst of all, they made npm packages dead easy, so most of them don't even have a readme file, not to mention inline docs like POD or RDoc. This is how you end up with spam pacakges, malware in npm and lpad disasters.
    - Vaguely2178 2y ago
      > most of them don't even have a readme file Given the popularity of Github, and the fact that a readme file is the first thing you see when pulling up a project on Github, most projects these days do in fact have readme files. > inline docs like POD or RDoc JSDoc is relatively popular.
syockit 2y ago
Because Node.js is the most bad ass rock star tech to come out, since Ruby on Rails.
mrcwinn 2y ago
Because it’s not as good. Why would I want two languages and two runtimes when I can just have one, all while delivering a demonstrably better user experience?
gedy 2y ago
Rails wants to be the UI framework, and a lot of devs didn't want to do server side UI and state, especially OOP style. So it was easier to do JS for your APIs, etc. DHH's opinions kind of made it an all or nothing choice for many folks.
Zanfa 2y ago
Node is web scale.

Google hired all the best JIT engineers and set them to work on v8. If you want better performance you'd have to choose an AOT compiled language.

Lio 2y ago
That seems like a meme from 10 years ago. I don’t think that’s really true anymore is it? I mean Truffle Ruby is as fast as V8 already and MRI yJIT and jRuby are catching up fast. It could also be argued that JVM is the gold standard JIT. I think that shows that Google doesn’t have a monopoly on great JIT engineers.
- masklinn 2y ago
  > I mean Truffle Ruby is as fast as V8 already v8 and node are 15 years old. That's when this actually mattered and js on the backend took off.
- attractivechaos 2y ago
  > Truffle Ruby is as fast as V8 already and MRI yJIT and jRuby are catching up fast According to which benchmark? At my hand [1], node is ~60% faster than TruffleRuby and over an order of magnitude faster than yjit v3.3.0. [1] https://github.com/attractivechaos/plb2?tab=readme-ov-file#appendix-timing-on-apple-m1-macbook-pro https://github.com/attractivechaos/plb2?tab=readme-ov-file#a...
neonsunset 2y ago
OpenJDK HotSpot and .NET RyuJIT both produce much faster code :) And the latter lets you operate on the same level of abstraction as Rust and C++ compilers do.
- dismalaf 2y ago
  > OpenJDK HotSpot and .NET RyuJIT both produce much faster code :) For dynamic languages? Stuff like Clojure, JRuby, Boo, are definitely not faster than V8 JavaScript...
petre 2y ago
Google also made Dart which is better than Js in every regard.

fastball 2y ago

Using the same language to write your frontend and backend is desirable for many people / teams.

t-writescode 2y ago
To add, front-end developers and other people that learned in Javascript (because a web browser is something everyone has, turns out it's a pretty great runtime environment, has live editing with dev tools, etc. It's honestly a fantastic way to 'get into programming) could write the icky backend code to make their slick websites, SPAs and games have internet-based savestate
malthaus 2y ago
but why does that language have to be one as braindead as javascript. path-dependency is the root of all evil.
- fastball 2y ago
  Because nobody championed another language for the browser. Good news is we have WASM now, so you can write backend and frontend code in basically whatever language you want.

briandear 2y ago

Because of the JavaScript Everywhere crowd. When you have a hammer, everything looks like a problem for JavaScript.

psychoslave 2y ago
To be fair, js interpreters are available out of the box in all digital devices out there that embed a browser. That's a huge deal, as far as portability is concerned. That said you do have things like https://opalrb.com/ https://opalrb.com/
wiseowise 2y ago
God forbid we reuse knowledge instead of drudging lives through never ending learning of same concepts with different syntax’s and 10x costs for supporting every special native snowflake toolchain.
- ericb 2y ago
  If that's the goal, the problem itself has been re-implemented by the Javascript ecosystem.
- xigoi 2y ago
  That’s why you use a language where the build tool of choice changes every month?
- blandflakes 2y ago
  And of course the right way to do that is to take an extremely mediocre, rushed, incomplete language that is currently constrained to the browser, and make it run everywhere else, ironically having to reinvent many wheels and re-learn very old lessons the hard way along the way. Mission "reuse knowledge" is a hearty failure in node.js-land.
  - deleted 2y ago
    [deleted]
- never_inline 2y ago

Tainnor 2y ago

nonblocking IO

ninkendo 2y ago

People say frontend/backend parity, and that’s true, but I also remember there was a time in 2011 or so where single thread/async was this new hot thing. Nginx was starting to get popular and overtake Apache on installs, and people were enamored with its performance and idea of “no blocking, ever” and “callbacks for everything”, which the nginx codebase sorta takes to the extreme. The c10k problem and all that. When JavaScript got a good engine in v8, Node was lauded as this way to do what nginx was doing, but automatically and by default: you simply couldn’t write blocking code so waiting on I/O will never bottleneck your incoming connections. Maximum concurrency because your web server could go right back to serving the next request concurrently while any I/O was happening. But no “real” multithreading so you didn’t have to worry about mutexes or anything. I remember being slightly jealous of that as a Rails developer, because webrick/unicorn/etc had a worker pool and every worker could only handle one request at a time, and fixing that could only happen if everything was async, which it basically wasn’t. JavaScript becoming a popular language in its own right due to frontend was certainly the most important factor, but it wasn’t the only one.

loloquwowndueo 2y ago
“Node makes it impossible to write blocking code” reminds me of this classic and hilarious piece by Ted Dziuba: http://widgetsandshit.com/teddziuba/2011/10/node-js-is-cancer.html http://widgetsandshit.com/teddziuba/2011/10/node-js-is-cance...
- petre 2y ago
  Heh, he's so right in every regard although I use Node. Worst of all, they made npm packages dead easy, so most of them don't even have a readme file, not to mention inline docs like POD or RDoc. This is how you end up with spam pacakges, malware in npm and lpad disasters.
  - Vaguely2178 2y ago
    > most of them don't even have a readme file Given the popularity of Github, and the fact that a readme file is the first thing you see when pulling up a project on Github, most projects these days do in fact have readme files. > inline docs like POD or RDoc JSDoc is relatively popular.

syockit 2y ago

Because Node.js is the most bad ass rock star tech to come out, since Ruby on Rails.

mrcwinn 2y ago

Because it’s not as good. Why would I want two languages and two runtimes when I can just have one, all while delivering a demonstrably better user experience?

gedy 2y ago

Rails wants to be the UI framework, and a lot of devs didn't want to do server side UI and state, especially OOP style. So it was easier to do JS for your APIs, etc. DHH's opinions kind of made it an all or nothing choice for many folks.

Zanfa 2y ago

Node is web scale.