50

Recently there has been a lot of praise for Node.js. I am not a developer that has had much exposure to network application. From my bare understanding of Nodes.js, its strength is: we have only one thread handling multiple connections, providing an event-based architecture.

However, for example in Java, I can create only one thread using NIO/AIO (which is non-blocking APIs from my bare understanding), and handle multiple connections using that thread, and I provide an event-based architecture to implement the data handling logic (shouldn't be that difficult by providing some callback etc.)?

Given JVM being a even more mature VM than V8 (I expect it to run faster too), and event-based handling architecture seems to be something not difficult to create, I am not sure why Node.js is attracting so much attention. Did I miss some important points?

Joachim Sauer
  • 10,956
  • 3
  • 52
  • 45
Adrian Shum
  • 1,095
  • 7
  • 11
  • 3
    I wonder why it is downvoted... I feel this question is more a programming discussion so I didn't put in stackoverflow. I also tried to search similar topics but I only found information about the strength of Nodes.js but my problem is I don't really understand why the "strength" is so unique (which I still can't find ) – Adrian Shum Jun 19 '12 at 02:42
  • 6
    Try implementing that pattern in Java. It works, of course. But you'll see one thing: It'll be very, very verbose in Java: you need tons of callbacks, which almost always means creating new classes. That might sound like a minor nitpick, but in a big program it can get ugly and unwieldly quite quickly. – Joachim Sauer Jun 19 '12 at 05:20
  • 6
    Javascript callbacks are just as prone to becoming unwieldy -- and such spaghetti is far easier to debug and refactor in Java than in Javascript IMO. – funkybro Jun 19 '12 at 08:00
  • 1
    @funkybro: while JavaScript is probably not the ideal language either, its syntax for these kinds of things *far* nicer than that of Java. And the ease of debugging/refactoring depends almost exclusively on the available tools and Java showed that *a lot* can happen in that area. – Joachim Sauer Jun 19 '12 at 08:05
  • 5
    @AdrianShum: its a slashdot effect, anything that doesn't fit in with the group mindset will be downvoted - like praising Microsoft on /. – gbjbaanb Jun 19 '12 at 08:54
  • 3
    I'm surprised to not see anyone mentioning the hype. – deadalnix Jun 19 '12 at 08:59
  • 1
    @deadalnix: why should we mention it? This question is about actual, technical differences. The hype exists, but it doesn't influence the technical merit of the approach (not negatively and not positively). – Joachim Sauer Jun 19 '12 at 11:20

3 Answers3

34

While that concept can indeed be implemented in many languages (and as dodgy_coder mentioned, it has been implemented in Ruby and Python at least), it's not quite as trivial as you state.

True, Java has non-blocking IO APIs. So you can do raw disk/network IO in a non-blocking way. However every API that somehow wraps or handles IO needs to be implemented in a non-blocking way as well. Every XML parser, every Database driver, every file-format converter needs to be written to support non-blocking IO. Because if a single library is blocking in this pattern, then that brings down your servers performance to stone-age values.

Node.js has that library infrastructure, because it was always designed that way: every library that strives to become popular has to provide an asynchronous API or it will not be used.

Community
  • 1
Joachim Sauer
  • 10,956
  • 3
  • 52
  • 45
  • 19
    Yep. In other words: Node.js's most important strength is ECMAScript's most important weakness: the incredibly crappy ECMAScript standard library. Since the Node.js developers had to reinvent every single wheel anyway, they had the chance to reinvent it the right way. – Jörg W Mittag Jun 19 '12 at 07:59
  • 4
    Well, as far as I know ECMAScript was always designed as an embedded language, so there was no need for OS-level APIs of any kind (even network IO was mostly abstracted away). That lack was indeed an advantage to Node.js. – Joachim Sauer Jun 19 '12 at 08:07
  • "every library that strives to become popular has to provide an asnychronous API or it will not be used" I think that's precisely what I am looking for. Is there any resource to look into about how asynchronous api is provided for, for example, XML parsing and DB access, in Node.js? – Adrian Shum Jun 19 '12 at 09:24
  • 1
    @AdrianShum in general, look for event driven programming examples. Specific implementations can be found in many languages. Besides Node.js modules, you could look at Twisted examples in Python, http://twistedmatrix.com/trac/wiki, POE examples in Perl, http://poe.perl.org/, and Ruby has EventMachine, https://github.com/eventmachine/eventmachine – mghicks Dec 20 '12 at 11:56
19

Probably the main reason is that it uses JavaScript to write server-side components for things such as web servers, web applications or web services. This unifies the traditional front end (client-side) development language JavaScript with the server-side language.

You're right - the fact it is non-blocking, using the reactor pattern is not unique - it has been done before using other languages and frameworks, such as Ruby's EventMachine or Python's Twisted for example.

dodgy_coder
  • 1,098
  • 7
  • 22
  • 5
    very few technologies have truly unique features, the uniqueness comes from their particular combination of all their features – jk. Jun 19 '12 at 07:30
  • 1
    Agreed, there's a list here of libraries which support it in all major languages ... [Reactor Pattern on Wikipedia](http://en.wikipedia.org/wiki/Reactor_pattern) – dodgy_coder Jun 19 '12 at 13:37
10

The three main reasons I would give are:

  1. Non Blocking IO / Asynchronous IO. This is hashed everywhere on the web and in the previous posters. One thing I would contribute is that designing your code to explicitly assume asynchronous behaviours assists the compiler engine to maximize the hardware. Yes, many of the JIT compilers and hyperthreading processors take synchronous code and help parallelize the execution. This of course is a best effort approach. In contrast, explicitly building the application for async io you ensure the engine and the hardware can maximize the execution time for your code. Admittedly, I don't have quantifiable data to prove this, but it makes me feel warm inside to think this way.

  2. Single code base for client and server. This has a number of advantages: help optimize datacenter costs by being able to move business logic from the server to the client; help reuse business logic / data validation; reduce the complexity of developer skills that need to exist to support the product (vs. Python & javascript).

  3. Low barrier to entry. In many ways Javascirpt is like Basic, Pascal and Perl of yester-year. It is super easy to start writing code and does not require a lot of domain knowledge to get going. This also helps reduce your development costs by being able to bring in more jr developers and getting the ramped up on a project. [Of course you need to get past the ideologues who believe programming languages should be difficult in order to weed out the low functioning developers]

cflat
  • 109
  • 4
  • I'm not sure I'd recommend building a Node team entirely with jr. JS devs. Architecture isn't really something we have to think about in more jr-grade web/UI projects and JS takes as long to get really good at in terms of building for the long haul as any other language does even if you can get results relatively fast at a lower level of experience on less complex projects than is typical. – Erik Reppen Aug 20 '14 at 21:25
  • I agree with @ErikReppen; an architecture team entirely of junior devs (regardless of language) is like designing and building a house entirely using carpenters who are good at building chairs, tables and dog houses. – Wildcard Apr 18 '16 at 20:04