I am excited about this topic, since the technology we are going to talk about opens the way for a new generation of web-based apps, which can directly communicate across multiple browser windows without involving a backend.

[side note] The article got pretty long. In case you got only a short amount of time, take a look at the video in 2., read the highlight in 10. and then decide if you want to read all of it.


  1. Introduction
  2. The demo app
  3. Are we using the HTML5 drag & drop API?
  4. How can we communicate between browser windows?
  5. How is…

To get a better idea of how powerful an application worker as the main actor can be, I enhanced the helix demo to give you a visual feedback.


  1. Introduction
  2. The helix DOM structure
  3. What does happen internally when scrolling?
  4. Inspecting the deltas inside your console
  5. Video to show it in action
  6. Online demo
  7. Update: new demo with 33k updates
  8. Final thoughts

1. Introduction

In neo.mjs, you applications and components live within the application worker:

One of the most impressive performance demos is the helix component. …

including cross browser window lazy loaded CSS delta updates

This article covers a disruptive new approach on how we can further improve the rendering performance of web based frontends, since we will lazy load CSS exactly as needed.


  1. Introduction
  2. The three different environments in neo.mjs
  3. Why is OOP “out of fashion”?
  4. Cross browser window CSS delta updates
  5. How does this work?
  6. What is coming next?
  7. Call for action!

1. Introduction

It has been a while since I have written part 1. In case you missed it, it is definitely still worth reading:

The neo.mjs project has evolved a lot. Let us take…

For some reason, especially this quick write-up is getting a lot of traction.

You should take a look into the "real" articles:

https://neomjs.github.io/pages/ (blog)

Got a lot of feedback on other channels and it feels like the basic concepts are not clear.

In short: you don't drop components into the json based vdom. nor listeners. nor logic.

The JS side is in charge. You could call it OOP done right VS template driven approaches.

In e.g. React, a render() call destroys child items and creates new instances. Expensive and not needed and imo a reason why functional programming got popular.

While this sounds like a common problem, I was not able to find a good solution for it on the web. So I thought writing an article about it to save others some time is a good idea.

While there are many use cases where you can rely on e.g. webpack to create fitting CSS split chunks out of the box for you, there are scenarios where you need to go from scratch instead to create a 1 input → 1 output based solution.

I strongly recommend to read the article first, but for the curious ones who want to…

When I first dived into Javascript back in 2001 (pre jQuery → 2006), there was the concept:

“Do not mix html with Javascript”

Examples like jQuery or Wordpress have shown us how bad code can get in case you push mixing it to a limit.

The combination of React and JSX has shown us that it can be done in a way which is ok, so the concept no longer applies today.

However, the meaning of the concept was a different one:

“Do not mix logic with your markup”

In my opinion, this is something most frontend developers have forgotten…

While it is nice to only render active cards and optionally remove inactive cards from the DOM while keeping their JS instances alive, it is even better to lazy load the JS modules for cards at the point when you need them.


  1. Introduction
  2. The problem
  3. The solution
  4. How does it work under the hood?
  5. Let’s see it in action!
  6. Online demo
  7. What is coming next?
  8. Final thoughts

1. Introduction

You have most likely seen the Covid Dashboard demo app by now:

The app is running inside the app worker. All components live there.

This new approach is extremely powerful, yet easy to use.

The implementation relies on using SharedWorkers.


  1. The demo app in action
  2. The magic inside the application architecture
  3. Bindings to access the state data
  4. Online demo
  5. More infos about state management in neo.mjs
  6. Can we get a standalone repository for this demo?

1. The demo app in action

I kept the demo app as simple as possible.

Here is a short video to see what we are going to talk about:

2. The magic inside the application architecture

The autogenerated index file:

We are using the useSharedWorkers framework config to switch from using normal web workers to shared ones (required for the…

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


  1. The related ticket
  2. Installing the “Safari Technology Preview”
  3. How to create a worker from a JS module?
  4. Verifying the logic in a big use case
  5. Comparing the rendering performance in Chrome, Safari and Firefox
  6. What is missing in Safari (Webkit)?
  7. Final thoughts

1. The related ticket

I was super excited when opening the ticket, to see that it got changed to “resolved”.

2. Installing the “Safari Technology Preview”

The installation is extremely easy:

Concepts for new products need to be disruptive, otherwise there is little need for them. However, the way to use them should be as consistent as possible.

For a framework this means that the API on how to use it should be rock solid, especially when it comes to new versions. Migrating from neo.mjs v1 to v2 is a piece of cake.

This article assumes that you are not familiar with the project yet, so we will cover some of the basics as well.


  1. Eye candy
  2. Design Goals
  3. What is new in version 2?
  4. Statistics
  5. How can I set up…

Tobias Uhlig

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store