DEV Community: Pascal Schilp

A cleaner node modules ecosystem

Pascal Schilp — Thu, 25 Jul 2024 22:59:44 +0000

There are many jokes in the software development ecosystem about the size of node_modules and JavaScript dependencies in general, like for example dependencies like is-even, or is-odd, or packages adding a ton of dependencies to support ridiculously low versions of Node.js. Fortunately, there are many individuals who are working on improving this situation, but there are also individuals actively adding more and more unnecessary dependencies to popular projects that get millions of downloads, leading to bloated node_modules folders with tons of dependencies.

A lot of people have spoken up about this recently, and this has caused a great initiative to form in the shape of the e18e community, where a bunch of incredibly talented, like-minded people are actively working on creating a cleaner, healthier, and more performant ecosystem. I should also note that the e18e initiative is not only about countering package bloat, there's a lot of wonderful work going on to improve runtime performance of packages as well, but in this blog I'll be mainly addressing the node_modules situation.

How do we fix this situation the ecosystem is in?

It starts with awareness. I've always been a firm believer of speaking up about things that you disagree with, because it might resonate with others and actually lead to change. (Definitely) not always, but sometimes it does.

Package bloat can be a very tricky thing to keep track of; you install a dependency and never think about it again. But what dependencies does your dependency have? Do you religiously review your package-lock.json on PRs? Do you inspect your JavaScript bundles to see if anything weird got bundled? For a large amount of people the answer is likely "no". A smart guy once pointed out to me, in a discussion about barrel files and the performance implications of using them, that:

"Changes like this cannot really happen in a sustainable fashion unless there's tooling around them."

And I wholeheartedly agree with that. If we're to counter package bloat, we're gonna need tooling; nobody wants to do these things manually, we need automation.

Fortunately, there are many great projects being worked on to achieve this. The list at e18e - resources is a good overview of tools that you can use in your projects, but in this blog I'd like to discuss a couple I've personally been involved with and worked on.

Module Replacements

es-tooling/module-replacements is a project that was started by James Garbutt who started up a lot of great work on the ecosystem cleanup. Module replacements provides several "manifests" that list modules, and leaner, lighter replacements for them; which can either be alternative packages with fewer dependencies, or API's that have now been built-in natively.

What's nice about having these manifests available as machine readable documents, is that we can use them for automation, like for example eslint-plugin-depend. eslint-plugin-depend helps suggest alternatives to various dependencies based on es-tooling/module-replacements, so you can easily discover potentially problematic dependencies in your projects, and find more modern/lightweight solutions for them.

Module Replacements Codemods

If we have these module replacements and alternatives for them available, we can even take things further and automatically replace them via codemods.

For those of you who are unsure what codemods are, codemods are automatic transformations that run on your codebase programmatically. What that means is that you give a codemod some input source code, and it will output changed code, like for example cleanup of dependencies. For example, a codemod for is-even would result in:

Before:

const isEven = require('is-even');

console.log(isEven(0));

After:

console.log((0 % 2 === 0));

To achieve this, we created the repository es-tooling/module-replacements-codemods, which aims to provide automatic codemods for the module listed in es-tooling/module-replacements, so we can automatically replace them. Implementing codemods for all these packages is a herculean effort; there are simply so many of them, which is why I've been spamming Twitter hoping to find more like-minded people and contributors.

Fortunately (and a huge shoutout to codemod.studio here, which is an amazing tool to start building codemods — even if you've never built one before!), the bulk of them were mostly fairly straightforward to implement, and we got many, many great contributions from people to implement codemods. What's nice about this is that for some of those people, it was their first time implementing a codemod! Being able to create codemods is a super valuable skill to have as a developer, so it's been really nice to see people taking on the challenge, learning something new in the process, and contributing to a healthier ecosystem.

I also want to give a special shoutout to Matvey here who implemented a huge amount of codemods single handedly.

We've currently implemented over 90% of all codemods, with the following module replacements left to implement:

If you're interested in helping out, you can find some instructions on how to get started here. If you've never built a codemod before, I challenge you to try it! Take a look at codemod.studio, and I'm sure you'll be up and running in no time. If you're unsure how to get started or get stuck, please feel free to shoot me a DM, and we can take a look together.

So what do we do with these codemods?

For me, the goal of creating these codemods was to simplify the replacement of these packages on a large scale; I want people to be able to run these codemods on their own projects, but also I want everyone to be able to create pull requests to other projects that may be using these dependencies. If people notice any of their dependencies leading to bloated node_modules, I want to enable them to fork and clone that project, run the codemods, and create a PR, hopefully speeding up the ecosystem cleanup by a lot.

In the near future, we'll be looking into implementing a CLI to help with this, so we can easily run these codemods on our projects; I'll create a separate blogpost about that when that happens.

In conclusion, it's been really great to see the amount of awareness that's been created around these issues, and also to see the amount of people it has resonated with and spurred into action. But we're not there yet! There are still, many, many, many projects that cause bloated node_modules folders. I hope this blog finds you, I hope you agree, and I hope you'll do something about it with the tools being created.

A practical guide against barrel files for library authors

Pascal Schilp — Sat, 01 Jun 2024 10:59:45 +0000

Over the past couple of months I've been working on a lot on tooling against barrel files. A barrel file is essentially just a big index.js file that re-exports everything else from the package. Which means that if you import only one thing from that barrel file, you end up loading everything in its module graph. This has lots of downsides, from slowing down runtime performance to slowing down bundler performance. You can find a good introduction on the topic here or a deep dive of the effects of barrel files on a popular real world library here.

In this post, I'll give some practical advice for library authors on how to deal with barrel files in your packages.

Use automated tooling

First of all, automated tooling can help a lot here. For example, if you want to check if your project has been setup in a barrel-file-free way, you can use barrel-begone:

npx barrel-begone

barrel-begone will analyze your packages entrypoints, and analyze your code and warn for various different things:

The total amount of modules loaded by importing the entrypoint
Whether a file is a barrel or not
Whether export * is used, which leads to poor or no treeshaking
Whether import * is used, which leads to poor or no treeshaking
Whether an entrypoint leads to a barrel file somewhere down in your module graph

Lint against barrel files

Additionally, you can use linters against barrel files, like for example eslint-plugin-barrel-files if you're using ESLint. If you're using tools like Oxlint or Biome, these rules are already built-in. This eslint plugin warns you against authoring barrel files, but also warns against importing from other barrel files, and helps you avoid using barrel files all around.

Avoid authoring barrel files

For example, if you author the following file, the eslint plugin will give a warning:

// The eslint rule will detect this file as being a barrel file, and warn against it
// It will also provide additional warnings, for example again using namespace re-exports:
export * from './foo.js'; // Error: Avoid namespace re-exports
export { foo, bar, baz } from './bar.js';
export * from './baz.js'; // Error: Avoid namespace re-exports

Avoid importing from barrel files

It will also warn you if you, as a library author, are importing something from a barrel file. For example, maybe your library makes use of an external library:

import { thing } from 'external-dep-thats-a-barrel-file';

This will give the following warning:

The imported module is a barrel file, which leads to importing a module graph of <number> modules

If you run into this, you can instead try to find a more specific entrypoint to import thing from. If the project has a package exports map, you can consult that to see if there's a more specific import for the thing you're trying to import. Here's an example:

{
  "name": "external-dep-thats-a-barrel-file",
  "exports": {
    ".": "./barrel-file.js", // 🚨
    "./thing.js": "./lib/thing.js" // ✅
  }
}

In this case, we can optimize our module graph size by a lot by just importing form "external-dep-thats-a-barrel-file/thing.js" instead!

If a project does not have a package exports map, that essentially means anything is fair game, and you can try to find the more specific import on the filesystem instead.

Don't expose a barrel file as the entrypoint of your package

Avoid exposing a barrel file as the entrypoint of your package. Imagine we have a project with some utilities, called "my-utils-lib". You might have authored an index.js file that looks like this:

export * from './math.js';
export { debounce, throttle } from './timing.js';
export * from './analytics.js';

Now if I, as a consumer of your package, only import:

import { debounce } from 'my-utils-lib';

I'm still importing everything from the index.js file, and everything that comes with it down the line; maybe analytics.js makes use of a hefty analytics library that itself imports a bunch of modules. And all I wanted to do was use a debounce! Very wasteful.

On treeshaking

"But Pascal, wont everything else just get treeshaken by my bundler??"

First of all, you've incorrectly assumed that everybody uses a bundler for every step of their development or testing workflow. It could also be the case that your consumer if using your library from a CDN, where treeshaking doesn't apply. Additionally, some patterns treeshake poorly, or may not get treeshaken as you might expect them too; because of sideeffects. There may be things in your code that are seen as sideeffectul by bundlers, which will cause things to not get treeshaken. Like for example, did you know that:

Math.random().toString().slice(1);

Is seen as sideeffectful and might mess with your treeshaking?

Create granular entrypoints for your library

Instead, provide granular entrypoints for your library, with a sensible grouping of functionality. Given our "my-utils-lib" library:

export * from './math.js';
export { debounce, throttle } from './timing.js';
export * from './analytics.js';

We can see that there are separate kinds of functionality exposed: some math-related helpers, some timing-related helpers, and analytics. In this case, we might create the following entrypoints:

my-utils-lib/math.js
my-utils-lib/timing.js
my-utils-lib/analytics.js

Now, I, as a consumer of "my-utils-lib", will have to update my import from:

import { debounce } from 'my-utils-lib';

to:

import { debounce } from 'my-utils-lib/timing.js';

Small effort, fully automatable via codemods, and big improvement all around!

How do I add granular entrypoints?

If you're using package exports for your project, and your main entrypoint is a barrel file, it probably looks something like this:

{
  "name": "my-utils-lib",
  "exports": {
    ".": "./index.js" // 🚨
  }
}

Instead, create entrypoints that look like:

{
  "name": "my-utils-lib",
  "exports": {
    "./math.js": "./lib/math.js", // ✅
    "./timing.js": "./lib/timing.js", // ✅
    "./analytics.js": "./lib/analytics.js" // ✅
  }
}

Alternative: Subpath exports

Alternatively, you can add subpath exports for your package, something like:

{
  "name": "my-utils-lib",
  "exports": {
    "./lib/*": "./lib/*"
  }
}

This will make anything under ./lib/* importable for consumers of your package.

A real-life example

Lets again take a look at the msw library as a case study. msw exposes a barrel file as the main entrypoint, and it looks something like this:

Note: I've omitted the type exports for brevity

export { SetupApi } from './SetupApi'

/* Request handlers */
export { RequestHandler } from './handlers/RequestHandler'
export { http } from './http'
export { HttpHandler, HttpMethods } from './handlers/HttpHandler'
export { graphql } from './graphql'
export { GraphQLHandler } from './handlers/GraphQLHandler'

/* Utils */
export { matchRequestUrl } from './utils/matching/matchRequestUrl'
export * from './utils/handleRequest'
export { getResponse } from './getResponse'
export { cleanUrl } from './utils/url/cleanUrl'

export * from './HttpResponse'
export * from './delay'
export { bypass } from './bypass'
export { passthrough } from './passthrough'

If I'm a consumer of msw, I might use msw to mock api calls with the http function, or graphql function, or both. Let's imagine my project doesn't use GraphQL, so I'm only using the http function:

import { http } from 'msw';

Just importing this http function, will import the entire barrel file, including all of the graphql project as well, which adds a hefty 123 modules to our module graph!

Note: msw has since my last blogpost on the case study also added granular entrypoints for msw/core/http and msw/core/graphql, but they still expose a barrel file as main entrypoint, which most of its users actually use.

Instead of shipping this barrel file, we could group certain kinds of functionalities, like for example:

http.js:

export { HttpHandler, http };

graphql.js:

export { GraphQLHandler, graphql };

builtins.js:

export { bypass, passthrough };

utils.js:

export { cleanUrl, getResponse, matchRequestUrl };

That leaves us with a ratatouille of the following exports, that frankly I'm not sure what to name, so I'll just name those todo.js for now (I also think these are actually just types, but they weren't imported via a type import):

export { HttpMethods, RequestHandler, SetupApi };

Our package exports could look something like:

{
  "name": "msw",
  "exports": {
    "./http.js": "./http.js",
    "./graphql.js": "./graphql.js",
    "./builtins.js": "./builtins.js",
    "./utils.js": "./utils.js",
    "./TODO.js": "./TODO.js"
  }
}

Now, I, as a consumer of MSW, only have to update my import from:

import { http } from 'msw';

to:

import { http } from 'msw/http.js';

Very small change, and fully automatable via codemods, but results in a big improvement all around, and no longer imports all of the graphql parser when I'm not even using graphql in my project!

Now, ofcourse it could be that users are not only importing the http function, but also other things from 'msw'. In this case the user may have to add an additional import or two, but that seems hardly a problem. Additionally, the evidence seems to suggest that most people will mainly be importing http or graphql anyway.

Conclusion

Hopefully this blogpost provides some helpful examples and guidelines for avoiding barrel files in your project. Here's a list of some helpful links for you to explore to learn more:

Rustify your JavaScript tooling

Pascal Schilp — Tue, 21 May 2024 14:55:26 +0000

A big part of my work revolves around JavaScript tooling, and as such it's important to keep an eye on the ecosystem and see where things are going. It's no secret that recently lots of projects are native-ying (??) parts of their codebase, or even rewriting them to native languages altogether. Esbuild is one of the first popular and successful examples of this, which was written in Go. Other examples are Rspack and Turbopack, which are both Rust-based alternatives to Webpack, powered by SWC ("Speedy Web Compiler"). There's also Rolldown, a Rust-based alternative to Rollup powered by OXC ("The JavaScript Oxidation Compiler"), but Rollup itself is also native-ying (??) parts of their codebase and recently started using SWC for parts of their codebase. And finally, there are Oxlint (powered by OXC) and Biome as Rust-based alternatives for Eslint and Prettier respectively.

Having said all that, there definitely seems to be a big push to move lots of JavaScript tooling to Rust, and as mentioned above, as someone working on JavaScript tooling it's good to stick with the times a bit, so I've been keeping a close eye on these developments and learning bits of Rust here and there in my spare time. While I've built a couple of hobby projects with Rust, for a long time I haven't really been able to really apply my Rust knowledge at work, or other tooling projects. One of the big reasons for that was that a lot of the necessary building blocks either simply weren't available yet, or not user-friendly (for a mostly mainly JS dev like your boy) enough.

That has changed.

Notably by projects like OXC and Napi-rs, and these projects combined make for an absolute powerhouse for tooling. A lot of the tooling I work on have to do with some kind of analysis, AST parsing, module graph crawling, codemodding, and other dev tooling related stuff; but a lot of very AST-heavy stuff. OXC provides some really great projects to help with this, and I'll namedrop a few of them here.

Lil bit of namedropping

Starting off with oxc_module_lexer. Admittedly not an actual lexer; it actually does do a full parse of the code, but achieves the same result as the popular es-module-lexer, but made very easy to use in Rust. If you're not a dummy like me, you're probably able to get es-module-lexer up and running in Rust. For me, it takes days of fiddling around, not knowing what I'm doing, and getting frustrated. I just want to install a crate that works and be on my way and write some code. There is also a fork of es-module-lexer made by the creator of Parcel, but it's not actually published on crates.io, and so you have to install it via a Github link, which makes me a bit squeemish in terms of versioning/breakage, so just being able to use oxc_module_lexer is really great. Very useful for lots of tooling. Here's a small example:

let allocator = Allocator::default();
let ret = Parser::new(&allocator, &source, SourceType::default()).parse();
let ModuleLexer { exports, imports, .. } = ModuleLexer::new().build(&ret.program);

Next up there's oxc_resolver which implements node module resolution in Rust, super useful to have available in Rust:

let options = ResolveOptions {
  condition_names: vec!["node".into(), "import".into()],
  main_fields: vec!["module".into(), "main".into()],
  ..ResolveOptions::default()
};

let resolver = Resolver::new(options);
let resolved = resolver.resolve(&importer, importee).unwrap();

And finally oxc_parser, which parses JS/TS code and gives you the AST so you can do some AST analysis:

let ret = Parser::new(
  Allocator::default(), 
  &source_code, 
  SourceType::default()
).parse();

let mut variable_declarations = 0;
for declaration in ret.program.body {
  match declaration {
    Statement::VariableDeclaration(variable) => {
      variable_declarations += variable.declarations.len();
    }
    _ => {}
  }
}

With these things combined, you can already build some pretty powerful (and fast) tooling. However, we still need a way to be able to consume this Rust code on the JavaScript side in Node. That's where Napi-rs comes in.

Using your Rust code in Node

"NAPI-RS is a framework for building pre-compiled Node.js addons in Rust."

Or for dummy's: rust code go brrrr

Conveniently, Napi-rs provides a starter project that you can find here, which makes getting setup very easy. I will say however, that the starter project comes with quite a lot of bells and whistles; and the first thing I did was cut a lot of the stuff I didn't absolutely need out. When I'm starting out with a new tool or technology I like to keep things very simple and minimal.

Alright, let's get to some code. Consider the previous example where we used the oxc_parser to count all the top-level variable declarations in a file, our Rust code would look something like this:

use napi::{Env};
use napi_derive::napi;
use oxc_allocator::Allocator;
use oxc_ast::ast::Statement;
use oxc_parser::Parser;
use oxc_span::SourceType;

#[napi]
pub fn count_variables(env: Env, source_code: String) -> Result<i32> {
  let ret = Parser::new(
    Allocator::default(), 
    &source_code, 
    SourceType::default()
  ).parse();

  let mut variable_declarations = 0;
  for declaration in ret.program.body {
    match declaration {
      Statement::VariableDeclaration(variable) => {
        variable_declarations += variable.declarations.len();
      }
      _ => {}
    }
  }
  Ok(variable_declarations)
}

Even if you've never written Rust, you can probably still tell what this code does and if not, that's okay too because I'm still gonna explain it anyway.

In this Rust code we create a function that takes some source_code, which is just some text. We then create a new Parser instance, pass it the source_code, and have it parse it. Then, we loop through the AST nodes in the program, and for every VariableDeclaration, we add the number of declarations (a variable declaration can have multiple declarations, e.g.: let foo, bar;) to variable_declarations, and finally we return an Ok result.

And what's cool about Napi is that you don't have to communicate just via strings only; you can pass many different data types back and forth between Rust and JavaScript, and you can even pass callbacks from JS. Consider the following example:

#[napi]
pub fn foo(env: Env, callback: JsFunction) {
  // We call the callback from JavaScript on the Rust side, and pass it a string
  let result = callback.call1::<JsString, JsUnknown>(
    env.create_string("Hello world".to_str().unwrap())?,
  )?;

  // The result of this callback can either be a string or a boolean
  match &result.get_type()? {
    napi::ValueType::String => {
      let js_string: JsString = result.coerce_to_string()?;
      // do something with the string
    }
    napi::ValueType::Boolean => {
      let js_bool: JsBoolean = result.coerce_to_bool()?;
      // do something with the boolean
    }
    _ => {
      println!("Expected a string or a boolean");
    }
  }
}

Which we can then use on the JavaScript side like this:

import { foo } from './index.js';

foo((greeting) => {
  console.log(greeting); // "Hello world"
  return "Good evening";
});

This is really cool, because it means you'll be able to create plugin systems for your Rust-based programs with the flexibility of JS/callbacks, which previously seemed like a big hurdle for Rust-based tooling.

Alright, back to our count_variables function. Now that we have the Rust code, we'll want to smurf it into something that we can actually consume on the JavaScript side of things. Since I'm using the napi-rs starter project, I can run the npm run build script, and it'll compile the Rust code, and provide me with an index.d.ts file that has the types for my count_variables function, which looks something like this:

/* tslint:disable */
/* eslint-disable */

/* auto-generated by NAPI-RS */

export function countVariables(sourceCode: string): number

As well as a generated index.js file which actually loads the bindings and exposes the function. The file is pretty long, but at the end of it you'll see this:

// ... etc, other code

const { countVariables } = nativeBinding

module.exports.countVariables = countVariables

Next up, you can simply create a run.js file:

import { countVariables } from './index.js';

console.log(countVariables(`let foo, bar;`)); // 2

And it Just Works™️. Super easy to write some rust code, and just consume it in your existing JS projects.

Publishing

Publishing with the Napi-rs starter admittedly wasn't super clear to me, and took some fiddling with to get it working. For starters, you have to use Yarn instead of NPM, otherwise Github Action the starter repo comes with will fail because it's unable to find a yarn.lock file. Im sure it's not rocket science to refactor the Github Action to use NPM instead, but it's a fairly big (~450 loc) .yml file and I just want to ship some code. Additionally, if you want to actually publish the code, the commit message has to conform to: grep "^[0-9]\+\.[0-9]\+\.[0-9]\+". This was a bit frustrating to find out because the CI job took about half an hour (although I suspect something was up at Github Actions today making it slower than it actually should be) to reach the "Publish" stage, only for me to find out it wouldn't actually publish.

In conclusion

I think all of these developments are just really cool, which is why I wanted to do a quick blog on it, but the point I wanted to get across here is; Go try this out, clone the Napi-rs starter template, write some Rust, and see if you can integrate something in your existing Node projects, I think you'd be surprised at how well all this works. If I can do it, so can you. Having said that, there are definitely rough edges, and I think there are definitely some things that can be improved to make getting started with this a bit easier, but I'm sure those will come to pass in time; hopefully this blogpost will help someone figure out how to get up and running and play with this as well.

And finally, a big shoutout to the maintainers of Napi-rs and OXC, they're really cool and friendly people and their projects are super cool.

Self unregistering service workers

Pascal Schilp — Mon, 25 Mar 2024 18:58:05 +0000

The Problem

At work, we use microfrontends for our frontend features. These features get deployed to a CDN, and the url for those features look something like this:

https://cdn.ing.com/ing-web/2.44.0/es-modules/button.js

The way this works is that features have full autonomy of their project and their dependencies when they are deployed. Imports to dependencies in a features source code get rewritten to a versioned URL of the dependency. Consider the following example:

feature-a@1.0.0
├─ ing-web@2.44.0
├─ ing-lib-ow@4.0.0

Feature-a is the feature teams project, and it has two dependencies: ing-web@2.44.0 and ing-lib-ow@4.0.0. At buildtime, the imports for those dependencies will get rewritten so that they'll get loaded from:

https://cdn.ing.com/ing-web/2.44.0/es-modules/index.js
https://cdn.ing.com/ing-lib-ow/4.0.0/es-modules/index.js

This is nice, because feature-a is totally in control of their project and dependencies. However, this leads to a problem when features come together in apps. If we have many different features, feature-a, feature-b, feature-c, and they all depend on a different version of ing-web:

feature-a@1.0.0
├─ ing-web@2.40.0
├─ ing-lib-ow@4.0.0

feature-b@1.0.0
├─ ing-web@2.41.0

feature-c@1.0.0
├─ ing-web@2.41.1

The problem here is that the user visiting the app will download ing-web three times: version 2.40.0, version 2.41.0 and version 2.41.1. You can probably see why this is an issue; This is terrible for performance.

A potential solution

To combat this, I was tinkering with a service worker that simply rewrites the URL whenever a request is done to the CDN. Given the following request:

https://cdn.ing.com/ing-web/2.41.0/es-modules/button.js

It will get rewritten to:

https://cdn.ing.com/ing-web/2.44.0/es-modules/button.js

Given that we use semver, we can expect there not to be breaking changes in the entrypoints of those projects. This does however mean that teams lose a bit of autonomy, as common, shared dependencies (like the design system) will now get deduped on the application level, and the application dictates which version of the design system is supported. I think this is a fair trade-off to make, given the performance implications.

The service worker I implemented only does one thing;

If a CDN request comes in
- If that request is for one of the packages we want to dedupe
- Rewrite the request url to the version dictated by the app

Pretty straightforward. Here's some code:

const packages = {
  'ing-web': {
    '2': '2.44.0',
  },
};

self.addEventListener('fetch', event => {
  const url = new URL(event.request.url);

  if (url.host.includes('cdn.ing.com')) {
    const [pkg, requestedVersion, _, file] = url.pathname.split('/').filter(Boolean);
    const [requestedMajor] = requestedVersion.split('.');

    for (const [packageName, versions] of Object.entries(packages)) {
      if (packageName === pkg) {
        for (const [major, rewriteTo] of Object.entries(versions)) {
          if (major === requestedMajor && requestedVersion !== rewriteTo) {
            url.pathname = url.pathname.replace(requestedVersion, rewriteTo);
            return event.respondWith(fetch(url));
          }
        }
      }
    }
  }
});

self.addEventListener('install', () => {
  self.skipWaiting();
});

self.addEventListener('activate', event => {
  event.waitUntil(clients.claim());
});

And in the index.html of our app, we register the service worker:

<script>
  navigator.serviceWorker.register('./sw.js');
</script>

So what are you getting at?

So far so good. So what's actually the problem here? Well, my colleague Kristjan Oddsson mentioned this thing to me once:

It's always good to have an exit strategy for any code or library that you add

And so I was considering the impact of the service worker. I've used service workers quite a bit and I'd say I'm fairly well-versed with them, but in a large production application it can be a bit scary. What if something goes wrong? What if the service worker is buggy? If we ever want to get rid of the service worker, what is our exit strategy?

Doing some homework (googling and asking chatgpt), quickly leads to people recommending to just deploy a noop service worker, something like:

self.addEventListener('install', () => {
  self.skipWaiting();
});

self.addEventListener('activate', () => {
  self.clients.matchAll({
    type: 'window'
  }).then(windowClients => {
    windowClients.forEach((windowClient) => {
      windowClient.navigate(windowClient.url);
    });
  });
});

Another way of doing this, is just by calling the unregister method:

<script>
  navigator.serviceWorker.unregister();
</script>

These options work well for the following scenario:

However, consider the following scenario:

So the question here is: when can you ever get rid of that code? When can you ever be sure that all your users have the noop service worker installed? And... then what happens to the noop service worker? Do they just have that installed forever? One way to achieve this is by basing it on analytics, but I wondered if there wasn't a different way of achieving this. For example, what if the service worker itself would have some kind of keepalive check built-in?

Here's the gist of it:

On every fetch request, the service worker sends a debounced message to the index.html; a keepalive check
- If the index.html responds to that message, the service worker will stay alive
- If the index.html does not respond to that message, the service worker will unregister itself

Here's an example:

<script>
  navigator.serviceWorker?.register("./sw.js").catch(console.error);
  navigator.serviceWorker?.addEventListener("message", (event) => {
    console.log("[Client]: Pong sent.");
    event.ports[0].postMessage('pong');
  });
</script>

function checkPong(pong, interval = 500, maxInterval = 4000) {
  setTimeout(() => {
    if (!pong()) {
      if (interval < maxInterval) {
        console.log('[Deduping SW]: Pong not received. Checking again in', interval * 2, 'ms.');
        checkPong(pong, interval * 2);
      } else {
        console.log('[Deduping SW]: Unregistering.');
        self.registration.unregister();
      }
    } else {
      console.log('[Deduping SW]: Pong received.');
    }
  }, interval);
}

async function _keepaliveCheck(clientId) {
  const channel = new MessageChannel();
  let pong = false;

  channel.port1.onmessage = event => {
    if (event.data === 'pong') {
      pong = true;
    }
  };

  const client = await clients.get(clientId);
  if (client) {
    client.postMessage('ping', [channel.port2]);
    console.log('[Deduping SW]: Ping.');

    checkPong(() => pong);
  }
}

const keepaliveCheck = debounce(_keepaliveCheck, 2000);

self.addEventListener('fetch', event => {
  keepaliveCheck(event.clientId);
  // other SW-ey code
});

This way, if we ever want to get rid of the service worker, we can just remove the following code from our index.html:

<script>
  navigator.serviceWorker?.register("./sw.js").catch(console.error);
  navigator.serviceWorker?.addEventListener("message", (event) => {
    console.log("[Client]: Pong sent.");
    event.ports[0].postMessage('pong');
  });
</script>

Then, on the next keepalive check from the service worker, it will no longer get an answer from the index.html, and unregister itself; effectively ensuring that eventually every service worker will get unregistered, and we don't have any lingering code in our codebase because someone might still have a service worker installed.

Is this crazy? Maybe! Let me know on twitter or mastodon, because I'd love to hear some other thoughts about this!

Barrel files: A case study

Pascal Schilp — Thu, 01 Feb 2024 09:17:31 +0000

Let me preface this blogpost with 2 things:

1: This blogs intention is not to shame MSW, I'm a maintainer of MSW myself and it's a great project that has to consider lots of different usecases and environments, which is not always easy to do. The reason I'm highlighting MSW in this blog is because I encountered all this while working on it, and so it makes for a good illustrative case study of sorts.

2: This is also not an "all barrel files are evil" kind of blog; consider your project, how people may consume it, and apply some critical thinking. Although I will say that I personally find, more often than not, barrel files (and most notably some barrel-file related practices) to be a code smell. This blog is also not a criticism against anyone, it's just me going down a rabbit hole and taking you along for the ride

A couple of weeks ago I was working on one of our features, and I noticed that an enormous amount of JavaScript files were getting loaded in the browser during local development.

I set out to investigate, and noticed that out of 184 requests on the page, 179 were caused by MSW. For our local development environment, and also for running our unit tests, we don't bundle; we use buildless development, and we get a lot of benefits from this approach.

Originally posted on my personal blog site

Now, it may be easy to jump to: "Just use a bundler", but there are many usecases and environments where its not common to use a bundler, like for example:

When loading the library from a CDN
During local development
Test runners
- in the browser
- in node processes
In JavaScript server-side runtime environments

These are all scenarios and examples of cases where we typically don't (or can't) bundle code, and we don't benefit from treeshaking. Additionally, MSW is a (mostly? only?) dev-time library, that we import and consume in our unit test code, not our source code directly; we also don't typically bundle our unit test code before running our unit tests.

Additionally, barrel files also cause bundlers to slow down, and barrel files also often contain code like export * from or import * as foo, which bundlers often can't treeshake correctly.

Untangling MSW's module graph

Knowing a little bit about MSW's internals, and what it does, it felt like 179 modules being loaded was way too much for what it does, so I started looking at what kind of modules are actually being loaded. I noticed pretty quickly that GraphQL is a large source of the requests being made, which struck me as curious, because while MSW does support mocking GraphQL requests, my project doesn't. So why am I still loading all this GraphQL related code that's going unused, and slows my development down?

Thankfully, the browser's network tab has a nifty initiator tab that shows you the import chain for a given import:

Starting at the root of the import chain, I pretty quickly discovered the culprit:

MSW ships as a barrel file. A barrel file is essentially just an index file that re-exports everything else from the package. Which means that if you import only one thing from that barrel file, you end up loaded everything in its module graph.

So even though in my code I'm only importing:



import { http } from 'msw';
import { setupWorker } from 'msw/browser';

I still end up loading all the other modules, and the entire module graph, which itself may also contain other barrel files, like for example GraphQL:

Automating it

I brought this up in MSW's maintainer channel on their Discord, and had a good discussion about it, and opened an issue on the MSW github repository. The creator of MSW and I also had a private chat on Discord and discussed how it would be nice to have some tooling around this, to make it easier for package authors and create more awareness around what their module graph may look like, and highlight some potential issues.

So I set out to coding, and created barrel-begone and eslint-plugin-barrel-files which is a little eslint plugin that helps detect some barrel file-related issues during development.

The barrel-begone package does a couple things:

It scans your packages entrypoints, either via the "module", "main" or "exports" field in your package.json, and then it analyzes your module graph to detect the amount of modules that will be loaded in total by importing this entrypoint, and it also does some analysis on the modules that will be imported by this entrypoint, for example:

Detecting barrel files
Detecting import * style imports
Detecting export * style exports

And pointing them out. Here's what that looks like on the MSW project:

From this information, we see that importing from module specifier 'msw' causes a total of 179 modules to be loaded, which is pretty much in line with what I noticed earlier on. We also see some other information like:

The entrypoint itself is a barrel file
The entrypoint uses some export * style exports
The entrypoint leads to other modules that import from a barrel file

There's a lot to unpack, but since GraphQL makes up such a significant portion of all modules loaded, I figured I'd hunt that one down first. I found that there's actually only one import for 'graphql', so I changed that import from:



import { parse } from 'graphql';

To:



import { parse } from 'graphql/language/parser.mjs';

And ran npx barrel-begone again:

We're down from 179 modules to 74 modules. That seems like a pretty significant change already!

I didn't think I'd have to spell this out, but Twitter proved otherwise; loading less modules in the browser is better and more performant, and speeds up local development. The less you load, the less the browser has to do.

However, we're still importing GraphQL's parser while we don't even use it. So lets take another step, and create some separate entrypoints. Looking at the 'msw' barrel file, there's a lot of stuff in there, but it seems reasonable to have separate entrypoints for (likely) the two most commonly imported things: the http and graphql handlers, so we'll be able to import them like:



import { http } from 'msw/http';

Splitting up the entrypoints like this reduces the amount of modules loaded by a lot, because we're no longer importing anything from GraphQL which goes unused; the msw/http entrypoint leads to a module graph of 32 modules. However, we're also importing the msw/browser entrypoint (because you can't use the one without the other), which itself leads to a module graph of 21 modules, so in total, we're down from 179 modules to 53 modules.

Next up, barrel-begone told me there were a couple of other imports to another barrel file, namely in @mswjs/interceptors, lets see what that looks like:

Yep, looks like another barrel file, with only one locally declared function. And it turns out that that in the msw/http entrypoint, that one function is the only thing that we need from the @mswjs/interceptors package. If we were to remove that from the barrel file as well, that brings us down from 32 modules to 24 modules, in total:

Down from 179 modules to 45 modules. That's a pretty significant difference! I didn't run any objective benchmarks, but on my personal macbook this improved the performance of the page load by 67%. If you're interested in more numbers, I encourage you to take a look at some of your own projects and setups, finding the barrel files in your projects and/or libraries that you use with barrel-begone (or other tools), and see how much benefit you get from removing them.

Conclusion

The github discussion on barrel files is still on-going, and there are some pull requests, but not everything in this blogpost has been implemented yet; all of this was done locally. Some things, like changing the GraphQL import may be tricky to do, because MSW uses a dual CJS/ESM setup. Hopefully, we can still make a lot of the changes highlighted in this blogpost in the near future though.

Despite that, I really wanted to make this blogpost to highlight a couple of things. Firstly, when authoring a package it's importing to consider how people consume your package. As mentioned before, this is not always easy (like in the case of MSW's dual CJS/ESM setup), but as a package author you should be conscious of this. Where does your package get used? Does it make sense to ship only a barrel file? Or should you create some more granular, grouped entrypoints?

Secondly, a lot of the changes highlighted in this blogpost are not rocket science. Many of them were changing one import to another, or simply creating an additional entrypoint. Hopefully the barrel-begone tool will prove useful for other people as well to take a look at their entrypoints and give insight in what they are actually shipping to their users.

And finally, I think this is important because not doing this means death by a thousand cuts. In this case study, I've looked exclusively at MSW, and I've done all this testing with just an empty index.html that imports MSW, but in an actual project you might be loading additional libraries, like testing utilities/helpers and other things as well, do they also have barrel files? All of these things combined add up.

Service Worker Templating Language (SWTL)

Pascal Schilp — Sat, 19 Aug 2023 08:27:56 +0000

Check out the starter project here.

I've previously written about Service Worker Side Rendering (SWSR) in this blog, when I was exploring running Astro in a Service Worker.

I recently had a usecase for a small app at work and I just kind of defaulted to a SPA. At some point I realized I needed a Service Worker for my app, and I figured, why not have the entire app rendered by the Service Worker? All I need to do was fetch some data, some light interactivity that I don't need a library or framework for, and stitch some html partials together based on that data. If I did that in a Service Worker, I could stream in the html as well.

While I was able to achieve this fairly easily, the developer experience of manually stitching strings together wasnt great. Being myself a fan of buildless libraries, such as htm and lit-html, I figured I'd try to take a stab at implementing a DSL for component-like templating in Service Workers myself, called Service Worker Templating Language (SWTL), here's what it looks like:

import { html, Router } from 'swtl';
import { BreadCrumbs } from './BreadCrumbs.js'

function HtmlPage({children, title}) {
  return html`<html><head><title>${title}</title></head><body>${children}</body></html>`;
}

function Footer() {
  return html`<footer>Copyright</footer>`;
}

const router = new Router({
  routes: [
    {
      path: '/',
      render: ({params, query, request}) => html`
        <${HtmlPage} title="Home">
          <h1>Home</h1>
          <nav>
            <${BreadCrumbs} path=${request.url.pathname}/>
          </nav>
          ${fetch('./some-partial.html')}
          ${caches.match('./another-partial.html')}
          <ul>
            ${['foo', 'bar', 'baz'].map(i => html`<li>${i}</li>`)}
          </ul>
          <${Footer}/>
        <//>
      `
    },
  ]
});

self.addEventListener('fetch', (event) => {
  if (event.request.mode === 'navigate') {
    event.respondWith(router.handleRequest(event.request));
  }
});

`html`

To create this DSL, I'm using Tagged Template Literals. For those of you who are not familiar with them, here's what they look like:

function html(statics, ...dynamics) {
  console.log(statics);
  console.log(dynamics);
}

html`hello ${1} world`;

// ["hello ", " world"];
// [1]

A Tagged Template Literal gets passed an array of static values (string), and an array of dynamic values (expressions). Based on those strings and expressions, I can parse the result and add support for reusable components.

I figured that since I'm doing this in a Service Worker, I'm only creating html responses and not doing any kind of diffing, I should be able to just return a stitched-together array of values, and components. Based on preact/htm's component syntax, I built something like this:

function Foo() {
  return html`<h2>foo</h2>`;
}

const world = 'world';

const template = html`<h1>Hello ${world}</h1><${Foo}/>`;

// ['<h1>Hello ', 'world', '</h1>', { fn: Foo, children: [], properties: []}]

I can then create a render function to serialize the results and stream the html to the browser:

/**
 * `render` is also a generator function that takes care of stringifying values
 * and actually calling the component functions so their html gets rendered too
 */
const iterator = render(html`hello ${1} world`);
const encoder = new TextEncoder();

const stream = new ReadableStream({
  async pull(controller) {
    const { value, done } = await iterator.next();
    if (done) {
      controller.close();
    } else {
      controller.enqueue(encoder.encode(value));
    }
  }
});

/**
 * Will stream the response to the browser as results are coming
 * in from our iterable
 */
new Response(stream);

However, I then realized that since I'm streaming the html anyways, instead of waiting for a template to be parsed entirely and return an array, why not stream the templates as they are being parsed? Consider the following example:

function* html(statics, ...dynamics) {
  for(let i = 0; i < statics.length; i++) {
    yield statics[i];
    if (dynamics[i]) {
      yield dynamics[i];
    }
  }
}

Using a generator function, we can yield results as we encounter them, and stream those results to the browser immediately. We can then iterate over the template results:

const template = html`hello ${1} world`;

for (const chunk of template) {
  console.log(chunk);
}

// "hello "
// 1
// " world"

What makes this even cooler is that we can provide first class support for other streamable things, like iterables:

function* generator() {
  yield* html`<li>1</li>`;
  yield* html`<li>2</li>`;
}

html`<ul>${generator()}</ul>`;

Or other streams, or Responses:

html`
  ${fetch('./some-html.html')}
  ${caches.match('./some-html.html')}
`;

Why not do this at build time?

The following template:

const template = html`<h1>hi</h1><${Foo} prop=${1}>bar<//>`

Would compile to something like:

const template = ['<h1>hi</h1>', {fn: Foo, properties: [{name: 'prop', value: 1}], children: ['bar']}];

While admittedly that would save a little runtime overhead, it would increase the bundlesize of the service worker itself. Considering the fact that templates are streamed while they are being parsed, I'm not convinced pre-compiling templates would actually result in a noticeable difference.

Also I'm a big fan of buildless development, and libraries like lit-html and preact/htm, and the bundlesize for the html function itself is small enough:

Isomorphic rendering

While I'm using this library in a Service Worker only, similar to a SPA approach, you can also use this library for isomorphic rendering in worker-like environments, or even just on any node-like JS runtime, and the browser! The following code will work in any kind of environment:

function Foo() {
  return html`<h1>hi</h1>`;
}

const template = html`<main><${Foo}/></main>`;

const result = await renderToString(template);
// <main><h1>hi</h1></main>

Hurray for agnostic libraries!

Router

I also implemented a simple router based on URLPattern so you can easily configure your apps routes:

import { Router, html } from 'swtl';

const router = new Router({
  routes: [
    {
      path: '/',
      render: () => html`<${HtmlPage}><h1>Home</h1><//>`
    },
    {
      path: '/users/:id',
      render: ({params}) => html`<${HtmlPage}><h1>User: ${params.id}</h1><//>`
    },
    {
      path: '/foo',
      render: ({params, query, request}) => html`<${HtmlPage}><h1>${request.url.pathname}</h1><//>`
    },
  ]
});

self.addEventListener('fetch', (event) => {
  if (event.request.mode === 'navigate') {
    event.respondWith(router.handleRequest(event.request));
  }
});

Out of order streaming

I also wanted to try and take a stab at out of order streaming, for cases where you may need to fetch some data. While you could do something like this:

async function SomeComponent() {
  try {
    const data = await fetch('/api/foo').then(r => r.json());
    return html`
      <ul>
        ${data.map(user => html`
          <li>${user.name}</li>
        `)}
      </ul>
    `;
  } catch {
    return html`Failed to fetch data.`;
  }
}

This would make the api call blocking and stop streaming html until the api call resolves, and we can't really show a loading state. Instead, we ship a special <${Await}/> component that takes an asynchronous promise function to enable out of order streaming.

import { Await, when, html } from 'swtl';

html`
  <${Await} promise=${() => fetch('/api/foo').then(r => r.json())}>
    ${({pending, error, success}, data, error) => html`
      <h2>Fetching data</h2>
      ${when(pending, () => html`<${Spinner}/>`)}
      ${when(error, () => html`Failed to fetch data.`)}
      ${when(success, () => html`
        <ul>
          ${data.map(user => html`
            <li>${user.name}</li>
          `)}
        </ul>
      `)}
    `}
  <//>
`;

When an Await component is encountered, it kicks off the promise that is provided to it, and immediately stream/render the pending state, and continues streaming the rest of the document. When the rest of the document is has finished streaming to the browser, we await all the promises in order of resolution (the promise that resolves first gets handled first), and replace the pending result with either the error or success template, based on the result of the promise.

So considering the following code:

html`
  <${HtmlPage}>
    <h1>home</h1>
    <ul>
      <li>
        <${Await} promise=${() => new Promise(r => setTimeout(() => r({foo:'foo'}), 3000))}>
          ${({pending, error, success}, data) => html`
            ${when(pending, () => html`[PENDING] slow`)}
            ${when(error, () => html`[ERROR] slow`)}
            ${when(success, () => html`[RESOLVED] slow`)}
          `}
        <//>
      </li>
      <li>
        <${Await} promise=${() => new Promise(r => setTimeout(() => r({bar:'bar'}), 1500))}>
          ${({pending, error, success}, data) => html`
            ${when(pending, () => html`[PENDING] fast`)}
            ${when(error, () => html`[ERROR] fast`)}
            ${when(success, () => html`[RESOLVED] fast`)}
          `}
        <//>
      </li>
    </ul>
    <h2>footer</h2>
  <//>
`;

This is the result:

We can see that the entire document is streamed, initially displaying loading states. Then, once the promises resolve, the content is updated in-place to display the success state.

Wrapping up

I've created an initial version of swtl to NPM, and so far it seems to hold up pretty well for my app, but please let me know if you run into any bugs or issues! Lets make it better together 🙂

You can also check out the starter project here.

Acknowledgements

lit-html
preact/htm
Astro and Matthew Philips - For doing the hard work of implementing the rendering logic back when I requested this in astro
Artem Zakharchenko - For helping with the handling of first-resolve-first-serve promises
Alvar Lagerlöf - For a cool demo of out of order streaming which largely influenced my implementation

And it's also good to mention that, while working/tweeting about some of the work in progress updates of this project, it seems like many other people had similar ideas and even similar implementations as well! It's always cool to see different people converging on the same idea 🙂

Events are the shit

Pascal Schilp — Wed, 26 Jul 2023 07:27:17 +0000

Pardon my profanity, there's just no better way to say it. Events are just great. In this blog I'll showcase some cool things that you can achieve with just plain old events. You might not need an expensive or heavy library! Try an event.

Use `EventTarget`

Did you know you can instantiate EventTargets?

const target = new EventTarget();

target.dispatchEvent(new Event('foo'));
target.addEventListener('foo', (event) => {});

Extend `Event`!

Did you know you can extend Event?

Instead of creating CustomEvents, you can just extend the Event class, and assign data to it, or even implement other methods on it:

// Create the event:
class MyEvent extends Event {
  constructor(data) {
    super('my-event', { bubbles: true, composed: true });
    this.data = data;
  }
}

const target = new EventTarget();

// Fire the event:
target.dispatchEvent(new MyEvent({foo: 'bar'}));

// Catch the event:
target.addEventListener('my-event', ({data}) => {
  console.log(data); // { foo: 'bar' }
});

Extend `EventTarget`!

Did you know you can also extend EventTarget?

Here's how you can create a super minimal state manager using events:

class StateEvent extends Event {
  constructor(state = {}) {
    super('state-changed');
    this.state = state;
  }
}

export class State extends EventTarget {
  #state;

  constructor(initialState) {
    super();
    this.#state = initialState;
  }

  setState(state) {
    this.#state = typeof state === 'function' ? state(this.#state) : structuredClone(state);
    this.dispatchEvent(new StateEvent(this.#state));
  }

  getState() {
    return this.#state;
  }
}

export const state = new State({});

And then you can use it like:

state.setState({foo: 'bar'}); // #state === {foo: 'bar'}
state.setState((old) => ({...old, bar: 'baz'})); // #state === {foo: 'bar', bar: 'baz'}

state.addEventListener('state-changed', ({state}) => {
  // Assign state, trigger a render, whatever
});

state.getState(); // {foo: 'bar', bar: 'baz'};

I use this in my @thepassle/app-tools library, and it's often all the state management I need. Super tiny, but powerful state manager.

Events are sync

Did you know events execute synchronously?

const target = new EventTarget();

console.log('first');

target.addEventListener('foo', ({data}) => {
  console.log('second');
});

target.dispatchEvent(new Event('foo'));

console.log('third');

Outputs:

// first
// second
// third

Context-like patterns

It's a common scenario to pass down properties to child components. However, sometimes you end up in a situation known as "prop drilling", where you need to get some property down to a deeply nested child component, and along the way you're passing the property through components that really don't need to know about the property in the first place. In this case, it can sometimes be easier for the child component to request the property from a parent higher up the tree. This is also known as the context pattern. Since events execute synchronously, we can just use the following pattern:

class MyParent extends HTMLElement {
  theme = 'dark';

  constructor() {
    super();
    /**
     * The provider: 
     */
    this.addEventListener('theme-context', (event) => {
      event.theme = this.theme;
    });
  }
}

export class MyChild extends HTMLElement {
  connectedCallback() {
    const event = new Event('theme-context', {
      bubbles: true, 
      composed: true, 
    });
    this.dispatchEvent(event);

    /**
     * Because events execute synchronously, the callback for `'theme-context'`
     * event executes first, and assigns the `theme` to the `event`, which we
     * can then access in the child component
     */
    console.log(event.theme); // 'dark';
  } 
}

Promise-carrying events

Did you know events can also carry promises? A great showcase of this pattern is the Pending Task Protocol by the Web Components Community Group. Now, "Pending Task Protocol" sounds very fancy, but really, it's just an event that carries a promise.

Consider the following example, we create a new PendingTaskEvent class:

class PendingTaskEvent extends Event {
  constructor(complete) {
    super('pending-task', {bubbles: true, composed: true});
    this.complete = complete;
  }
}

And then in a child component, whenever we do some asynchronous work, we can send a new PendingTaskEvent to signal to any parents that a task is pending:

class ChildElement extends HTMLElement {
  async doWork() { /* ... */ }

  startWork() {
    const workComplete = this.doWork();
    this.dispatchEvent(new PendingTaskEvent(workComplete));
  }
}

In our parent component we can then catch the event, and show/hide a loading state:

class ParentElement extends HTMLElement {
  #pendingTaskCount = 0;

  constructor() {
    super();
    this.addEventListener('pending-task', async (e) => {
      e.stopPropagation();
      if (++this.#pendingTaskCount === 1) {
        this.showSpinner();
      }
      await e.complete;
      if (--this.#pendingTaskCount === 0) {
        this.hideSpinner();
      }
    });
  }
}

The Cost of Convenience

Pascal Schilp — Thu, 04 May 2023 05:38:13 +0000

Something I see happen time and time again in frontend development is developers reaching for conveniences. It may be the hot new tool in town, it may be existing tooling, but developers just love to take shortcuts. And this is fine! We all love to spend our time being productive, right? We'll just add this one little convenience that will surely make our lives better, never think about it again and move on.

The conveniences

When we talk about conveniences, we generally talk about non-standardisms or any kind of magical behavior. A useful rule of thumb is to ask: "Does it run natively in a browser?". A good example of this are imports, which often get subjected to magical behavior and transformed into non-standardisms, like the following examples:

import icon from './icon.svg';
import data from './data.json';
import styles from './styles.css';
import whatever from '~/whatever.js';
import transformed from 'transform:whatever.js';

None of these examples will actually work in a browser, because they are non-standard. Some of you might have correctly spotted that a browser standard exists for two of the imports pointed out in the example, namely the Import Attributes proposal (previously known as Import Assertions), but these imports in their current shape will not work natively in a browser. Many of these non-standard imports exist for good reason; they are very convenient.

Other conveniences may include any kind of build-time transformations; like for example JSX. Nobody wants to write createElement calls by hand, but JSX will not run in a browser as is. The same goes for TypeScript. Developers evidently are very happy writing types in their source code (and will get very upset when you tell them you can use TypeScript without compiling your code), but alas, TypeScript source code does not run natively in the browser. Not until the Type Annotations proposal lands anyway, which is only stage 1 at the time of writing.

Using Node.js globals like process.env to enable special development-time logging is another convenience often added by libraries, but will also cause runtime errors in the browser when not specifically handled by adding additional tooling.

It is important to note that this is not to say that anything that doesn't run natively in the browser is wrong or bad. Exactly the opposite is true; It is convenient. Keep reading. It's also important to note that these are only some examples of conveniences.

The cost

The problem with conveniences is that they come at a cost. How easy is it to add this one little convenience that will surely make our lives better, never think about it again and move on.

It should come as no surprise to anybody that the frontend tooling ecosystem is complex, and in large part stems from the conveniences developers insist upon. When we apply a convenience to one tool, we have to now also make sure all of our other tooling plays nice with it, and enforce everything to also support anything. Whenever new tooling comes about, it is then also pressured into supporting these conveniences for it to ever be able to catch on, and to ease migrations to it.

But more concerningly, we become so accustomed to our toolchains and conveniences, that it often leads to assumptions of other people using the same toolchain as you do. Which then leads to packages containing conveniences to be published to the NPM registry. This, as you might have guessed, forces other projects to also adopt additional tooling to be able to support these packages that they want to use, and cause a never-ending spiral of imposed conveniences.

It is disappointing to see that we have still not learned from the mistakes made by the recently sunsetted starter kit of one of the most popular JavaScript frameworks over the past decade, when contemporary popular development tools are making the exact same mistakes as the one before it by enabling conveniences out of the box.

Where you apply conveniences, you apply lock in. What happens when the next, faster tool comes out? Will it support all of your conveniences?

The conclusion

Is this all to say that conveniences are bad? Are they not helpful, and not valuable? Should our tooling not be allowed to support conveniences? Should they be shunned, or should tooling not support them? Are they simply wrong? The answer is no. Conveniences have their merits and are undeniably valuable. But they come at a cost, and tools should absolutely not enable them by default.

Additionally, when you build for the lowest common denominator and don't rely on conveniences, your code will work anywhere. It ensures compatibility with new tools and web standards, eliminating conflicts. This practice is sometimes referred to as buildless development. While it may seem unnecessary to prioritize portability, the importance of this approach becomes evident when circumstances change; you might be right, until you're not.

And finally, you might actually find it refreshing to try frontend development without all the bells and whistles. Maybe you'll find that buildless development can get you pretty far, you'll often really only need a dev server with node resolution to resolve bare module specifiers, if at all. Maybe try it out some time.

Using Typescript without compilation

Pascal Schilp — Sun, 26 Mar 2023 10:41:28 +0000

Over the past couple of days, an article about the next major version of Svelte blew up on twitter, and caused lots of discussion. The article states:

The team is switching the underlying code from TypeScript to JavaScript.

Which, to be fair, is a bit misleading. Technically, the article is not wrong, the team is switching the underlying code from TypeScript to JavaScript. However, they're not dropping typechecking from their code. They're just moving from writing TypeScript source code directly, to writing JavaScript source code using JSDoc in combination with .d.ts files. This allows them to:

Write typesafe code, with TypeScript doing the typechecking
Write and ship plain JavaScript
Skip TypeScript's compilation step
Still provide types for their end users

What's interesting about this discussion is that a lot of people found this to be very upsetting, and twitter blew up with discussion about typechecking. We saw the exact same thing happen when the ESLint team announced they were not interested in using TypeScript for their rewrite of ESLint, but instead were choosing the same approach the Svelte team is going for; plain JavaScript with JSDoc for typechecking. In these twitter discussions it has become very clear that lots of people, even some of those who call themselves "educators", don't understand how capable JSDoc actually is and will unfortunately just spread blatant untruths about this way of working.

It should be noted here that neither of those teams are disregarding typesafety. They just chose a different way of utilizing typesafety, without having to use a compile step to achieve this. This is a preference. There is no right or wrong answer; you get typesafety by using TypeScript in either approach. This discussion and these decisions are not about not using TypeScript. And unless you're directly working on, or contributing to, either of those projects, these decisions do not involve you. It is, frankly stated, none of your business. If you want to use TypeScript with a compilation step; go for it! There's no need for animosity. These projects still utilize TypeScript to ensure typesafety in their code, and can still ship types to their end users. In this blog we'll take a look at the benefits of skipping TypeScripts compilation step, clarify some of the myths I've seen spread around, and emphasize the importance of understanding and being respectful of different preferences and methodologies.

In this blog, I won't go into detail on how to setup your project to enable typechecking with JSDoc, there are many great resources on that like this one here

Before we dive in, I'd like to reiterate one more time that using types via JSDoc allows people to still write typesafe JavaScript, by using TypeScript's typechecker. It just skips the compilation step. You'll also be able to still use .d.ts files when necessary (but you don't have to!), and provide types for your users. And yes, this approach is still using TypeScript.

Benefits of skipping a compilation step

Compilation or transpilation steps in the JavaScript tooling ecosystem are often a bit of a necessary evil, like for example transpiling JSX, or in this case TypeScript code. They're often not as fast as we'd like them to be, and often take a bit of fiddling with configuration (although it should be noted that lots of tooling has improved in recent years) to get your setup working just fine. Not only for building your projects for production, but also having everything setup correctly for your local development environment, as well as your test runner. While compilation or transpilation offers conveniences (writing JSX source code, instead of React.createElement calls manually, or writing types in your source code directly), some people find these compilation steps to be undesirable, and prefer to skip them where possible.

Skipping a compilation step, in the context of TypeScript usage, has several benefits. It makes your code runtime agnostic; your code will run in Node, Deno, the browser, Worker-like environments, etc. Some of these environments, like Deno, support running TypeScript natively (which has a whole other set of worrisome implications*). Some of those environments, like the browser, don't (not until the types as comments proposal lands anyway). This may or may not be an issue for you depending on what you are building, but again, some people find this to be preferable.

It has been pointed out to me that Deno will now run with --no-check by default, which mitigates some of it's issue. However, the issue still exists when using --check.

If your code is runtime agnostic, it also allows you to easily copy and paste snippets of code into REPLs. Shipping native JavaScript also simplifies debugging, consider the following example: You've shipped your package as native JavaScript. Somebody installs your package and discovers a bug. They can just go into their node_modules and easily tweak some code to try to fix the bug, without having to deal with transpiled code, source maps, etc.

An added benefit of using JSDoc that I've personally found (this is a personal preference), is that the barrier to documenting my code is much lower as opposed to TypeScript. Consider the following example:

Admittedly, a function named add probably doesn't require a whole lot of documentation, but for illustration purposes.

When I type /**<ENTER> on my keyboard, my editor will already scaffold the JSDoc comment for me, I just have to write my types. Note that the return type can be omitted, because TypeScript will still correctly infer the return type from the code. While I already have the JSDoc comment here anyway, I might as well add some documentation for it! Easypeasy.

Myths

Using JSDoc is unmaintainable

Some people on twitter have expressed concerns about the maintainability of using JSDoc for types, and claim that using JSDoc is only viable for small projects. As someone who maintains many projects at work (some of which are large) that utilize types via JSDoc, I can tell you this is simply not true. It can be true that if you're only using JSDoc to declare and consume your types, this can sometimes become a bit unwieldy. However, to avoid this, you can combine JSDoc with .d.ts files. Declare your types in a .d.ts file:

./types.d.ts:



export interface User {
  username: string,
  age: number
}

And import it in your source code:
./my-function.js:



/**
 * @typedef {import('./types').User} User
 */

/**
 * @param {User}
 */
function foo(user) {}

No type inference or intellisense

Some people seem to think that using JSDoc somehow will cause you to lose type inference. As already demonstrated earlier above, this is also not true. Consider the following example:

The reason for this claim seems to be that people don't understand that when you're using JSDoc for types, you're still using typescript. TypeScript is still doing the typechecking.

Manually writing types is bothersome

Some people claimed that writing types manually is bothersome. I can only assume that this is a case of preference, or perhaps its not clear to those people that you can still .d.ts files. Some people will prefer example B over example A. This is fine. Both can be used when using JSDoc for types.

example A:



/**
 * @typedef {Object} User
 * @property {string} username
 * @property {number} age
 */

example B:



export interface User {

  username: string,

  age: number

}

But that still uses TypeScript!

Yes, this is the point.

In conclusion

Finally, and I'm repeating myself here, using TypeScript without compiling your code is a preference. There is no right or wrong answer and I challenge anyone who is skeptical of this approach to be a little bit more open minded and give it a try some time when you're starting a new project, you might find it's actually a quite nice approach of utilizing types. And if you end up not liking it, that's fine too!

Javascript Questions for the Dazed and Confused

Pascal Schilp — Sat, 14 Jan 2023 14:52:15 +0000

This post is a little bit of a ratatouille on things that I often see people be confused about in the javascript ecosystem, and will hopefully serve as a reference to point to whenever I see people ask questions about some of the following topics: process.env, bare module specifiers, import maps, package exports, and non-standard imports.

`process.env`

The bane of my existence, and the curse that will haunt frontend for the next few years or so. Unfortunately, many frontend libraries (even modern ESM libraries, looking at you floating-ui) use process.env to distinguish between development-time and build-time, for example to enable development-time only logging. You'll often see code that looks something like this:

if (process.env.NODE_ENV === 'development') {
  console.log('Some dev logging!');
}

The problem with code like this is that the process global doesn't actually exist in the browser; its a Node.js global. So whenever you import a library that uses process.env in the browser, it'll cause a pesky Uncaught ReferenceError: process is not defined error. The browser is not Node.js.

When library authors include these kind of process.env checks, they make the assumption that their user uses some kind of tooling (like a bundler) to take care of handling the process global. However, this is assumption is often wrong, which leads to many people running into runtime errors caused by process.env.

So how can we deal with process.env in frontend code? Well, there's two things you can do, and they're equally bad. Your first option is to simply define the process global on the window object in your index.html:

index.html:

<script>
  window.process = {
    env: {
      NODE_ENV: 'development' // or 'production'
    }
  }
</script>

The second option is to use a buildtool to take care of this for you. Some buildtools will take care of process.env by default, but some buildtools do not. For example, if you're using Rollup as your buildtool of choice, you'll have to use something like @rollup/plugin-replace to replace any instance of process.env, or something like rollup-plugin-dotenv.

The reality is, that in the year 2023, there is no good reason for a browser-only library to contain process.env, period. So whenever you encounter the Uncaught ReferenceError: process is not defined error caused by a library using process.env, I urge you create a github issue on their repository.

Thankfully, there are other, more browser-friendly ways for library authors to distinguish between development and build-time, like for example the esm-env package by Ben McCann, which makes clever use of package exports, which I'll talk more about later in this blog post.

Bare module specifiers

Another thing that often throws developers off are bare module specifiers. In Node.js, you can import a library like so:

import { foo } from 'foo';
                     ^^^

And Node's resolution logic will try to resolve the 'foo' package. If you're using Node.js, its likely that the 'foo' package is a third-party package installed via NPM; because if it was a local file, the import specifier would be relative, and start with a '/', './' or '../'. So Node's resolution logic will try to locate the file on the filesystem, and resolve it to wherever it's installed.

At some point in time, bare module specifiers started making their way into frontend code, because NPM turned out to be a convenient way of publishing and installing libraries, and modularizing code. However, bare module specifiers by themself won't work in the browser; browsers dont have the same resolution logic thats built-in to Node.js, and they sure as hell don't have access to your filesystem by default. This means that if you use a bare module specifier in the browser, you'll get the following error:

Uncaught TypeError: Failed to resolve module specifier "foo". Relative references must start with either "/", "./", or "../".

This means that whenever you're using bare module specifiers, you'll have to somehow resolve those specifiers. This is usually done by applying Node.js's resolution logic to the bare module specifiers via tooling. For example, if you're using a development server, the development server may take a look at the imports in your code, and resolve them following Node.js's resolution logic. If you're using a bundler, it may take care of this behavior for you out of the box, or you may have to enable it specifically, like for example using @rollup/plugin-node-resolve.

If you've installed the foo package via NPM's npm install foo command, the foo package will be on your disk at my-project/node_modules/foo. So whenever you import bare module specifier 'foo', tools can resolve that bare module specifier to point to my-project/node_modules/foo. But by default, bare module specifiers will not work in the browser; they need to be handled somehow. The browser is not Node.js.

Import maps

Another way to handle bare module specifiers is by using a relatively new standard known as Import Maps. In your index.html you can define an import map via a script with type="importmap", and tell the browser how to resolve specific imports. Consider the following example:

<script type="importmap">
  { 
    "imports": {
      "foo": "./node_modules/foo/index.js",
      // or
      "foo": "https://some-cdn.com/foo/index.js",
    }                   ^
  }                     |
</script>               |
                        |
<script type="module">  |
  import { foo } from 'foo';
</script>

The browser will now resolve any import on the page being made to 'foo' to whatever we assigned to it in the import map; 'https://some-cdn.com/foo/index.js'. Now we can use bare module specifiers in the browser 🙂

Package exports

Another good thing to be aware of are a relatively new concept called package exports. Package exports modify the way Node's resolution logic resolves imports for your package. You can define package exports in your package.json. Consider the following project structure:

my-package/
├─ src/
│  ├─ bar.js
├─ index.js
├─ foo.js
├─ package.json
├─ README.md

And the following package.json:

{
  "exports": {
    ".": "./index.js",
    "./foo.js": "./foo.js"
  }
}

This will cause any import for 'my-package' to resolve to my-package/index.js, and any import to 'my-package/foo.js' to 'my-package/foo.js'. However, this will also PREVENT any import for 'my-package/src/bar.js'; it's not specified in the package exports, so there's no way for us to import that file. This can be nice for package authors, because it means they can control which code is public facing, and which code is intended for internal use only.

However, package exports can also be painful; sometimes packages add package exports to their project on minor or patch semver versions, not fully realizing how it will affect their users use of their code, and lead to unexpected breaking changes. As a rule of thumb, adding package exports to your project is always a breaking change!

On extensionless imports

I generally recommend package export keys to contain file extensions, e.g. prefer:

{
  "exports": {
    "./foo.js": "./foo.js"
  }
}

over:

{
  "exports": {
    "./foo": "./foo.js"
  }
}

The reason for this is how this translates to import maps. With import maps, we can support both extensionful and extensionless specifiers, but it'll lead to bloating your import map. Consider the following library:

my-library/
├─ bar.js
├─ foo.js
├─ index.js

 {
   "imports": {
     "my-library": "/node_modules/my-library/index.js",
     "my-library/": "/node_modules/my-library/",
   }
 }

This import map would allow the following imports:

import 'my-library';
import 'my-library/foo.js'; // ✅
import 'my-library/bar.js'; // ✅

But not:

import 'my-library/foo'; // ❌
import 'my-library/bar'; // ❌

While technically we can support the extensionless imports, it would mean adding lots of extra entries for every file that we want to support having extensionless imports for to our import map:

 {
   "imports": {
     "my-library": "/node_modules/my-library/index.js",
     "my-library/": "/node_modules/my-library/",
     "my-library/foo": "/node_modules/my-library/foo.js",
     "my-library/bar": "/node_modules/my-library/bar.js",
   }
 }

This results in the import map becoming more complicated and convoluted than it needs to be. As a rule of thumb; just always use file extensions in your package exports keys, and you'll keep your users import maps smaller and simpler.

Export conditions

You can also add conditions to your exports. Here's an example of what export conditions can look like:

{
  "exports": {
    ".": {
      "import": "./index.js", // when your package is loaded via `import` or `import()`
      "require": "./index.cjs", // when your package is loaded via `require`
      "default": "./index.js" // should always be last
    }
  }
}

By default, Node.js supports the following export conditions: "node-addons", "node", "import", "require" and "default". When resolving imports based on package exports, Node will look for keys in the package export to figure out which file to use.

Tools however can use custom keys here as well, like "types", "browser", "development", or "production". This is nice, because it means tools can easily distinguish between environments without having to rely on process.env; this is how esm-env cleverly utilizes package exports to distinguish between development and production environments;

{
  "exports": {
    ".": {
      "development": "./dev.js",
      "default": "./prod.js"
    },
  },
}

Where dev.js looks like:

export const DEV = true;
export const PROD = false;

and prod.js looks like:

export const DEV = false;
export const PROD = true;

There are many quirks related to this however, for example if you use "types" it should always be the first entry in your exports, and if you use "default" it should always be the last entry in your exports. Package exports are easy to mess up, and get wrong. Thankfully, there's a really nice project called publint that helps you with things like these.

Package.json

Another quirk of package exports is that, if not specified, it also prevents tooling from import or requireing your package.json 🙃 This means that it can sometimes be useful to add your package.json to your package exports as well.

{
  "exports": {
    "./package.json": "./package.json",
  }
}

Fallback

Technically, we can make package export keys pretty much anything we want. Consider the following example:

my-library/
├─ bar.js
├─ index.js

And the following package exports:

{
  "exports": {
    "./whatever-name-we-want": "./bar.js",
  }
}

This package exports map will allow the following import:

import 'my-library/whatever-name-we-want';

However, tools that don't support package exports yet, or CDN's will not be able to resolve that import. This is why generally it's good practice to keep a 1-on-1 mapping between your package export keys and the project structure on the filesystem. In this case, the following package exports would have been better:

{
  "exports": {
    "./bar.js": "./bar.js",
  }
}

Non standard imports

Another nice example of non-standard behavior I see often is non standard imports. Here's a common example:

import icon from './my-icon.svg';

This, also, will not run in the browser. You need a buildtool to enable this behavior. Some buildtools, like Vite (which under the hood uses an opinionated Rollup build), enable this behavior by default. Philosophies and opinions on this differ, but I would consider this a bad default. The problem with enabling imports like these in tools by default, while convenient, is that it's non-standard behavior, and developers learn the wrong basics.

Alternatively, you can use import.meta to reference non-javascript assets. import.meta is a special object provided by the runtime that provides some metadata about the current module.

For example, given the following project:

my-project/
├─ index.html
├─ src/
│  ├─ bar.js
│  ├─ icon.svg

Where bar.js looks like:

const iconUrl = new URL('./icon.svg', import.meta.url);
const image = document.createElement('img');
image.src = iconUrl.href;
document.body.appendChild(image);

When opening the index.html in the browser, import.meta.url will point to http://localhost:8000/src/bar.js; the full URL to the module. This means that we can reference assets relative to our current module by creating a new URL that combines'./icon.svg' and import.meta.url, the iconUrl.href will correctly point to http://localhost:8000/src/icon.svg.

During local development, this should all work nicely and without any build magic. However, imagine we want to bundle our project for production. We give our bundler an entrypoint javascript file, and from there it bundles any other javascript thats used in the project. After running our build, our project directory may look something like this:

my-project/
├─ dist/
│  ├─ as7d547asd45.js
├─ index.html
├─ src/
│  ├─ bar.js
│  ├─ icon.svg

In our build output, which is now a bundled (and probably minified) javascript file (as7d547asd45.js), import.meta.url does not point to the correct location of './icon.svg' anymore! There's several things we can do about this; we can simply copy icon.svg to our dist/ folder, or we can use a plugin in our buildtool to automatically take care of this for us. If you're using rollup, @web/rollup-plugin-import-meta-assets takes care of this for you.

Asdgf

Pascal Schilp — Tue, 06 Dec 2022 18:48:15 +0000

Alex Turner, in an interview with BBC Radio 1's Annie Mac reveals how his favourite albums feel like places that he can go and visit in his mind, and so it made sense to model an actual place for the album (Tranquility Base Hotel & Casino). The same can be said for feelings, sounds, and even smells can trigger vivid memories and experiences.

Alex Turner designing a model of Tranquility Base Hotel & Casino, a fictional hotel placed on the moon

Something similar is mentioned by Mike Burakoff, writer and director of the music video for The Strokes' At The Door:

There's a feeling when you are growing up that you are just leaving for a second to go get something, that you'll be right back. But reality is not the same as a memory, you can't go back. Something or some time that feels so close to you can be impenetrably far away. It's a feeling of loss that I get when I think about certain memories from my past. That notion is at the heart of this video.

Still of the music video of At The Door by The Strokes, illustrated and animated in the style of a nostalgic-looking cartoon, displaying an old and clearly abandoned house, transitioning into a portal showing a futuristic city that has taken it's place

The music video for The Strokes' At The Door and the quote from its director, Mike Burakoff, brought to mind websites from my past that no longer exist or have changed beyond recognition. As a child, I would frequently visit the forum for my favorite video game, The Elder Scrolls: Morrowind. Though the forum no longer exists, it is still accessible through the Wayback Machine. However, whenever I revisit it, it feels like a ghost town. The once-popular forum that was full of discussions is now abandoned.

Screenshot of the Morrowind forum visited through the Wayback Machine, displaying some forum posts and broken images

It's almost like looking at the ruins of an ancient city. Not everythings works anymore, links have rotten and now lead to pages that don't exist anymore, images have disappeared, its users have moved on in life, but a lot of their posts are still visible to browse through. There's a rich history of a community, its discussions, its unique sense of humor and in-jokes, and its drama; a legacy. Maybe the closest thing to a time machine I'll ever experience.

It reminds me of a project a friend of mine did in art school, on the human tendency of wanting to leave a legacy, and to contribute to something bigger. Often unintentionally so; a quick scribble with a pen on a piece of paper to check that the pen works correctly as a proof of life. The message not being as important as the need to leave one, a reminder of the impact we have had on the world around us.

Some scribblings on a piece of papier

A human handprint on a wall of cavepaintings. A test-tweet saying no more than a simple, effortless "asdgf". Hello world.

"I was here".

A tweet from June 27, 2013 that says "asdgf"

In the song Four Out of Five from Arctic Monkeys' album Tranquility Base Hotel & Casino, Alex Turner explores the idea of leaving a lasting legacy, even in the most unlikely of places. in the song, Turner takes on the persona of the owner of a hotel on the moon, boasting about a taqueria he has opened on the roof. Despite the unconventional setting and the seemingly mundane nature of a taqueria, it got rave reviews; four stars out of five.

What's the latest on the European Accessibility Act in the Netherlands?

Pascal Schilp — Sat, 01 Oct 2022 09:41:15 +0000

Or: A human tries to read laws and make sense of it 🙃

First of all, I am not a lawyer. I'm but a simple software developer with an interest in accessibility. You would be a fool to take anything in this blogpost at face value.

I am also constantly amazed by the sorry state of accessibility on the web. It seems like a lot of companies and online services still don't seem to care a lot about accessibility (like for example one of the largest music festivals in the Netherlands), and I regularly see the following question pop up on twitter, and other forums or messageboards: "How do I convince business to prioritize accessibility?". And well, a good answer for that might possibly be:

THE LAW.

However, what is the law? "It should be accessible" seems like a fairly vague description for a law. Curious to find some answers and specifics to this, I went down the rabbit hole that is the European Accessibility Act, government and law websites, and tried to find out.

Note: This blogpost will focus largely on the status of the European Accessibility Act in the Netherlands specifically.

The Temporary Decree on digital accessibility of the government

In the Netherlands, the temporary decree on digital accessibility of the government (tijdelijk besluit digitale toegankelijkheid overheid) has been in effect since May 3rd 2018, which entails that the accessibility of government related websites and mobile applications should be up to standard. This decree is temporary, because it's the precursor or younger brother of the Digital Government Act (Wet Digitale Overheid).

Who?

So to which kind of organizations does this decree apply?

State, regional or local government agencies (of which a very convenient list is published here)
Public law instutions
Partnerships

Interestingly, the decree does not apply to healthcare related organizations, nor nurseries and schools, NGOs, and privatized sectors like transport, gas, water and post.

How?

Websites and mobile apps should be made accessible based on the requirements of the European standard EN 301 549. Which pretty much just means WCAG 2.1, level A and AA.
By publishing an accessibility statement that explains which steps the organization takes to ensure accessibility, as well as a planning to keep the the website accessible
Continuing to fully comply with points 1 and 2

Interestingly, additional information and potential exceptions are provided for "specific situations", such as audiovisual content, online ticket services, intranet applications, archival content, and more in this here list.

As mentioned above, this is only applicable to (semi-)governmental institutions. What about other businesses and organizations?

European Accessibility Act

The European Accessibility Act (Europese Toegankelijkheidswet, or EAA) is a European directive, which means that rules and guidelines have been agreed upon by the European Union, and now have to be translated and implemented on a per country basis. You can read the source code of the EAA here.

Who/what?

Whereas the temporary decree on digital accessibility of the government applies mainly to the websites and mobile applications of governmental organizations, the implementation of the European Accessibility Act applies to a wider spectrum of organizations, services, devices and businesses, such as:

Computer hardware systems and operating systems
Self-service terminals like ticket machines, check-in machines, and information terminals
e-readers
consumer terminal equipment with interactive computing capabilities (smart phones)
electronic communication services
services providing access to audiovisual media services (netflix)
air, bus, rail and waterborne passenger transport services
consumer banking services (banking)
e-commerce (webshops)

You can find the complete list here.

How?

There's a very detailed description of the accessibility requirements for products and services in the source code of the EAA.

Update October 19, 2022: I've since found a source that indeed states that the EAA will be based on the European Norm (EN) 301 549, which includes A and AA successcriteria from the WCAG.

Some blogposts online seem to state that the EAA will be based on WCAG as well (like the temporary decree on digital accessibility of the government), but I've not actually found any mention or confirmation of WCAG in relation to the implementation of the EAA itself; only in relation to the temporary decree on digital accessibility of the government. The EAA source does mention the principles "perceivable, operable, understandable and robust", which are taken from the WCAG, and considering the temporary decree on digital accessibility of the government is also based on the WCAG, it seems likely that the implementation of the EAA will be based on it as well. The real answer though is; we don't know yet.

When?

The EAA should have been implemented by European countries on the 28th of June, 2022. In the Netherlands, this deadline has been missed. The directive will start to actually apply to products and services starting from June 28th, 2025.

Status?

The reason for the delay of the implementation of the EAA in the Netherlands seems to be related to several things. In a status report on the website of de Eerste Kamer it is said that the act has been in consultation between December 22, 2021 until Februari 25th 2022. In the status update, it is mentioned that because of the complexity of the matter, and the involvement of many different ministries were cause for delays. The expectation is that the act will presented to the Advice Department of the Council of State (Afdeling advisering van de Raad van State) in spring 2023. It is also mentioned that the EAA will only be actually applicable from June 28th, 2025, and the expectation is that this deadline will not be missed.

There were also concerns about the fact that there is no mention of education in the EAA, which lead to questions about the act.

2: Are you aware of the fact that "education" is not mentioned in the European Accessibility Act?

Yes.

3: Do you think it is possible to still ensure that the requirements the act sets for accessibility are also guaranteed in the field of education?

Amending the Act to ensure this would still be a lengthy and complex process, with no guarantee of success at European level, therefore possibilities are now being explored in national legislation and regulations. [...]

Admittedly, this seems like a fair point. There is no mention of education in the source code of the EAA at all.

Additionally, Ieder(in) (umbrella organization for people with disabilities in the Netherlands), expressed their concerns about the delay of the implementation in this letter. In the letter, they call for more urgency to avoid further delays, provide clarity to citizens and business via a central information point, and to actively include people with disabilities and representing organizations.

(77) With a view to establishing, in the most efficient way, harmonised standards and technical specifications that meet the accessibility requirements of this Directive for products and services, the Commission should, where this is feasible, involve European umbrella organisations of persons with disabilities and all other relevant stakeholders in the process.

In conclusion, it seems like the implementation will still be dragged out a fair bit under the cover of "it will only be applicable in 2025 anyways". I've personally found that there especially is a huge need for a centralized point of information regarding the implementation of the EAA, because the information is all over the place.

Points of interest in the EAA

Something that is mentioned a lot in the EAA is "proportionality", and "disproportionate burden" which, put plainly, feels like it might enable huge cop-outs by claiming disproportionate burden:

(64) For reasons of proportionality, accessibility requirements should only apply to the extent that they do not impose a disproportionate burden on the economic operator concerned, or to the extent that they do not require a significant change in the products and services which would result in their fundamental alteration in the light of this Directive. Control mechanisms should nevertheless be in place in order to verify entitlement to exceptions to the applicability of accessibility requirements.

The criteria for assessment of disproportionate burden is described in ANNEX VI.

(65) This Directive should follow the principle of ‘think small first’ and should take account of the administrative burdens that SMEs are faced with. It should set light rules in terms of conformity assessment and should establish safeguard clauses for economic operators, rather than providing for general exceptions and derogations for those enterprises. Consequently, when setting up the rules for the selection and implementation of the most appropriate conformity assessment procedures, the situation of SMEs should be taken into account and the obligations to assess conformity of accessibility requirements should be limited to the extent that they do not impose a disproportionate burden on SMEs. In addition, market surveillance authorities should operate in a proportionate manner in relation to the size of undertakings and to the small serial or non-serial nature of the production concerned, without creating unnecessary obstacles for SMEs and without compromising the protection of public interest.

SMEs are small or medium sized enterprises

(66) In exceptional cases, where the compliance with accessibility requirements of this Directive would impose a disproportionate burden on economic operators, economic operators should only be required to comply with those requirements to the extent that they do not impose a disproportionate burden. In such duly justified cases, it would not be reasonably possible for an economic operator to fully apply one or more of the accessibility requirements of this Directive. However, the economic operator should make a service or a product that falls within the scope of this Directive as accessible as possible by applying those requirements to the extent that they do not impose a disproportionate burden. Those accessibility requirements which were not considered by the economic operator to impose a disproportionate burden should apply fully. Exceptions to compliance with one or more accessibility requirements due to the disproportionate burden that they impose should not go beyond what is strictly necessary in order to limit that burden with respect to the particular product or service concerned in each individual case. Measures that would impose a disproportionate burden should be understood as measures that would impose an additional excessive organisational or financial burden on the economic operator, while taking into account the likely resulting benefit for persons with disabilities in line with the criteria set out in this Directive. Criteria based on these considerations should be defined in order to enable both economic operators and relevant authorities to compare different situations and to assess in a systematic way whether a disproportionate burden exists. Only legitimate reasons should be taken into account in any assessment of the extent to which the accessibility requirements cannot be met because they would impose a disproportionate burden. Lack of priority, time or knowledge should not be considered to be legitimate reasons.

And finally, the following point seemed interesting as well:

(70) Microenterprises are distinguished from all other undertakings by their limited human resources, annual turnover or annual balance sheet. The burden of complying with the accessibility requirements for microenterprises therefore, in general, takes a greater share of their financial and human resources than for other undertakings and is more likely to represent a disproportionate share of the costs. A significant proportion of cost for microenterprises comes from completing or keeping paperwork and records to demonstrate compliance with the different requirements set out in Union law. While all economic operators covered by this Directive should be able to assess the proportionality of complying with the accessibility requirements of this Directive and should only comply with them to the extent they are not disproportionate, demanding such an assessment from microenterprises providing services would in itself constitute a disproportionate burden. The requirements and obligations of this Directive should therefore not apply to microenterprises providing services within the scope of this Directive.

DEV Community: Pascal Schilp

A cleaner node modules ecosystem

How do we fix this situation the ecosystem is in?

Module Replacements

Module Replacements Codemods

So what do we do with these codemods?

A practical guide against barrel files for library authors

Use automated tooling

Lint against barrel files

Avoid authoring barrel files

Avoid importing from barrel files

Don't expose a barrel file as the entrypoint of your package

On treeshaking

Create granular entrypoints for your library

How do I add granular entrypoints?

Alternative: Subpath exports

A real-life example

Conclusion

Rustify your JavaScript tooling

Lil bit of namedropping

Using your Rust code in Node

Publishing

In conclusion

Self unregistering service workers

The Problem

A potential solution

So what are you getting at?

Barrel files: A case study

Untangling MSW's module graph

Automating it

Conclusion

Service Worker Templating Language (SWTL)

html

Why not do this at build time?

Isomorphic rendering

Router

Out of order streaming

Wrapping up

Acknowledgements

Events are the shit

Use EventTarget

Extend Event!

Extend EventTarget!

Events are sync

Context-like patterns

Promise-carrying events

The Cost of Convenience

The conveniences

The cost

The conclusion

Using Typescript without compilation

Benefits of skipping a compilation step

Myths

Using JSDoc is unmaintainable

No type inference or intellisense

Manually writing types is bothersome

But that still uses TypeScript!

In conclusion

Javascript Questions for the Dazed and Confused

process.env

Bare module specifiers

Import maps

Package exports

On extensionless imports

Export conditions

Package.json

Fallback

Non standard imports

Asdgf

What's the latest on the European Accessibility Act in the Netherlands?

The Temporary Decree on digital accessibility of the government

Who?

How?

European Accessibility Act

Who/what?

How?

When?

Status?

Points of interest in the EAA

`html`

Use `EventTarget`

Extend `Event`!

Extend `EventTarget`!

`process.env`