The standard is the web platform itself. That's the only standard that will ever be followed to any meaningful degree.
Much of the needless splintering we see today can be traced back to having too many mutually-incompatible reactive rendering systems. If you make a button in React, even though I'd like the exact same button in my Vue app, I can't use it because it's rendered via a different API.
The core barrier here comes down to the different templated-rendering systems. What we need is a browser standard for templated/reactive rendering of DOM content (data + template = DOM). The <template> element doesn't count because it doesn't actually do anything. Web components are nearly useless without having a story for reactive rendering.
Beyond just compatibility this would give web apps a massive performance boost, in terms of both CPU cycles and initial payload size. It's long past due.
> The core barrier here comes down to the different templated-rendering systems.
This shouldn't be a barrier at all. The rendering system a component uses should be an entirely encapsulated implementation detail of the component. Components should absolutely not have to use the same template system to be used together.
This is something web components get very, very correct.
> Web components are nearly useless without having a story for reactive rendering
There are libraries that address just that specific need, like lit-html which I maintain. Again, it's an implementation detail of the component.
> What we need is a browser standard for templated/reactive rendering of DOM content (data + template = DOM)
While rendering should be an implementation detail, I still agree with you here, simply because templating is such a universal need that the platform should provide some primitives to help developers.
The main idea is that it lets you mark up a <template> with references that will be cloned along with the template contents. These references can then be used to dynamically update the cloned instance. You can accelerate most template systems with these primitives. It's critical because the DOM doesn't have any other way to clone a chunk of DOM along with references to specific nodes in that tree without manually walking the clone's tree.
'rendering should be an implementation detail', right so I need to download 3 overly complicated template engines for every website instead of one? Seems like modern UI dev is just nuts...
You can attempt to standardize all you want, the problem is that some companies wanted to put things on their rails and not share the controls...vs just enhancing html itself as was done in past. But SPAs are not documents, modern web is nothing but highly optimized UI delivery, not fast UI nor descriptive UI.
Seems... a bit misguided of an effort when the SPA makers are not clamoring for change and things largely 'work' from a dev perspective already.
About once every six months I’ll come across a problem, think of possible solutions, think it will be impossibly complicated, remember XForms exists, remember it wasn’t as easy as it needed to be last time (usually a mobile related issue), research the current state... and walk away full of disappointment.
XForms was a brilliant idea and a perfectly acceptable technology to solve extremely useful but mostly boring business type problems that never caught on... probably because of the boring / business type feel.
But there are glimmers of hope, https://enketo.org Enketo looks like it’s turning into a pretty good backend agnostic option for developing with XForms which is one of the usual issues... there are quite a few XForms options out there but many require the use of specific server side tool chains.
This division isn't unexpected. Compare the Mac OS toolbox and the Windows API for UI elements. UI's widget toolkits are built atop the graphics and input APIs below them and tend to end up tightly interwoven (and the projects that attempt to provide a spanning set of widgets across different graphics / input UIs seem to tend to end up looking like a lowest-common-denominator solution with the clock rolled all the way back to the late '80s / early '90s concept of what "good UI" looks like).
Much of the needless splintering we see today can be traced back to having too many mutually-incompatible reactive rendering systems. If you make a button in React, even though I'd like the exact same button in my Vue app, I can't use it because it's rendered via a different API.
The core barrier here comes down to the different templated-rendering systems. What we need is a browser standard for templated/reactive rendering of DOM content (data + template = DOM). The <template> element doesn't count because it doesn't actually do anything. Web components are nearly useless without having a story for reactive rendering.
Beyond just compatibility this would give web apps a massive performance boost, in terms of both CPU cycles and initial payload size. It's long past due.