Become a fan of Slashdot on Facebook

 



Forgot your password?
typodupeerror
×
Java Programming IT

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."
This discussion has been archived. No new comments can be posted.

Java Vs. Node.js: Epic Battle For Dev Mindshare

Comments Filter:
  • Fight! (Score:5, Funny)

    by Anonymous Coward on Wednesday February 18, 2015 @04:09PM (#49082217)

    Hipster Crap vs Crap. Fight!

  • by Anonymous Coward

    That's all I can think.

  • by QuietLagoon ( 813062 ) on Wednesday February 18, 2015 @04:21PM (#49082299)
    Is there a real battle going on? Or is the battle in the head of some writers who are creating an ersatz battle in order boost their page hit count?

    .
    Computer media are usually pretty dull, so there's nothing like a supposed battle to up the interest.

    • 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.

      • 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

        • by robi5 ( 1261542 )

          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.

          • by Jane Q. Public ( 1010737 ) on Wednesday February 18, 2015 @10:17PM (#49084381)

            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.

  • by EmperorOfCanada ( 1332175 ) on Wednesday February 18, 2015 @04:22PM (#49082303)
    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.
    • by kenj123 ( 658721 )
      I think node.js has Microsoft scared. .net is setup to allow mostly server side code spit out bland, minimal html and work on any browser. but browsers are becoming standardized so javascript acting on the DOM is portable across browsers. node.js on the server, javascript and html on the client has the potential to make .net irrelevant. I'm surprised node.js didn't come along awhile ago, but it would have been useless without html 5 and cross browser support for javascript.
  • by Just Some Guy ( 3352 ) <kirk+slashdot@strauser.com> on Wednesday February 18, 2015 @04:23PM (#49082305) Homepage Journal

    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.

    • by farble1670 ( 803356 ) on Wednesday February 18, 2015 @04:31PM (#49082369)

      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]

    • And Java can be concurrent as well. It depends on the framework you are using to run it. Tomcat is thread bound, but things like akka and vert.x are not. In fact I suggest you look at the vert.x site to examine the speed increases you get on multi-core java with vert.x vs. node.js. Plus vert.x is a polyglot so you can also do Scala if it makes more sense. It is all about using asynchronous programming techniques which you HAVE to do in JavaScript, since it is single threaded, and you can do with Java.
    • by IamTheRealMike ( 537420 ) on Wednesday February 18, 2015 @04:39PM (#49082413)

      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.

      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.

      • The JavaScript world meanwhile has developed a kind of Stockholm syndrome in which obvious weaknesses are spun around to become strengths.

        Damn, this is both +Funny and +Insightful. Wish I had mod points, and the ability to assign two of them to your post.

      • by Just Some Guy ( 3352 ) <kirk+slashdot@strauser.com> on Wednesday February 18, 2015 @05:24PM (#49082711) Homepage Journal

        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.

      • by sribe ( 304414 )

        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.

    • 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.

    • by sribe ( 304414 )

      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.)

    • 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?

  • Comment removed based on user account deletion
    • by new_01 ( 4014887 ) on Wednesday February 18, 2015 @04:35PM (#49082393)
      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.
    • 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

    • by mrops ( 927562 )

      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

    • by radish ( 98371 )

      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)

    by netsavior ( 627338 ) on Wednesday February 18, 2015 @04:28PM (#49082341)
    Node.js - I don't want to pay my programmers
    Java - I don't want to pay microsoft
  • 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.

  • 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.

    • by IamTheRealMike ( 537420 ) on Wednesday February 18, 2015 @05:31PM (#49082763)

      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

      • by robi5 ( 1261542 )

        > 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

    • 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].

    • 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...

  • 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

    • by robi5 ( 1261542 )

      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.

  • by JustNiz ( 692889 ) on Wednesday February 18, 2015 @04:50PM (#49082483)

    >> 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).

    • Most of the Internet also runs on C and C++. Networking firmware, web servers, browsers, hell node.js is written in C++. I don't see any shortage of demand for people who work in a language that doesn't need a VM to run.
    • by Eythian ( 552130 )

      Device driver writing is pretty niche. Wake me up when you can write a good web application in C.

  • by MillerHighLife21 ( 876240 ) on Wednesday February 18, 2015 @04:57PM (#49082539) Homepage

    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.

    • by robi5 ( 1261542 )

      > 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

      • > 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

    • 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.

      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

  • by quietwalker ( 969769 ) <pdughi@gmail.com> on Wednesday February 18, 2015 @05:00PM (#49082565)

    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.

  • by marienf ( 140573 ) on Wednesday February 18, 2015 @05:09PM (#49082607)

    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.

    • by sribe ( 304414 )

      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.

    • 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)

  • by tcr ( 39109 )
    Seen both flavours of web frameworks. For comprehensibility to on-board new devs to unfamiliar code, I'd go with something like ExpressJS any day. This is from comparisons with Java and PHP web frameworks I've encountered on projects. Suspect that many who pontificate haven't actually used this stuff for real, as the lack of a type system has had F all impact for me when working on real NodeJS projects.
  • See the Titan that is Javascript take on the Giant that is Java, making them both seem normal size!

  • This would be a much more interesting battle. Java, Node, [Name your lang here] is just a vehicle
  • Huh? (Score:4, Informative)

    by nitehawk214 ( 222219 ) on Wednesday February 18, 2015 @05:31PM (#49082761)

    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.

  • by bored ( 40072 )

    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

    • by Shados ( 741919 ) on Wednesday February 18, 2015 @09:08PM (#49084041)

      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]

    • by noda132 ( 531521 )

      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;

  • 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

    • 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

    • by Shados ( 741919 )

      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.

  • Sun Microsystems should not have allowed Netscape to name their new web page scripting language "JavaScript".

The best things in life go on sale sooner or later.

Working...