8 ms·

I believe part of the reason Node got popular was because of two reasons 1. V8, which is actually really fast 2. Hype around being _asynchronous_ at the time

I believe part of the reason Node got popular was because of two reasons 1. V8, which is actually really fast 2. Hype around being _asynchronous_ at the time JS itself started to become more hyped up.

Klonoar 4y ago
Asynchronous, and Node being so HTTP-friendly - I cannot begin to explain the sheer number of regurgitated "build a webserver in Node" tutorials that got written up back in the day. For whatever reason, you could have done this stuff in Rhino - for better or for worse - it's just that nobody ever took it as seriously.
- saurik 4y ago
  Not only could you, but some of us even did (though it definitely was never, as you say, "taken seriously"). What made it super powerful (and very node.js-like) was combining it with Jetty, which was a servlet engine that could be used as a library. My (trivial, personal blog) website is still running with this stack (though I finally put it behind an nginx SSL terminator as I have been putting off upgrading Java and Bouncy Castle just couldn't keep up), and it gives me more warm fuzzies than v8 alternatives. A "people actually used this" framework that had Rhino at its core (well, in one of many ways of using it) was Apache Cocoon (which was maybe more by-default based in XSL/T), only they did something almost ridiculously clever: as Rhino had full support for continuations, they didn't need "callback hell" (or async/await) and could even support pseudo-synchronous code that could block on the user (such as a function which sent the user a form and returned the user's selection, possibly hours later) by storing the continuation state in the user's session.
  - Klonoar 4y ago
    >A "people actually used this" framework that had Rhino at its core (well, in one of many ways of using it) was Apache Cocoon (which was maybe more by-default based in XSL/T), only they did something almost ridiculously clever: as Rhino had full support for continuations, they didn't need "callback hell" (or async/await) and could even support pseudo-synchronous code that could block on the user (such as a function which sent the user a form and returned the user's selection, possibly hours later) by storing the continuation state in the user's session. Wow! I'd only dabbled in Rhino back in the day so this is a neat little bit of history. Teleports me back to when this stuff felt fun...
- neurostimulant 4y ago
  I think it's due to the huge hype around chrome among developers back then. Each tab as separate process was huge. It also has built-in dev tool, and v8 being actually fast excites a lot of devs and drove them away from firefox. So when nodejs was released, a lot of people already know what v8 is and have positive impression of it, probably enough to nudge them to try nodejs. On the other hand, I never heard of Rhino until now.
bin_bash 4y ago
And npm. I don’t think Rhino had a good story for dependency management.
- emn13 4y ago
  I think you've hit the nail on the head; npm was the real killer app - it makes it very easy to try out node and result in a real, usable app with very little code nor (visible) complexity.
  - moffkalast 4y ago
    npm is what pip could've been if wasn't mismanaged into oblivion.
    - MereInterest 4y ago
      As someone who hasn't used npm beyond toy projects, what major features does it have that pip doesn't have?
      - matsemann 4y ago
        Installs in a local folder to the project (node_modules) instead of pip which installs packages to the global python installation unless ran in a virtual env. So getting anything up and running is trivial, compared to the amount of installations and steps needed with pip, unless you wanna bork your global python installation. With npm it's also really easy (almost too easy) to take your current folder and push it to npm, making the ecosystem bloom with packages.
        goodoldneon 4y ago
        The virtual env thing is extra friction but isn’t terrible: $ python -m venv .venv $ source .venv/bin/activate $ pip install -r requirements.txt Most IDEs will automatically pick up the .venv folder
j45 4y ago
v8 was huge was fast but the CLI was a big deal too
brightball 4y ago
When Node first came out, all of the hype around it was using the same language on the client and the server OR at least managing all of your frontend bits in a language independent of your server side language. At the time, there were JS/CSS/image minifiers in just about every language IIRC. Doing it with Node was a stronger argument to at least save the frontend side of the house from having to find a way to do them with Java or ASP. During that time period, Java compile times were so slow that using PHP as a frontend that spoke to Java backends with SOAP services was really, really common just to avoid slowing everything on the frontend down with Java.
zokier 4y ago
For context, the thing preceding nodejs in the hype cycle was ruby on rails. While many great things could be said about RoR, performance definitely is not one of them, especially in the early days.
- pragmatic 4y ago
  I love having to run a sentinel app that would restart your app on crashes. I forget the details but RoR was a deployment catastrophe.

Klonoar 4y ago

Asynchronous, and Node being so HTTP-friendly - I cannot begin to explain the sheer number of regurgitated "build a webserver in Node" tutorials that got written up back in the day. For whatever reason, you could have done this stuff in Rhino - for better or for worse - it's just that nobody ever took it as seriously.

saurik 4y ago
Not only could you, but some of us even did (though it definitely was never, as you say, "taken seriously"). What made it super powerful (and very node.js-like) was combining it with Jetty, which was a servlet engine that could be used as a library. My (trivial, personal blog) website is still running with this stack (though I finally put it behind an nginx SSL terminator as I have been putting off upgrading Java and Bouncy Castle just couldn't keep up), and it gives me more warm fuzzies than v8 alternatives. A "people actually used this" framework that had Rhino at its core (well, in one of many ways of using it) was Apache Cocoon (which was maybe more by-default based in XSL/T), only they did something almost ridiculously clever: as Rhino had full support for continuations, they didn't need "callback hell" (or async/await) and could even support pseudo-synchronous code that could block on the user (such as a function which sent the user a form and returned the user's selection, possibly hours later) by storing the continuation state in the user's session.
- Klonoar 4y ago
  >A "people actually used this" framework that had Rhino at its core (well, in one of many ways of using it) was Apache Cocoon (which was maybe more by-default based in XSL/T), only they did something almost ridiculously clever: as Rhino had full support for continuations, they didn't need "callback hell" (or async/await) and could even support pseudo-synchronous code that could block on the user (such as a function which sent the user a form and returned the user's selection, possibly hours later) by storing the continuation state in the user's session. Wow! I'd only dabbled in Rhino back in the day so this is a neat little bit of history. Teleports me back to when this stuff felt fun...
neurostimulant 4y ago
I think it's due to the huge hype around chrome among developers back then. Each tab as separate process was huge. It also has built-in dev tool, and v8 being actually fast excites a lot of devs and drove them away from firefox. So when nodejs was released, a lot of people already know what v8 is and have positive impression of it, probably enough to nudge them to try nodejs. On the other hand, I never heard of Rhino until now.

bin_bash 4y ago

And npm. I don’t think Rhino had a good story for dependency management.

emn13 4y ago
I think you've hit the nail on the head; npm was the real killer app - it makes it very easy to try out node and result in a real, usable app with very little code nor (visible) complexity.
- moffkalast 4y ago
  npm is what pip could've been if wasn't mismanaged into oblivion.
  - MereInterest 4y ago
    As someone who hasn't used npm beyond toy projects, what major features does it have that pip doesn't have?
    - matsemann 4y ago
      Installs in a local folder to the project (node_modules) instead of pip which installs packages to the global python installation unless ran in a virtual env. So getting anything up and running is trivial, compared to the amount of installations and steps needed with pip, unless you wanna bork your global python installation. With npm it's also really easy (almost too easy) to take your current folder and push it to npm, making the ecosystem bloom with packages.
      - goodoldneon 4y ago
        The virtual env thing is extra friction but isn’t terrible: $ python -m venv .venv $ source .venv/bin/activate $ pip install -r requirements.txt Most IDEs will automatically pick up the .venv folder

j45 4y ago

v8 was huge was fast but the CLI was a big deal too

brightball 4y ago

When Node first came out, all of the hype around it was using the same language on the client and the server OR at least managing all of your frontend bits in a language independent of your server side language. At the time, there were JS/CSS/image minifiers in just about every language IIRC. Doing it with Node was a stronger argument to at least save the frontend side of the house from having to find a way to do them with Java or ASP. During that time period, Java compile times were so slow that using PHP as a frontend that spoke to Java backends with SOAP services was really, really common just to avoid slowing everything on the frontend down with Java.

zokier 4y ago

For context, the thing preceding nodejs in the hype cycle was ruby on rails. While many great things could be said about RoR, performance definitely is not one of them, especially in the early days.

pragmatic 4y ago
I love having to run a sentinel app that would restart your app on crashes. I forget the details but RoR was a deployment catastrophe.