Safari (Webkit) just released support for JS modules inside the worker scope

This is a huge step for getting UI development back where it belongs:
Into the browser.

Content

1. Introduction
2. How to create a worker from a JS module?
3. Verifying the logic in a big use case
4. What is the current state of Firefox?
5. The future of build tools
6. What is missing in Safari (Webkit)?
7. Final thoughts

1. Introduction

The related ticket:

164860 - JS Modules in Workers

This feature was already working inside the Safari Technology Preview since April 2021, so this is a follow up blog post for:

Safari (Webkit) about to release support for JS modules inside the worker scope

It was just released inside the “normal” Safari version (15.0).

2. How to create a worker from a JS module?

You can create a non module based worker like this:

const worker = new Worker('worker.js');

In case you do want a JS module as the starting point, just use the type option:

const worker = new Worker('worker.mjs', {
  type: 'module'
});

3. Verifying the logic in a big use case

neo.mjs is most likely the biggest project out there which relies on using JS modules inside the worker scope. After all, it follows the “an application worker being the main actor” paradigm and your apps and components live there.

So far it was only possible to use the development mode → real code without any builds and transpilations in Chromiun (Chrome & Edge) as well as the Safari Technology Preview.

Of course we could use the webpack based dist/developmentand dist/productionoutputs inside Safari as well before, but in case you want to style or fix specific things for Webkit, this was not really fun.

My test case is the Covid Dashboard, which is a pretty complex app.

You can find the source code here: apps/covid

As soon as you are using import and/or export statements, your file does count as a JS module. You obviously need this in case you want to extend a class and import the base class.

This makes a lot of sense in case you are sticking to the “one class per file” design pattern.

As you can see inside the console, Neo.worker.App is living inside the app web worker. This is the real code (no source-maps).

4. What is the current state of Firefox?

You can find the related ticket here:

1247687 - Implement worker modules

The ticket is in development, but not done yet.

5. The future of build tools

Once Firefox catches up, all major modern browsers are ready to support JS modules. At this point, build tools like webpack can get simplified.

Harmony, the engine to convert modules into “non modules”, would become obsolete at this point.

In case you don’t want to create bundles (split chunks), you could also just minify your files at this point.

6. What is missing in Safari (Webkit)?

We still need support for SharedWorkers:

149850 - Reinstate support for SharedWorkers

Chromium as well as Firefox support them.

This is especially important since all browsers on iOS have to use it.

I would love to see the multi window covid app running here as well:

SharedWorkers are important for mobile too, since many apps are using a native shell containing multiple web views (headless browsers).

We could directly communicate between them.

7. Final thoughts

You can find the neo repository here:

GitHub - neomjs/neo: The application worker driven frontend framework

I will add some links to development mode examples which you can now run directly inside Safari.

Covid Dashboard:
apps/covid/index.html

Covid Gallery:
examples/component/coronaGallery/index.html

Helix:
examples/component/helix/index.html

Best regards & happy coding,
Tobias