JavaScript Servers Compared

snydeq writes "InfoWorld's Peter Wayner test-drives five leading JavaScript servers and finds the results compelling though still a work-in-progress. 'I enjoyed the challenge and stimulation of rethinking everything I know about the server, but I still found myself hesitant to push these new ideas too far or too fast. The speed of experimentation and development is heady and exciting to the open source crowd, but it will probably seem scary to corporate developers who like the long, stable lives of tools from Microsoft or Oracle. Some of these platforms will probably morph three or four times over the next few years, something that won't happen to the good, old JSP standard in the Java world,' Wayner writes in review of Node.js, Jaxer, EJScript, RingoJS, and AppengineJS."

Comments

Second post!

[Anonymous Coward]

Second post! Would've been first if slashdot had a faster javascript server.

Third post

[Anonymous Coward]

Third post! Would've been first if slashdot had a faster javascript server.

First post!

[Anonymous Coward]

First post! Good thing slashdot has a fast javascript server.

The only good JavaScript is a contained JavaScript

[VortexCortex]

Or, i dunno... maybe we could use JavaScript to add flexible dynamic scripting to our existing stable Java platforms? ...otherwise what's the point? To use a domain specific language for tasks it wasn't designed for or is very good at?

Personally, I'd rather use a slow dynamic scripting language to glue the fast compiled language code together, (see: Perl), not write the whole damn server in slow JS.

Hint: Just use Rino and be done with this nonsense.

Print version of the article

[Kenz0r]

Read the print version of the article in one page:
http://www.infoworld.com/print/161969

You are a renegade.

[not already in use]

Remember when javascript had a terrible rep? Then people were all like, "No! It's totally awesome! It has first-class functions and prototypal inheritance!" Yeah, you remember. You read all the blogs. You had flashbacks to your not-so-pleasant encounters with javascript while developing client-side web applications. Then, all the sudden, prototypal inheritance became the in-thing, like popped collars. No matter how ugly or ridiculous it looked, you didn't want to be the only one who didn't think it was cool. You started writing gobs of hard to organize, impossible to refactor serverside javascript code. You convinced yourself, somehow, that you saved time by not having to issue some "compile" command. No, it just starts, DYNAMICALLY! What a cool word, dynamic -- like Ugg boots! And like wearing Ugg boots in the summertime, you tortured yourself searching for simple runtime errors. Static checking? Compiling? These are the things of white-collared enterprise folks.

You are not a white collared enterprise guy. You are a renegade. With a popped-collar. And ugg boots.

Re:You are a renegade.

[ya really]

Apparently you have never googled for javascript testing There's quite a few organized testing and unit frameworks for javascript out there and there are even IDEs that have support for them, such as Intelij IDE and its primarily php/web cousin, PHP Storm. I've use both of them on a regular basis and they both support NodeJS and have have built in javascript debugging/unit testing.

Re:You are a renegade.

[tixxit]

Prototypical inheritance didn't make JS cool, and JS wasn't the reason we hated JS 10 years ago.

The reason JS was hated so much 10 years ago was because of the DOM. That's it. Every browser had close enough implementations that you thought mucking about with the DOM would be simple... but they were different enough to cause endless headaches and hardcoded hacks to work around all sorts of quirks. Making a simple drop-down menu meant coding everything from scratch, maintaining essentially 3 different versions of the same code for different browsers.

JS is cool today because of many things.

The convergence of browser features and DOM implementations towards the standard. Coding JS to work cross browser has definitely gotten easier.

The proliferation of browser libraries that abstract the browser away from us developers and handle all the little DOM implementation differences for us.

There is a solid (and growing) set of best practices for client-side programming (eg. progressive enhancement, event-driven programming, etc.). This has dramatically cut down on the amount of time spent (re)writing JS and let's people create better abstractions that work well with JS.

The functional aspect of JS is definitely nice, and allows for some very concise code (considering) to be written. However, it can also be eschewed for those that are not comfortable with functional programming.

JS is SIMPLE. In the browser it is single threaded. You don't need to worry about concurrent programming. The language itself is also dead simple, but still very powerful if needed.

However, I don't think people think prototypical inheritance is really all the grand. It's simple, is what it is and that fits well with JS (simple). When most the original crop of modern JS frameworks came out, the first order of business was to build a more traditional class-based inheritance approach. I know it doesn't fit well with your "renegade" theory, but it's true. People now seem to be getting comfortable with prototypical inheritance, but I don't think you'll find many people willing to extol its virtues.

Also, JS has first class functions, yes, but so do LOTS of other languages. I'm not sure why you're picking on JS developers for liking some aspects of functional programming.

Re:The only good JavaScript is a contained JavaScr

[bmuon]

Personally, I'd rather use a slow dynamic scripting language to glue the fast compiled language code together, (see: Perl), not write the whole damn server in slow JS.

That is the whole idea. Write processor intensive tasks in a fast compiled language (C or whatever) and glue them with a server that is good at handling asynchronous requests. That's what Node.js is about and JavaScript is actually a good fit for it because of closures.

like Netscape FastTrack & LiveScript in '96?

[darkeye]

wow, how is JavaScript on the server side new?

anyone remember the Netscape FastTrack server, and the LiveWire environment, where LiveScript was used to code both server & client side of a web application. LiveScript being of course the original name of JavaScript. this was back in 1996, merely 15 years ago...

history seems to repeat itself...

Re:like Netscape FastTrack & LiveScript in '96

[betterunixthanunix]

We used to call it "SSJS" -- server-side Javascript. Times really have not changed, but why would you expect them to? Despite the superficial changes, the underlying structure of the Internet and the Web has not really changed. We have not really seen much in the way of "revolution" in the past 15 years, just incremental changes (or if you would prefer, "improvements") to the way everything works.

Re:Awful Article

[dgatwood]

The article made it sound like you have one instance of a JavaScript server that runs as part of your web server (Apache, presumably) and all JavaScript requests get funneled into a handler, all within a single thread. Apparently, that's not the case. Thus further emphasizing the point that the article doesn't describe things too well. :-)

Re:The only good JavaScript is a contained JavaScr

[the linux geek]

The Javascript engines in browsers come nowhere close to the runtimes for the mainstream server-side platforms (J2EE, .NET, etc) in performance. It's not always orders of magnitude difference anymore, but one of those runtimes will still reliably be several times faster than the fastest JS engines.

Re:The only good JavaScript is a contained JavaScr

[Anonymous Coward]

Hi. We (I'm a google employee) have GWT, which compiles java to javascript, but we don't actually use it much. Most projects I'm aware use Javascript written as javascript. We do use build scripts to pre-process, include dependencies, and minimize/obfuscate, though.

Re:The only good JavaScript is a contained JavaScr

[GreyLurk]

In terms of numerical computation? Probably. In terms of actual useful web applications, Node.js meets or beats compiled Java in the benchmarks that I've seen, even with the Java Code using esoteric and not commonly used behaviours like Non-Blocking IO: http://www.subbu.org/blog/2011/03/nodejs-vs-play-for-front-end-apps

V8 is actually really damn fast.

Re:The only good JavaScript is a contained JavaScr

[CapOblivious2010]

Honestly, if you want a fast, dynamically typed, interpreted scripting language, then look no further than JS.

Honestly? Well, honestly, the more code I write/debug in dynamically-typed interpreted languages, the more I like statically-typed compiled languages (and it has nothing to do with execution speed)

Re:The only good JavaScript is a contained JavaScr

[Billly Gates]

The bottleneck on a dynamic webserver is either network or SQL access times. It does not matter if you have the fastest web server software in assembly when it takes 1,000 ms to access a SQL query to display for a client's browser.

Static it is a different story, but who besides a small mom pop page uses simply static pages anymore? So this is why Java took off a decade ago while slashdotters scratched their head wondering why could something so slow and slugish could ever scale. It is about SQL