Hacker News Reader

Comment by untog | Hacker News Reader

I mean, Ruby was created in 1995, Python in 1991. Node was first released in 2009. That's not an entirely fair comparison since, of course, JavaScript was created long before Node, but Node introduced the language to a new environment, and a lot of complications needed (and in some cases, still need) to be sorted out.

As for no recommend approach - that's deliberate. I don't think most people working on Node want a Rails equivalent.

View on HN

> As for no recommend approach - that's deliberate. I don't think most people working on Node want a Rails equivalent

This is a useful way to understand what Node is. Node's core API is for building any sort of network service: A DNS server, an SMTP server, HTTP server, socket listener, etc. and so it applies to a wide and varied set of problems. Rails is for building a very specific type of database-backed web application.

Exactly. I don't think Node is a good fit for monolithic CRUD apps. These are already solved problems in various other languages. Instead Node lets you compose small purpose-built modules.

Now out only problem is how to build decoupled/distributed micro services.

I'd argue only Erlang and Elixir are going to survive into the multi core multi server future, but that would be little more than a slightly educated opinion unless I take the time to write a very large explanation with cited references. I don't have time for that this week.

We are an (almost) completely node.js team and are having quite a bit of success using it for microservices. gRPC makes communication fast and easy, while Docker and Kubernetes make deployment and composition just as simple.

Personally I prefer having a monolithic app at the core and using Node as the glue to tie everything together (e.g. to provide "real-time" features or to integrate third party services).

I think what's holding Erlang back is mostly its rather obscure syntax. Only a mother could love that.

I agree - I think I could get away with arguing that Ruby became popular because of Rails (that may not be completely true, but I and a lot of other devs I know learned about ruby because of rails at least). Node, OTOH, has no central framework that people learn of and then say, "oh, I have to learn node to use XYZ".

There are plenty of libraries that provide whatever level of support you want, but one big reason people seem to use Node is for the ease of the DIY process. Honestly, I don't need an all-in-one system, because my system has needs that aren't easily modeled in ActiveRecord (or at least weren't during Rails 3 days when I moved over to Node). Instead, I am doing mix-and-match with smaller libraries to help database access, realtime (websocket) services, OAUTH, and a trad REST backend.

I also think it's fair to compare the release of node and the release date of ruby or python - it was really only then that we can start talking about needing frameworks for building web applications that run in the javascript language, whereas the other two languages could have done so right away (or ... later, once the web application world became more than just a cgi gateway on top of a c++ stack, like the lunch menu randomizer I had running back in 1995). Still, no matter how you slice it, node and server-side javascript are still relatively new on the scene, and not necessarily well-suited for an all-in-wonder, highly-opinionated framework.

> ... Ruby was created in 1995, Python in 1991. Node was first released in 2009. That's not an entirely fair comparison since, of course, JavaScript was created long before Node, but Node introduced the language to a new environment...

Actually, no, it didn't. JavaScript was first introduced "on the server side" about 20 years ago in the Netscape web server[1].

  We learn from history that we learn nothing
  from history.

  George Bernard Shaw[2]

1 - http://docs.oracle.com/cd/E19957-01/816-6411-10/getstart.htm

2 - http://www.wisdomquotes.com/quote/george-bernard-shaw-19.htm...

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.

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.

That said, Netscape's SSJS is entirely unrelated to Node or anything like it[0]. 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).

[0]: http://docs.oracle.com/cd/E19957-01/816-6411-10/jsserv.htm

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

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...

Sure, and after that we had Rhino and Adobe has been using JavaScript for a very long time as a scripting language (ExtendScript) and there are probably many other examples of JavaScript outside of a browser. But I don't see what that has to do with untog's main point.

I saw "untog"'s post as having two points, to which I responded to the former. You identify the latter point as being the main one and that's perfectly fine.

Just different importance discerned from the same post IMHO.

How long have you been waiting to use this pedantic comment and the obnoxious condescending quote about it to prove someone wrong and make yourself feel smart?

This has nothing to do with the parent comment about node deliberately differing from rails, it's typical hn/reddit pedantry.

Living up to his username.

I believe that Node can and will become more stable. It feels like it has too much momentum not to. But until it does achieve stability, it's difficult to use it for anything serious without investing a lot of time into it.

Perhaps Go is a better comparison than Ruby and Python.

it's difficult to use it for anything serious without investing a lot of time into it.

Isn't that true for many platforms?

Either way, I have multiple apps running Node in production, and I've never had the issues described. You don't have to be as breakneck as Node itself - some things I have are still running v0.10x just fine.

> Isn't that true for many platforms?

I would say that the ROI is lower for time spent learning Node. I've found that with all the other languages I've learnt, in a couple of days I've been able to build something useful, leave it running in production and reuse skills learned a year later.

With Node, even the name of the language is not stable! A few weeks back I went to install Zombie, and now I have to install iojs and not Node. Assumedly it's now Node again. If you live and breathe the language, subscribe to the mailing lists, go to the meetups, etc, these things might be obvious. But when you're just dipping in and out, it really dents your confidence in the language.

Your latter paragraph seems a bit fuddy as people 'just dipping in and out' would never have to have contended with the iojs 'name' any more than Python/Ruby/PHP people have to switch to a different VM every time one is announced (e.g. PyPy/Rubinius/Hack).

I'd agree with your first paragraph in that Node is a bit lower-level out of the box and probably takes more effort to get started building a web-app, but I think the time invested jumping in at that low-level is actually useful vs diving in at a higher 'framework level' with some of the other popular web languages.

Also it does have superior installer/package-manager/deployment stories compared to say ... Python & Django, which does have an impact on ROI.

> Your latter paragraph seems a bit fuddy as people 'just dipping in and out' would never have to have contended with the iojs 'name' any more than Python/Ruby/PHP people have to switch to a different VM every time one is announced (e.g. PyPy/Rubinius/Hack).

One of my main use cases for Node is Zombie, and that required io.js after v3. No mainstream PHP, Ruby or Python application has required a different interpreter.

Sounds to me like your issue is with the author of Zombie.

Actually it's with jsdom, Zombie's major dependency which dropped Node support pretty soon after IOjs was released.

That sounds political, more than anything else.

Actually, IIRC it's the exact same reason as the io.js split. The maintainer of jsdom had changes that weren't being merged into node's VM module.

So jsdom 3.x used a lib called "contextify". When io.js was released and the changes included, node support was dropped. Now node 4.0.0 is out and has those changes, jsdom now works on node again.

It was. The maintainer of jsdom decided to no longer support node after 3.x and made the library throw a condescending exception if you tried to run it with node. The docs were also filled with childish "tm" symbols whenever node was mentioned.

I see things like this all the time and it really puts me off OSS.

The io.js situation was more akin to Python 3 vs Python 2 than Python vs PyPy. It might not have looked like a major difference at first glance, but there were notable significant, which came with some breaking under-the-hood changes.

I use Java/Spring, Ruby, and Node.js in production, and Node.js is by far the hardest to stay up to date with without introducing major problems. The only framework I have used that is harder to update is Finagle.

It's not just Node itself to blame. There seems to be a culture of breaking things in the Node.js ecosystem. Breaking changes in third-party libraries are common. I have to specify exact dependency versions in my package.json, and almost every time I update one of them, something goes wrong.

have to specify exact dependency versions in my package.json, and almost every time I update one of them, something goes wrong.

That's where semantic versioning comes in. Most libraries follow it - if the major version number changes, it's a breaking change. If it doesn't, you're safe to upgrade.

Semantic version doesn't solve compatibility problems, it just makes it more transparent. In some ways semver encourages breaking changes that otherwise might be avoided because, how, a major version bump gives you sufficient warning.

There are some major libraries that are on version 15 or greater... there's nothing good from a user's perspective about having a library they use do a major breaking release every other month.

What's worse is many libraries take advantage of "it's the wild west until 1.0" rule in semver and simple never release a 1.0.

In my experience, Ruby (particularly rubygems) is quite a pain in the ass with regard to package upgrades, especially when the previous developer/ops has leveraged rvm to install multiple combinations of ruby/gem versions. I can't tell you how many times I've had to trace down problems in a project because a single gem fails to upgrade/pull/compile/resolve on 2 out of 4 machines even though the project has an identical gemfile and available ruby version on every server.

I contrast this with node/npm where my projects seem to behave identically across deployments (and in some cases, when in a bind, I've even been able to simply tar & scp the project src and have it run without further effort beyond installing node, something I've never been able to do with ruby).

Identical Gemfile.lock and same OS? Then you shouldn't be having any problems. What kind of errors were you getting?

in fact, to my surprise, I've just tested our app (v0.10.x in production) on v4.0.0 and all our unit tests pass, the server works...

I'm amazed. A single module had to be bumped (Elasticsearch@8) while we directly rely on 50+ third party modules... Our npm-shrinkwrap is 2600 lines long.

That's not really a sign of instability to me, but rather great work

You seemingly have much more experience with Node than me. Perhaps my amateur anecdotes are just bad luck, but certainly my Bash scripts that talk to Node break frequently.

Bash scripts talking to Node sounds like a recipe for disaster.

Why?

Please explain.

I think the npm project should document best practices, like when to use "*" version, when to use npm-shrinkwrap, etc... to limit problems.

NPM is a very powerful tool. In fact, it's our deploy tool: we run `npm install` on servers (private Sinopia npm repository) to deploy. But to do that, you must follow many many rules that are written nowhere.

We used to do this and it caused a lot of issues. Shrinkwrap is a must to keep versions stable. NPM and network unreliability can cause failed installs, as well as other issues.

Our first major improvement to this work flow was a tar of the app with all of the dependencies coupled with `npm rebuild` after unpacking. This worked quite well.

However, recently, we have switched to using Docker to generated this sealed packages which is working great.

We've never really had a problem... Our sinopia npm server is probably isolating some network problems, plus we don't start/update servers that often.

Our NPM workflow also ensures builds are easy to replicate. Most problems in development occur because of obsolete versions of some packages (our apps contain many private modules)... Clean npm-installs shields us from that in production.

Most of the instability is related to compiled modules. Hopefully they'll be updated to support v4.0.0 shortly.

mongodb and redis are two compiled modules and we didn't have problems with those. Honestly, there may be others, I don't even know!

We try hard to keep our dependencies up to date to limit the risks of an upgrade. We progressively apply dependencies updates to dev->staging->sandbox->production environments.

Was I worried when node.js forked? sure! but the situation is much better now. I think node.js can move forward smoothly now.

> I don't think most people working on Node want a Rails equivalent

It wouldn't really be possible anyway. Async programming is hard and the shortcuts one can take with synchronous Ruby are impossible with Async Javascript. Nodejs has a "fibers" lib though , but it doesn't look like it is widely popular, but AFAIK it is the only to truly abstract async programming.

Using abstractions like http://koajs.com/ and https://github.com/tj/co make Node code feel like every other language.

    var user;
    try {
      user = yield db.insertUser('foo')
    } catch(err) {
      if (err.code === '23505') {
        this.flash['error'] = 'Username taken';
        this.redirect('/register');
        return;
      }
      throw err;
    }

no because you can't write a library which apis are thunks. And your code needs to run in a generator, something you omitted. Fibers are a better alternative , no need for yield and generators everywhere.

Well, I was earnestly sharing run-of-the-mill Koa code since you made async abstractions sound elusive. Didn't realize you just had an agenda.

The thing is that people are actually using Koa/co to solve this problem. I've yet to see someone use fibers as their core webapp control flow abstraction.

What agenda do I have ? I have none, I'm just saying using generators do not abstract async calls. The only way to do that is by using fibers. I'm not pushing for anything, i'm just saying that something like rails couldn't be written in nodejs , (and no sails , is nothing like rails in terms of complexity ).

It's your fiber agenda. My mother used it to try to make me eat my brussels sprouts and I thwarted that, too.

ECMAScript 7 has brought true async/await into the language, which currently works in Babel on top of Promises. As far as a regular user is concerned, define a function as "async" and then "await" on the result you're after inside of it. Hardly difficult, in my opinion!

async/await is nice syntax, but it doesn't change the fundamental difference between synchronous and asynchronous code and the viral nature of async functions. Sync functions cannot properly compose async functions in general.

A great essay on this is "What Color is Your Function": http://journal.stuffwithstuff.com/2015/02/01/what-color-is-y...

Try bluebird's Promise.coroutine, I use it everywhere and it works great.

https://github.com/petkaantonov/bluebird/blob/master/API.md#...

Or if you want to use native promises, I threw this together

https://github.com/Dashron/roads-coroutine

With async functions you interface with everything using promises, it's great.

There is http://sailsjs.org/ for people who want a Rails equivalent.

Reply on news.ycombinator.com