

JavaScript conquers the server - gulbrandr
http://www.javaworld.com/cgi-bin/mailto/x_java.cgi?pagetosend=/export/home/httpd/javaworld/javaworld/jw-05-2011/110525-server-side-javascript.html&pagename=/javaworld/jw-05-2011/110525-server-side-javascript.html&pageurl=http://www.javaworld.com/javaworld/jw-05-2011/110525-server-side-javascript.html&site=jw_core

======
gary4gar
Article Summary:

1) Node.JS or other JavaScript platforms are NOT ready for prime-time. Only
good for experimentation or prototyping.

2) For coding in callback style that javascript on servers needs, extreme
discipline is required. Else, it will make your code hard to debug or maintain
aka "callback hell".

3) Currently, projects like Node.js are not maintaining compatibility & things
break often. that's not their current focus. This makes them unfriendly to
enterprises.

4) Current state of Documentation is poor as the project are constantly
changing at rapid pace. Tutorials just scratch the surface.

5) Event loop Style of programming is worth looking at for building real-time
applications with thousands of concurrent users.

6) Some of ideas from Node.JS & other Javascript server side frameworks might
be adopted into other languages.

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

I found this analogy excellent.

~~~
cageface
This seems a little backwards to me. Wouldn't you want to make sure you're
using every possible byte? Isn't this why Linux essentially uses all available
ram for I/O caching? Obviously you don't want to _waste_ memory, but if it's
sitting there unused you're probably missing some caching opportunities.

~~~
dspillett
Yes and no. You want to use as much RAM as you have available, but for data
not code.

You want your code, including the framework it is using, to take as little RAM
as possible - then there is more available for data (either held specifically
in your structures or cached/buffered by the OS to avoid I/O operations).

------
jlind
I enjoyed this article. I'm familiar with JavaScript but haven't really had
the time to learn about these server-side engines. Great use of analogies to
explain how some of them work.

------
sktrdie
They didn't mention my <https://github.com/lmatteis/apejs>

~~~
gulbrandr
Neither did they mention all server-side javascript solutions listed here:
[http://en.wikipedia.org/wiki/Comparison_of_server-
side_JavaS...](http://en.wikipedia.org/wiki/Comparison_of_server-
side_JavaScript_solutions)

~~~
sktrdie
It was a joke, no need to downvote.

~~~
gulbrandr
It's not me.

