Hello JS-heroes!!

Last updated: 2019-04-12

Flaki, tinkering

Szmozsánszky István "Flaki"

Mozilla DevRel

Developer Outreach / DevRel

Mozilla TechSpeakers

Mozilla TechSpeakers


Tessel Project, JS+HW hacker

the JavaScript Singularity

István Szmozsánszky "Flaki"

a.k.a.: the burning questions of the JS ecosystem

JavaScript in Hyperdrive


  • 2008: V8 (Node.js in 2009)
  • 2013: asm.js (WebAssembly in 2015)

JavaScript is everywhere. JavaScript is faster than ever. JS became fast despite itself - it was never intended to be particularly fast, but as its adoption grew it was destined to be.

Birth of the GREAT DIVIDE

The boom in execution speed gained JavaScript new embedders, as it enabled new usecases.

Universal & Isomorphic

“We’ve worked on multiple React projects, but in every case, the output was server-rendered. Developers get the benefit of working with a tool that helps them. Users don’t pay the price.” — Jeremy Keith

SSR! I cannot promise to explain away the framework churn, this isn't a talk for that, I would be up here all day. Jeremy Keith & Remy Sharp in their recent articles provide insights into one particular facet of this issue, though: does it matter, if the user won't see it?

The answer is "Maybe. Maybe not." -- see Adactio's concerns why it might still matter but for the sakes of this talk, I'll focus on how JavaScript's universality on the client AND the "server" enabled this in the first place.

Let's talk about Node.js


It earned its place (tooling, server-side)

  • server side code (servers)
  • functions (serverless)
  • ssr/ssg (back-of-front-end)
  • tooling

Let's talk about Node.js. Why Node?


Node.js & the Web

  • missing secure sandbox
  • unlimited file and network access
  • native modules
  • exec permissions

Node is not the Web -- but this is on purpose. DShaw actually talks about its ongoing (and much needed!) transformation in the talk I linked to from NodeConf Argentina last year, and I'll get into this in a minute but first…

Planet breaking up, by David Edwards

The Permissions Fissure


  • network (request vs fetch -- CORS)
  • filesystem (unlimited -- sandbox/dom api)
  • native (high-speed) execution (native binaries vs …?)
  • low-level features and system access (hardware, graphics)
  • advanced processing features (threads, simd…)

A single system cannot cover every single use case. No matter how flexible a system is, there's a good chance someone will need an even more powerful one, and will build it -- there will always be differences. The important question is: how easy it is to move between these systems.


With great power, comes great vulnerability

When Node chose to forgo the sandbox, that invited all kinds of weirdness. Jake (and few others) have been musing about the security implications of this lately, and while there are mitigations against most of these issues, this insecure baseline is less than ideal. That said…

Node.js was inevitable

JavaScript world domination

Node.js was born out of the need of wanting to do more with a familiar (and now finally fast) language, using it in many more places than just writing scripts that chased the mouse pointer around and greeted the user by their name. Node wasn't the first attempt at this, but for a variety of reason that we cannot dive into here, became a wildly successful driving force in the inevitable rise in JavaScript usage.

Node.js and the Web Platform


API convergence: slowly but surely

More on worker threads from Anna Henningsen

Joyee Cheung - Web APIs in Node.js Core: Past, Present, and Future

The prodigal son…

Joyee Cheung - Web APIs in Node.js Core: Past, Present, and Future

The prodigal son… returns?

Node.js is slowly finding its way back to the Web Platform:

  • Native fetch()
  • Various utility APIs (e.g. TextEncoder/Decoder)
  • Cross-platform viable APIs (e.g. Performance Timing API)
  • WebAssembly & ES Modules

While most of these are DOM (browser) APIs, the last two come with the JS-engine so it shouldn't be that surprising that they are (eventually) going to be supported -- but, as with everything in Web & Standards land, this is far from being this straightforward :)

À propos modules…

Code separation in JavaScript

…has traditionally been perilous

Let's face it, JS wasn't great in isolation, especially async (commonJS is inherently sync - again, it's more 'convenient')

We got better, promises and later async (thanks, Maya!) made async calls almost as convenient as synchronous ones. What about isolation?

Well, good news!

Node & npm had a bat at fixing this

Having everything in a single thread/process makes you sloppy

You need modularization, isolation and asynchronous loose coupling (+synchronization)

Okay, so how big of a mess, exactly?

EcmaScript Modules has set out to fix this mess

Experimental Native ES Modules in Node 10+

It gets even better…

Node.js ESModules Phase two adds seamless support and adoption for the EcmaScript modules spec. CommonJS is basically "legacy" now. Complete opt-in possible, interop with CJS also possible and reasonably effortless. Currently still needs --experimental-modules cmdline flag.

But…will it blend (in)?

So you could use modules across platforms but will they work? The API differences between the platforms might mean they won't (and that's exactly why the DOM API convergence is good news), or you could use the appropriate abstractions, but there's a way around this too. But before we get into that, let's have a look into how the fancy stuff works under the hood in Node.js

Ever met this guy? :)

Besides the libUV bindings, Node.js also allows binary modules, compiled during installation from scratch by node-gyp. Ideally.

The rabbit hole goes even deeper with Electron

These lower-level abstractions are nothing new

When we take a look at any number of programming languages, dropping to a lower level of abstraction when performance or access to system resources require it is a mainstream practice: high-level languages like Ruby, Python, even Node.js achieve this via platform-specific binary modules; even low-level languages like C/C++ allow for inline assembly when performance & precise control becomes a priority. What WebAssembly brings today is this exact capability to the entire Web Platform — without the drawbacks like platform-dependence, but also with the added choice of virtually any programming language (with big asterisks on "any", at least today).

WebAssembly was born, out of the need for something that was able to cater for those usecases not already covered

WebAssembly one day may solve all your binary portability problems

In fact WebAssembly might be first in line for solving some of these platforms’ binary-module-specific woes.

Small, fast, portable bundles with WebAssembly + ES Modules

Fast enough to power parts of your browser!

Wasm is used in improving source map parsing speed tenfold in Firefox’s Developer Tools by surgically replacing performance-sensitive parts of its JavaScript-heavy Debugger with tailor-made WebAssembly solutions. Yes, that's JavaScript and WebAssembly powering parts of a production web browser on hundreds of millions of computers all across the world!

MVP or not, Wasm is already in production

Wasm-ifying a small, purpose-built Rust library and using it on the web is the perfect usecase behind WebAssembly!

Experimentation is essential!

It's like jQuery all over again!

I'm not saying you should re-implement jQuery in the Lambda-calculus…

Tech that was once experimental, is now running purely in-browser!

Jupyter on steroids

Early standardization might help with the later head-scratching

Thinking about security early on

Experiments teach us how to improve our ways

Deno tried to learn from the permission-cataclysm

The tools might be there already

Node.js might have not had a choice 10 years ago, but the tools might already be there today. Deno is an experiment in exploring these tools.


So much amazingness!

Build your own toolbelt


This is is from a Node conference.

These are just tools -- use the one that fits the job, and one that you (your team, your company…) is most familiar with.

Bad news: nobody should tell you if you should use a tool. You will have to figure it out for yourself.

You don't have to know everything!

You don't have to know everything!

  • You don't have to know everything
  • Play early & often
  • Don't be afraid to step out of your comfort zone
  • Know yourself -- discover your strengths and interests
  • Build a team of different strengths
  • Identify problems & find the right people & tools to solve them with

But you need to discover new tools to be able to tell if you can use them for something. I'm not saying you should spend your nights & weekends trawling the orange website! Fight for time to discover new tools and regularly embed them in your (and your team's) workflow. R&D time.

Enjoy what you do!


Mozilla Hacks @mozhacks

Flaki @slsoftworks


Reading list: