If browsers provided data binding and reactivity out of the box, frameworks and applications would be much faster and lighter.
Whenever a feature gets added to standard HTML, web frameworks and "polyfills" keep implementing their own versions because the standards don't fit them and they don't want to rewrite (or keep their own implementation as a mere fallback).
Even if a data binding framework would be standardized today, it would take years for browsers to catch up and gain critical mass. There'd only be more polyfills and Javascript to help support people running IE11 or whatever.
I'm glad many JS features have been implemented natively in HTML5, but this specific case feels overkill to me. HTML templates have been introduced and then ignored by frameworks already and I doubt any framework would switch over to a new data binding API if it became a standard today.
I mean... maybe in some legacy plugins that budget-shops drop into a Wordpress site without thinking. This stuff doesn't really happen anymore in real projects; there's not much point.
> Whenever a feature gets added to standard HTML, web frameworks and "polyfills" keep implementing their own versions because the standards don't fit them and they don't want to rewrite (or keep their own implementation as a mere fallback).
I think you misunderstand what polyfills are. Polyfills exist as an implementation of the standard, before the standard has been fully supported. They get stripped out when possible. In no way are they "their own version" of the standard.
> Even if a data binding framework would be standardized today, it would take years for browsers to catch up and gain critical mass.
It definitely wouldn't. All major browsers get silent auto-updates now, and Chromium alone has over 75% of the market share now that Edge is based on it. Google was the one pushing web components in the first place, and today Firefox and Safari would face pressure to keep up lest they lose ground when more sites become "just for Chrome". The silver lining of the browser monoculture is that features get implemented quickly.
> There'd only be more polyfills and Javascript to help support people running IE11 or whatever.
Possibly. But in today's world polyfills are less and less necessary (see my previous statement). Most companies these days just write off IE and outdated browsers as not worth bothering with. And for all those other browsers, there would be a dramatic drop in the amount of Javascript.
> HTML templates have been introduced and then ignored by frameworks already
HTML templates are the prime example of how useless the web component standard is in its current form: they literally just hold DOM nodes. Those DOM nodes can't appear on the page without being cloned by JavaScript. They gain no special functionality. They just sit there. Templates without databinding are hardly better than an HTML string.
That's the idea, but many projects never actually remove the polyfills once browsers catch up to a given standard. In theory they solve the problem, but in practice I'm still ending up downloading polyfills on Firefox and Chrome because Safari doesn't support a particular API. Sure, the code barely executes, but the bandwidth is wasted regardless.
> It definitely wouldn't. All major browsers get silent auto-updates now [..]
Tell that to mobile Safari. Updates are packed into OS updates and features regularly take ages to be implemented. One day we'll get WebP and notification support. One day...
> Templates without databinding are hardly better than an HTML string.
Templates without databinding provide everything you need to render a component; structured elements that can be filled out with code. With class names and query selectors they can be filled and rendered very quickly with little code and no need for a framework.
Using the API properly can ensure that inserted text is never seen as code, making it free of the injection attacks that HTML string replacing often exposes. Content and structure are clearly separated and provide no challenges for the browser to parse. Generated components are always well-formed, which string replacement also doesn't guarantee, modification of contents is no different from regular DOM updates.
Maybe in some experimental project, but I've never seen this in any video site.
> input elements such as calendar controls are rewritten
Yes, because the native browser widgets are totally insufficient and can't be styled.
> animations are done in JS instead of smooth CSS transitions
JS animation can be super fast (see GSAP) and it seems you're talking about jQuery.animate() which I agree was terrible. But these days most people use CSS animations.
> drag and drop support is manually rewritten in JS
Again, because the browser does not have a proper drag and drop API to do it. I know because I've had to implement drag and drop many times. From vanilla, to jQuery, to React... for mouse and touch UIs.
Here's another huge thing lacking in the browser world: touch gestures.
I don't want them to be styled, thank you very much.
> JS animation can be super fast (see GSAP) and it seems you're talking about jQuery.animate() which I agree was terrible. But these days most people use CSS animations.
GSAP is giving me stuttery animation when I scroll through their website on my phone, presumably because it's constantly updating the DOM to keep control of the animation. It's not as bad as the state of JS animation was 10 years ago, but I can think of very few use cases where such a library would actually be necessary instead of using pre-calculated CSS transitions and such.
> Again, because the browser does not have a proper drag and drop API to do it.
I haven't had that much trouble when I had to use the HTML5 DnD API. Well, not more than with the frameworks I've seen; touch screen DnD support sucks on all platforms I've tried.
Popular browsers such as Firefox and Safari don't have native date controls: https://caniuse.com/input-datetime