JavaScript and fungibility

I’ve been thinking about JavaScript this year as Alley does more work with ES6 and React. There’s a lot of upfront setup with JS these days, due how Ecma specs work and the need to use Babel or other compilers to map next generation functions to their fallback implementations.

But I’m working on a project this morning that’s totally built on JavaScript – the POUND open source clone – and it struck me that I will be using JavaScript in four different contexts, all of which can swap code pretty much seamlessly. The traditional JavaScript “tag”, a AWS Lambda “serverless” API, and an isomorphic graph app (that runs both server side and on client). JavaScript’s ability to run in multiple contexts and, after some configuration, do so in an optimized and compatible manner makes it the code equivalent of fungible. One solving of the problem in idiomatic ES6 should be substantially equivalent to another example of solving the same problem at the same quality at the same time and place.

Fungibility introduces a lot of cool things, most notably better exchange of code on marketplaces and therefore more efficient operating of engineering teams. NPM is the classic example, another being Algorithimia, which is more “functions as a service”. As developers this lets us focus efforts on the top of the integration layer and then the rest of our stack can and should embrace open source (including upstream contributions).

Posted Jul. 30 2017, 6:41 am by davis