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.
The summary doesn't explain node.js , but node.js is a server side javascript solution
So now you can code both backend and frontend in javascript
.
Computer media are usually pretty dull, so there's nothing like a supposed battle to up the interest.
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.
1) Languages aren't compiled or interpreted: implementations are. Java has had a decent optimizing compiler for a long time, but JVM 1.0 wasn't exactly a speed daemon. JavaScript was a dog for a long time, but modern engines like V8 compile it to native machine code.
2) Node.js isn't fast. It's concurrent. You can handle many thousands of simultaneous requests, as long as none of them are working particularly hard.
3) Exactly what collision course are we talking about? I can't imagine many situations I'd consider Node.js for that I ever would have though about Java for in the first place. If anything, I see Node.js as more of a competitor to Python for building scalable backend services.
Dewey, what part of this looks like authorities should be involved?
Node.js - I don't want to pay my programmers
Java - I don't want to pay microsoft
God I swear the Java world is overrun with this kind of stuff. It requires you to fully jump into their world instead of just using a piece of it happily and moving on with your day. You have to go install the kitchen sink IDE, server, and whatever else. It's a career path just learning all of the lingo.
>> Java and JavaScript are now locked in a battle of sorts for control of the programming world.
Whatever. Wake me up when you can write a (good) device driver in either then I'll take your claim a little more seriously.
I realise that the internet is a massive source of employment, but believe it or not, its not the only thing out there. There are acutally a few of us software developers left that do not do web stuff (and actually like it that way).
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
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!
The summary is not about node.js vs. the browser, but Java vs. Javascript.
The main problem with Java (other than the other major problems others listed) is that it's not Javascript:
1. you cannot realistically avoid Javascript on the client side ... and you can use common data validation (on the client: reject/highlight bad user input without a server trip; on the server: 'never trust the client' principle, infosec) ... and common aggregation analytics (allow your user to sort, filter, aggregate data, product descriptions, events whatever) between client and server ... common domain-specific logic, common utilities libraries, DRY principle, no duplicated testing of logic, common development toolchain, we could go on
2. the client side is only getting richer in functionality (look up something like dc.js, crossfilter.js, d3.js, Google apps, mapping, all web apps...)
3. there is benefit to using one language instead of two, if the feature set is comparable: no context switch for programmers...
4.
5.
6.
So the 'they both have their place' isn't quite true for a very large fraction of deployments which currently use Java on the server (and naturally, JS on the client).
Javascript is not 'only so performant', and, as someone else below assumed, JS isn't fast 'because of concurrency'. Most JS is run on V8 or similarly advanced engine, and in my experience the resulting code is about as fast (or slow) as Java execution (single threaded) even if we ignore the most often cited benefit of node.js, which is non-blocking IO. As JS itself is evolving, with typed arrays and the possibility of programming it without generating garbage, WebGL, Web workers, and low level numeric and bit logic functions coming up in about a year, so it'll only get faster. It's unlikely Java will ever have a performance lead on JS ever again.
Using the same language end-to-end is a more powerful argument than 'the right tool for the job' argument, especially if Java's current lead in some specific server side areas (e.g. finance/reliability/type safety aspects, or machine learning) aren't inherently a consequence of the language, just a consequence of a head start in those areas.
So in my opinion there is a strengthening incentive for using one language end to end at the expense of Java.
I think you would have to be nuts to build something on a Google technology. I thought about it because GWT is very cool, but with my luck I would roll out version 1.0 and Google would cancel that project and donate the code to the Apache orphanage.