Server side JavaScript?
• Has been around for a long time
• Very fragmented:
• Netscape started server-side scripting (SSJS),
December, 1994
• Mozilla Spidermonkey, C, Firefox > 3.5,
GNOME (started at Netscape), first engine
ever, 1996
• Mozilla Rhino, Java, 1997 (started by
Netscape for navigator)
• Google V8, Chrome, September 2, 2008.
• SquirrelFish (AKA JavaScriptCore), Webkit,
June 2, 2008
Server side problems?
• No compatible standard library.
• No standard interface to connect to a database.
• No standard method to insert different modules.
• No method for packaging code for distribution and
installation.
• Module storage of a common package that solves
dependency is necessary.
Commonjs ?
• Kevin Dangoor, January 2009
• Spec
• JavaScript ecosystem for web servers, desktop and
command line apps and in the browser.
• CommonJS-compliant systems:
• Server-side JavaScript applications
• Command line tools
• Desktop GUI-based applications
• Hybrid applications (Titanium, Adobe AIR)
Why Server Side js?
• Familiar and universal
• Same language on server and client
(code sharing)
• Notions from Self, Scheme, and
Prototype - all with a C/C++/Java-like
syntax.
• Server side JavaScript has the
potential to significantly outperform
other common dynamic languages.
Common Spec?
• Modules
• Binary strings and buffers
• Charset encodings
• Binary, buffered, and textual input and output (io) streams
• System process arguments, environment, and streams
• File system interface
• Socket streams
• Unit test assertions, running, and reporting
• Web server gateway interface, JSGI
• Local and remote packages and package management
AMD?
• Asynchronous module definition
• Started as offspin (fork) of CommonJs
• Failed to reach an agreement in discussions with
CommonJS about using JavaScript module in an
asynchronous situation.
• Evolved in own module definition API
• The difference in the module specifications defined by
the two territories are in module load.
Nodejs?
• Event-driven
• Flow is determined by events
• Event loop
• Non-blocking I/O (AKA asynchronous I/O)
• I/O processing while permitting other processing to continue
• Parallel I/O
• You can do other things while waiting.
• You can wait on more than one thing at a time.
• CommonJS
• V8
What makes nodejs Fast?
• Node.js is fast by design
• Never blocking on I/O means less threads.
• This means YOU handle scheduling.
CPU intensive computations
• Node -> single threaded execution
model
• Fibonacci function = one event tick
• Blocking your node server completely
• IO (DB, Filesystem) is the bottleneck,
These calls are completely async
CPU intensive computations
• NPM Modules:
• ‘flow’, ‘async’, ‘step’ and ‘Q’.
• ‘Threads a GoGo’ natively utilizes threading inside the
V8 engine (and therefore relies on a newer release of
node.js)
• ‘Webworkers’