It just blows my mind that after all these years, the very obvious problem that you stated yourself: "But it's hard to overstate what an awkward interface it is for building interactive applications."
has not been tackled.
The browser was made to display hypertext media. The DOM was based on that idea.
If we want interactive apps in the browser, why isn't there an alternative to the DOM for interactive apps? Why isn't there a DOMv4?
Why can't we let go of HTML as the outer shell of an application?
We are down to 2 or 3 major browser engines. Time to renovate.
30+ years of tech, retired from an identity intelligence company, now part-time with an insurance broker.
Dev community mod - mostly light gardening & weeding out spam :)
Late to the argument here, but this is the first comment that I understood (not a front-end dev, grokked HTML when it was introduced, backed away for many years..have never used a JS framework/extension/component/whatever or browser API in anger).
It really feels like modern front end development is struggling to escape the document-oriented world of HTML, but has a paranoid fear of shipping code to customers. There have been several attempts in the past to ship portable code under the radar: Shockwave Flash, ActiveX (I lied about portability), Java Applets, Java Web Start, then it seems we got by with ECMAscript and ever-growing numbers of cross-browser APIs, but in that world we're stuck with the DOM, or going it alone in a Canvas?
Perhaps we'll see something akin to the X11/Wayland shift - the old API is too painful and we reach mass adoption of systems that are happy to do everything in OpenGL/3D rendering (three.js and similar are very performant these days), perhaps Web Assembly will help this along.. and folks can finally ship unfettered GUI apps & frameworks that work exactly as they wish - written in their preferred language.. in effect the browser has become a means to ship a runtime (could just as easily be Java, ECMA-335/.NET, WebAssembly, ECMA-262/JS), with a well-defined set of rules to load applications dynamically over a network. It's this last point that makes all the difference between joy and terror for users!
Is it time to re-think the structure of these beasts? Take the network loading rules (almost there with Fetch API I think) and package them up with the chosen runtime, then plug in an HTML renderer on the side, for those few occasions when a plain document arrives?
I'll stop ruminating at this point..
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
It just blows my mind that after all these years, the very obvious problem that you stated yourself: "But it's hard to overstate what an awkward interface it is for building interactive applications."
has not been tackled.
The browser was made to display hypertext media. The DOM was based on that idea.
If we want interactive apps in the browser, why isn't there an alternative to the DOM for interactive apps? Why isn't there a DOMv4?
Why can't we let go of HTML as the outer shell of an application?
We are down to 2 or 3 major browser engines. Time to renovate.
Late to the argument here, but this is the first comment that I understood (not a front-end dev, grokked HTML when it was introduced, backed away for many years..have never used a JS framework/extension/component/whatever or browser API in anger).
It really feels like modern front end development is struggling to escape the document-oriented world of HTML, but has a paranoid fear of shipping code to customers. There have been several attempts in the past to ship portable code under the radar: Shockwave Flash, ActiveX (I lied about portability), Java Applets, Java Web Start, then it seems we got by with ECMAscript and ever-growing numbers of cross-browser APIs, but in that world we're stuck with the DOM, or going it alone in a Canvas?
Perhaps we'll see something akin to the X11/Wayland shift - the old API is too painful and we reach mass adoption of systems that are happy to do everything in OpenGL/3D rendering (three.js and similar are very performant these days), perhaps Web Assembly will help this along.. and folks can finally ship unfettered GUI apps & frameworks that work exactly as they wish - written in their preferred language.. in effect the browser has become a means to ship a runtime (could just as easily be Java, ECMA-335/.NET, WebAssembly, ECMA-262/JS), with a well-defined set of rules to load applications dynamically over a network. It's this last point that makes all the difference between joy and terror for users!
Is it time to re-think the structure of these beasts? Take the network loading rules (almost there with Fetch API I think) and package them up with the chosen runtime, then plug in an HTML renderer on the side, for those few occasions when a plain document arrives?
I'll stop ruminating at this point..