5 ms·

I think the only new thing that node.js brought to the table was a nice way to run Javascript on the server. Node.js doesn't use threads, but as you said, their

I think the only new thing that node.js brought to the table was a nice way to run Javascript on the server. Node.js doesn't use threads, but as you said, their event-driven non-blocking I/O model wasn't new (Python had Twisted and Java had Netty). In addition, Java has had non-blocking I/O (in the form of the nio) packages for quite some time. In my opinion, Node.js became popular because people wanted to run Javascript in a server environment.

sporkland 9y ago
I remember distinctly at the time that the fact that there was excitement around node.js because it was built from the ground up to use evented IO exclusively. All the libraries, the core runtime etc. People in other languages (C) were for sure doing it, but not in the holistic way node was. As opposed to java and python where you needed to avoid using the library calls that were blocking.
- cmiles74 9y ago
  Fair enough, I agree that Node.js uses the evented model (AFAIK) almost exclusively. Still, the evented model is not unique to Node.js nor did they invent it. In my opinion, it was the dedication of Javascript developers and their reluctance to use another language that popularized this model: they had no choice.
  - sporkland 9y ago
    Yeah. Ryan Dahl was pretty clear at the time that he was inspired by people using C and achieving really high connection counts on single machines. So he for sure was inspired by others, and obviously built off the same foundations in the kernel. At some point Isomorphic Javascript became the main reason to use it, as golang has largely stolen the non-blocking IO crown with its implementation of green threads.
z3t4 9y ago
You can write JavaScript in classic ASP, there are many server JavaScript, but they are serial/blocking, and NodeJS is async/non blocking.
AgentME 9y ago
>Node.js doesn't use threads, but as you said, their event-driven non-blocking I/O model wasn't new (Python had Twisted and Java had Netty). The new thing that it brought was an entire environment that used non-blocking I/O exclusively without any pre-existing thread-based code and libraries. With node.js, you don't have to wonder if a library you want to adopt supports non-blocking I/O.
- disordinary 9y ago
  That's exactly the point and what people are missing. If you used Twisted you didn't have access to the entire Python ecosystem and there was a lot of work that was required to get standard packages to work in a non blocking way. Also callbacks for all that they're derided now were an easy paradigm to understand to get into the whole philosophy of async. The first prototypes of node supported different paradigms before callbacks were settled on IIRC.
bryanrasmussen 9y ago
There were lots of ways to run JavaScript on the server before Node, however all the ways I am familiar with suffered from having either poor support, poor performance, or being marginally difficult to get to work. JavaScript on the server before Node was a second-class solution. On edit: so yeah, a nice way.

sporkland 9y ago

I remember distinctly at the time that the fact that there was excitement around node.js because it was built from the ground up to use evented IO exclusively. All the libraries, the core runtime etc. People in other languages (C) were for sure doing it, but not in the holistic way node was. As opposed to java and python where you needed to avoid using the library calls that were blocking.

cmiles74 9y ago
Fair enough, I agree that Node.js uses the evented model (AFAIK) almost exclusively. Still, the evented model is not unique to Node.js nor did they invent it. In my opinion, it was the dedication of Javascript developers and their reluctance to use another language that popularized this model: they had no choice.
- sporkland 9y ago
  Yeah. Ryan Dahl was pretty clear at the time that he was inspired by people using C and achieving really high connection counts on single machines. So he for sure was inspired by others, and obviously built off the same foundations in the kernel. At some point Isomorphic Javascript became the main reason to use it, as golang has largely stolen the non-blocking IO crown with its implementation of green threads.

z3t4 9y ago

You can write JavaScript in classic ASP, there are many server JavaScript, but they are serial/blocking, and NodeJS is async/non blocking.

AgentME 9y ago

>Node.js doesn't use threads, but as you said, their event-driven non-blocking I/O model wasn't new (Python had Twisted and Java had Netty). The new thing that it brought was an entire environment that used non-blocking I/O exclusively without any pre-existing thread-based code and libraries. With node.js, you don't have to wonder if a library you want to adopt supports non-blocking I/O.

disordinary 9y ago
That's exactly the point and what people are missing. If you used Twisted you didn't have access to the entire Python ecosystem and there was a lot of work that was required to get standard packages to work in a non blocking way. Also callbacks for all that they're derided now were an easy paradigm to understand to get into the whole philosophy of async. The first prototypes of node supported different paradigms before callbacks were settled on IIRC.

bryanrasmussen 9y ago

There were lots of ways to run JavaScript on the server before Node, however all the ways I am familiar with suffered from having either poor support, poor performance, or being marginally difficult to get to work. JavaScript on the server before Node was a second-class solution. On edit: so yeah, a nice way.