Damien Maillard dmail

In defense of blocks for local scopes (Part 1)

[EDIT: I've added a part 2 to this blog post, to address some of the feedback that has come up: https://gist.github.com/getify/706e5e10822a298375da40f9cc1fa295]

Recently, this article on "The JavaScript Block Statement" came out, and it received some good discussion in a reddit thread. But the general reaction seems to be against this approach. That saddens me.

Fwiw, the past couple of weeks I've been working on supporting import assertions and CSS/JSON modules in our app at work, I thought it might be worth to share the experience and also prompted by this, maybe its helpful to someone looking into doing the same.

We currently transform our app to Systemjs. My initial thought was to start using es-module-shims, for several reasons:

We use importmaps
It supports CSS/JSON modules
It would save a buildtime transformation to Systemjs

I initially thought that bundling from ESM to ESM would be at least somewhat noticeably faster than bundling from ESM to Systemjs, because of the code transform, but after running some benchmarks in our pipeline, it seemed to not make a significant difference.

Parens And Performance

Years ago, some smart folks that worked on JS engines realized that not all JS that's loaded into a page/app initially is needed right away. They implemented JIT to optimize this situation.

JIT means Just-In-Time, which means essentially that the engine can defer processing (parsing, compiling) certain parts of a JS program until a later time, for example when the function in question is actually needed. This deferral means the engine is freer to spend the important cycles right now on the code that's going to run right now. This is a really good thing for JS performance.

Some time later, some JS engine devs realized that they needed to get some hints from the code as to which functions would run right away, and which ones wouldn't. In technical speak, these hints are called heuristics.

So they realized that one very common pattern for knowing that a function was going to run right away is if the first character before the function keyword was a (, because that usually m

Dynamic module loading done right

Follow-up to Top-level await is a footgun – maybe read that first

Here are some things I believe to be true:

Static module syntax is beneficial in lots of ways – code is easier to write (you get better linting etc) and easier to optimise (tree-shaking and other things that are only really possible with static syntax), and most importantly, faster to load (it's trivial for a module loader to load multiple dependencies concurrently when they're declared with a static syntax – not so with imperative statements like require(...) or await import(...)).
App startup time is perhaps when performance is most critical. (You already know this, I don't need to cite the studies.)
If you're in favour of constructs that jeopardise app startup time, you are anti-user. Top-level await is such a construct.

Edit — February 2019

This gist had a far larger impact than I imagined it would, and apparently people are still finding it, so a quick update:

TC39 is currently moving forward with a slightly different version of TLA, referred to as 'variant B', in which a module with TLA doesn't block sibling execution. This vastly reduces the danger of parallelizable work happening in serial and thereby delaying startup, which was the concern that motivated me to write this gist
In the wild, we're seeing (async main(){...}()) as a substitute for TLA. This completely eliminates the blocking problem (yay!) but it's less powerful, and harder to statically analyse (boo). In other words the lack of TLA is causing real problems
Therefore, a version of TLA that solves the original issue is a valuable addition to the language, and I'm in full support of the current proposal, which you can read here.

I'll leave the rest of this document unedited, for archaeological

Debugging ES6 in VS Code

My current editor of choice for all things related to Javascript and Node is VS Code, which I highly recommend. The other day I needed to hunt down a bug in one of my tests written in ES6, which at time of writing is not fully supported in Node. Shortly after, I found myself down the rabbit hole of debugging in VS Code and realized this isn't as straightforward as I thought initially. This short post summarizes the steps I took to make debugging ES6 in VS Code frictionless.

What doesn't work

My first approach was a launch configuration in launch.json mimicking tape -r babel-register ./path/to/testfile.js with babel configured to create inline sourcemaps in my package.json. The debugging started but breakpoints and stepping through the code in VS Code were a complete mess. Apparently, ad-hoc transpilation via babel-require-hook and inline sourcemaps do not work in VS Code. The same result for attaching (instead of launch) to `babel-node

	// Open a supplied HTML file and record whatever's going on to an MP4.
	//
	// Usage: node recorder.cjs <path_to_html_file>
	// Dependencies: npm install puppeteer fluent-ffmpeg
	// (and yes, you need ffmpeg installed)
	//
	// It expects a <canvas> element to be on the page as it waits for
	// that to load in first, but you can edit the code below if you
	// don't want that.
	//

	// Sometimes you want to run parent effects before those of the children. E.g. when setting
	// something up or binding document event listeners. By passing the effect to the first child it
	// will run before any effects by later children.

	export function Effect({ effect }) {
	useEffect(() => effect?.(), [effect]);
	return null;
	}

	//



	composable("composites.Range", function (require, global) {


	"use strict";


	require("environment_extended_introspective_core");