Node v4.0.0 - Hackdot

Re:Node v4.0.0 by AdieuToLogic on Thursday September 10, 2015 @12:34AM (#10196161)

With utmost respect, I respond to each point you mention below.

  The JS of 2009 was an entirely different language
  from the JS Netscape originally created. Plus
  Netscape's web server was an evolutionary dead end
  and a proprietary closed-source product.

The reason I cited Netscape's server was to unequivocally show that NodeJS did not introduce JavaScript to "a new environment" as the GP stated. Why previous efforts failed to gain traction or if it is even a good idea to use JavaScript to define server-side logic is left as an exercise to the reader.

  Node was in part influenced by CommonJS, which
  tried to unify the various competing but
  relatively obscure (mostly non-browser) JS
  environments. To say that it learned nothing
  from the history of SSJS (or JS environments
  in general) is, frankly, wrong.

It would seem we have differing perspectives of history. CommonJS was started in 2009[1], the same year as NodeJS[2]. The lessons of history I implied regarded attempts to use JavaScript as a server-side solution over the past 20-ish years. While you make the distinction:

  Node lets you write application servers,
  Netscape's SSJS effectively was more like
  Rhino-meets-JSP or maybe GWT (i.e. the heavy
  lifting was apparently implemented in Java,
  not JS).

I suggest that this is irrelevant, as the details of how the JavaScript logic is executed is orthogonal from the fact that systems such as these use JavaScript to define behaviour itself. The fact remains that there have been more than one previous project/offering/effort which had JavaScript as a key component. IMHO, it behooves interested parties to do whatever postmortem examinations possible before committing to the same or significantly similar path.

1 - https://en.wikipedia.org/wiki/CommonJS

2 - https://en.wikipedia.org/wiki/Node.js

[ Parent | on HN ]

Re:Node v4.0.0 by pluma on Thursday September 10, 2015 @06:46AM (#10197240)

I don't think how Netscape's SSJS worked is irrelevant at all. There is a huge difference[0] between Node as a JS environment for writing applications and Netscape's SSJS as an environment for writing "server pages".

Node is for writing small standalone services. Netscape's SSJS was for creating dynamic web pages -- just like CGI scripts or (at the time) PHP.

SSJS may be considered prior art for "JS on the server" but it's barely recognizable. As far as I can tell the execution was entirely synchronous; but Node is defined by its evented -- and therefore asynchronous -- I/O. It's a data point for comparison but it's not a good lesson to learn from, other than what not to do.

A lot of the shortcomings of Node come from the limitations of JS at the time. Callbacks and streams (arguably two of the biggest issues with Node) are a result of Node being asynchronous. At the time, event listeners and callbacks were the best tool JS offered and the best thing the JS community had.

I can only imagine you're trying to say that Node should have taken more inspiration from other languages that solve problems better (like gradual typing, or the Maybe monad or the actor model). But none of this has anything to do with Netscape's SSJS.

You explicitly point out Netscape's SSJS as a part of history Node should have learned from. What specifically do you think Node should have learned from it? Are you just trying to say "SSJS is a bad idea (because Netscape's SSJS was bad) and shouldn't have been attempted again, even in an entirely different way"?

[0]: http://stackoverflow.com/questions/18350910/netscape-enterpr...

[ Parent | on HN ]