Language Compatibility

As discussed in the last two talks, EXCMAscript is being improved on yearly cycle.

That means the ES Engines (thus browsers) are always trying to keep up**. While ES6/ECMAScript 2015 support is pretty great for Evergreen browsers, anything past that is dodgy.

And what if you have to support non-Evergreen Browsers?

** Browsers sometimes implement features well before they're approved leading to incompatible or broken implementations.

Language Compatibility Solutions

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.

Of course the third option is to not use new features, and while that's reasonable, many of the new features are uniquely new, or offer significant code readability improvements.

ES6

They're not perfect even when targeting ES6:

ES7 plus?

ES2016+ support isn't bad, considering:

ES.next

Pretty poor so don't rely on these for compatibity.

Transpiler

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

Transpiling

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.

Transpiling Issues

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 these 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?!**

Polyfills/Shims

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

Compilers & polyfills, II

• 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.
• Traceur: Introduced in '11 by Google. ES6 to some ES.next, to ES5. It can be used in browser or as CL tooling.

Compilers & polyfills, III

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

Compilers & polyfills, IV

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 polyfill.io which will auto-magically determine the right polyfills and load them.

Package management

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

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

Package management

Package managers do at least one or more of the following:

• 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

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.

Generally you want wide for browser, deep for server.

Deep vs Wide, 2

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.

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.

Deterministic vs non-, 2

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 semver.org, see it for more details:

SemVer, 2

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.

Webpack

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.

Bower

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.

JSPM

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.

Browserify

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

Task Runners/Build Tools

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

Linting

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.

Linting, 2

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.

Linters

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

Linters, 2

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

Style Guides, 2

• "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...

prettier.io

Prettier is an opinionated code formatter.

Make a mess while writing your code and it cleans it all up for you.

Back-end Interfaces

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

Back-end Interfaces, 2

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

Components

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: being able to combine arbitrary components

Web Components in practice

How to get WC running live in a browser:

• 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 Components, 2

• 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 Programming, 2

• 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

FRP in practice, 2

• Bacon.js: "A small functional reactive programming library." Inspired by RxJs.
• 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.

FRP in practice, 3

• WebRx: "a browser-based MVVM-Framework that combines functional-reactive programming with declarative Data-Binding, Templating and Client-Side Routing", built on RxJs.
• 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*

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.

MV*'s status

To get a better understanding of MV*'s, see my "A Walk-through of a Simple JavaScript MVC Implementation" medium.com/@ToddZebert/a-walk-through-of-a-simple-javascript-mvc-implementation-c188a69138dc

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.

MV* Frameworks, 3

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

MV* Frameworks, 4

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, 2

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."
• Jest - a JS "testing framework ... to test all JavaScript code including React". Rising star?

Testing Solutions, 2

• Jasmine - "A behavior-driven development framework for testing JavaScript code. It does not depend on any other JavaScript frameworks."
• 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."

Testing Solutions, 3

• 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."
• 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)

Testing Solutions, 4

• Karma - "Things should be simple. We believe in testing and so we want to make it as simple as possible."
• 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..."
• 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..."

"Serverless"

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.

Benefits:

• 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
• Iron.io

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:

• serverless.com - "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 step was using web technologies to make "apps".
• VR & AR

JavaScript Goes Wild, 2

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

Electron

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.

Electron, 2

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.

Progressive Web Apps, 2

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
• HTTPS
• Web App Manifest
• Network Information API

PWA's, 3

These technologies replace the depreciated "appcache" solution.

Google made Lighthouse to test PWAs and provide feedback developers.google.com/web/tools/lighthouse/

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.

React Native, 2

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.

NativeScript

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.

AR & VR

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

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.

AR.js

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.

Examples follow.

IoT, Embedded & Robotics, 2

• 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.
• Cylon.JS - a very cross-platform robotics framework; uses Node.JS

IoT, Embedded & Robotics, 3

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