I think a big part of the problem is precisely the interpreted and web browser part of your post, so you're right, but I think at this point it's difficult to disabiguate the browser, the DOM, and JavaScript. I think JavaScript as a language also has problems that make it difficult to do large scale engineering with, thus transpilers.
Maybe WebAssembly will provide fruitful ground for new, simpler, and more rigorous languages.
I also think that much of modern web apps could be accomplished better with HATEOS apps doing pure server side. But I will allow that my beliefs there are at least partly nostalgic
Using Elm, even a little bit, has given me a perspective on what a different language can do in the browser.
If you subscribe to Gary Benhardt’s Capability/Suitability theory of programming history [1], JavaScript is the highly capable technology that can be used for any sort of architecture you can imagine, and Elm is a turn towards suitability that says, “some of those architectures are unsound or have a very low floor for quality.”
You might want to abstract over DOM APIs for different reasons, but at their semantic core they are fine.
I think that JavaScript is a really interesting and unique language. I would rather have had Perl in the browser. JS seems more appropriate as a relatively obscure academic language. Note that I tend to view trying to enforce types or use classes in JS as being misguided and futile, which does not seem to be a mainstream view.
yes and no, the two big issues are that a) the SPA has to work within the very poorly documented render loop, for lack of a better term, of the browser and b) Javascript has some very idiosyncratic idiosyncracies and lacks some basic language functionality that is present in most languages
ok, if a div is added to the page body, and then another div is removed, what does the render loop do? any pointers to documentation are appreciated :)
