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.

Re:First post!

[Anonymous Coward]

Well, I guess that explains how Obama's birth certificate ended up coming in behind the Nordyke twins'. Apparently they were using slashdot's servers to process them.

Burn the bible

[Anonymous Coward]

Burn the bible

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

Re:The only good JavaScript is a contained JavaScr

[Anonymous Coward]

Shhhh.... (quietly) every generation has to reinvent the wheel so they can have a job. Don't tell anybody. Just keep your mouth shut.

Re:The only good JavaScript is a contained JavaScr

[Fusselwurm]

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.

Awful Article

[Anonymous Coward]

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?)
- "Just as businesses try desperately to avoid tying up capital in inventory, a programmer's job is to think like a factory boss, treat RAM as capital, and avoid consuming any of it." (Holy Crap, don't know where to start! Aren't we in the age of memory is the new disk? Use it wisely, don't avoid using it all together!)

Re:Awful Article

[dgatwood]

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:Awful Article

[badboy_tw2002]

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:Awful Article

[gilleain]

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'

Re:Awful Article

[Transfinite]

Oh god! that's why you have such projects as multi-node. If you bothered to figure it out for yourself you might realise why single threaded apps can be good in the right situation.

Re:Awful Article

[Transfinite]

Yes, generally "The default thread stack size varies with JVM, OS and environment variables. A typical value is 512k". However one approach is to have a single thread and use that more efficiently. Nothing wrong with that. NodeJS along with nginx can solve the C10K problem out of the box, Tomcat can be tuned to deal with more than 10K concurrent connections, but eventually your multi threaded app *could* eat up all you memory.

Re:Awful Article

[omfgnosis]

Node is working on adopting Web Workers, but it already has the ability to spawn new processes.

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:Awful Article

[DrXym]

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:Awful Article

[Guspaz]

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:Awful Article

[ChunderDownunder]

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.

No real comparison.

[Anonymous Coward]

They are all slow, insecure, malware engines.

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.

[cyfer2000]

Ever wrote something in Perl?

Re:You are a renegade.

[vlm]

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:You are a renegade.

[timothyf]

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:You are a renegade.

[Transfinite]

Uh... is got https://github.com/joyent/node/wiki/modules and that is just for starters

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:You are a renegade.

[Transfinite]

While not as full featured as Intelij..... cloud9 http://cloud9ide.com/ which is actually written in NodeJS

Re:You are a renegade.

[Anonymous Coward]

Uh... is got https://github.com/joyent/node/wiki/modules and that is just for starters

watch out everyone! this guy wrote a web framework for node.js!!

Re:You are a renegade.

[Roachie]

Firebug.

Re:You are a renegade.

[Inda]

...Microsoft Script Editor.

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:You are a renegade.

[lennier]

Ever wrote something in Perl?

Only once, and I took fifteen showers afterwards and still felt dirty.

Re:You are a renegade.

[eigenstates]

Uhh, I quite like how the module and 'require' patterns work in JS. <-- read: I am extolling their virtues. I am a big fan of quick and dirty object decoration as well (as long as you keep it in the closure). Webworkers do processing in other threads. And V8 has a whole debugging API.

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 Actionscript after learning how to deal with the wild nature of JS). I guess it'a all about knowing when to hold them, when to fold them and when to walk away.

Re:You are a renegade.

[jdoverholt]

You make several good points, I only take exception to one small part.

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.

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 concurrency, blocking, etc. Incidentally, this has a tendency to come about when you're writing server software.

Re:You are a renegade.

[eigenstates]

Yes- I agree with you on this. JS is simple but you should always be concerned with handling data asynchro- especially with JS where one frozen or busy thread will bring the whole thing to a halt. Callbacks, callbacks, callbacks

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:You are a renegade.

[MobyDisk]

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:You are a renegade.

[eigenstates]

http://www.html5rocks.com/tutorials/workers/basics/

There's probably a lot of concurrency one could get away with using workers.

Re:You are a renegade.

[Transfinite]

People generally 'pee' over things when they don't understand them or can get their heads around thinking in different ways for different problems. After all single threaded has to worse than multi-threaded, right? I mean why would you want to use Javascript for the 'web', I mean it's not like it's suited... Oh wait. Anyway we should all be using languages that were solely designed for the web, like Java... Oh hang on...

Re:You are a renegade.

[not already in use]

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. As if, if I were to choose another language, I would be forced to write multithreaded code.

Also, JS has first class functions, yes, but so do LOTS of other languages.

Exactly. I was never "picking" on first class functions. It was part of all the hubbub when some random group of hipsters suddenly thought javascript had enough redeeming qualities to make it worth using outside the browser, as if it was somehow unique, or in the case of prototypal inheritance, actually useful in any sort of practical sense.

Re:You are a renegade.

[maraist]

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

Re:You are a renegade.

[tixxit]

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 apparent when dealing with event driven UI code. This includes setTimeout/Interval. The functions that run on this timer are atomic. Again, this is not immediately apparent if you aren't familiar with JS. And, yes, this is a nice feature, as having all even driven UI code, timers, etc. run in the same thread is not as easy as it seems.

Re:You are a renegade.

[tixxit]

The difference is that JS can appear to be multi-threaded. For instance, I can set a function to run after a set amount of time (setTimeout). In the browser, this function will be run in the same thread as all the other code and it will be atomic. The same goes for all the UI events and the like. If I wanted to set a timeout in C that would run a function after 1 seconds, while doing some other stuff in the mean time, threads would be what I'd grab for first. However, JS promises to be single threaded, so you never have to worry about the underlying implementation.

Re:You are a renegade.

[tixxit]

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 prototypical inheritance isn't something people usually fawn over. However, I also mentioned that it IS in keeping with Javascript's simplicity. For note, I LIKE simple. Simple is good. Simple and powerful are not mutually exclusive.

Re:You are a renegade.

[dodobh]

Threads were a lightweight fork(2) replacement.

Re:You are a renegade.

[JakeD409]

That's a pretty wide net you're casting there. Feel the same way about Python? Ruby? Perl? PHP? Not saying you're wrong (I do think you're wrong, but that's a separate issue); just want to make sure that you have the same problem with all interpreted weakly-typed languages.

Re:You are a renegade.

[Raenex]

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

Re:You are a renegade.

[js_sebastian]

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:You are a renegade.

[MemoryDragon]

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 inheritance every framework who really wants to support this now rolls its own solution with its own syntax
You wont get conflicts that way thanks to the unification on prototype level, but you cannot mix classes either, and to the worse documentation tools like jsdoc now have to be tailored towards every framework separately to get the meta information for namespaces and classes out of the code or what the runtime makes of it.

Sorry but I dont drink the coolaid here, I see it from a day to day problem point of view of having to deal with on industrial level.
But it probably is cool to wank about the lack of this and to roll your own solution mentally on an academic point of view.

Re:You are a renegade.

[MemoryDragon]

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 typing.
Of course you never run into those issues if you only do a little bit of jquery application in a webpage.

From my experience dynamic languages are blazingly fast to develop for for small systems but once you cross a critical barrier I think it is somewhere between 3000 and 5000 locs you really have to be careful with every step and the productivity goes down significantly and due to excessive unit testing and parameter assertions the code per usecase becomes way more. But thats not generally a problem of javascript but generally a problem of highly dynamic and extensible languages.

Re:You are a renegade.

[tixxit]

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 helps with most issues you'd have, I think.

Re:You are a renegade.

[Anonymous Coward]

Pff, back in the day I was writing 255-character lines of BASIC code. The only thing that broke up the flow was a REM, GOTO, or an IF-THEN-ELSE, because there wasn't any "always" clause - it simply dropped to the next line after executing the THEN or ELSE clause. (And the entire IF-THEN-ELSE construct had to be on the same logical line, in that version of BASIC.)

The 255-character limitation was actually a limitation on the logical line length imposed by the editor, too: the code was stored in a shorter tokenized form. Which leads me to a curious question: it seems that one could create an editor that could take VB-style formatted code and automatically add line numbers only where necessary for labels or after an IF clause. The logical lines in the program could be indefinitely long, since the line-break separations could be automatically converted to single-line form with the : operator to delimit separate statements for execution, and the : operator could be converted back to a line-break when the program was listed. Maybe I'll try it. If nothing else, it seems like it would be an interesting way of compressing one's code and making it very difficult for anyone to edit.

Re:You are a renegade.

[Anonymous Coward]

Well, much of what was written was for effect. Personally, I do not see much, if any benefit to weakly-typed, dynamic languages over modern, statically-typed languages (C# is my language of choice: first class functions, implicit typing, and all sorts of other goodies that make the type system less intrusive). "Scripting languages" as they were previously and appropriately referred to, were used as such: writing quick and dirty scripts where worrying about types wasn't even worth the time. I guess what really bothers me about this whole debate, is that it became widely accepted that such languages were appropriate for writing large scale applications. Once a certain threshold is reached in code-size, it all the sudden becomes a rather tedious if not gargantuan task to hunt down type related errors at runtime that a compiler could do in under a second. The refactoring capabilities allowed by strong-typing, as seen in Eclipse or Resharper, are simply not possible in these languages either. The code quickly becomes rigid and unmanageable. Google, who has arguably some of the most impressive, large scale client-side java applications, went so far as to write a Java-to-Javascript compiler in GWT.
 
I guess my point is that any programmer who is more concerned spending their time writing solid, manageable code, would never willingly choose to write a large scale application in a weakly typed, dynamic language, given the choice.

Re:You are a renegade.

[Anonymous Coward]

How long ago? Perhaps you should shower more often. ;-)

Re:You are a renegade.

[MemoryDragon]

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:You are a renegade.

[tixxit]

What ifs are great; may be Zope corp could've created Zope in a statically typed language in the same amount of time. Maybe not. I honestly can't say. Zope, like most other well built systems (whether statically or dynamically typed), relies on the loose coupling of smaller, well developed, separate components. What Zope did well was their component oriented architecture. It makes integrating all the different components, and writing new ones, very easy. That said, they did this by building a stronger type system on top of Python (without getting in the way too much). However, this kind of flexibility is what makes dynamic languages so great.

Re:You are a renegade.

[maraist]

Do you debug and maintain 'cd'ing directories? How about opening a log file with a text editor? How about debugging your excel file? Why not? Because the input and output are reproducable and they are one-time events. If I'm trying to ask the question - how many log files did this application just produce.. I can
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, and manually count them.
C) Write a one-liner such as:

find -name '*.log' | wc -l

Now if I wanted to add up their file sizes:

find -name '*.log' | xargs ls -l | awk ' { $sum += $F[5] } END {print $sum} '

This is the basis of shell programming - BUT when you start adding conditional, it becomes very unnatural

for x in $(find -name '*.log'); do [[ -f $x ]] && echo "Found $x"; done

Nothing there denoted the 'if statement'. Enter perl. The ability to run all these shell-like commands, AND leverage all of 'awk' and 'sed's text-processing powers, AND have a full blown turing complete language.

Go through 4 more revisions and you create the one-time glue of the internet.

Perl is a very natural language if you're use to sh, bash, sed, awk, grep and friends. It looks foreign to windows people because batch files have equally bad syntax. And of course straight-programmers that have never had to script in their lives look down on such languages as beneath them I'm sure - much like menial labor.

Re:You are a renegade.

[__aagujc9792]

Heh. I wrote that program sometime in 1976, target was DEC RSTS Basic. It helped me squeeze more function into a rather limited amount of memory.

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.

Re:The only good JavaScript is a contained JavaScr

[Anonymous Coward]

just because of historical accident...thats the only extension mechanism available

if i were going to design a full featured application i wouldn't choose javascript

hmm, maybe thats why the google applications are actually compiled into javascript instead of
being written in it

Re:The only good JavaScript is a contained JavaScr

[tixxit]

Except that JavaScript, today, is not a slow dynamic scripting language. The latest JS engines in IE 9, FF 4, and Chrome are lightning fast. You'll be hard pressed to find a faster dynamically typed scripting language today. Honestly, if you want a fast, dynamically typed, interpreted scripting language, then look no further than JS. Also Rhino IS slow (compared to most other JS interpreters) and has been included with Java by default since Java 6.

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:like Netscape FastTrack & LiveScript in '96

[Anonymous Coward]

You must not remember anything from having read about it, given that the first line of TFA is "in 1996 ... Netscape took its shiny, new JavaScript language from the browser and stuck it in the Netscape Enterprise HTTP server."

Callbacks and Promises

[otakuj462]

"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), and in Node.js development (e.g. node-promise module by Kris Zyp). So, I think this critique is a bit unwarranted.

Re:Callbacks and Promises

[shutdown -p now]

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 in the (yet upcoming) C# 5.0.

Good thing is that there is a proposal for this feature for the next major EcmaScript version. Hopefully it'll end up in the spec.

Re:Callbacks and Promises

[Animats]

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 this. I've written hard real-time code and OS internals code where timing really mattered and concurrency was crucial. But the typical web developer doesn't do anything that tough. Nor should they. They need an environment which doesn't have potential race conditions.

(Misery is writing for a callback environment without continuations, like background code for the original MacOS. With continuations, it works much better.)

Re:Callbacks and Promises

[shutdown -p now]

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, though. It's also a way to get responsive UI. If all potentially blocking platform API calls are removed, and only async-callback versions of those are provided (e.g. no open() or read(), but only open_async() and read_async() etc), it forces the programmer into a model where any lengthy task he is performing can be pre-empted by UI to paint or respond to user actions - but without the need for the programmer himself to explicitly spin off background threads, and do cross-thread synchronization (indeed, his code still runs entirely on the same single main thread! - just interleaved with UI).

Re:Callbacks and Promises

[Lord_Naikon]

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.

I disagree with the view that "headaches" of concurrency go away with a continuation model, because in a server environment, you often have to deal with shared resources, and I don't really see how this model helps (note that asynchronous model does not mean no threads...). The two concepts are orthogonal IMHO.

In case of your example, a UI, instead of letting the OS take care of the state of the background threads, you now have to keep state yourself, needlessly complicating application design. For complicated tasks you will get enormous state machines.

Re:Callbacks and Promises

[shutdown -p now]

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 lightweight than processes, but they're still not featherweight, so there are limits - so you have to use a thread pool with a hard limit. Now, whenever one of your threads blocks waiting, that thread is a burden on your pool - it's scarce resource (you can't always just grab another thread from the pool to service a new request - there might not be any left!) tied up doing nothing. With async model, your pool is always 100% loaded, and you can service more requests than there are threads.

I disagree with the view that "headaches" of concurrency go away with a continuation model, because in a server environment, you often have to deal with shared resources, and I don't really see how this model helps (note that asynchronous model does not mean no threads...). The two concepts are orthogonal IMHO.

In a server environment, yes, absolutely.

I wouldn't say the concepts are entirely orthogonal, however - asynchrony does not require nor prevent you from doing concurrency, yes, but it does let you write some code that would otherwise have to involve many threads in such a way that it only needs one - really, it's just cooperative multitasking in that mode. And using that lets you forget about concurrency headaches. Of course, this is mostly handy for client apps.

In case of your example, a UI, instead of letting the OS take care of the state of the background threads, you now have to keep state yourself, needlessly complicating application design. For complicated tasks you will get enormous state machines.

If you write this in a language without syntactic sugar for asynchrony, yes, this can be tedious. But did you look at the link in my earlier thread? That's the kind of thing we're heading towards - the state machines would still be there, as complicated as needed to support your logic, but compiler would generate them from said logic encoded in almost exact same way as you do it today in an imperative language - expressions and conditionals and loops and exceptions.

F# already has this today. C# is getting it in the next major release, and a preview of the new compiler is available today. And EcmaScript has a proposal for a very similar thing for Harmony. More to come, no doubt.

Re:Callbacks and Promises

[Lord_Naikon]

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.

I mostly agree, but I see this more as an implementation detail. The root cause here is that threads are apparently resource intensive. In a perfect world, the data that a thread would have to store during a context switch is exactly the same amount that you would store yourself during a voluntary context switch. 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 and thus can write more efficient applications.

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.

Re:Callbacks and Promises

[shutdown -p now]

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 sure that all API functions that are likely to block only exist in async versions. Silverlight (and, consequently, WinPhone) does that, for example.

Syntactic sugar which makes continuations implicit goes even further in that goal - now you only need to teach people to write "await" at the right points, and otherwise they can code in a simple, linear way. Sure, such mechanical approach, without fully understanding the execution model, might not yield a well-optimized application; but at least it will always remain responsive, and unresponsiveness tends to be a much more immediate annoyance to the end user.

Re:like Netscape FastTrack & LiveScript in '96

[badboy_tw2002]

We do remember it. Probably because it was the first line of the article.

Re:like Netscape FastTrack & LiveScript in '96

[RussellSHarris]

Or .jsp, which has been around for quite a long time.

Node.js user here...

[Anonymous Coward]

There is definitely a "fanboy" mentality among Node.js programmers, which is really irritating.

I use Node.js to create command-line scripts, similar to bash scripts. It's great! The secret is to install the Fibers package, which can help turn all those annoying asynchronous Node.js calls into synchronous calls.

Asynch is great for building web servers... not so much when you just want to run a script from top to bottom, and don't care about blocking the thread.

Also, you'll notice that if you use Node.js for web application development, you will be tabbing over quite a bit as the asynch functions are nested inside each other.

Re:like Netscape FastTrack & LiveScript in '96

[shutdown -p now]

history seems to repeat itself...

This.

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.

JavaScript is a nice language

[Anonymous Coward]

But there's something just worrisome in my mind to be using dynamic typed functional languages. I get bugged out by Python and JavaScript because they offer too much flexibility. Try debugging lower levels of SproutCore without mountains of headaches. I'm going to plug Scala, just because the contract for functions is clearer than in Python or Javascript.

Re:like Netscape FastTrack & LiveScript in '96

[Transfinite]

Not really. 15 years is a long time in technology.

V8 :(

[StripedCow]

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:V8 :(

[Guspaz]

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.

Re:V8 :(

[Anonymous Coward]

"A Computer is a state machine.
Threads are for people who can't program state machines."
- Alan Cox

Re:like Netscape FastTrack & LiveScript in '96

[Transfinite]

really it's not changed. I'd think about that again? Where have you been?

Re:The only good JavaScript is a contained JavaScr

[omfgnosis]

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 that those kinds of applications didn't appear until later, but they could have been made much sooner. But poor standards support in browsers made interoperability a nightmare, slow client hardware made performance questionable, and ultimately poor understanding of JavaScript and the DOM delayed serious uptake among developers for about a decade.

Ouch

[StripedCow]

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:Ouch

[ChunderDownunder]

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:Ouch

[StripedCow]

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.

Your dad's ass was hot

[Anonymous Coward]

No, but I fucked your dad's ass 5 minutes ago.

Re:like Netscape FastTrack & LiveScript in '96

[Transfinite]

What like when they added closure support for Java. Yawn!

Re:The only good JavaScript is a contained JavaScr

[GooberToo]

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: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:like Netscape FastTrack & LiveScript in '96

[sproketboy]

Yup mod parent up.

ASP

[Anonymous Coward]

so someone has re-invented ASP (with Jscript) and its now cool?

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:like Netscape FastTrack & LiveScript in '96

[betterunixthanunix]

I said the underlying structure has not changed much, but that there have been superficial changes. Can you please point out where the underlying structure of the Internet or the Web has undergone a significant change? When last I checked, we are still using IPv4 and we are still using HTTP, and we are still using a client-server model. This most significant change that I can think of is AJAX, and that is not a terribly significant change (it really just means that things people would have done in an applet can now be done by the browser itself).

Yes, things look a lot different now, and we are making more sophisticated use of the underlying technology (sometimes), but for the most part we are still talking about the same system.

Server side ActionScript ?

[cr_nucleus]

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:Server side ActionScript ?

[GreyLurk]

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:Server side ActionScript ?

[Anonymous Coward]

The lack of namespaces can be worked around by using functions. For example, to implement an equivalent of class Bar in namespace Foo, you can:

var Foo = Foo || {};
(function($) {
    Foo.Bar = function() { // implementation
    };
})(jQuery-or-library-of-choice);

This way classes are implemented in seperate files, but well organised. You can then use firebug etc to browse your api.

Apart from that, I can't help you with syntax and strong typing.

Re:Server side ActionScript ?

[MemoryDragon]

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 int for free in actionscript and other languages would cost you about 30% of performance on method call level due to the indirection layer introduced.

Re:The only good JavaScript is a contained JavaScr

[BitZtream]

uhm, thats pretty much EXACTLY what Javascript was intended for ... you do know where it came from ... right?

Re:The only good JavaScript is a contained JavaScr

[BitZtream]

Your definition of 'lightning fast' is my definition of 'painfully slow language' even in the new JS engines.

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:like Netscape FastTrack & LiveScript in '96

[BitZtream]

jsp is java, not javascript, which is entirely different other than the name.

Re:like Netscape FastTrack & LiveScript in '96

[Transfinite]

Yes the underlying structure is much the same. But our paradigms have changed a lot. The early web was request response, with very little focus on the client at all. That's changed, there is now far more parity between what happens on the server and client. This is only going to increase. The point is this, if you have a common language (Javascript) that fits the web, very, very well and you have browser vendors implementing features in HTML5 that encourage distributed, real time apps. Together with improvements in HTTP1.1 (which is really one of the main drivers). Then you have a web that in reality looks nothing like the one we had 15 years ago. What I don't understand if the fear people seem to exhibit with stuff like this. There is absolutely nothing wrong with a modern implementation of server side Javascript. There is nothing wrong with single threaded apps, there is also nothing wrong with multi-threaded. Single threaded systems can have certain qualities that perhaps multi-threaded apps don't. They certainly use resources in a much more effective way. We don't need multi threaded-ness everywhere. These are tools. Use them. Technology changes, embrace that.

Re:like Netscape FastTrack & LiveScript in '96

[icebraining]

You could use JScript in ASP too. Thankfully I never had to.

Re:The only good JavaScript is a contained JavaScr

[Transfinite]

I assume you write all your web apps in machine code then?

Re:like Netscape FastTrack & LiveScript in '96

[GreyLurk]

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:like Netscape FastTrack & LiveScript in '96

[GreyLurk]

Err... <%@ Language=Javascript%>

Re:like Netscape FastTrack & LiveScript in '96

[Anonymous Coward]

"They'll come back. Technology is cyclical"
-- The beeper king

Re:The only good JavaScript is a contained JavaScr

[GreyLurk]

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

Clarification Needed

[Nexzus]

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?

Re:Clarification Needed

[larry bagina]

jscript seemed to be a second class citizen in asp. And a second class citizen compared to every other javascript implementation.

Re:like Netscape FastTrack & LiveScript in '96

[Anonymous Coward]

The desktop computer hasn't changed much in the past 30 years. I mean, we still have a keyboard, a monitor, and some little collection of copper and silicon connecting the two and it still uses the same ol' electricity. Sure the operating systems have changed, the applications have changed, the keyboard might be virtual, the monitor might be 3 inches tall, and you might be using 5 different computers throughout the day for so many different/diverse tasks that your life is rather different from what it would have been 30 years ago. But it's still just superficial changes, we're still talking about the same system.

</rant> Yeah maybe a bit over the top there. I actually agree with you to some extent, but then most every advance in technology just comes at incremental steps. It's not like Swan/Edison/Others went from the light bulb to the iPad over a fortnight. And sometimes some overlooked technology which wasn't up to the challenge 10~15 years ago could suddenly be useful in the more modern Web X.0 era.

Maybe it's not a whole new wheel, but the fancy round shape has worked pretty well for us for a while.

Err, did I just compare the buzz of server-side Javascript with the jump from incandescent light bulbs to tablet computers? I apologize. I did not get enough sleep last night, and my AC died this morning so it is ridiculously hot in my house right now.

Node.js is fast, BUT...

[Anonymous Coward]

Unless it's been updated recently it's still single threaded. So, if you have a multicore server - as I'm sure most do, it'll only be using 1 of those cores in its single thread. Of course you could fire up 4 instances for a 4-core machine, but then the threads can't communicate, so you lose one of its advantages (being ideal for chat/game servers, or anything that uses real-time message passing between clients.)

On my own dev server - (Core 2 Quad, 2.5ghz, 4GB, RAID) Node.js can handle around 8000 requests per second, when just outputting a simple text message. In comparison, PHP can handle around 12,000 requests per second to return the same text. However, PHP/Apache is using all 4 cores for this, and Node.js just 1. So it's doing over half the work with 1/4 the resources. The tests were conducted using ab with 100 concurrent requests.

I can definitely see a case being made for using Node.js to handle AJAX requests from a page served via Apache (or some other webserver.) It seems absolutely ideal for this - also for a site offering realtime chat, since at worst it will only take up a single core, and not cause too many problems with the rest of a site.

Re:Node.js is fast, BUT...

[Anonymous Coward]

Ok I'm tired - I meant HTML, not PHP there. A flat HTML page was being served at 12,000 requests per second. PHP manages only 400 requests per second (single echo statement)

Re:Node.js is fast, BUT...

[dodobh]

You can't make method calls. You can communicate via explicit message passing, like a Unix pipeline. That's why we have bidirectional sockets.

Re:Node.js is fast, BUT...

[Transfinite]

multi-node. The above is not an issue. Also get Apache out of the mix as this will become the next bottle neck. Use something like Nginx that's an evented web server unlike Apache

Re:like Netscape FastTrack & LiveScript in '96

[JonySuede]

they are supposed to add statically typed closure you insensitive claud !

Re:The only good JavaScript is a contained JavaScr

[tixxit]

My favourite language, by far, is Scala, so don't think I don't know where you are coming from. And, honestly, my favourite dynamic language is Python, though I am using JS on occasion now.

JavaScript is usable, but....

[Sloppy]

if i were going to design a full featured application i wouldn't choose javascript

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 perl.) But anyway: Classes. Prototypes are lame. Anyone who starts a new project involving Javascript in any situation other than running in a web browser, is totally fucked in the head. Someone has so many choices and they pick Javascript? Please. Yes, it can function as a general-purpose programming language, but it's not one, and it is very sad that the world is possibly going to be forever burdened by it.

Damn you, Netscape. You may end up being a longer-lasting plague than Microsoft.

Re:JavaScript is usable, but....

[Transfinite]

Well those that are choosing to do this obviously know something you don't. You do realise there are things like this?: http://cloud9ide.com/ http://hummingbirdstats.com/ and that Yahoo use node heavily, right?

Re:The only good JavaScript is a contained JavaScr

[tixxit]

I guess it wasn't obvious, but I was comparing JS to other dynamically typed scripting languages. I'm also talking in respect to tasks that scripting languages usually tackle. If JS is painfully slow for you, I'm just assuming you are using it for something you probably shouldn't be using ANY scripting language for.

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

Re:The only good JavaScript is a contained JavaScr

[davester666]

Guess what.

The leading proponent of all 5 Javascript Server projects is....Intel!

Re:like Netscape FastTrack & LiveScript in '96

[sourcerror]

Can you put a current processor in a motherboard from '95?
Can you install DOS to a x64 processor system?
Well, no because the structure of things changed.

Re:like Netscape FastTrack & LiveScript in '96

[Transfinite]

Thank you.

Re:The only good JavaScript is a contained JavaScr

[Transfinite]

what just like Java was originally designed for set top boxes and fridges? Oak. anyone, anyone?

Re:The only good JavaScript is a contained JavaScr

[Anonymous Coward]

Jeepers. You really didn't read that linked post nor understand it - that is a comparison of a *very* slow interpreted stack running on top of java, it is not java/jsp/jee or anything close. Nor is it comparing it deployed in any remotely production quality scenario which would use much more host networking features to significantly boost throughput.

Go back to your JS & enjoy it by all means, but don't make laughable comments about it being so much faster than java as a generic statement. I'm also fairly certain that node.js has been very heavily devloped toward quick http serving, not nescessarily all the other logic possibly used to serve a request...

Still waiting for my...

[Kamiza Ikioi]

... optimized animated .gif server so ytmnd.com could load 5GB loops faster.

JS is MUCH, MUCH better than PHP

[Nicolas MONNET]

- 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 strong incentive for security and more generally code quality compared to other scripting languages.

thread per server in Java? really??

[Anonymous Coward]

when an article starts out with "As the standard Java Servlet container creates one thread for each request..." you know the rest of the article has to be flawed