JavaScript Servers Compared 132
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."
Second post! (Score:4, Funny)
Third post (Score:3, Funny)
Third post! Would've been first if slashdot had a faster javascript server.
First post! (Score:2, Funny)
First post! Good thing slashdot has a fast javascript server.
Burn the bible (Score:1, Interesting)
Burn the bible [goo.gl]
The only good JavaScript is a contained JavaScript (Score:3)
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 [mozilla.org] and be done with this nonsense.
Re: (Score:1)
To use a domain specific language for tasks it wasn't designed for or is very good at?
JavaScript works very well as something it wasnt designed for every time you use GMail, Meebo or any other application that's running within the browser these days.
Re: (Score:2)
Why wasn't it designed for those applications? It's a general purpose programming language. Perhaps the browser's APIs (DOM) weren't designed with those applications in mind, but even the first standardization of the DOM (DOM Level 1) APIs could implement most if not all of those applications' features, one way or another (eg. submitting forms to a frame—a feature introduced with JavaScript in Netscape 2—and periodically appending new scripts which contain server data).
There's a lot of reasons t
Re: (Score:1)
Guess what.
The leading proponent of all 5 Javascript Server projects is....Intel!
Re: (Score:2)
uhm, thats pretty much EXACTLY what Javascript was intended for ... you do know where it came from ... right?
Re: (Score:2)
hmm, maybe thats why the google applications are actually compiled into javascript instead of being written in it
No idea why this was posted anonymously.
+1 Profoundly Fucking Insightful
Re: (Score:2, Interesting)
JavaScript is usable, but.... (Score:2)
Nobody would.
Javascript is adequate. I am never going to complain that Javascript somehow keeps me from doing my job. I can do anything in Javascript. I have bigger fish to fry and the need to occasionally write Javascript doesn't make the list of my "real" problems.
But Javascript sucks. It is wrong. I would rather program in PHP (!) than Javascript. (Maybe even perl? Well, no. I would rather program in Javascript than
JS is MUCH, MUCH better than PHP (Score:2)
- It has idiosyncracies, but several orders of magnitude fewer than PHP.
- It is standardized and has multiple, F/OSS implementations
- Its syntax has much less line noise
- It probably has the fastest implementations of all scripting languages; last time I checked (might have changed) the only contender was LUA-jit or something.
- The various implementations are thoroughly stress tested in browsers by something like a billion users.
- Similarly the high stakes in browser securities guarantee that there is a str
Re: (Score:2)
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.
Re: (Score:2)
Re: (Score:3)
Re: (Score:3, Interesting)
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 [subbu.org]
V8 is actually really damn fast.
Re: (Score:2)
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
Re: (Score:2)
Your definition of 'lightning fast' is my definition of 'painfully slow language' even in the new JS engines.
Re: (Score:1)
Re: (Score:1)
I prefer my webservers to run purely on ASICs. Sure, updating the web site is a little costly, but I can handle more traffic than Amazon.
Re: (Score:2)
Re: (Score:2)
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: (Score:2)
Print version of the article (Score:5, Informative)
http://www.infoworld.com/print/161969 [infoworld.com]
You are a renegade. (Score:5, Funny)
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: (Score:2)
Re: (Score:2)
Ever wrote something in Perl?
Even Perl, believe it or not, actually has Test::Unit, Test::Simple, Test::Harness, and about eighty zillion logging and debugging systems.
Javascript, thats got... uh...
Re: (Score:2)
Perl does not have Test::whatever. CPAN has it. And there's nothing preventing anyone from implementing test frameworks in JS. In fact there are already a number of them out there, jsUnit to name an example off the top of my head.
Re: (Score:1)
Re: (Score:3)
Re: (Score:1)
Re: (Score:1)
Re: (Score:2)
You know, even being forced to use it wasn't so bad... for small jobs... in the corporate environment.
That was about 8 years ago too.
JS has tools.
Re: (Score:2)
Ever wrote something in Perl?
Only once, and I took fifteen showers afterwards and still felt dirty.
Re: (Score:2)
perl -ne 'chomp; (/start/
Re: (Score:2)
If you learn the syntax inside and out, perl has some of the most concise verbs I've ever used. 90% of the perl scripts I've written were 1 liners (where a line can exceed 200 characters). perl -ne 'chomp; (/start/ ... /end/) && $words{$_}++; END { print join "\n", map { "$_ : $words{$_}" } keys %words }' file.txt
200+ char perl one-liner scripts? That's software engineering for you. Hurray for debuggability and maintainability...
Re: (Score:2)
A) open up a stupid gui and manually count them (if I'm lucky, I can sort by extension - but good luck if they're spanning multiple directories)
B) I can do a file-system search for *.log files,
Re:You are a renegade. (Score:5, Informative)
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: (Score:1)
Never have been entirely sure why people are so quick to pee all over JS. After having done Perl, Python, C# and Actionscript for corporate production as well as private there are benefits to all of them (less so Actionscrip
Re: (Score:1)
Re: (Score:2)
I'm not sure what the "module" and "require" patterns have to do with prototypical inheritance. Ruby, Python, and Groovy (for example, there are many others) are all class based and allow metaprogramming and/or "monkey patching," so "dirty object decoration" is not a trait only found with JS.
Web workers are very restricted. They run in a completely different scope and can merely pass messages to the main UI thread.
I wasn't peeing on JS. I love Javascript. The only negative thing I mentioned was that prototy
Re: (Score:1)
C (or most any other language) is single threaded too, and you don't have to worry about concurrent programming. That is, until a single thread just isn't good enough anymore and it's time to break out a threading library. Then you have to worry about concur
Re: (Score:1)
And if anyone is up for some reading this series is pretty nice:
http://howtonode.org/object-graphs
As well as 'JavaScript: The Good Parts'- Douglass Crockford
Re: (Score:2)
The key difference is that it is not even possible to spawn a thread in a browser. But you are right, that isn't a benefit.
Single threaded is actually harder - you still have concurrency issues because even simple operations must be done using an asynch event pattern. Multithreading was created because simulating concurrency in a single-threaded app is hard.
Re: (Score:1)
There's probably a lot of concurrency one could get away with using workers.
Re: (Score:2)
Threads were a lightweight fork(2) replacement.
Re: (Score:2)
Re: (Score:2)
JS is SIMPLE.
Hardly. JS is nuanced. Undefined vs null? == vs ===? Simple in the fact that it doesn't contain crazy "advanced" language constructs like namespaces or imports so you ultimately have to bastardize the ever-loving shit out of other language constructs to accomplish the same thing? Yes, it's simple in the sense that it will let you do almost anything and you will pull your hair out trying to figure out what the hell is going wrong.
In the browser it is single threaded. You don't need to worry about concurrent programming.
Well played, sir. Pretend that an inherent limitation is somehow a feature.
Re: (Score:2)
Hardly. JS is nuanced. Undefined vs null? == vs ===? Simple in the fact that it doesn't contain crazy "advanced" language constructs like namespaces or imports so you ultimately have to bastardize the ever-loving shit out of other language constructs to accomplish the same thing? Yes, it's simple in the sense that it will let you do almost anything and you will pull your hair out trying to figure out what the hell is going wrong.
Undefined vs. null is nuanced? Hardly. And == vs. ===? Pretty much every language defines a difference between equivalence and object identity, whether its Python (== vs. is), Java (equals vs. ==), or Javascript (== vs. ===). What I meant by simple is that there aren't a whole lot of "extras" in the language. Every language is nuanced to the extent you are describing.
Well played, sir. Pretend that an inherent limitation is somehow a feature. As if, if I were to choose another language, I would be forced to write multithreaded code.
It's a design decision, there is no reason they couldn't have allowed threads. Also, it is a design decision that isn't always immediately app
Re: (Score:2)
The reason JS was hated so much 10 years ago was because of the DOM. That's it.
That's just a lie. The reason people hated it was stated by the parent you replied to. It had the appearance of a toy language if you were coming to it from a language like Java. That's why all the hipsters starting talking about prototype inheritance and first-class functions.
They're right that those are cool features for a toy language, and you can bend JavaScript to do stuff to get around lacking features, but it's still not a good modern language.
I don't see what JavaScript has for appeal on the server
Re: (Score:2)
Outside of the problems of not having namespaces and real inheritance (see my post above where the problems really are, and those are overlooked often from an academic point of view)
I would not really call javascript that simple once you do bigger systems with it. Then you run into the typical sets of problems of purely dynamic languages that you have to work a lot over unit tests and you have to add a lot of parameter assertions to every function to avoid hidden pitfalls which are caused by no til weak typ
Re: (Score:2)
Clearly dynamic languages' biggest flaw is that they have no compile time type checking. However, since this is the big demarcation line between static & dynamic languages, I can't really fault dynamic languages here. As always, the right tool for the right job is the best credo for most professions.
I'd suggest you take a look at Zope if you want to see a good example of a complex application developed in a dynamic language (Python). Zope is built on a rather nice component-oriented architecture which h
Re: (Score:2)
I have not been talking of not being able to build those systems in dynamic languages, i have done that myself but more along the lines of productivity per day and once you cross a certain loc barrier dynamic languages do not really have an advantage that much anymore.
The creators of Zope probably would have gotten similar results in a strongly typed language in about the same amount of time.
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
Heck I earn my living currently with javascript on professional framework level but I still think the language is not cool.
Namely the lack of namespaces and the lack of real inheritance are my biggest problems.
And before someone comes you can write those with maps and prototype inheritance just think of this:
a) Maps are slower than real namespaces and to get a better performance you have to add lookup indices yourself and even then you are not even close to the real thing.
b) Given that there is no real inhe
like Netscape FastTrack & LiveScript in '96? (Score:2)
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: (Score:3)
Re: (Score:1)
Or .jsp, which has been around for quite a long time.
Re: (Score:2)
jsp is java, not javascript, which is entirely different other than the name.
Re: (Score:1)
Re: (Score:2)
Re: (Score:1)
Re: (Score:1)
We do remember it. Probably because it was the first line of the article.
Re: (Score:2)
history seems to repeat itself...
This [habreffect.ru].
Don't worry - I'm pretty sure that, 10 years down the line, they'll be touting the addition of static typing to JavaScript as the next big thing to improve productivity etc.
Re: (Score:1)
Re: (Score:2)
they are supposed to add statically typed closure you insensitive claud !
Re: (Score:1)
Re: (Score:1)
Yup mod parent up.
Re: (Score:2)
You could use JScript in ASP too. Thankfully I never had to.
Re: (Score:1)
Ah,
It meant I didn't have to bother learning VB in order to write ASP Pages, and it looked a lot closer to the PHP, C and Java I was used to writing.
Re: (Score:1)
Err... <%@ Language=Javascript%>
Callbacks and Promises (Score:1)
"I'm increasingly convinced this asynchronous callback style of programming is too difficult for most developers to manage," Robinson said. "Without extreme discipline it can easily lead to 'callback hell,' with deeply nested callbacks and complex code to implement logic that would be simple on a synchronous platform." What's next for him? He sees the older framework being rethought and reworked using the best ideas from Node.js. In place of callbacks, he sees ideas like "promises," "co-routines," "actors," and other objects that hang on to the information in the variables for use later. These objects may be easier to juggle than the callbacks.
Callbacks and promises are not mutually exclusive. In particular, a promise API can be built on top of callbacks. This has been well-understood for a long time in both the Ajax world (e.g. dojo.Deferred [dojotoolkit.org]), and in Node.js development (e.g. node-promise [github.com] module by Kris Zyp). So, I think this critique is a bit unwarranted.
Re: (Score:2)
Ultimately, what you want to do is to hide the whole call-with-continuation pattern that is the fundamental building block of async under a thick layer of syntactic sugar in the language, such that your async code looks almost exactly the same as the corresponding synchronous version, with marker keywords to identify "points of asynchrony" (where the rest of the code path is an implicit continuation, and a closure is generated for it under the hood). Kinda like this [msdn.com] in the (yet upcoming) C# 5.0.
Good thing i
Re: (Score:2)
Ultimately, what you want to do is to hide the whole call-with-continuation pattern that is the fundamental building block of async under a thick layer of syntactic sugar in the language, such that your async code looks almost exactly the same as the corresponding synchronous version,
There's a theoretical argument (presented by a speaker in EE380 at Stanford last spring, but I don't have the ref handy), that the call-with-continuation model is a superior way to deal with concurrent transactions compared to the lock-and-block model. With the call and continuation model, most of the programmer-confusing headaches of real concurrency go away. The amount of state per transaction is low, since you only save what you need. This reduces memory consumption.
There's something to be said for th
Re: (Score:2)
There's a theoretical argument (presented by a speaker in EE380 at Stanford last spring, but I don't have the ref handy), that the call-with-continuation model is a superior way to deal with concurrent transactions compared to the lock-and-block model. With the call and continuation model, most of the programmer-confusing headaches of real concurrency go away. The amount of state per transaction is low, since you only save what you need. This reduces memory consumption.
I thought that's an established wisdom by now? I mean, that's why most server-side frameworks are embracing the continuation model (and most of current JS-on-the-server hype is more about such frameworks, which just happen to be written in JS). You still have code running concurrently there, though - the point is to get it running into much smaller chunks, such that, as soon as one task blocks on something, the thread can be immediately reused for another task.
It's more than just supporting high load, thoug
Re: (Score:2)
Really the only difference between a synchronous and an asynchronous model is that you shift the burden (and the resources) of multitasking from the the operating system to the application. Under the hood, everything is always asynchronous. It's just that in a synchronous multi-threaded program the OS deschedules a thread whenever you do a blocking call, instead of doing it yourself. So you can consider threads to be syntactic sugar for any I/O bound program.
Both yes and no. Sure, the OS will use processing time to run another thread while one is blocked, but it has to preserve its complete call stack - e.g. on Windows, that's the default reservation of 1Mb for every thread, plus whatever it may have incurred on top of that. With async model, the continuation closure only needs to preserve what it needs to run after control is returned to it, which can be significantly less.
More importantly, you usually can't spawn infinitely many OS threads - they are more lig
Re: (Score:2)
In reality, the "win" from the asynchronous model is that you as an application developer have more knowledge about that state that needs to preserved than the OS probably will ever have
It's not even me as application developer - it's the compiler. I just write an anonymous function, and use whatever variables I need within its body - the compiler figures out which of those come from the outer scope, and creates a closure object accordingly.
I agree that for single threaded client side programs, it is a real boon not to have to use threads, and still be responsive while performing I/O.
One other subtle benefit is for platform/framework authors: it lets you force developers targeting your platforms to be asynchronous (and hence responsive), without requiring them to fully understand and know how to use threads and locks - just make sur
V8 :( (Score:2)
Too bad that chrome's V8 javascript engine does not support multithreading, thereby making itself unsuitable for server-side scripting.
(Of course, you can run each script in a separate process, but that is way too expensive)
Re: (Score:2)
PHP doesn't properly support multithreading. It must also be unsuitable for server-side scripting. And because running each script in a separate process is way too expensive, nobody would ever try to use something like mpm_prefork or fastcgi to get around that limitation. That'd be silly.
Ouch (Score:2)
It seems the author of the article knows little about how real servers use multithreading to reduce latency.
From the article:
Node.js is one good solution. It uses only one thread for your server and everything runs within it. When the requests come flying in, Node.js takes them one at a time and hands them to the single function that was specified when the server is invoked.
Sadly, one of the best javascript engines is V8 (used in google chrome), and it does not support multithreading.
Re: (Score:2)
one of the supposed benefits of stateless monadic code is that it is somewhat more parallelizable than traditional imperative or stateful OO paradigms.
Could 'clean' js be marked with annotations and magically threaded behind the scenes by the javascript runtime?
(above is hearsay - i am not a functional programmer)
Re: (Score:2)
Nice idea, but although javascript is a functional language, it is not a pure functional language (it has side-effects). This probably makes that a lot more difficult.
Server side ActionScript ? (Score:2)
I've been intrigued by this whole serverside js thing since i started doing a lot of flex and therefore using actionscript a lot. :)
Callbacks are so cool
But thing is js is still a mess if you have a lot of code.
What we really need is server side actionscript to get proper OO syntax, strong typing and namespaces.
If i ever got that, i'd be a happy camper !
Re: (Score:1)
Adobe showed off a demo of this at MAX 2009, so I suspect that they're going to be pushing for it at some point in the near future. AS is annoying though, when you have to switch between AS and C# or Java, and muscle memory throws your type declarations into the wrong syntax.
Re: (Score:2)
Actually you can build namespaces in javascript not strong typing though, but even then it is still a mess. Namespaces and inheritance constructs cannot be picked up by documentation tools automatically you have to roll them into the doc tools you have at your disposal manually and if you roll this stuff in javascript yourself or via third party lib the performance will never be as good as the real thing.
To my knowlege a prototype inheritance construct via call and prototype functions like you would get in
Clarification Needed (Score:2)
I'm about 8 years out of date on my web development, but can someone give me a quick rundown on the subject of the article vs. what I know as server side javascript, aka ASP classic?
Still waiting for my... (Score:2)
... optimized animated .gif server so ytmnd.com [ytmnd.com] could load 5GB loops faster.
Re: (Score:2)
While we're at it, the JavaScript engines are all single-threaded per server? So you get no benefit from having multiple cores or multiple CPUs in your server? What a colossal train wreck of a design.
Re: (Score:1)
That should be solved in the next version of the Linux kernel which allows you to run multiple processes _per machine_. Think of it! "Multitasking" is the future!
Re: (Score:1)
Re: (Score:3)
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: (Score:2)
Since we seem to be comparing JS to Java, it's worth noting that server-side java frameworks such as EJB discourage or even forbid explicit thread creation, arguing that "the container" is much better at managing concurrency and lifecycle than the average JavaEE code-monkey.
Re: (Score:2)
Node is working on adopting Web Workers, but it already has the ability to spawn new processes.
Re: (Score:2)
While we're at it, the JavaScript engines are all single-threaded per server? So you get no benefit from having multiple cores or multiple CPUs in your server? What a colossal train wreck of a design.
Fire up a different process per core and route each request through a load balancer. Alternatively use web workers to service the requests with the main thread acting as the conductor which spins them up and services common functionality.
Re: (Score:2)
PHP is also single-threaded per server; PHP doesn't jive well with multithreading. So what we get is mpm_prefork with one instance of mod_php per process, or alternatively, a web server using fastcgi that spawns multiple PHP processes.
Re: (Score:2)
Just the tip of the fudberg: - States 2MB for each Java thread created (WTF... Where did they pull this number? Isn't the default stack size for each thread 512KB?)
Default is 512k, yes. But there are some extra details: 'Java stack size myths' [www.odi.ch]
Re: (Score:1)
Re: (Score:2)
You can't make method calls. You can communicate via explicit message passing, like a Unix pipeline. That's why we have bidirectional sockets.