“This is your last chance. After this, there is no turning back. You take the blue pill — the story ends, you wake up in your bed and believe whatever you want to believe. You take the red pill — you stay in Wonderland and I show you how deep the rabbit-hole goes.” Morpheus (The Matrix)
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.
I just needed this widget for the neo.mjs calendar implementation.
Following the “Application worker being the main actor” paradigm, the list lives within the App web worker scope.
While the task sounds non trivial at first, it is actually very easy to implement using an UI framework.
Let us take a quick look at the result first:
The neo.mjs v2.0 release was focussed on the new view models implementation, which enables you to bind component configs to view model data properties anywhere inside the model hierarchy tree.
This article is covering the latest enhancements to make complex application based state management even easier and more powerful.
I got asked to create more content which can help new developers getting up to speed. In general there are two main topics which make the most sense:
Following the “application worker is the main actor” concept, Fieldset instances will live inside the App web worker scope.
I am still moved by the neo.mjs nomination:
This article covers the enhancements of the version v2.2.0 Release.
Let us take a look at the format of an index.html file prior to the v2.2 release:
You were able to define all available configs of DefaultConfig.mjs directly inside the index file. …
More precisely: workspace based styling
It was possible for a long time to add new components into the neo.mjs framework and using the SCSS based theming engine to style your components differently for each theme.
With the new theming engine in place, we now get a granular CSS output, we can automatically lazy load CSS files as needed and we even get…
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.
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.
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:
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.