The JS Ecosystem

  • ES variants, transpiling, and polyfills/shims
  • ES Engines
  • Package management
  • Task runners/Build tools, and linting
  • Back-end Interfaces
  • Web Components and related libs
  • Functional Programming libs
  • Reactive Programming libs
  • MV* frameworks/libraries
  • JS goes wild


ES Variants

I don't know of any other language that has spawned so many variants.

  • Node: Introduced '09, it uses Google's V8 JavaScript engine, plus numerous custom modules, to run outside the browser and provide networking, file IO, and more.
  • WebAssembly (wasm): Announced '15 it's a low-level binary "target" that will run in the JS engine with the aim of compiling from C/C++. Avail in most browsers.
  • TypeScript: Introduced in '12 by Microsoft, it stresses types and classes. It's strongly preferred by Angular and others. v2 released 9/'16.

ES Variants, II

  • Dart: Introduced '11 by Google it's a full stand-alone language, that also can compile to ES to run in the browser. It's future is uncertain.
  • asm.js: Introduced '13 by Mozilla, it's a strict subset of JS, and strongly typed. Its aim is performance. Most code written is transpiled using EMScripten. It's essentially being replaced by WebAssembly.
  • CoffeeScript: Introduced in '09, influenced by Ruby and Python, yet influenced ES6. It's future is uncertain.

ES Variants, III

  • PureScript: "a small strongly typed programming language that compiles to [idiomatic] JavaScript [without a runtime]." In integrates with others including React.
  • JSX (JavaScript XML): Part of Facebook's React, it's HTML, JS (extended, including types) and even CSS written together which gets processed into JavaScript. It uses Babel. It laughs at separation of concerns.
  • ActionScript: Introduced '98 by Adobe (then Macromedia), it was based on HyperTalk/HyperCard, became more JS like, but now it's more TypeScript like.

ES Variants, IV

  • Elm: Introduced '12, it's a statically typed, pure functional language. There's also a package registry.
  • Haxe: Has it's origins in ActionScript 3, but it's real difference is its transpilier which can generate JS, Flash, C#/++, PHP, Phython, and Lua.
  • AtScript: Introduced in '14 by Google for Angular 2.0, its been discontinued (Mar '15) in deference to Typescript which as of v1.5 added/merged many of its features.

ES Variants, V

  • ClojureScript: "... is a compiler for Clojure that targets JavaScript." It's a "dialect of Lisp", and Functional. A promising, if radical, future.
  • Flow: "A static type checker for JavaScript". It uses annotations and syntax, along with type inference, to find bugs.
  • F#: Introduced '05, by Microsoft; it's strongly typed but "multi-paradigm", including functional, imperative, OO, async and parallel. As of v3 in '12, JavaScript was introduced as target platform.

ES Variants, V

  • OCaml: "OCaml is an industrial strength programming language supporting functional, imperative and object-oriented styles." Hack, Flow, Haxe, WebAssembly compiliers are written in Ocaml. F# is based on Ocaml. BuckleScript (early '16) by Bloomberg has a JS target.
  • Reason: Introduced by Facebook, it's an "approachable [from JS perspective] interface to the OCaml", plus build system, NPM & BuckleScript integration, and more.
  • Kotlin: Introduced by Jetbrains, it runs under the JVM and hopes to be a "better Java", can also be compiled to JavaScript

ES6+ & Variants VS The Browser

Oh look, shiny! But will it blend run? (12/2017)

Yes! But you'll need some magic for older browsers.

Compatibility Magic

You've got basically two options:

  • Transpiling: convert the source into something compatible with the ES engine.
  • Polyfills/shims: add to or change the ES engine to work with the source.

They're not perfect though when targeting ES5: (12/2017)

What about ES7 plus?

JavaScript 2016 support isn't bad, considering: (12/2017)

ES7 plus compiliers and polyfills? (12/2017)


AKA Transcompiler or Source-to-Source Compiler

This is "source to source" compilation because it's from one high-level language to another.

A common example would be the Sass compiler to go from SCSS to CSS.

Most work as part of the tool chain, but some can also work in the browser (which is slow, but OK for learning).


Sometimes they are configurable as to the capabilities or compatibility of the output.

Transpilers can't always compile all features or implementations; usually they need shims in the output environment to work.

A big problem can be debugging, because the target language may be unfamiliar, or the resulting code is incoherent to humans, or the structure may not correlate, so Source Maps may be generated which link target code with source code. Some variants produce very "idiomatic" (meaning "natural") code which alleviates this issue.

But do I have to transpile?

You're probably already "compiling" from JS... as you're probably bundling modules and minifying.

You *will* be transpililing forever because ES will continue to evolve and engines will always lag.

Did you know?

Almost any language you can think of...

Including: PHP, Python, Ruby, Perl, Java, C/+/++/#, F#, Lisp, Haskel, Basic, Pascal, etc

Can be compiled to JavaScript?!


Polyfill is the just the name we give to Web technology shims.

This is library code that is included in the target code that "fills" in the "gaps" between the target code and a particular JavaScript engine's capability.

Compilers & polyfills

  • Babel: Current "winning". ES2015/2016/2017 and others to ES5. Very modular and pluggable. Works with almost any build system and test framework. Has various plugins ( >1200!) for React, minification, and much more. Includes babel-polyfill which includes the core-js polyfill.
  • TypeScript: compiles its own extensions (mostly types) and some ES6 to ES6, ES5 (or even ES3). Also creates/consumes "declaration files" which are like C header files. Primarily used from CLI.

Compilers & polyfills, II

  • Traceur: Introduced in '11 by Google. ES6 to some, to ES5. It can be used in browser or as CL tooling.
  • Closure Compiler: Introduced '09 by Google, it's a bit different: it primarily checks for various issues (including type checking with JSDoc), tries to optimize the code for speed, and also minifies it. It also does transpile some ES6 features. It's primarily to be used as CL tooling.

Compilers & polyfills, II

  • core-js: a modular library of pollyfills for ES6 and up. Often used in conjunction with a transpilier.
  • es6-shim: a library of pollyfills of ES6 for ES5. It's simple, just add the library before any other JS.

There's also many individual ES5/6/next/etc component polyfills that are useful if you just need that 1 or 2 newer features, or are concerned your code might run in an ES3 browser.

Try which will auto-magically determine the right polyfills and load them.

ES Engines

  • SpiderMonkey: Firefox & Adobe Acrobat.
  • V8: Chrome & Node.
  • Nitro: WebKit & Safari.
  • Chakra: MS Edge.
  • Plus a dozen less popular ones...

ES Engine performance and capabilities is a competitive and dynamic arena. Some have Just In Time (JIT) compiliers to generate bytecode or machine code, some use LLVM, and most use all sorts of arcane optimizations.

Modules and Package Managers


  • ES6 Modules: the new standard ... pretty soon now...
  • Asynchronous Module Definition (AMD): for client-side. Usually with RequireJS.
  • CommonJS (CJS): for Node and usually server-side.
  • "Global" module pattern: A DIY solution for the browser that works with ES3+.
  • Universal Module Definition (UMD): a library, ... and a hack?

Be aware, some frameworks rely on certain module systems (or their own custom), or may not work with some.

Using Modules

For async modules there's a trade off between responsiveness (waiting for dynamic lazy loading) VS initial bundled JS load.

Async (individual) modules may limit minifaction and other optimizations.

HTTP/2 can help alleviate server request penalities of async modules.

Some options (like Webpack) bundle into static assets (avoiding dynamic loading).

ES6 Modules

The ES6 format is similar to CommonJS, and allows export and import of modules or parts of modules.

Will have support for both synchronous and asynchronous loading.

Has a load API to programmatically configure interactions with modules.

Supported in Chrome, Safari 10.1, Edge 15 & Firefox 54 (both with a setting)


The current standard for async modules, AKA dynamic lazy-loading modules.

Intended for use in a browser, you can load multiple modules and defer loading, as needed.

Somtimes asynch loading of dependencies can get tricky. Code execution order may not be as expected.

You define() modules then later require() them.


The current standard for synch (server side) modules.

Order of execution is guaranteed, as all modules load synchronously (possibly slower).

Not appropriate for the browser, *except* when using Webpack or Browserify.

You assign module.exports object and later require() them.


Why choose AMD or CJS when you can use both?!

  • UMD(.js): loads AMD and CJS modules, as well as "global" (Modual Pattern) modules.
  • SystemJS: loads ES6, AMD and CJS modules. Plugins are available to load other things, including CSS, SVGs, MarkDown, and more.
  • Manually: possible, but it's ugly

"Global" module pattern

var doSomething = (function (doSomething, $) {
  var privateVariable = 1;
  function privateMethod() { /* ... */ };

  var my = {},
  my.publicProperty = 2;
  my.publicMethod = function () { /* ... */ };

  return my;
}(doSomething || {}, jQuery));

It's a great pattern that doesn't need any tooling and really enforces writting modular, interface-centric code. I've done a session on this, see

Package management

Most modern JS development involves use of some form of modules, often formalized into packages.

  • Repository: where packages are kept
  • Acquisition & installing: download, verify, and local org.
  • Package Configuration: optimize use of the package
  • Dependency management: managing compatibility
  • Bundling: composing one or more files of packages

On a *nix system equivalents are pear, cpan, yum, apt, etc.

Deep vs Wide

You'll see some package managers create flat, deep, or somewhere in between, dependency trees. The dependency tree is all the packages required by all the other packages.

Flat dependency trees are created because the manager has to figure out which 1 version of a package will satisfy all requirements. Sometimes this attempt fails and packages or dependencies have to be re-chosen.

A Deep dependency tree tries to find the "best" dependency version for every package at every level.

Generally you want wide for browser, deep for server.

Deterministic vs non-

Most package managers work off one or more config files (often JSON or YML) which specify dependent packages.

With each package comes compatible, usually in SemVer syntax, versions. This syntax specify an exact version, or some sort of approximate version, like on patch or minor version.

With non-specific syntax you run the risk that a build on one system may be different from another, and this is called "non-deterministic".

Some package managers offer control over this, like npm's deteministic "shrinkwrap" or Yarn.

SemVer, quickly

A defined, sensible way of maintaining version numbers. From the site:

Given a version number MAJOR.MINOR.PATCH, increment the:

  1. MAJOR version when you make incompatible API changes,
  2. MINOR version when you add functionality in a backwards-compatible manner, and
  3. PATCH version when you make backwards-compatible bug fixes.

Additional labels for pre-release and build metadata are available as extensions to the MAJOR.MINOR.PATCH format.

Check the site for all the details

Tree Shaking

Even with flat dependency trees, the amount of code can really add up.

Tree Shaking is removing code that isn't going to be executed from the deployed bundle.

As Front End applications get larger, more complex, and have more dependencies, there's some manual and (at least semi-) automatic methods to tackle that.

TS is included in some frameworks like Angular 2.

Bundling / Code Splitting

You're following best practices by keeping all your JS in small, organized files.

You bundle them up to ship to the browser.

Code Splitting is defining portions, sometimes called "chunks", of code to be loaded asyncronously on demand.

Template* Compilation

This isn't the best conceptual place to put this but it's messy...

This means HTML Templates (* and sometimes more) are converted to JavaScript during "compilation" (ie prior to running in a browser).

This is important because frameworks like Angular and React (using JSX) don't use pure HTML templates, and can identify errors at compile time.

Angular2 calls this AOT (Ahead of Time) compiling.

Package Managers

  • npm: "Is the package manager for [everything]". See also Yarn.
  • Bower: "A package manager for the web"
  • JSPM: "Frictionless browser package management"
  • Webpack: "Emits static assets representing those modules [with dependencies]"
  • Browserify: "Lets you require('modules') in the browser by bundling up all of your dependencies."

Node Package Manager (npm)

A very popular repository, handles acquisition & installing, and dependency management. Has nearly 300K modules in the registry, in CommonJS format.

Originally intended for Node it's now become the leading repository/package manager.

Node packages can contain almost any asset.

npm creates a deep dependency tree for each package and subpackage, ensuring proper versioning, but also often duplicating requires packages, sometimes numerous times.


Does not have it's own repo, nor does it acquire modules (nor their dependencies). It depends on (and works with) "nearly every 3rd party library" being in-place.

Works with ES6, CJS and AMD modules.

Targets Browsers, with an emphasis on big SPA (Single Page Apps).

It can replace task runners, with the exception of linting and unit tests, but can be difficult to configure.

Supports live and hot reload.

Webpack, continued

Controlled by a (declarative) config file, and is very opinionated.

Has a loader/plugin system to do almost anything, including things often handled by Task Runners.

Webpack can do bundling, and loading on demand.

Also supports Hot Module Replacement.

Seems to be the choice of React, and generally most popular, despite a seriously complicated config.


decidedly looking long in the tooth

Bower is "unopinionated". It has a popular repository but also has "pluggable resolvers" which can acquire packages from npm, git, bitbucket, and pretty much any other repo.

It also handles dependency management, and installation. It's installed via npm.

Bower can handle packages of just about any asset.

It creates a flat dependency tree to minimize client-side transfer size, sometimes at the risk of the best versions.

Bower-related tooling can handle bundling and loading.


Does not have its own repository but works with npm and GitHub, referred to as "endpoints."

Works with ES6, AMD, CJS and Global modules.

Creates a flat dependency tree, and bundles as needed.

Loads SystemJS library for module loading.

Designed with HTTP/2 in mind.

Supports Hot Module Replacement - dynamically loading new code in the browser automatically, without losing state.

Seems to be the choice of Aurelia.


Does not have it's own repo, nor does it acquire modules (nor their dependencies.) It works with npm and CommonJS.

Targets Browsers.

Supports only Live Reload.

Has a plugin system to do almost anaything, but needs to be controlled by your choice of Task Runners.

Bundles up into a single file.

Losing out in popularity to Webpack?

Elm Package Manager

Since Elm is strictly typed, the interesting thing about this PM is that not only handles dependency management, it enforces SemVer rules such that breaking API/"interfaces" means the Major version number must update.

Task Runners/Build Tools

These provide automation of the "tooling" around preparing modern dev assets into a run-ready state, such as "doing":

  • Sass or LESS
  • Compass or other CSS frameworks
  • Linting, and Transpiling
  • Processing, spriting & minifying assets
  • Processing modules, and Bundling
  • And almost anything imaginable

Some Task Runners/Build Tools

  • Gulp: uses a (imperative) js code file to use a large number of available plugins. "Winning" popularity.
  • npm scripts: avoid "plugin hell" of Grunt & Gulp, and (declaratively) create scripts that use npm modules' CLI directly. Increasing in popularity.

More Task Runners/Build Tools

  • Grunt: uses a (declarative) configuration-based js file to use a substantial number of available plugins. Decreasing in popularity.
  • Makefiles: yup, that 1977 tools is still around... dare I call it's JS use a hipster thing?
  • RunJS: A minimalistic tool in JS, that's "halfway" between using npm and Grunt/Gulp.
  • ... and a few other minor ones like Rollup, Broccoli, etc., and GUI apps like CodeKit


Linters flag erroneous or suspicious syntax or usage, and/or stylistic issues.

Probably the most controversial "rule" is around semicolons. ES doesn't need them, but without them you must ensure you don't use any syntax that will be parsed incorrectly. "Automatic Semicolon Insertion" is an actual spec'd function of ES.

Don't discount the important of stylistic linting (usually used in conjunction with a Style Guide). They help increase readability, clarity, re-use and debugging.


  • ESLint: most extensive, configurable & pluggable. Best ES6 support. Somewhat slow. Use this one.
  • babel-eslint: a custom ESLint parser that has support for some "experimental" (pre-stage 4) JS syntax.
  • TSLint: just for TypeScript. Extensive, configurable, and custom formatters.
  • JSLint: first, but pretty much limited to Crockford-isms.
  • JS Hint: more extensive and configurable, but no custom rules. Rule feedback isn't great.
  • JSCS: only checks for stylistic issues based on rule sets. Supports plugins and custom reporters. Slowest.

Style Guides

Not all these are available as linter plugins/styles. Some have IDE plugins or integration.

  • airbnb - "mostly reasonable approach to JavaScript"
  • Idiomatic.js - "principles of writing consistent, idiomatic JavaScript"
  • Google - "for Google-originated open-source projects"
  • "Standard" Style - "One JavaScript Style Guide to Rule Them All"
  • Crockfords' - "The long-term value of software to an organization is in direct proportion to the quality of the codebase."

Domain-specific Style Guides

Often when used with various framework, or "full stack" products, they'll have their own:

  • jQuery - often used for jQuery plugins
  • Drupal - as of v8, it uses a slight variation on airbnb's
  • npm style guide - for npm modules
  • Wordpress - adopted from jQuery's

There's many more...

Back-end Interfaces

Basically this includes both the conceptual and practical way your front-end talks to your back-end.

  • REST - the de facto interface, that uses specific endpoints to deliver pre-defined data based on a key (more or less).
  • GraphQL/Relay - From the makers of React, GraphQL is a JSON-like declaritive language for requesting *arbitrary* data, using the Relay library. Apollo is a variant.
  • Firebase - request data via client library API, REST, or directly bound into some frameworks.
  • ... and others like Parse, Falcor, Couchbase, Swagger, etc.


There's a distinction between components as a concept and components as implemented various way, including as "official" Web Components. As a concept:

  • isolated: they do not interfere with each other, even multiple copies of the same component
  • defined "api": how to interact with a component is clearly defined, as well as it's output
  • declarative
  • composable: a key strength, being able to combine arbitrary components

Web Components in practice

How to get WC running live in a browser:

  • webcomponents.js: or variant webcomponents-lite.js which lacks shadow DOM
  • Polymer: a "lightweight sugaring layer on top of the Web Components"
  • SkatejS: a "functional, featherweight and cross-framework compatible web component library built on W3C specs."
  • Stencil: "The magical, reusable web component compiler" based on W3C. It's an spin-off from Ionic, but is largely framework-agnostic.

Web Component-ish

React, Angular, Aurelia, Ember, and other frameworks are build on a "component" structure but do not use W3C WC's.

Their ability to utilize or work with W3C WC's varies greatly.

Functional Programming

FP programs are a sequence of stateless function evaluations, and tries to treat a programming function as a mathematical function, and less like a simple procedure.

Concepts included: First-class and higher-order functions, Immutability, Function Composition, Partial Application, etc.

Functional Programming in practice

You can do functional programming manually, or there's some libraries and frameworks to help:

  • underscore: helper library that's functional-ish.
  • lodash: a rewritten, performant and enhanced drop-in replacement for underscore. Use this.
  • Ramda.js: functional-first helper library
  • Functional.js: functional-first helper library
  • Immutable.js: persistent immutable collections library
  • ... and FP ES variants, and ES frameworks that encourage FP.

(Functional) Reactive Programming

RP is an abstraction for capturing and manipulating asynchronous data streams, and automatically "react"ing to changes.

Functional Reactive combines Function and Reactive paradigms.

Reactive is inversion of control

(Functional) Reactive Programming in practice

  • RxJs: by Microsoft, "a set of libraries to compose asynchronous and event-based programs using observable collections..." Usable in many situations, but direcly supports frameworks like (some versions of) Angular, Backbone, Ember, etc.
    • RxJS = Observables + Operators + Schedulers
    • There are Java, .NET, Scala, Swift and other implementations of this same library
  • Bacon.js: "A small functional reactive programming library." Inspired by RxJs.

FRP in practice, 2

  • React: By Facebook, a "library for building user interfaces". The "V" in MV*, and distinctly component based. To say it's popular is an understatement. Best used with Facebook's JSX (JS and HTML) and Flux (like the "MC" in MV*). Can do server-side rendering. It's ecosystem is unopinionated to the point of being fragmented.
  • WebRx: "a browser-based MVVM-Framework that combines functional-reactive programming with declarative Data-Binding, Templating and Client-Side Routing", built on RxJs.

FRP in practice, 3

Last but not least:

  • Vue: "Reactive Components for Modern Web Interfaces". Similar to React: it's reactive but not FP, but doesn't use a Virtual DOM. Fast and lean. Popularity rising. Tooling is a concern. Laravel is a big supporter.


MV* means "Model View ... something". It's shorthand for a "family" of similar design patterns where implementations fall in a spectrum vs meeting strict definitions.

There's Model View [Controller | Presenter | View Module | Intent | Update], the related PAC, and probably others:

  • "M"odel or "A"bstraction: is the data (or "object")
  • "V"iew: the interface for viewing and modifing the Model.
  • "C"ontroller or "P"resenter: handles input, and is an intermediary between M & V

MV*'s status

Some consider some MV* a code smell as it's too tightly coupled, with insufficient separation of concerns.

We may be in a post-MV* world now, as "component"-based development may our (present and) future.

  • Angular, React, Ember have all moved to (or started out as) component based.

To get a better understanding of MV*'s, see my "A Walk-through of a Simple JavaScript MVC Implementation"

MV* Frameworks

  • Angular 1: ES3/5, uses Promises and custom elements.
  • Angular 2+: Angular2 released 9/'16 but now the "2" is just the major version number; Angular 5 released 10/2/17. Only somewhat MV*-ish. Recommended to use TypeScript, or use ES6+, requires transpilation. Uses RxJS Observables over Promises. It is a radical rewrite of v1, but will work in conjunction with Angular1. Usually used with Webpack. Angular Universal is for server-side rendering. Recommended.

MV* Frameworks, 2

  • Aurelia: use ES6+ or TypeScript, requires transpilation. More convention over code. A fairly "thin" framework. The creator of Aurelia was on the Angular2 team for a while but decided to go his own way, thus Aurelia. Struggling to gain a foothold.
  • Ember: something of a "all this and the kitchen sink" solution (including SSR, including a CLI that includes dependency management, task runner, etc) that stresses "convention over configuration" (which makes it popular with Rails-ers). Despite that, gaining popularity, especially with Rails folks. Size and performance may be an issue. It's trying hard to modernize but is struggling.

MV* Frameworks, 3

  • Meteor: and Blaze, it's frontend rendering system, it's more than an MV*, it's a full-stack framework. Recently it's adopted React though. It has a unique and somewhat incompatible "DPP" PubSub system.
  • Backbone: A bit dated and minimal, but quite useful.
  • KnockoutJS: "Simplify dynamic JavaScript UIs with the Model-View-View Model (MVVM)".
  • ... and many more

State Management

At any given point in time, the values of the program's variables is its "state".

State discussed here is not so much an academic discussion, but rather the Model and how the how the Model changes.

State Management is part of MV* frameworks but with M-less frameworks getting popular (like React), a solution for complex applications was needed.

Flux and Redux (the most popular), along with MobX, Relay, Alt.js, etc., have arisen to fill that gap.

Testing Solutions

There are many solutions, some work together, or have other requirements:

Mocha and Jasmine are by far the most popular, but some are popular in conjunction with certain frameworks.

  • Mocha - "A feature-rich JavaScript test framework running on Node.js and in the browser, making asynchronous testing simple and fun."
  • Jasmine - "A behavior-driven development framework for testing JavaScript code. It does not depend on any other JavaScript frameworks."

Testing Solutions, 2

  • QUnit - "A JavaScript Unit Testing framework."
  • Ava - "Futuristic JavaScript test runner". Works concurrently.
  • Tape - A test harness for node and browsers, that takes Unit tests and produces TAP (Test Anything Protocol) output.
  • Protractor - "An end-to-end test framework for AngularJS applications."
  • Nightwatch - "An easy to use Node.js based End-to-End (E2E) testing solution for browser based apps and websites. It uses the powerful Selenium API."

Testing Solutions, 3

  • CasperJS - "Navigation scripting & testing for PhantomJS and SlimerJS."
  • WebDriver - "a remote control [W3C] interface that enables introspection and control of user agents."
  • PhantomJS - "A headless WebKit scriptable with a JavaScript API." As of 4/'17 it's being abandoned as native headless Chrome 59 (also possibly FF 55)
  • Karma - "Things should be simple. We believe in testing and so we want to make it as simple as possible."

Testing Solutions, 4

  • Unit.js - "is an assertion library for Javascript, running on Node.js and the browser. It works with any test runner and unit testing framework like Mocha, Jasmine, Karma, protractor..."
  • Jest - a JS "testing framework ... to test all JavaScript code including React"
  • Enzyme - A JS testing utility for React, and can be used with Mocha, Karma, and more.
  • Selenium - "...automates browsers. Primarily, it is for automating web applications for testing purposes..."


AKA FaaS (Functions-as-a-Service)

Allow discrete, stateless, usually short-running, code to be run in the cloud. It's the continued abstration of HW.

Usually event-driven from things like databases, or mobile or IoT devices.


  • decompose big problems into small manageable tasks
  • enforces decoupling
  • stresses clean API's

Serverless Providers

Providers (to varying degrees):

  • AWS Lambda
  • Firebase
  • Google Cloud Datastore
  • Azure Functions/Serverless
  • RabbitMQ
  • Stackdriver
  • Google Cloud Drive
  • App Engine
  • Apache OpenWhisk

Generally providers require no specific provisioning, but may have some "tuning" configurations.

Metered ($$) usage, but usually scales down to $0, and scales up practically limitless.

It's ready for production use.

more Serverless

Frameworks and libraries also exist to help:

  • - "is your toolkit for deploying and operating serverless architectures."

JavaScript Goes Wild

JS' popularity has spread its use to unexpected places, and even "dragged" other web technologies with it.

  • The most obvious place was using web technologies to make "apps".
  • VR & AR
  • Embedded, IoT & robotics systems have tried to leverage JS' wide appeal.
  • JS your CSS? JSX includes CSS; there's CSSX fluent JS library, and CSS as ES6 Tagged Template Literals.

Web "Apps"

Web Technologies have long been used to try to make mobile "apps"-like or even native apps.

Some present a webpage as a mobile app, others result in "native" app that hides the fact it's using a "web view" (browser), but at least you can download it from the App Store.

Below are a list of many solutions, followed by in-depth of a few.

Web Tech as "Apps"

  • Adobe Flash & AIR Applications: often powered by Actionsctipt (historically interwoven with JS).
  • jQuery Mobile: a cross-platform user interface system for browsers.
  • Various Browser-specific Solutions.
  • Cordova/PhoneGap (and ecosystem): Not a framework but a API hardware abstraction & packaging/release solution.
  • Ionic (Angular): "beautiful, open source mobile SDK for developing native and progressive web apps. Recommended.

Web Tech as "Apps", 2

  • Intel XDK: an all-encompasing system of integrations, APIs, Cordova, development, testing, deploying mobile HTML5 apps, and now also Node.JS IoT apps.
  • Appcelerator Titanium: "Write in JavaScript, run native everywhere". Includes Alloy, a MVC framework.
  • Sencha Touch: "The leading cross-platform mobile web application framework based on HTML5 and JavaScript for creating universal mobile apps."
  • Kendo UI: "Build rich, smart HTML5 and JavaScript apps for any platform, browser, or device." Also integrates with Angular.

Web Tech as "Apps", 3

  • W3C Packaged Web Apps: "re full-fledged client-side applications that are authored using Web standards such as [HTML] and packaged for distribution."
  • NativeScript: "Open source framework for building truly native mobile apps with Angular, TypeScript or JavaScript."
  • Electron: see more below.
  • Chromium Embdded Framework (CEF)
  • "Progressive Web Apps": see more below.
  • React Native: see more below.


A project by Github to create support Atom(editor), which became a general sollution to make desktop applications with web technologies.

It uses a modified versions of Chromium and Node to share a single V8 Javascript Engine to support both event loops! It's gained a lot of popularity and has generated quite an ecosystem of its own.

Just use Node, HTML, CSS, and whatever JavaScript based Front End framework of your choice.

Disadvantages include large file size (50/60MB+), performance, battery life, etc.

Successful examples include: OpenFin (a Financial "OS/VM"), Atom (IDE), Slack, Microsoft's Visual Studio Code, Postman.

Progressive Web Apps (PWA)

PWA's are web sites that use (although new and evolving) standards to not only work as "regular" web sites, but also as a mobile apps.

To the user, the "site" has these app-like characteristics:

  • (Screen) Responsive - although this isn't new if you've practiced RWD
  • Network de-coupled - works (at least to some degree) with low or no bandwidth
  • Installable - can be added to mobile home screen
  • "Fresh" - data is kept up to date w/out user interaction
  • App-like - design and operation are more like native apps

PWA's, 2

A common pattern is PRPL (often pronounced "Purple"): Push critical initial route resouces, Render initial route, Pre-cache remaining routes, Lazy-load routes as needed.

Tech used to make PWA's:

  • Responsive CSS
  • Service Workers
  • Web App Manifest
  • Network Information API

These technologies replace the depreciated "appcache" solution.

Google made Lighthouse to test PWAs and provide feedback

React Native

Also by Facebook, it extends React to run as a "real" native app that exposes native device components, APIs and modules to JavaScript. It also allows integration with native code written in Objective-C, Java, or Swift.

In some sense, it's like Cordova/PhoneGap taken one step further.

Because RN is different enough from React, the Holy Grail (nee!) of sharing components and code isn't really realized. So, this was born:

"React Native for Web" brings the platform-agnostic Components and APIs of React Native to the Web.


Originally by Progress, in 2015, like React Native (as compared to Ionic/Cordova), NativeScript does not use web views (basically the browser) on mobile devices - it uses native UI.

Works with either Angular/TypeScript, or JavaScript, or even Vue.

It's production ready and has a great "Showcase" of results.


While themselves Augmented Reality and Virtual Reality are still in their (modern) infancy, JavaScript implementations have not been far behind.

To get good smooth display the code needs to render 60 frames per second, or faster; jank is bad while scrolling but worse in AR/VR.

React VR

Build VR websites and interactive 360 experiences with React

It uses React concepts (although more similar to React Native), components and (optional, though recommended) JSX, Three.js, WebGL, and physical headsets via WebVR.

The VR can be experienced with a headset, or in a browser - even embedded on a webpage.

Although not an official "thing" a number of efforts to make "React AR" have been based on React, React Native or React VR.


WebVR is an open specification for web-based VR to a physical headset.

Support is scattered, and most headsets are only really supported on a single browser, like Oculus Rift & HTC Vive on Firefox (nightly), Windows MR headsets on Edge, or Daydream or Cardboard on Chrome.

There's even a WebVR polyfill, although it's very limited in support. There's also a simulation plugin for Chrome.

But, it's definitely experimental at this stage.


Efficient Augmented Reality for the Web - 60fps on mobile!

It uses webgl, webrtc, Three.js, and jsartoolkit5. Device/Browser support is very spotty, but it's been also shown to work on both HTC Vive and Hololens

But, there's a number of demos, articles and videos on it.

IoT, Embedded & Robotics

While JS' inherent async nature and deftness with data "streams" make it seem ideal, it's inability to deliver accurate repeatable timing, make it's use limited, although accessible to hobbyists.

  • Tessel - "Tessel 2 is a robust IoT and robots platform" that leverages Node.JS libraries.
  • Espruino - both a custom JS Interpreter for - and a line of compatible - microcontrollers. I have a couple myself.

IoT, Embedded & Robotics, II

  • Cylon.JS - a very cross-platform robotics framework; uses Node.JS
  • Johnny-Five - a JavaScript Robotics & IoT platform; uses Node.JS.
  • PebbleKit - a JS framework for the Pebble watch.
  • SparkJS - a SDK for the Spark OS and hardware.
  • Etc...

About Todd

Lead Drupal Developer at @meetmiles