re: Why I don't use web components VIEW POST

TOP OF THREAD FULL DISCUSSION
re: 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 in...
 

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..

code of conduct - report abuse