Entropy. Good point. I don't think many brought up that issue, it's either ignored (we know what we're doing) or coped with when it's too late (we knew what we're doing).
Entropy handling should be the goal for 2019 UI/Frontend engineering.
I think the reduction of the cognitive load of entropy was what propelled React (and specifically its innovation of the Virtual DOM) to be the most widely-used front-end framework. Being able to write a function transforming state to a description of the view, without having to worry about getting from whatever the view currently looks like to what you want it to look like, is a huge advantage.
It can certainly still be greatly improved, but I think we've already made great strides in entropy handling on the front-end in recent years.
Virtual DOM is rather a desperate move - to support components life time constructor/destructor events componentWill/DidMount / Unmount.
What if you will be able to define in standard HTML/CSS something like this (as it is supported natively in Sciter)
// css
div.mycomponent {
behavior: MyComponent url(components.js);
}
// script in components.js
class MyComponent : Element {
function attached() { /*constructor*/ }
function detached() { /*destructor*/ }
… other custom component specific methods …
}
With that simple mechanism you don't need virtual DOM and its overhead at all. Component binding requires only inclusion of that CSS.
So let's say that that's a component that displays a user's username - how do you make sure that its view is always up-to-date, whether the user is logged in, logged out, or another user's logged in?
Virtual DOM is not just about componentWill/DidMount/UnMount. It's when updating the view when a component's inputs (props) change that Virtual DOM shines.
looks pretty close to the web components api. specifically "customized built-in elements" which use the `is` attribute on a regular element to add custom beavior.
Entropy handling should be the goal for 2019 UI/Frontend engineering.