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."
Re:Some misconceptions
By Just Some Guy
•
2015-Feb-18 17:24
• Score: 5, Informative
• Thread
Disclaimer: I'm not remotely a Node.js fanboy. I've used it and and chances are good that you've interacted with some of my code today, but it's definitely not my preference.
I said that "Node.js is concurrent" because 1) the summary claims it's fast, and 2) Node.js fans who don't fully understand it seem to think it's magically fast. No, it's not particularly fast: it's just able to handle a lot of requests at once. Those are orthogonal.
Re:Can someone explain node's supposed speed
By IamTheRealMike
•
2015-Feb-18 17:31
• Score: 5, Interesting
• Thread
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.js (eye rolling)
By bored
•
2015-Feb-18 17:42
• Score: 3
• Thread
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.
Re:Ummmm....
By robi5
•
2015-Feb-18 18:13
• Score: 5, Insightful
• Thread
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
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. ... 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)
5. ... and common aggregation analytics (allow your user to sort, filter, aggregate data, product descriptions, events whatever) between client and server
6. ... common domain-specific logic, common utilities libraries, DRY principle, no duplicated testing of logic, common development toolchain, we could go on
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.
Re:Ummmm....
By Dutch Gun
•
2015-Feb-18 18:52
• Score: 5, Insightful
• Thread
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.