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.
That's all I can think.
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
Java = back end
JavaScript = front end
Need both to do useful things, no?
Node.js is an event driven framework for build web/network apps. It doesn't run in the browser, it is the server fulfilling browser requests. It just happens to use the javascript language.
http://nodejs.org/
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.
You're not supposed to do any heavy back-end work with node itself; it can handle simple database interactions and streaming etc. but anything that requires serious computation is supposed to be forked off to a separate process. Unfortunately it encourages misuse by providing a toehold for JavaScript programmers to start worming their way deeper into server processing.
>> 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
Every few years, we have a new latest and greatest. A few years ago it was ruby on rails, then it seemed python was starting to come into it's own, and now it's node.js. At one point in time, in the mid 90's, it was actually Java. If you can imagine, Applets were actually a big deal.
Programmers flock to these in droves because, being new(ish), it attracts proselytizers who overhyper and oversell it, authors to write about it, articles about it, speakers to present it, a race to be seen as an expert in it, etc. New means 'new opportunities' so there's a rush to fill this hole that's already been filled in other languages/frameworks. Lots of activity.
All this attention, and it being new makes it a toy to play with and something to trick the boss into agreeing to use, so you have an excuse to use it. Some small number of folks will end up dealing with it for a bit, but then they drop it when something newer - and thus more interesting and exciting - comes out. Check out the TIOBE index for what's happened to Ruby lately.
But here's the real reason this isn't a battle. Java was not a language, it was a product. Every part of it was made to sell - not to developers, specifically - but to businesses. Here is an end-to-end solution, with certification, a training program, literature, professional advocates that will travel to conferences, your company, programming competitions, and local java users groups - in fact, they'll sponsor them. They'll pay for flashy commercials, and take out ads in trade magazines, and get companies to include the java logo on their software. They'll provide support contracts and expert help, and they'll push Java as a brand.
It's not a toy. It doesn't stick because it's cool and new and neat, it sticks because now there's money behind it and it's cheaper not to change much. That's why we still have Cobol around, isn't it?
So, Java's already been sold to the big dogs, the guys with money who make decisions. It's embedded into the corporate hierarchy, and outside of a few side projects and startups, it's not competing with Node.js at all. Node.js will make it's splash, and in 2 years, we'll all be jazzed about something else, while the cobal, c, c#, java, and other legacy frameworks just keep chugging along with the majority shares.
Modern web sites shouldn't rely on Java plugins. There is only one native scripting language for the web, and that's js.
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.
Yes.
It doesn't help that a lot of the people going crazy for node.js are also want to offload the work the meet dependencies on the admin/superuser, and yet still want to do a rapid-release-cycle schedule. They can't even meet their own internal dependencies right.
I was working with an educational classroom management project. They theoretically use Debian or Ubuntu, but require so many third-party repositories that it's impossible to just install and have it work. They also rely on specific versions of some of these third-party modules, such that one has to be mindful of the version of Debian or Ubuntu one uses for a starting point (ie, 14-anything won't work) and one has to be careful with these repositories as they themselves will install wrong versions of things (including node.js itself). Then there's the dependencies relying on MySQL, while the package that one actually is tryng to use requiring PostgreSQL, so there ends up being a whole lot of garbage to do something that shouldn't be all that complicated.
My point is, node.js might itself be fine, but when the software that relies on it is so badly broken as this, it does not come across as a professional product. The amateurish approach to the software using it taints it. Every time I see github or node.js or anything with "ppa:" I now assume that it's crap.
Do not look into laser with remaining eye.
This would be a much more interesting battle. Java, Node, [Name your lang here] is just a vehicle
I use Java and Javascript every single day. Are new programmers simply not able to learn more than one language? My work is primarily on a webapp, so its the classical Java backend Javascript frontend. However if our platform was different we would be using different tools.
What the hell they teaching kids in school these days? Back to the "Java is a hammer" days? Or is this the "outsourcing, so only one language for your entire end to end on every system"?
But, my guess that the article is clickbait trolling, and real architects actually know to use the best tool for the job.
I'm a good cook. I'm a fantastic eater. - Steven Brust
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
Node is fast supposedly because it uses low-overhead single-threaded asynchronous calls, instead of threading. So if that is such a fast paradigm, why don't we build a low-overhead single-threaded asynchronous Java or Python or C# engine? Eg: Node.java, Node.cs, and Node.py?
There is no reason not to build a single-threaded, asynchronous web server in the language of your choice. I'd be surprised if there aren't a bunch of them out there by now.
Node has the advantage of using the same language for both client and server side code. Since JavaScript is the de facto standard for in-browser code, any other language pretty much requires a translation step.
Node also has a robust community and a lot of framework and library packages.
http://vertx.io/
Vert.x is a lightweight, high performance application platform for the JVM that's designed for modern mobile, web, and enterprise applications.
Write your application components in Java, JavaScript, CoffeeScript, Ruby, Python or Groovy...
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 have nothing against Java either, but I think making it web-facing has been something of a disaster from a security standpoint. And let's face it, security isn't a high-priority feature up until you're breached, and then it becomes a critical feature. If you disable the Java web plugin on the client, the language itself really has a lot going for it. If it didn't, so many programmers wouldn't still be using it today - according to some rankings, it's the most popular language right after C, and just before PHP and Javascript.
Fortunately, given the fact that we have dozens of reasonably popular languages to choose from, and even more obscure ones, we don't have to pick one language to do everything. In fact, it's downright silly to think that one language ever could do it all. The reason we have so many languages to begin with is because there are so many diverse programming challenges and environments in the modern world, and every language has specific strengths and weaknesses.
Irony: Agile development has too much intertia to be abandoned now.
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 could use GWT which is Java compiled to JS, then you're not touching JS directly (except by treating it as an assembly language.)
It's not native, true. But it's as native as C is to a regular OS environment.
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.
Now that pre-compilation is pretty much pervasive in any advanced browser development, you DO have "real alternatives" to ES5 (probably what you're referring to if you're mentioning being stuck with it).
CoffeeScript, TypeScript, ES6, Clojure, hell, Scala is available, and you can use Java with stuff like GWT (imo sucks, but Amazon thought it was great for a while).
People keep going back to JavaScript because, aside for a couple of stupid things (a lot of which are fixed with strict mode and ES6 constructs), its actually pretty damn good, and some things that used to be considered hacks or half baked, like prototypical inheritance, are starting to be viewed as superior to the alternative, with good reasons.
But even without that, the reason people will use node on the server, when its not for isomorphic app (which btw, is a REALLY good way to build your app, if you can afford the development overhead and care about your customers), is because the threading model of Node/V8 has very interesting performance and scaling characteristics for I/O heavy applications. It can scale like fucking crazy. http://blog.caustik.com/2012/04/10/node-js-w250k-concurrent-connections
I could go into a dozen technical reasons why javascript is a terrible, horrible, outrageously bad language
So is Java. It's unfair to call JavaScript's problems "product killing" ... unless you mean Java's are as well?
I juggle two day jobs, both for responsive, background-processing-heavy websites. One's in Node and one's in Scala (Java on steroids). To me, the Node way Makes More Sense.
Yes, Java can process in multiple threads at once; but then you need to worry about atomicity. Yes, Java it can delegate different jobs to different threads; but then you need to read up on ExecutorServices. Yes, Java is faster; but if you want async file reads, things get complicated pretty quickly. (If you're going to block your thread, you'd better adjust your thread pool....) Yes, Java is type-safe and compiled; but that hinders as often as it helps.
These are two different cultures. Java culture seems to whirl around huge infrastructures -- J2EE, JDBC, Swing, Ant, etc -- that have gargantuan learning curves and ten-year-old flaws. (One that bit me: Java 7's UTF-8 decoder accepts invalid UTF-8 to maintain compatibility with Java 5 -- that is, a ten-year-old version of the standard.)
In contrast, Node culture is about self-organizing chaos. You can deliver results really quickly, but you might need to rewrite your code in a few months to keep up with library changes. And your favourite dependency might not be there tomorrow.
Java and JavaScript (and any other language, really) can kill your product in different ways. Pick your poison.
GWT is not maintained by Google anymore. From http://www.gwtproject.org/ "GWT is used by many products at Google, including Google AdWords and Google Wallet. It's open source, completely free, and used by thousands of enthusiastic developers around the world."