Expanding Single Page Apps into multiple Browser Windows

Content

1. Introduction
2. Scalable frontend architectures
3. More background infos
4. Benefits of the Shared App Worker
5. How can DOM events still work?
6. How do the Apps inside the Shared Covid App look like?
7. How can we position Popup Windows to exactly overlay an existing Component?
8. What are the use cases for the Shared Workers setup?
9. Webpack based dist versions?
10. What about Webkit / Safari?
11. Online Demo
12. What is coming next?
13. Would you like a tutorial on how to transform the Covid App into the new Shared Covid App version?
14. Close to the end game?
15. Final thoughts

1. Introduction

For me, it was alway a big dream, if not a life time goal, to create a meaningful Open Source project, with the potential to make a significant impact to improve the way how UI development works in general. This is it. I am very excited to not only share this article with you, but the entire code base as well (using the MIT license).

Before diving into the topic of scalable frontend architectures, please watch this 95s video first:

2. Scalable frontend architectures

In a nut shell:

1. In case you are working inside the UI development area, the first picture should look familiar. Everything happens inside the main thread (Browser Window). This is actually a performance problem. A big one. By default, each Browser Window is just using 1 CPU / Core, while close to every computer or mobile device has more than one available. The worst case which can happen is that one CPU is running at 100% => freezing your UI, while other CPUs are idle. Even framework background tasks, like internal garbage collection, can already mess up your beautiful CSS animations and it is hard for developers to figure out what is happening. Some project started moving isolated expensive tasks into a separate thread. Sorry, this is not enough!
2. The default neo.mjs setup for Single Page Apps (SPAs) started with the concept to move out everything that is possible from the Main Thread, so that this one is mostly idle and can fully concentrate on its primal purpose: manipulating the DOM. A tiny part (37KB) of the neo.mjs is running inside the Main Thread: the logic to create the workers, applying delta updates on the real DOM & delegating virtualised UI events to the App Worker. There are no background tasks here. Optional Main Thread addons can get dynamically imported as needed. Since this concept put a lot of weight on the App Worker, the VDom & Data Workers were added. Of course you can connect to your backend from the App worker as well.
3. The neo.mjs setup was designed right from the start keeping the Shared Workers setup in mind. From an architecture perspective, this is close to the end game. We can now optionally replace the Workers with Shared Workers, which allows us to connect multiple Main Threads (Browser Windows) to the Shared App Worker. This way our Apps can directly communicate (not even needing postMessages to do so), but it goes way beyond this, as you have seen inside the video.

3. More background infos

The last 2 articles are worth a look:

4. Benefits of the Shared App Worker

Of course you only need to load a framework once for all connected Browser Windows.

It might sound trivial, but the biggest benefit is probably that the App Worker is using just one IdGenerator. Meaning: all Components for all of your Apps have unique IDs.

The VDom worker is using just one IdGenerator as well, which ensures that all DOM nodes for all Apps have unique IDs as well.

The combination of both makes it super easy to move Components or entire Component Trees around different Browser Windows. Even better: we can just move the virtual DOM around while keeping & re-using the same Javascript instances.

Example: