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."
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.
Node.js and Java couldn't be much more different in the types of programmers/clients that each attracts. A typical Java client would be a somewhat stodgy to extremely stodgy company where the programmers are completely wild and out of control because they don't wear ties with their dressshirts. These same programmers either work in large pools of programmers for the company or are doing contract work for a large stodgy consulting company.
A Node.js programmer might not own a dress shirt and works for a company that mightn't have ever printed an org-chart. The only stodgy companies using node.js would be where they completely outsourced their web infrastructure to a young hungry up and coming development company that has another decade or two before it becomes fully decrepit and stodgy.
There is no competition for mindshare between these two. Maybe, just maybe, there are a tiny few companies right in the middle of these two extremes that would go one way or the other but in all probablity these middle companies are using PHP, Ruby, or Something Microsoft.
But the reality is that Java is competing with Microsoft's C# and maybe other JVM languages such as Scala. Whereas Node.js is competing with PHP, Ruby, Python.
All I could say to product/project manager at a fortune 500 company who wanted to switch their system from Java to Node.js is "Good Luck." And the same with someone who proposed Java at a young startup that had a successful Node.js codebase. In the later I could maybe see a switch to Python but the first would and will potentially not be switching from Java for the next decade or three.
2) Node.js isn't fast. It's concurrent.
hmmm. i thought the thing about Node.js is that it *isn't* concurrent, it's event driven. there's one thread for your code, although connections are queued asynchronously. so ... many connections, but one thread servicing them all?
http://blog.mixu.net/2011/02/0...
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 on the server-side is total bollocks. Now that the client has gone smart again, because the browser *is* the client-side env, therefore Javascript has clearly won as *the* client-side language, and this means the server may become lean and mean again, because it can dispense with all the GUI, HTML, etc.. nonsense. And that means it can be done in real programming languages again. The kind where mistakes will cause a crash, not just inefficiency, unreliability and an entire generation of ops that think "just restart" is "normal". Which means that bad developers are filtered out, not saved by a nanny language and environment. Which means there will be less, but far better developers. And good developers can make good code in any language. Whatever I may have said and thought about JS in the past decade or so, I changed my mind since owning Crockford's "Javascript: The Good Parts". ON THE CLIENT SIDE, that is. I have never like anything but C(++), on the server side, and experiencing J2EE Containers, PHP, RubyOnRails, and various python frameworks there has only entrenched me more into thinking there is not one among them that I ended up respecting. If I could do a full e-commerce solution in serverside C++ in 1998, and get excellent performance from the cheap boxen of that time, imagine what you could do today by doing it right, on the server-side, by not wasting CPU cycles on another interpretative layer and letting some dumb algorithm mis-handle your memory management for you.
I read "sledgehammer" as "security nightmare". It's sort of sad when something completely eclipses Adobe Flash for sheer number and seriousness of security issues. As of a year ago, Java accounted for over 90% of all recent web-based exploits. It's a real problem, because so many enterprise applications rely on old and insecure versions of the Java runtime. It may be that security issues are what actually ends up completely killing Java on the client - besides the simple fact that the trend is simply moving away from plugins because of their inconvenience and proprietary nature.
Irony: Agile development has too much intertia to be abandoned now.
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
I could go into a dozen technical reasons why javascript is a terrible, horrible, outrageously bad language here but this post would be TL;DR; for most people. Lets just settle for goggling "javascript terrible" and reading the first couple links.
Or for some silly (not not really deal killing) things watch https://www.destroyallsoftware...
The fact that there are actually people who think using in on the server is a good idea, proves there are insane or completely incompetent developers out there. If someone actually approaches me with this idea, I immediately think they are an idiot.
See, on the browser we basically have to deal with javascript because there aren't any real alternatives. But things that are just "issues" or "irritations" in the browser quickly blossom into product killing problems when used on the server.
Oh, and yes, I've written my fair share of javascript (and other languages), so don't think i'm talking out of my ass here.
this is not about applets, which have been dead for years already. it's about javascript as back-end platform.
but TFA (without reading it) is pure nonsense. back-end js (= node.js/io.js) is very interesting but far from competing with java. java's installed base is simply too big to even speak of that, and the paradigm shift is also considerable: node.js is based on monothreading and non-blocking io, a completely different model. it's also very new technology just emerging. but still a very interesting architecture. it's also much more fun and exciting. :)
i guess we have about 4-5 years of fun ahead until node gets it's share of certifications and "experts" and best practice bullshit, and until someone comes up with some moronic idea like java's generics (yes, 1.5 already signalled java's decadence and oracle had nothing to do with it (imagine!)) and everything starts to rot and turns to yet another boring, stupid, ugly cobol, sorry, i meant java. industry never had a heart. but we irredent coders do!
Your reasoning is invalid.
With Java, I can use Spring + JSF2.2 with a toolkit such as PrimeFaces.
This lets me develop completely in one language (Java) while the components render in HTML5+Javascript. These components can even apply java validators to the client side (auto converted into JS).
The real value of Java is it strong typed nature and strict language, which makes things like static checks, refactoring, autocompletion a breeze. Furthermore, there exist free Java libraries for just about anything.
I like Javascript, but I wouldn't want to write a complex enterprise application in it...
You clearly seem to be in one of the camps but your post has contained no substance whatsoever other than conveying unsupported second hand sentiment (again with no specifics) and no direct experience.
Your ASSUMPTIONS are unwarranted. I held off on taking the plunge into Node.js because I was already busy elsewhere, and suspected it was a fad. But I know people who have. I have simply reported what they have said to me. I was willing to adopt it, if it proved out.
You can doubt that however much you like, but you have absolutely zero evidence on which to base your comment. Except, apparently, your own twist on what you think I implied. I stated myself, quite clearly, that I did not have personal experience with it and was only reporting what I'd heard from others.
And based on the same lack of evidence, I could just as easily suspect that you're a shill for Node.js who is trying to downplay perceived criticism.