Slashdot Mirror
Java Vs. Node.js: Epic Battle For Dev Mindshare
snydeq writes While it may have been unthinkable 20 years ago, Java and JavaScript are now locked in a battle of sorts for control of the programming world. InfoWorld's Peter Wayner examines where the old-school compiler-driven world of Java hold its ground and where the speed and flexibility of Node.js gives JavaScript on the server the nod. "In the history of computing, 1995 was a crazy time. First Java appeared, then close on its heels came JavaScript. The names made them seem like conjoined twins newly detached, but they couldn't be more different. One of them compiled and statically typed; the other interpreted and dynamically typed. That's only the beginning of the technical differences between these two wildly distinct languages that have since shifted onto a collision course of sorts, thanks to Node.js."
Hipster Crap vs Crap. Fight!
Node.js is specifically for using javascript on the backend and has no real application on the front end- of course Javascript itself does though.
Java has servlets, servers, web applets, and desktop applications.
Both technologies can do both sides. Java is of course much more feature rich with more low-level operations.
I don't think it's really a true apples to apples comparison - they both have their place. Some people like writing end-to-end java, some people like writing end-to-end javascript. But at this point in time, java on the web is kind of dwindling because it is a sledgehammer when all you need is a regular hammer in most cases and javascript end to end is on the rise but there's probably a plateau somewhere because javascript is only so performant and has some limitations. Most of us though I think use the more honed tools for the right jobs even if it means we can't use the same language end-to-end.
.
Computer media are usually pretty dull, so there's nothing like a supposed battle to up the interest.
That makes it sound like some Node.js specific trick. If you define concurrent to mean "has callbacks and non-blocking IO" then basically any language can be described as concurrent, so this doesn't tell us much. Nothing stops you writing Java in a fully non-blocking single threaded style if you want to mimic Node programming, and in Java 8 the syntax for doing so is actually lighter weight than JavaScript.
But mostly people don't do that, because it's a pain in the ass. Node.js doesn't rely entirely on non-blocking operations with tons of nested callbacks because this is such a brilliant way of programming. Node relies on this because it's based on V8, a virtual machine designed exclusively for web browsers and browsers are not thread safe. Indeed one of the reasons V8 is able to get pretty impressive speed for such a dynamically typed language is because it just throws multi-threading out the window entirely. Writing a high performance VM is hard. Writing a high performance thread safe VM is much, much harder. Luckily the V8 guys can ignore it because a thread-safe JavaScript runtime is useless for browsers, and they never anticipated that anyone would love JS so much they'd actually use even if they didn't have to. So, it resurrects the Visual Basic model of concurrency from the 1990's.
The JavaScript world meanwhile has developed a kind of Stockholm syndrome in which obvious weaknesses are spun around to become strengths. No type safety? No threading? Blocking on even a disk seek trashes your performance? You're just doing programming wrong, see, and Node's lack of features is in fact some kind of Zen minimalist wisdom designed to guide you to the light.
This sort of thinking is very common in the world of programming languages because making a good one with all the features of the really big platforms (like the JVM) is really, really hard work, meaning compromises have to be made. Then because you are limited to interop with libraries written in C (again unless you build on .NET or the JVM), those language users realise their only chance for non-crap libraries is to convince the world to join them and rewrite everything in their language - hence the quasi-religious preaching of "simplicity is strength, our way is the high way" etc. The Go world seems to have this problem cubed.
Javascript, despite it's popularity, is a terrible language. It's popularity is due to one thing, it is embedded in the browser. If you could just pick your own language to embed in the browser, you'd never hear of it. The entire level of popularity from Node.js has come from 3 things:
1. Frontend (read, client side, not "PHP") developers who get the idea in their head that they already know javascript so wouldn't it be great to use it on the server too so they don't have to learn another language
2. Non-blocking I/O, which is admittedly very worthwhile on the server side...however, Java still blows it out of the water for concurrency and Go is currently doing everything that Node does here, but better.
3. AJAX development, making JSON popular, leading to JSON based NoSQL databases like Mongo (which is great at what it does) and then uses Javascript for processing in the database too because of JSON
There's a 4th reason that gets tossed around that I've never seen actually validated with the idea of "reusing code on the backend and the front-end" but I've never seen a case where that was actually a good idea since it involves exposing so much logic.
On the frontend, yes, Javascript everything...because you have no other option. That's like saying black was beating green for mind share with the Model T Ford.
On the backend, you have Java, Go, .NET, Ruby, Python, PHP, Clojure, Groovy, Erlang, Perl, Scala...all of these languages exist with different benefits and different trade offs.
If anything, a huge piece of Go's skyrocketing popularity is people wanting the non-blocking I/O perk of Node for certain use cases without all of the pain that comes from dealing with Javascript.
"Don't teach a man to fish, feed yourself. He's a grown man. Fishing's not that hard." - Ron Swanson
Node is slower than a modern typed VM like the Java on the JVM or C# on .NET. Let's get that out of the way right now - Java is faster than Javascript. The reason is that Javascript source lacks a lot of info needed to efficiently map it to machine code, so V8 and other fast JSVM's all have to rely heavily on speculation. That's a fancy way of saying they guess what the code might do, compile that, and then recompile it again if it turns out they were wrong (or if the code actually changes itself at runtime which is not uncommon for dynamic languages).
Now to be clear, Java itself is actually a kind of hybrid static/dynamic language. For example all code is lazy linked and you can generate and load new code at runtime as well, if you want. All method calls are virtual by default etc. The JVM requires tons of complexity and machinery to make all that work with acceptable performance ... but it's still able to do a better job than with Javascript because the code contains more static type info up front.
So why do people think Node is fast? A couple of reasons. Partly it's because the sorts of people who are attracted to Node are the sorts of people who were previously using languages like Python, Ruby and PHP. Compared to the interpreters for those languages, V8 and thus Node really is very fast. Python/Ruby/etc don't speculate or produce machine code at all (though their JVM versions do). So, for people who code in the dynamic languages space, Node is a big step up.
Secondly, Node apps have a nasty habit of being built on NoSQL-ish database layers like MongoDB. These databases were being developed and getting hip around the same time that Node was becoming popular, so there are asynchronous database drivers for them. "Nasty" because they seem to be very frequently applied in cases where they aren't appropriate. BTW I say that as a former professional BigTable administrator, so I'm not a n00b when it comes to NoSQL databases.
In contrast most of the people developing Java/.NET web apps are usually developing business apps of various kinds and have older code bases, so they are using MySQL, PostgreSQL, Oracle, etc ..... more traditional relational databases which have only blocking drivers. That means for any web app that does database work i.e. all of them, the Java web servers will spend most of their time waiting around for the database. Whilst doing so they are holding thread stacks in memory. Thread stacks generally have to be sized at creation time for the worst case scenario, which means they tend to be large. 1mb stacks are not unheard of. Node, in contrast, requires asynchronous code at all times because V8 is not thread safe. It doesn't give you any choice in the matter. A callback closure held on the heap tends to require much less memory than a thread stack, thus, you can suspend many more computations at once when programming in this style.
If you can suspend a lot more computations simultaneously for the same amount of RAM, then you can force more traffic through a single server before it runs out of memory and falls over. And though people tend to talk about tens of thousands or hundreds of thousands of threads not scaling, actually since a bunch of major upgrades many years ago (NPTL, constant time scheduler etc) Linux has been actually able to handle bazillions of threads. The problem is that requires a very unusual programming style to achieve due to the tiny stacks, and Java/.NET aren't really designed with it in mind, so in practice nobody makes servers that work this way.
All this is a long winded way of saying that the programming style Node forces you into is genuinely more memory efficient than the thread-per-request style, and if you can fit more requests into memory at once then it will appear that a single server can "go faster" .... even if technically the code executes slower.
But here's the catch. Is it worth it? You've been able to do asynchronous programming for a