Chrome v83 enables JS module support for SharedWorkers → Starting a new era for...

https://www.chromestatus.com/feature/5169440012369920

A big thank you at the Blink Team for making this happen!

Now you might be wondering: “So, what does this mean?”

Since the release of Chrome v80, JS module support for “normal” workers is in place:

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

Now with v83, you can do this:

const sharedWorker = new SharedWorker(filePath, {type: 'module'});

Meaning: you can now use ES6+ classes & modules for your SharedWorkers, allowing us to create solid architectures for complex use cases.

2. How is the support in Firefox and Safari?

Truth to be told: not there yet.

Both, Firefox & Safari do not even support JS modules for non shared workers yet.

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

This will just break at the first (non dynamic) import statement.

(Opened 4 years ago)

(Opened 4 years ago)

In case you do care about Firefox & Safari not completely falling behind, please add some weight to the tickets. This should improve the priority.

What is neo.mjs?

neo.mjs is a webworkers driven UI framework I am working on. The first public release was on November 23, 2019.

The entire code base as well as all demo Apps are using the MIT license.

In short: neo.mjs is using 4 threads by default:

1. Main (top level)
2. App
3. Data
4. VDom

The main thread only creates the 3 workers, delegates virtualised UI events to the App worker and manipulates the real DOM (applying delta updates).

You can enhance Main using main thread addons, e.g. in case you want to work with external libraries like AmCharts or MapboxGL, which have to run inside the main thread.

Most parts of the framework as well as the Apps you build with it run inside the App worker.

This leaves the main thread mostly idle, leading to a blazing fast rendering performance.

To really get the idea, let us take a quick look at the Covid Dashboard Demo App without using SharedWorkers first: