JavaScript Servers Compared

Second post! by Anonymous Coward · 2011-05-25 08:02 · Score: 4, Funny

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

Third post by Anonymous Coward · 2011-05-25 08:03 · Score: 3, Funny

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

First post! by Anonymous Coward · 2011-05-25 08:06 · Score: 2, Funny

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

Burn the bible by Anonymous Coward · 2011-05-25 08:07 · Score: 1, Interesting

Burn the bible

The only good JavaScript is a contained JavaScript by VortexCortex · 2011-05-25 08:11 · Score: 2

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 by Kenz0r · 2011-05-25 08:15 · Score: 5, Informative

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

--
+1 Funny Signature

Re:The only good JavaScript is a contained JavaScr by Fusselwurm · 2011-05-25 08:18 · 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.

You are a renegade. by not+already+in+use · 2011-05-25 08:23 · 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.

--
Similes are like metaphors

Re:You are a renegade. by cyfer2000 · 2011-05-25 08:27 · Score: 1

Ever wrote something in Perl?

--
There is a spark in every single flame bait point.
Re:You are a renegade. by vlm · 2011-05-25 08:31 · Score: 1

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

--
"Science flies us to the moon. Religion flies us into buildings." - Victor Stenger
Re:You are a renegade. by timothyf · 2011-05-25 08:40 · Score: 1

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. by Transfinite · 2011-05-25 08:43 · Score: 1

Uh... is got https://github.com/joyent/node/wiki/modules and that is just for starters
Re:You are a renegade. by ya+really · 2011-05-25 08:45 · Score: 2

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. by tixxit · 2011-05-25 08:59 · Score: 4, 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:You are a renegade. by Transfinite · 2011-05-25 09:03 · Score: 1

While not as full featured as Intelij..... cloud9 http://cloud9ide.com/ which is actually written in NodeJS
Re:You are a renegade. by Roachie · 2011-05-25 09:10 · Score: 1

Firebug.

--
This sig is not paradoxical or ironic.
Re:You are a renegade. by Inda · 2011-05-25 09:22 · Score: 1

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

--
This post contains benzene, nitrosamines, formaldehyde and hydrogen cyanide.
Re:You are a renegade. by lennier · 2011-05-25 09:25 · Score: 1

Ever wrote something in Perl?
Only once, and I took fifteen showers afterwards and still felt dirty.

--
You are not a brain: http://books.google.com/books?id=2oV61CeDx-YC
Re:You are a renegade. by eigenstates · 2011-05-25 09:32 · Score: 1

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.

--
quis custodiet ipsos custodes
Re:You are a renegade. by jdoverholt · 2011-05-25 09:33 · Score: 1

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. by eigenstates · 2011-05-25 09:45 · Score: 1

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

--
quis custodiet ipsos custodes
Re:You are a renegade. by MobyDisk · 2011-05-25 09:48 · Score: 1

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. by eigenstates · 2011-05-25 10:09 · Score: 1

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

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

--
quis custodiet ipsos custodes
Re:You are a renegade. by Transfinite · 2011-05-25 10:09 · Score: 1

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. by not+already+in+use · 2011-05-25 10:25 · Score: 1

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.

--
Similes are like metaphors
Re:You are a renegade. by maraist · 2011-05-25 12:59 · Score: 1

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

--
-Michael
Re:You are a renegade. by tixxit · 2011-05-25 14:10 · Score: 1

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. by tixxit · 2011-05-25 14:16 · Score: 1

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. by tixxit · 2011-05-25 14:29 · Score: 1

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. by dodobh · 2011-05-25 16:37 · Score: 1

Threads were a lightweight fork(2) replacement.

--
I can throw myself at the ground, and miss.
Re:You are a renegade. by JakeD409 · 2011-05-25 18:40 · Score: 1

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. by Raenex · 2011-05-25 22:45 · Score: 1

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. by js_sebastian · 2011-05-25 23:18 · Score: 1

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. by MemoryDragon · 2011-05-26 01:04 · Score: 1

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. by MemoryDragon · 2011-05-26 01:10 · Score: 1

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. by tixxit · 2011-05-26 02:17 · Score: 1

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. by MemoryDragon · 2011-05-26 19:25 · Score: 1

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. by tixxit · 2011-05-27 03:28 · Score: 1

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. by maraist · 2011-05-27 11:04 · Score: 1

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.

--
-Michael
Re:You are a renegade. by __aagujc9792 · 2011-05-28 08:57 · Score: 1

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 by bmuon · 2011-05-25 08:24 · 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:Awful Article by dgatwood · 2011-05-25 08:26 · Score: 1

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.

--

Check out my sci-fi/humor trilogy at PatriotsBooks.

Re:The only good JavaScript is a contained JavaScr by tixxit · 2011-05-25 08:33 · Score: 1

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? by darkeye · 2011-05-25 08:38 · 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:like Netscape FastTrack & LiveScript in '96 by betterunixthanunix · 2011-05-25 08:44 · Score: 2

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.

--
Palm trees and 8

Re:Awful Article by badboy_tw2002 · 2011-05-25 08:44 · 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:Awful Article by gilleain · 2011-05-25 08:44 · Score: 1

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 by Transfinite · 2011-05-25 08:44 · Score: 1

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.

Callbacks and Promises by otakuj462 · 2011-05-25 08:45 · 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), 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 by shutdown+-p+now · 2011-05-25 08:59 · Score: 1

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 by Animats · 2011-05-25 09:53 · Score: 1

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 by shutdown+-p+now · 2011-05-25 11:40 · Score: 1

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 by Lord_Naikon · 2011-05-26 00:44 · Score: 1

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 by shutdown+-p+now · 2011-05-26 04:57 · Score: 1

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 by Lord_Naikon · 2011-05-26 05:27 · Score: 1

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 by shutdown+-p+now · 2011-05-26 05:43 · Score: 1

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 by badboy_tw2002 · 2011-05-25 08:46 · Score: 1

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

Re:like Netscape FastTrack & LiveScript in '96 by RussellSHarris · 2011-05-25 08:46 · Score: 1

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

Re:like Netscape FastTrack & LiveScript in '96 by shutdown+-p+now · 2011-05-25 08:52 · Score: 1

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.

Re:Awful Article by Transfinite · 2011-05-25 08:56 · Score: 1

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:like Netscape FastTrack & LiveScript in '96 by Transfinite · 2011-05-25 08:58 · Score: 1

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

V8 :( by StripedCow · 2011-05-25 09:01 · Score: 1

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)

--
If Pandora's box is destined to be opened, *I* want to be the one to open it.

Re:V8 :( by Guspaz · 2011-05-25 12:58 · Score: 1

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:like Netscape FastTrack & LiveScript in '96 by Transfinite · 2011-05-25 09:05 · Score: 1

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

Re:The only good JavaScript is a contained JavaScr by omfgnosis · 2011-05-25 09:07 · Score: 1

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 by StripedCow · 2011-05-25 09:09 · Score: 1

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.

--
If Pandora's box is destined to be opened, *I* want to be the one to open it.

Re:Ouch by ChunderDownunder · 2011-05-25 11:16 · Score: 1

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 by StripedCow · 2011-05-25 18:54 · Score: 1

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.

--
If Pandora's box is destined to be opened, *I* want to be the one to open it.

Re:Awful Article by omfgnosis · 2011-05-25 09:13 · Score: 1

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

Re:Awful Article by dgatwood · 2011-05-25 09:17 · Score: 2

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

--

Check out my sci-fi/humor trilogy at PatriotsBooks.

Re:like Netscape FastTrack & LiveScript in '96 by Transfinite · 2011-05-25 09:21 · Score: 1

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

Re:The only good JavaScript is a contained JavaScr by GooberToo · 2011-05-25 09:30 · Score: 1

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 by the+linux+geek · 2011-05-25 09:40 · Score: 2

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 by sproketboy · 2011-05-25 09:44 · Score: 1

Yup mod parent up.

Re:The only good JavaScript is a contained JavaScr by Anonymous Coward · 2011-05-25 09:55 · Score: 2, Interesting

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 by betterunixthanunix · 2011-05-25 10:08 · Score: 1

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.

--
Palm trees and 8

Server side ActionScript ? by cr_nucleus · 2011-05-25 10:09 · Score: 1

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 ? by GreyLurk · 2011-05-25 11:01 · 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:Server side ActionScript ? by MemoryDragon · 2011-05-26 01:13 · Score: 1

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:Awful Article by DrXym · 2011-05-25 10:11 · Score: 1

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:The only good JavaScript is a contained JavaScr by BitZtream · 2011-05-25 10:18 · Score: 1

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

--
Persistent Volume manager for Kubernetes - https://github.com/dwimsey/openshift-pvmanager

Re:The only good JavaScript is a contained JavaScr by BitZtream · 2011-05-25 10:20 · Score: 1

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

--
Persistent Volume manager for Kubernetes - https://github.com/dwimsey/openshift-pvmanager

Re:The only good JavaScript is a contained JavaScr by GreyLurk · 2011-05-25 10:23 · 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

V8 is actually really damn fast.

Re:like Netscape FastTrack & LiveScript in '96 by BitZtream · 2011-05-25 10:23 · Score: 1

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

--
Persistent Volume manager for Kubernetes - https://github.com/dwimsey/openshift-pvmanager

Re:like Netscape FastTrack & LiveScript in '96 by Transfinite · 2011-05-25 10:35 · Score: 1

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 by icebraining · 2011-05-25 10:37 · Score: 1

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

--
Dilbert RSS feed

Re:The only good JavaScript is a contained JavaScr by Transfinite · 2011-05-25 10:48 · Score: 1

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

Re:like Netscape FastTrack & LiveScript in '96 by GreyLurk · 2011-05-25 10:54 · 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:like Netscape FastTrack & LiveScript in '96 by GreyLurk · 2011-05-25 10:55 · Score: 1

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

Re:The only good JavaScript is a contained JavaScr by GreyLurk · 2011-05-25 11:08 · 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:The only good JavaScript is a contained JavaScr by CapOblivious2010 · 2011-05-25 11:09 · 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)

Clarification Needed by Nexzus · 2011-05-25 11:09 · Score: 1

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?

--
Karma: Can only be portioned out by the Cosmos.

Re:Clarification Needed by larry+bagina · 2011-05-26 16:53 · Score: 1

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

--
Do you even lift?
These aren't the 'roids you're looking for.

Re:Awful Article by Guspaz · 2011-05-25 12:46 · Score: 1

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:like Netscape FastTrack & LiveScript in '96 by JonySuede · 2011-05-25 14:03 · Score: 1

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

--
Jehovah be praised, Oracle was not selected

Re:The only good JavaScript is a contained JavaScr by tixxit · 2011-05-25 14:18 · Score: 1

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.... by Sloppy · 2011-05-25 14:53 · Score: 1

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.

--
As copyright owner of this comment, I authorize everyone to defeat any technological measure which limits access to it.

Re:JavaScript is usable, but.... by Transfinite · 2011-05-25 19:52 · Score: 1

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 by tixxit · 2011-05-25 15:01 · Score: 1

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 by Billly+Gates · 2011-05-25 16:31 · 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

--
http://saveie6.com/

Re:The only good JavaScript is a contained JavaScr by davester666 · 2011-05-25 16:36 · Score: 1

Guess what.

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

--
Sleep your way to a whiter smile...date a dentist!

Re:Node.js is fast, BUT... by dodobh · 2011-05-25 16:44 · Score: 1

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

--
I can throw myself at the ground, and miss.

Re:Node.js is fast, BUT... by Transfinite · 2011-05-25 19:44 · Score: 1

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 by Transfinite · 2011-05-25 19:59 · Score: 1

Thank you.

Re:The only good JavaScript is a contained JavaScr by Transfinite · 2011-05-25 20:37 · Score: 1

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

Re:Awful Article by ChunderDownunder · 2011-05-25 21:11 · Score: 1

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.

Still waiting for my... by Kamiza+Ikioi · 2011-05-26 00:43 · Score: 1

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

--
I8-D

JS is MUCH, MUCH better than PHP by Nicolas+MONNET · 2011-05-26 22:56 · Score: 1

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

108 of 132 comments (clear)