I think there's another way to look at this. Right now the DOM is exposed to the browser in a way that makes Javascript the most natural way to manipulate browser elements.
There is a movement towards a more elegant way of expressing UI, where functional languages and imperative languages with functional features can both be used, but these currently require often large and complicated frameworks or even comete language runtimes.
Ultimately these also require some kind of Javascript bridge which leads us back to it being central to web programming. You either use Javascript or you go to great lengths to hide it.
The solution, which is slowly emerging in a de-facto manner, is to expose to any chosen language whether implemented in Javascript, wasm, or some new JIT compiled bytecode with dynamic features, a transactional, IPC-based API for rendering, diffing, and merging web content.
JQuery inspired the selector APIs (querySelector*) which in turn improved the efficiency of, then mostly obviated, JQuery itself.
I imagine the same thing could happen with React-like frameworks and things like Elm.
There are sites written entirely in Flash and ActionScript, a platform that is now obsolete. Another attempt was Silverlight and XAML (and JavaScript), dead also. I am not sure the desire to abandon JS is shared by all.
Yes, and to be clear I am not calling on developers or browser makers to abandon JS.
I'm talking about an additional API that is more suitable to polyglot support in the browser and more in tune with how modern browser frameworks work.
JS would remain a first-class language, and users of libraries or frameworks such a React would have to make very few changes to their application if they had to make any at all. The difference is the new API used by React itself to render HTML elements would be faster with native support for diffing and batching updates. Less work would be performed in blocking script contexts or on UI threads with changes to content being essentially atomic.
A developer could decide to implement an ES6 module and use a new tag, <import module />, instead of <script>.
This tag would support JS, WASM, and a new Dynamic WASM with support for interpreted and dynamic languages like Python or Ruby or Clojure or Elm using a similar bytecode and syntax to WASM.
The <script> tag would not change and the window, navigator, and document objects and DOM APIs will be available as always.
The same would be true for Angular, Ember and even JQuery.
There is a movement towards a more elegant way of expressing UI, where functional languages and imperative languages with functional features can both be used, but these currently require often large and complicated frameworks or even comete language runtimes.
Ultimately these also require some kind of Javascript bridge which leads us back to it being central to web programming. You either use Javascript or you go to great lengths to hide it.
The solution, which is slowly emerging in a de-facto manner, is to expose to any chosen language whether implemented in Javascript, wasm, or some new JIT compiled bytecode with dynamic features, a transactional, IPC-based API for rendering, diffing, and merging web content.
JQuery inspired the selector APIs (querySelector*) which in turn improved the efficiency of, then mostly obviated, JQuery itself.
I imagine the same thing could happen with React-like frameworks and things like Elm.