Contents

1. Introduction
2. How Can WebWorkers Help?
3. Multi-Screen Apps
4. Multi-Screen Apps on Mobile
5. How Can We Include Our App code in a Worker?
6. What Are Remote Methods?
7. What’s the Problem With Templates?
8. Reducing the DOM by 80%+ on Average
9. ES8+ Code Directly Inside the Browser
10. Get Your App Documentation Out of the Box
11. Got curious? What is neo.mjs?
12. How to Get Up to Speed?

1. Introduction

The web moves forward at a great speed — but do you?

When Angular and React were introduced, browsers had poor support for ES6+ features. As a result, the entire UI development got moved into node.js.

Browsers caught up and can now handle JavaScript modules as well as several ESnext features on their own — so it’s time for a change.

While it might be convenient to use custom files like .vue, your Browser can’t understand them. You need a build process, transpilation, or at least a hot module replacement to get your code changes into the browser. This takes time and you can’t debug your real code.

Most apps today still use the following setup:

Some are using WebWorkers, to move out single expensive tasks, but this is not nearly enough. The main thread is responsible for DOM manipulations — the rendering queue. Getting that as idle and lightweight as possible must be the main goal.

2. How Can WebWorkers Help?

What we want to get out of this dilemma are the following setups:

A framework and your app logic can and should run inside a worker.

With this setup, there are zero background tasks inside the main thread. Nothing can slow down or even freeze your UI transitions.

With a simple switch to use SharedWorkers instead of normal workers, we can even connect multiple main threads.

#javascript #front-end-development #nodejs