1 / 15

OSGi for JavaScript: Solving Modularity and Extensibility Challenges

Explore how OSGi concepts and experiences can address the growing pains of JavaScript, providing solutions to modularity, package management, asynchronous APIs, and extensibility challenges. Discover how OSGi can make JavaScript development more approachable and help manage the evolving ecosystem.

eblalock
Download Presentation

OSGi for JavaScript: Solving Modularity and Extensibility Challenges

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

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

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

  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. 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. 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. “OSGI seems like overengineered Java stuff.  I'm generally pretty skeptical of big frameworks that do everything for everyone.  Usually they're a bigpain.” • -Isaac Schlueter (emphasis is mine)

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

  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 • MicroServices • 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

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

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

More Related