Interesting, this is more in line with what I was thinking of.
But, JavaScript is such a poor language, that it’s a poor choice for rigorous software development. However, it is a good candidate for transpiling code to.
I was thinking of bolting on an Lisp type of scripting language, which can transpile down to a rigorous subset of JavaScript, which then controls how the widgets behave in the browser.
This way, the Lisp script can be used to control how the widgets are organized in the browser screen. How each widget gets its data, and how it interacts with other widgets on the screen. Basically, it becomes its own little GUI development environment.
Then over time, a public library of Lisp functions can be made available, and easily integrated into your code, with recommendations on commonly accepted techniques to do something. But if you don’t like that, then you’re still free to reinvent your own new technique.
Then over time, the superior nature of this system, becomes popular enough that the major browser vendors begin integrating the Lisp scripting engine as a first class library. And to improve efficiency, it can cut out JavaScript entirely, and just interact directly with the browser. So the Lisp engine should have the ability to both, transpile down to JavaScript for backwards compatibility, as well as to compile down to bytecodes that can be executed by the browser. This way, all the variant JavaScript ecosystems gets neutralized, since this new system, just sidesteps JavaScript completely. (Wait, I think I just described WebAssembly.)
And then, a new variant of web-Lisp takes over the world.
Excellent..