The document discusses the future of server-side JavaScript. It provides reasons for using JavaScript on the server, including that it is the lingua franca of the web, allows for code reuse between server and client, and supports asynchronous programming well. It also discusses JavaScript engines, CommonJS modules and packages, environments like Node.js and RingoJS, and trends like wider adoption and cloud-based IDEs.

1. The future of server side JavaScript @olegpodsechin #froscon 20.08.2011

2. Why use JavaScript on the server? Language of the browser Competition amongst browser vendors means increased performance Code reuse between the server and client, no need for context switching Dynamic language No unnecessary constraints, allows one to mix procedural, object oriented and functional styles Allows for meta programing Data in JSON, no marshalling reduces amount of code

3. Why use JavaScript on the server? Lingua franca of the web Widely accessible, even to beginning developers Widely available in terms of platforms Decent IDE support Closures work well with asynchronous, real time web Diverse, active, growing community – http://communityjs.org We are stuck with it for the foreseeable future

4. It's Trendy

5. ServerJS != Node Engines Environments Platforms Frameworks

6. Engines 1996 SpiderMonkey (Mozilla) 1998 Rhino (Mozilla) 2008 Nitro/SquirrelFish (Apple) 2008 V8 (Google) 2011 Chakra (Microsoft) 2012 Nashorn (Oracle)

7. Rhino JavaScript 1.7 Interpreted or compiled to Java bytecode, allows for continuations Includes new and old features like destructuring assignment (var {a, b} = x) and E4X Easy access to Java classes Recent patches improve performance, e.g. InvokeDynamic in Java7

8. V8 EcmaScript 5 Compiles to native code – fast! Extended via native libraries Primarily targets the web browser

9. CommonJS Modules - 1.0, 1.1 , Async/A Packages - 1.0, 1.1 Console System Unit Testing – 1.0 Binary - A, B , C, D, E, Lite, F IO - A , B, C Filesystem - A , B JSGI - 0.2, 0.3 HttpClient – A , B

10. CommonJS modules // math.js exports.add = function(a, b) { return a + b; } // server.js var add = require('math').add; console.log(add(2, 2)); // client.js ???

11. CommonJS packages // package.json { &quot;name&quot;: &quot;hello&quot;, &quot;version&quot;: &quot;0.1.0&quot;, &quot;description&quot;: &quot;Hello world package&quot;, &quot;keywords&quot;: [&quot;hello&quot;, &quot;world&quot;], &quot;author&quot;: &quot;John Smith <john@smith.com>&quot;, &quot;main&quot;: &quot;./lib/hello.js&quot;, &quot;dependencies&quot;: {&quot;whatever&quot; : &quot;1&quot;}, &quot;engines&quot; : [&quot;v8&quot;, &quot;node&quot;, &quot;rhino&quot;], }

12. Future of CommonJS http://groups.google.com/group/commonjs Node mostly ignored CommonJS AMD split out into separate mailing list UncommonJS https://github.com/kriskowal/uncommonjs

13. Environments 1996 Netscape Livewire 1998 Helma (Rhino) 2007 AppJet (Rhino) 2008 CouchDB / Couch Apps (SpiderMonkey) 2008 RingoJS (Rhino) 2009 Narwhal (Rhino, V8, SpiderMonkey) 2009 Node (V8) 2010 Akshell (V8) 2011 Wakanda (Nitro) Over 30 in total http://wiki.commonjs.org/wiki/Implementations

14. Sync vs. Async http.get(url1) + http.get(url2)

15. Sync vs. Async function add(callback) { http.get(url1, function(response1) { var part1 = response1.data; http.get(url2, function(response2) { var part2 = response2.data; callback(part1 + part2); } } }

16. Interoperability Pure JavaScript CommonJS modules can run in any environment Templating, parsing, formatting, encoding – what else? Anything that does I/O must expose either a synchronous or an asynchronous API Dictates the style of interface exposed by higher level packages, e.g. database driver, ORM

17. API vs. Implementation Asynchronous, implement Node API Node RhiNodeII - https://github.com/lhofhansl/RhiNodeII SpiderNode - https://github.com/zpao/spidernode Node.NET - https://github.com/dnewcome/Node.net Synchronous, implement CommonJS API Ringo - https://github.com/ringo/ringojs Narwhal - https://github.com/280north/narwhal Common Node – https://github.com/olegp/common-node

18. Common Node Implements a number of synchronous CommonJS specifications on top of Node Uses node-fibers Uses co routines or multiple stacks within the same process not a fork or a hack Google's Traceur to support latest language features Bridges the gap between Ringo and Node, sync and async Fibers, HTTP proxy code examples & benchmarks

22. Platforms Node Joyent, Heroku, Nodejitsu, Nodester, Nodesocket, CloudFoundry Ringo Erbix, AppEngine & any other Java platform Akshell

23. Frameworks ServerJS is missing a Rails like framework Asynchronous DIY using Connect, Express etc. with Node Less of a problem, since Node is often used as glue Synchronous DIY using JSGI, Stick etc. with RingoJS Lack of a solid framework more of an issue

24. Trends Wider adoption Front end developers First time developers - http://www.codecademy.com Enterprises moving off legacy systems Java, PHP New operating systems Windows, mobile devices (but not WebOS)

25. Trends Web IDEs, XaaS Cloud9 – http://www.cloud9ide.com Akshell – http://www.akshell.com Compile to JavaScript languages CoffeeScript, AltJS http://altjs.org & http://notjs.org Extensible systems, crowd sourced functionality Think WordPress plugins + platform Locker Project http://lockerproject.org

26. Thank you! Questions? @olegpodsechin