Java Vs. Node.js: Epic Battle For Dev Mindshare 319
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."
Fight! (Score:5, Funny)
Hipster Crap vs Crap. Fight!
Re: (Score:2)
Sometime after node.py
Crippleee Fiiiight! (Score:2, Funny)
That's all I can think.
Battle for mindshare, or for page hits? (Score:5, Insightful)
.
Computer media are usually pretty dull, so there's nothing like a supposed battle to up the interest.
Re: (Score:3)
There is in my company. Seriously. A very very big e-commerce player. With all the politics and careers at stake that you would expect.
Re: (Score:3)
There is in my company. Seriously. A very very big e-commerce player. With all the politics and careers at stake that you would expect.
Well, I don't want to get into flame wars. But A LOT of developers I know gave Node.js a serious shot, then said "Never again."
Your mileage may vary. I'm just describing what others around me are saying. I never personally considered jumping on the Node.js bandwagon. It seemed like a pretty strange idea. I was willing to wait for the judgment of "First Responders" to give it a go. I tried to keep an open mind, and just wait and see.
What I've been hearing back hasn't been so good. I'm honestly getting
Re: (Score:2)
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.
Re:Battle for mindshare, or for page hits? (Score:4, Interesting)
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.
No overlap for mindshare (Score:4, Interesting)
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.
Re: (Score:2)
Re: (Score:3)
stodgy
[stoj-ee]
adjective, stodgier, stodgiest.
1. heavy, dull, or uninteresting; tediously commonplace; boring: a stodgy Victorian novel.
2. of a thick, semisolid consistency; heavy, as food.
3. stocky; thick-set.
4. old-fashioned; unduly formal and traditional: a stodgy old gentleman.
5. dull; graceless; inelegant: a stodgy business suit.
Re: (Score:2)
Some misconceptions (Score:5, Insightful)
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.
Re:Some misconceptions (Score:4, Interesting)
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... [mixu.net]
Re:Some misconceptions (Score:5, Informative)
Node.js is mostly event driven, but it's concurrent in the sense that it can be servicing many thousands of simultaneous requests by doing the parts that aren't currently blocked. It's not quite single threaded [stackoverflow.com], though, as the blocking parts are handled in their own threads.
Re: (Score:2)
Re:Some misconceptions (Score:5, Interesting)
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 Stockholm syndrome (Score:2)
Damn, this is both +Funny and +Insightful. Wish I had mod points, and the ability to assign two of them to your post.
Re:Some misconceptions (Score:5, Informative)
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: (Score:3)
The JavaScript world meanwhile has developed a kind of Stockholm syndrome...
Yep. Go to any support forum for node and point out what a pain in the ass it is in node to actually handle all paths, including errors, correctly, and just watch the comments rain down reaming you for not understanding event-driven programming. When I started looking at newer backends that might handle reactive stuff better than RoR, all the info seemed to point to Node.js. When I actually started learning it, I was horrified.
Re: (Score:2)
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.
With optimizing Javascript, it's hard to get around the speed problem that every variable access involves a hash-table lookup.
Re: (Score:2)
Node.js isn't fast. It's concurrent.
For an extremely limited notion of "concurrent". Also, extremely outdated, even though an awful lot of people who are ignorant of computing history have convinced themselves that it's totally new & revolutionary. (I've been asynchronous reactive programming for nearly 15 years, and the way node does it is just awful.)
Re: (Score:2)
Languages aren't compiled or interpreted: implementations are.
Though true, there are some languages that lend themselves to compilation more than others. Anything with an 'eval' statement, for instance, doesn't lend itself to compilation.
Node.js isn't fast. It's concurrent.
It should be though. If V8 compiles the javascript to machine code, why isn't it fast? I know it isn't, because it's an order of magnitude slower than the equivalent code written in C, and I think a fifth of the speed of code written in Go (from memory...). What's the deal?
Re: (Score:2)
Re:node is going away. (Score:4, Insightful)
Re: (Score:2)
Sounds like you don't enjoy Tomcat much. Me neither, though it has a lot of features. But running a Java web app doesn't require Tomcat. There's a whole market of servlet containers out there, and some of them are embeddable resulting in standalone servers if you don't like the "run the app in a big web server" model.
For example, a popular embedded servlet engine is Jetty, which has pretty good performance [webtide.com], easily handling hundreds of thousands of requests per second for a simple plaintext file, and seems t
Re: (Score:2)
Being a Java Developer, I am biased. Java lets you do things, large projects, deliver goods that need to be delivered. Tons of developers and extremely good set of third party libraries. Complete technology stacks from the likes of Apache and Spring.
Tomcat is one such solution, Java has such a large open source momentum behind it that I can't imagine the problems you are describing are show stoppers, else someone would have fixed them.
Last I checked, Maven had 860,000 artifacts, hard for a language to becom
Re: (Score:2)
Of course you don't need tomcat to write a web service in Java. I don't even remember the last time I used tomcat - typically I spin up a simple JVM process with an in-process http server (I like simplehttp, there are plenty of others) and take it from there. The nice thing about that approach is your process isn't tied to http as a protocol - want something else? Just add another in-process server for JMS or whatever. Where I work we front plain jvm processes with haproxy (apache is a dog, and even nginx i
Executive Summary (Score:5, Insightful)
Java - I don't want to pay microsoft
Re: (Score:3)
Re: (Score:3)
Whereas Java developers expect to get paid market wages so they can live in houses and buy cars, that sort of thing.
Re: (Score:2)
That's why I'm fighting to keep node.js out of my organization... Management might start getting ideas. I am NOT switching back to PBR!
Re: (Score:2)
Not sure why you think that? The Very Large Company I work for pays myself and my team very well to do node.js. Maybe they are rare in that they pay based on the type of work they do (building highly scalable services) instead of just by the technology they work in.
Ya, no. (Score:2)
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.
Hyperbolic much? Ya, no. It's still unthinkable.
Can someone explain node's supposed speed (Score:2)
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?
People love to praise the speed of Node.js. The data comes in and the answers come out like lightning. Node.js doesn't mess around with setting up separate threads with all of the locking headaches. There's no overhead to slow down anything. You write simple code and Node.js takes the right step as quickly as possible.
Re:Can someone explain node's supposed speed (Score:5, Interesting)
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
Re: (Score:2)
> 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 ru
Re: (Score:3)
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 [npmjs.com].
Re: (Score:3)
http://vertx.io/ [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...
That's where Vaadin enters the picture (Score:2)
Instead of writing JS both on client and server, the Node.js approach, you can write Java on both - that's how Vaadin Framework approaches web applications, by using GWT Java-to-JavaScript compiler for the client-side part. And usually you don't need to write ANY client code, and all client-server communications are completely invisible. You're just writing a UI in Java and can forget most of the client-side peculiarities.
Vaadin is also pretty flexible and allows mixing the approaches to a great extent, all
Re: (Score:2)
One can find an interesting niche project for anything... but probably the analogous meteor.js (as in Javascript) has a larger community. It may be to do with social reasons; the JS world could remain nimble while the Java world has matured, consolidated, slowed down and lost its coolness as well as edge. By now, those Java folks who were more ambitious, are testing Clojure, Scala or RxJava.
Massive over generalization much? (Score:5, Insightful)
>> 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).
Re: (Score:3)
Re: (Score:2)
Device driver writing is pretty niche. Wake me up when you can write a good web application in C.
This is not a mindshare battle...at all (Score:5, Insightful)
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.
Re: (Score:2)
> Javascript, despite it's popularity, is a terrible language. It's popularity is due to one thing, it is embedded in the browser.
A devil's advocate may answer that if JS were that terrible, it and the browser and the web (or Web 2) wouldn't have taken off. But this also offers no proof or reason.
Admittedly there's lots of dislikeable parts of JS, but we probably agree that for whatever reason it happens to be one of the most popular languages ever.
> There's a 4th reason that gets tossed around that I
Re: (Score:3)
> I don't understand 'so much logic'. You need to validate user input in the browser (with 'logic') to avoid server round trips for common errors; but you also must validate data on the server side, because you can't trust the incoming POST/PUTdata (it may come from a malicious agent). Why would you program the validation twice? The same goes for aggregations, filtering, sorting, utilities etc. - not to mention prerendering the page on the server side for faster initial load or some other purpose (SEO op
Re: (Score:2)
Check out Meteor, a framework built exactly on that idea - it's pretty crazy how easy it is to setup a rich *reactive* web app that keeps state sync across multilple devices. It's also crazy tiny for transmission size because only micro-snippets of data are
There's no battle (Score:3)
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 [tiobe.com].
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.
Moot Point and useless debate. (Score:4, Interesting)
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.
Re: (Score:2)
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.
Good point.
Re: (Score:2)
If you want to handle DB access in C++ with stuff like ODBC and write your own object relational mapper, or even simply manipulate "text results" from the DB and update "text lines" in the DB "manually" ... why not.
I prefer to have an OR-mapper that instantiates me real objects in memory.
However using stuff like GemStone in C++ was a nice time ... or having my own VM interception based OR mapping (VM in the sense of virtual memory, not virtual machine)
Meh (Score:2)
Epic Battle! (Score:2)
See the Titan that is Javascript take on the Giant that is Java, making them both seem normal size!
Object Oriented VS Functional Programming (Score:2)
Huh? (Score:4, Informative)
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.
node.js (eye rolling) (Score:2, Interesting)
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... [destroyallsoftware.com]
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 someon
Re:node.js (eye rolling) (Score:4, Insightful)
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 [caustik.com]
Re: (Score:3)
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;
What exactly is Apache Maven again? (Score:2)
Here's something I noticed that bugged me in the article.
It claims that Node.js wins for build process because Java's popular build processors require you to write XML.
Which makes me think they're not aware of what Apache Maven actually is.
Maven is much more than just a build tool. It not only is used to control the build order of a multi-project build, but it also downloads and installs your project's dependencies from the Maven Central repository.
You need a JSON parser in your project? Easy, just add a
Re: (Score:2)
The Node.JS ecosystem has this as well
Dependencies? Node Package Manager, Bower, and others
Build scripts? Grunt, Gulp, and others
And the best part of all? All the scripting, configuration files, etc, for these are all in Javascript and JSON (JavaScript Object Notation)... the exact same language and structure you are using for your primary development.
The same code formatting rules, editor configs, syntax highlighting, autocomplete, for your code are used for your config, your build scripts, etc
Re: (Score:2)
Dependency management on the JVM and the CLR is hard, so Maven is "a lot more than a build tool". In many other environments, dependency management is "comoditized". No one gives a fuck about the build tool being able to handle dependencies in Ruby-land or Node-world. Gem and Npm are good enough. Not perfect, but good enough.
So then you're left with only the actual build tool, and Maven/Ant/whatever are pretty bad at it. Sufficient, but still bad.
Confusing (Score:2)
Sun Microsystems should not have allowed Netscape to name their new web page scripting language "JavaScript".
Re:Ummmm.... (Score:5, Interesting)
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.
Re: (Score:3, Insightful)
Modern web sites shouldn't rely on Java plugins. There is only one native scripting language for the web, and that's js.
Re:Ummmm.... (Score:5, Interesting)
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!
Re: (Score:2)
Of course applets are dead, but Loconut1389 has mentioned them.
Re: Node.js is WEBSCALE! ! (Score:2)
It is badass rock store technology [youtube.com]
Re: (Score:2)
"did you just say lisp?" XDDDD
Re: (Score:3)
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.
Re:Ummmm.... (Score:5, Insightful)
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.
Re: (Score:2)
Heh, I used it for a project about 6 or 7 years ago. As far as I know, it's still around.
Re: (Score:3, Informative)
Re:Ummmm.... (Score:4, Interesting)
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. [infoworld.com] 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.
Re:Ummmm.... (Score:4, Insightful)
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 [langpop.com], 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.
Re:Ummmm.... (Score:5, Insightful)
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.
Re: (Score:3, Interesting)
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 l
Re:Ummmm.... (Score:5, Informative)
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
Re: (Score:2)
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
On the face of it, that's a pretty useful thing. There's a pretty big fly in that ointment, though, because the whole node.js development environment is still quite young. It's improving by leaps and bounds, and happily, people are learning from others's experience and mistakes. NPM, Grunt and a few other tools make packaging and deploying Node applications easier day by day.
So while developers—and sysadmins especially—have every right to gripe about Node as it stands, it's clearly in the ascen
Re: (Score:2)
And I can remember putting together ASP pages using JScript to run on IIS 4, more than a decade ago. Everything old is new again, I guess.
Re: (Score:3)
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 versio
Re: (Score:2)
My point is, node.js might itself be fine, but when the software that relies on it is so badly broken as this,
very true for the "npm" constellation, and possibly for the particular projects/products you have experienced. but this just reflects that it's a new platform and a hyperactive ecosystem. sure it has it's fair share of hipster crap, but just keep looking, there's quite solid stuff too. and there is a lot you can do with pure node.
besides, running java applications on linux has sufferd the very same problems for years (hell, it still does sometimes!), even when java was more mature back then than node is no
Node.js is server side (Score:3)
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/ [nodejs.org]
Re: (Score:3)
With the introduction of stylesheets there's really no reason to do scripting on the client anymore. All formatting can be done with the stylesheet and the server can process what it needs.
Re: (Score:2)
Node.js is the server. Perl and PHP are rarely used as servers. Python's Twisted stuff resembles Node.js in many ways, I believe. Not domain expert, I'm sure someone corrects me shortly.
Re: (Score:2)
There is a wave between fat-client and thin-client that will be everlasting cycle. I got out of sync, though and forgot on which swing of the cycle we are on. I am pretty sure that XSLT was a few cycles ago, though. :)
Re: (Score:2)
With the introduction of stylesheets there's really no reason to do scripting on the client anymore.
Please explain how to implement a 3D FPS game, or other interactive animation, using only static HTML and stylesheets.
Re: (Score:2)
Re: (Score:2)
Please explain how a web browser is the optimal medium through which to play a 3d first person shooter.
Optimal? Obviously not. But... it is in fact adequate these days, for an increasing set of games. And the web makes for fantastically low-friction deployment.
OTOH, A mobile web browser is not adequate except for the most trivial games, and a bad idea for most of them.
Re: (Score:3)
Re: (Score:2)
Why PHP or Perl on the backend, if you already need to use JS on the client, AND you can as well use it on the server?
For it is obvious that the modern web experience requires more and more dynamism, with fluid interactions, and this necessitates JS more and more (though with high bandwidth, low latency and high reliability may come dumber terminals which just receive video streams, but that's another 10-15 years).
Re: (Score:2)
Not knowing anything about Node.js except various blurbs and hype I've read, here's something I don't understand about this so-called "epic battle": assuming Java generally has better run-time performance than Javascript, couldn't Node.js become "Node.java" and then the battle would be won by Java? Specifically, the good things I've read about Node.js seem to revolve around its architecture rather than the language it happens to be written in.
Re: Node.js is server side (Score:2)
Re: (Score:2)
Interestingly, one of the most important but forgotten part about node.js hides in plain sight - it is that it's a NODE.
More traditional architectures have a strong separation of client vs. server. But node.js is already showing some of what it means that it's a node: :-) be it client, server, middleware etc.
- you can write your code once and run it anywhere
- your server may not be just one server: maybe it's a network of servers (nodes), e.g. with functional separation, domaln object separation or partitio
Re: (Score:2)
Nope.
Angular is an event driven framework for web/network apps. Node.JS is an executable that lets you run javascript on the server just like you can any other scripting language (PHP, Perl, etc...)
It is popular because it allows for single-language client/server webapps, which nothing other thean Flash/Flex has been able to do with wide support.
It also is extremely powerful in doing development-side preprocessing for client-side delivery. No need to learn Java in order to automate some JS/HTML/CSS tasks.
Re: (Score:2)
Re: (Score:2)
The compelling argument is having your code base in a single language. SPA applications don't require much from the service layer anyway....
Re:Oxymoron (Score:4, Informative)
Re: (Score:2, Informative)
Java is actually mostly back-end these days, while JavaScript is decidedly browser-only, so the whole comparison is nonsense.
Have you not heard of Node.js [nodejs.org]? It is server-side JavaScript, built around Google's V8 execution engine.
Re: (Score:2)
Node processes its own logic in 1 thread, but it still has multi-process support. So you can use clusters to have multiple instances running at once, or go old school with spawn/fork. It does confirm what you said: it is an old technology as far as multi-core goes, and you're not going to be writing a ray tracer this way.
For I/O intensive load though, just use clustering to have 1 instance per logical core and you're golden.
Node's claim to fame is really just its async-first I/O design. Some other environme