Discussions

News: Where does Node.js stand?

  1. Where does Node.js stand? (9 messages)

    I recently became aware of Node.js and I'm trying to sort out where Node.js fits in the server side development picture. I found a few introductory videos from Ryan Dahl which sort of gave me the impression that Node might be the way of the future. So naturally the first thing I did from there was to Google "Node.js sucks". And of course, like anything that anyone thinks is good, somebody has to explain why that first guy was totally wrong. Whenever I hear the type of argument where one side says "X is the best possible," while the other side says "X is the worst possible," I always assume that X is very specialized – it's very good at doing something that people who like it need to do, but others don't. What I'm trying to put my finger on is just what exactly does Node.js specialize in?

    So as I understand it Node.js has a few things that make it a lot different than traditional server-side development platforms. First off Node code is basically JavaScript. Client code running on the servers? That's weird. Also, I shouldn't have said servers (plural) because Node.js requires a dedicated HTTP server – just one server, and it's got to be HTTP. This is also weird. Node's got some clear advantages though. It's asynchronous and events-based, so theoretically Node applications should never block I/O. Non-blocking I/O might make Node.js a powerful new tool for dealing with giant message queues, but maybe it's got more working against it than just being weird.

    I think the guys that say Node.js sucks sound kind of crazy, but they do have a point or three. First and foremost is that Node.js is single threaded; then the detractors have a problem with the similarities Node.js shares with JavaScript; and finally, they say that Node.js cannot possibly back their claim of being blockless.

    Addressing the concern about JavaScript is tough for me. I'm not an expert with JavaScript and I don't really know its advantages and disadvantages over other languages. I have read detractors state that JavaScript is a slow language because it is scripted and not compiled. I have read JavaScript proponents explain that it's not the language that is either slower or faster, but the way the code is written, meaning that the skill of the coder supersedes the inherent qualities of the language. Both arguments have merit, and I don't feel qualified to pick a winner.

    Most server-side developers are very used to running basically linear processes concurrently in separate threads. This method allows you to run multiple complicated processes at the same time, and if one process fails, the other threads can still remain intact. So having a single thread run one process at a time sounds like it would be really slow. I don't think this is the case with Node.js because it is asynchronous and event based, which is a very different model than one might be used to.

    Instead of running one process, waiting for the client to respond and then starting another process, Node.js runs the processes it has the data to run as soon as possible in the order it receives them. Then when the response comes back that's a new process in the queue, and the application just keeps juggling these requests. The overall design is such that Node developers are forced to keep each process very short because – as the detractors are quick to point out – if any one process takes too long it will block the server's CPU which will in effect block the application.

    So you can't do long complicated processes like calculating pi with Node.js. Apparently they have workarounds for spinning off really complicated processes if you really need to, but that seems to be outside of the scope of the original plan. I think that where Node shines is in routing a high volume of low-overhead requests. Which means to me that Node.js is great for light messaging applications with a high user volume.

    Are there other uses I've missed? Are there other issues with asynchronous programming in a single thread? Is there some part of the big picture I'm not seeing? Am I just plain wrong about all of this? Leave me a comment and let me know what's what.

    Threaded Messages (9)

  2. JavaScript and NodeJS[ Go to top ]

    Let me explain some of the basics:

    - JavaScript is a compiled language. It's 2012, dynamic languages can be compiled, JIT-style. Oh, and it actually has bytecode (some minifiers do code-optimization pre-compiling) nowadays!

    - Node.js is a general IO library over V8, the JIT compiler of Google Chrome. 

    - I don't know where you heard that it can do only HTTP, that's not true, it's an I/O library, it's about opening sockets. Yes, there's an HTTP library over the IO library to write servlets, I guess it's a sane idea to do (and actually, there's also a pure socket example on the frontpage of nodejs.org)

    - Why would you write code in GWT? Or why would you do an applet? Or why on Earth would you use J2ME? I mean, java is a server side language, right? While I wholeheartedly agree that GWT should be banned as it's blurring a line (server and client) which shouldn't be blurred, causing debug/profiling/etc nightmares, having a single language on all platforms was a wish since the ancient time of technology.

    - JavaScript is a functional language which is omnipresent, and it's the lingua franca of webbrowsers. It's advantages therefore are simple: it's there on every single platform, and it's a functional language (like Scala, but the type system is different).

    - Since it's the lingua franca of webbrowsers, and every single enterprise application has a web UI, every single senior developer (or at least lead dev / architect) should know it deeply I guess, as it's the common denominator, and it's part of every project, and it's always there.

    - Node.js is using closures. Its asynchronous nature is exploited with closures so when the answer event comes back, the whole context is in closure and it's "just there". That's the trick. You can write fairly linear programs and virtually not care about threads and synchronization, as the variables are there even if the app needs async programming. Not a perfect solution, but another way to tackle a well-known hard problem.

  3. Some of your concerns were already addressed in the previous comment.

    What was missing is your concern of node being single-threaded. But, ah, that is why "node" is named "node": on a real-life production environment, you won't have just one instance of node running all your site, you will probably have at least one instance of node per available processor. So each instance of node will be a node in your server farm, and even if one request takes longer than expected, it won't affect the overall response time.

    The power of node is precisely its much better scalability. When traditional servers such as Apache or any JavaEE app server reach a certain limit of concurrent requests, performance degrades dramatically, whereas in node the degradation is more gradual.

    In my opinion, the only concern of node is that it is just a barebones base for server-side app development, as opposed to full-stack platforms such as JavaEE, .net, LAMP, etc. But application frameworks and being built around node, so if in a few years we may see a full stack based on node that can compete with the classical ones.

  4. to be precise[ Go to top ]

    This is solution, but to be precise, many single-threaded instances is not the same as one multithreaded in terms of communication and synchronization between threads, resource consuming, garbage collection optimization.

     

  5. to be precise[ Go to top ]

    Indeed. This is one of the reasons why when we created vert.x we wanted the good things about frameworks such as node.js but not the bad bits.

    Vert.x has multple event loops in the same JVM process so you don't have to spin up X instances like you do with node.js

    Vert.x has a worker pool for long lived tasks so you don't have to do stupid things like split up your algorithm into lots of tiny pieces so you can don't hold up the event loop for too long before calculating the next part.

    We also allow you to use other programming languages if you don't want JavaScript. As someone else mentioned, if you have a large project, you might prefer a statically typed language.

     

  6. Vert.x[ Go to top ]

    You might be interested in this project http://purplefox.github.com/vert.x/

    It's an asynchronous application framework, similar to node.js in some ways, but runs on the JVM, and lets you use it with JavaScript, Ruby or Java (other languages coming soon).

    We also throw in a distributed event bus and other goodies.

    If you're interested in seeing what kind of apps these kind of frameworks are good for, I recommend taking a look at the tutorial.

     

     

     

  7. Already disscused here[ Go to top ]

    It was discussed here at TheServerSide (in spite of the tittle is not a pro-Node.js article).

     

     

  8. Where does Node.js stand?[ Go to top ]

    http://www.youtube.com/watch?v=bzkRVzciAZg

  9. Where does Node.js stand?[ Go to top ]

    Poll:

    People who use dynamically typed languages for mission critical systems are invariably idiots.

     

    Are you?

  10. Idiots? I don't think so[ Go to top ]

    Only a Sith deals in absolutes.