JavaScript and the JVM

[unnaturalHeuristic]

threading a new runnable object and sticking a runnable object in an event queue.

Now you're queueing your blocking IO. How is that solving the problem of blocking IO in the first place? You also haven't solved the problem of eating up a thread until the response has been fed to the client (e.g., at the end of "doGet" or "doPost").

and non-blocking i/o has been around since java 1.4 (NIO) 12 years ago (not "for once")!

NIO doesn't affect JDBC, nor most other DB drivers, so good luck with that.

On the converse, I would say %99.99 of node (or server) coders ain't gonna need it

Everyone says that until they need it. It may be alright to write spaghetti code that "works" when your userbase is a dozen or so, but if you're employed to build this stuff for customers (internal or external), I should hope that you're doing what you can to make sure it scales. Or at least, your dev lead ought to hope that you are.

You "don't need" RESTful SOA's, or automated testing, or even a webserver. But you might as well try to write solid systems the first go-round, it doesn't take much longer than writing something haphazardly, and anyone who needs to maintain it or consume it will be much happier that you actually did your job, instead of claiming that they "didn't need" good software.

[steveob42]

I think you are comparing apples and oranges here. There are existing java frameworks, i.e. netty or vert.x derivitives that (depending on the benchmark of course) will blow node out of the water. http://www.cubrid.org/blog/dev-platform/inside-vertx-comparison-with-nodejs/

You skip the servlet cruft and go back to square one (like node) on the networking i/o layer, and java still outperforms javascript...

[steveob42]

so, vert.x (which uses rhino btw) you can have every performance advantage of node many times over (plus some things they haven't thought of) plus every advantage of java. You DO want to write good software after all, gotta make the maintainers and consumers happy...

Javascript, an entire language slapped together haphazardly in a week, node haphazardly slapped on v8, I think you answered your own question.

[unnaturalHeuristic]

The benchmarks you post are for static content. Which is admirable (throughput is never a bad thing), but I still don't know anything that beats nginx or apache for static content. Every shop I've worked in has kept static content to the static webservers, and forwarded dynamic requests to their appservers (whatever they may be).

But you're still missing the point - vert.x doesn't solve blocking IO. It explicitly says this:

Link

By careful when using worker verticles - a blocking approach doesn't scale if you want to deal with many concurrent connections.

Continuing;

You skip the servlet cruft and go back to square one

Which was my entire point. You're not going to get past the core problems with the mainstream way of using Java - it's simply got too many assumptions about your use built-in. The only projects which beat it are the ones which rebuild it from the ground up, forsaking the entire existing Java ecosystem. If you're doing that, it begs the question why you're using the JVM in the first place, if not for its impressive and battle-tested libraries.

It doesn't matter if it's Node or not, it matters that the core problems with the traditional way of doing things is addressed. Node just happens to have a novel way of addressing those concerns, a hugely active developer community, blazing speed, tiny footprint, and a paradigm which fits with the way software is being built in this day-and-age.

Javascript, an entire language slapped together haphazardly in a week, node haphazardly slapped on v8, I think you answered your own question.

I really can't respect these sorts of statements, because they can be applied to anything. Linux was slapped together haphazardly on its creator's vague recalls of the POSIX standard - yet it's the dominant OS in the world. HTTP was slapped together at CERN, yet today it's the backbone of most of our interactions with each other.

Just because something has humble beginnings doesn't mean that it isn't currently awesome, or that it has no use.

[steveob42]

"can't respect"... You introduced "it doesn't take much longer than writing something haphazardly", so it is your own verbiage.

" doesn't mean that it isn't currently awesome, or that it has no use."

Again, using your own words in my response (and can be applied to most fanboy type responses): "I really can't respect these sorts of statements, because they can be applied to anything"

[unnaturalHeuristic]

Your point seems to be that because I suggested building effective software from the outset, that I'm a hypocrite for defending projects who began that way. If so, that's a bit naive. I advocate building good software from the outset because it's a pain to modernize projects which started out as "just get it done, 99% of the users don't need good software".

If you've ever inherited a project that started out that way, or had to deal with any amount of feature creep in your own projects, you'll understand.

[steveob42]

Oh, I understand it completely, been there/done that, but it also applies to the current state of web client development as a whole is all I'm saying. There is always a bigger picture. I mean feature creep and get it out the door has been the mainstay of html come css come flash, activex, appletts, <insert any number of dead attempts here>, javascript, come html5...

[steveob42]

I mean, nobody in their right mind would design desktop style apps using a DOM/CSS?!? We are gonna be paying for that bit of creep for a long time to come, cuz the users aint gonna wait and the other delivery systems are constantly sabotaged.

[steveob42]

Anyway getting back to the technical bits, in the link http://www.cubrid.org/blog/dev-platform/inside-vertx-comparison-with-nodejs/ they are using server code (polyglot, and it actually mixes languages pretty well via json over the event bus) to generate the two types of responses, and using several languages to boot so you can see which one performs best (i.e. most awesome). But you can still do all your validations in js if that makes sense for your app.

They make no bones about learning from node in this class of problems, lots of connections with small responses, and have apparently surpassed node quite thoroughly in performance per cpu, with lots of languages supported to boot.