This document discusses how JavaScript is experiencing growing pains similar to what Java experienced 10 years ago and how OSGi concepts and experiences can help address some core JavaScript problem areas related to modularity, packages, asynchronous APIs, and extensibility. It provides examples of how the Orion project has implemented OSGi microservices and plugins in a way that leverages OSGi lifecycle semantics and configuration while using promises to decouple from asynchronous implementations. The closing thoughts emphasize that JavaScript is becoming a reasonable systems language but has growing pains, and that OSGi can help if perceptions are corrected and APIs are made easier to adopt.

1. JavaScript and OSGi
Simon Kaegi, Orion Project Co-lead
IBM Canada @skaegi

2. 2
What’s up with JavaScript …
and why OSGi now?

3. 3
2005 – Open Source AJAX Libraries
Firefox and Webkit
2008 – Google Chrome and … V8!
WHATWG and HTML5
EcmaScript 5 (nee 3.1)
2009 – Node.js

4. 4
JavaScript 2013…
Aging AJAX Frameworks
Limited framework inter-op
Cottage industry of micro libraries
NPM Package Hell
(Tools are still horrible)
…victim of its own success

5. 5
JavaScript is going through growing pains
similar to what Java experienced ten years
ago.
OSGi concepts and experiences are universal
and relevant to JavaScript.

6. 6
“OSGI seems like overengineered Java stuff. I'm
generally pretty skeptical of big frameworks that do
everything for everyone. Usually they're a big
pain.”
-Isaac Schlueter (emphasis is mine)

7. 7
OSGi for JavaScript
OSGi
Focused, Lightweight, Open

8. Core JavaScript Problem Areas
• Modularity
• CommonJS “require”
• AMD (Browser) – require(stringID, callback) – async
• Node (Server) – require(stringID) – sync
• ES6 Module Loader
• http://wiki.ecmascript.org/doku.php?id=harmony:module_loaders
• Closer to class-loading than bundle loading

9. Core JavaScript Problem Areas
• Packages
• NPM Packages
• Closest thing to a bundle but more just project metadata
• OSGi bundles can be NPM Packages and vice-versa
• Useful work to be done right now!

10. Core JavaScript Problem Areas
• Asynchronous API
• Registered Callback Pattern (Node)
• doService(params, callback)
• Promises “A+”
• doService(params).then(onSuccess, onFailure)
• http://promises-aplus.github.com/promises-spec/
• W3C DomFutures
• ES6 Generators / Co-routines
• http://wiki.ecmascript.org/doku.php?id=harmony:generators

11. Core JavaScript Problem Areas
• Extensibility and Services
• OpenAjax / OpenSocial
• Web Intents (W3C Webapps WG)
• No strong standards plays at the moment
• Go OSGi!

12. Orion and OSGi
• Micro Services
• Complete implementation of OSGi Services API
• Uses Promises for return types to decouple from async service
implementation details
• Data only / No transferable functions
• PluginRegistry
• OSGi Lifecycle and Bundle State semantics used for Plugins
• OSGi Framework startup
• Preferences/Settings
• Implementation of Configuration Admin and Metatype for Plugin
Settings and Schema

14. Orion Core Retrospective
• Orion core “strongly” OSGi influenced
• Very small, fast, stable and predictable
• Nearly all OSGi service specifications in the compendium
are applicable in JavaScript.
• Direct Service API use has poor usability characteristics
• We need to find a simpler usage pattern to make OSGi
Services more approachable to the JavaScript community.

15. Closing Thoughts
• JavaScript is an increasingly reasonable choice as a systems
language
• Tons of innovation and tons of growing pains
• OSGi can really be of help here however
• We need to correct some invalid perceptions
• We need to make our APIs easier to use and adopt