TomWe have the performance, do we?
Web development, especially the frontend, can just be a joy to work with. Install Node.js, download one of the many starter packs for React, Angular, Vue or vanilla HTML/JS and kick-start your coding. Building a performant, scalable web application was never easier. Beginners and seasoned developers alike also have a vast repository of libraries available. Thanks to tools like NPM, many hours of coding can be skipped if desired by just installing the components you need.
With the advent of PWAs (progressive web apps), the future looks brighter than ever for full-fledged apps, directly available in every browser. Yet one major architectural aspect is still taming the frontend development: Every app runs its business logic + rendering in a single process, the main thread, by default. As a reminder, the main thread is bound to the browser window, which in all current browsers translated to a window tab.
What even is a multithreaded web app
Thanks to great advancements lately, developers can now implement multithreading in their apps. Using Web Workers, tasks can be run in its isolated threads. Data gets serialized/deserialized before/after being sent between the main thread and a worker. Each web worker is truly running its own process and only bound to the main thread by the app’s lifecycle, that is if the application gets closed, so do all workers.
Enter Neo.mjs
Neo.mjs aims at building on this foundation and enhancing it. Out of the box, Neo uses a whopping four threads, as described in the documentation:
- Main: Creating the workers, manipulating the real DOM, forwarding UI events to App
- App: Most parts of the framework & your apps live here
- Data: Responsible for the BE connections
- Vdom: Converting the virtual DOM into HTML, as well as calculating delta updates
Here’s a visual representation by the framework’s creators:
The main goal of Neo is to reduce main’s work as much as possible and delegating computationally intensive tasks to the workers, thus guaranteeing not only a UI without stuttering or lags, but also no overhead for each process, as every worker has its specific role.
The crazy concept to achieve this goal: also create the vDOM in a worker and only send the “real” rendering to the main thread. If you haven’t heard of it yet, modern UI frameworks such as React don’t render every change you make to your views immediately. They first update a virtual DOM (“vDOM”) and only apply the necessary changes to the real DOM, thus enabling quite a good performance.
Keep watching
If you’re now curious, check out the links below and test the project for yourself, which is under active and busy development. Mind that it’s still in its early stages and not production-ready. The concept is quite intriguing and promises to be a major architectural design change, for the better.
- Tom