Looking at the history of Custom Elements we can analyze few facts: the initial momentum, brought by Chrome and advocated through Polymer, was based on V0 API and also built-in extends most successful stories, including or , were based on V0 AFrame AMP when V0 got killed, V1 discussed, and built-ins re-factored- from Polymer, developers still believing in standards understood the feature was not stable and started looking at every Web framework that meanwhile solved through built-in elements all major devs painful points out Even if agreed between more browsers vendors, the V1 API left web developers with tons of issues that were previously, somehow, solved: classes such HTMLInputElement started breaking once extended the createdCallback got removed, leaving developers incapable of finding, in a reliable way, an entry point to simply initialize their components what was well understood and advocated as progressive enhancement, through built in extends, became a nightmare full of issues for transpilers, polyfills, older browsers, etc. Everyone had to re-implement the wheel through a meaningless HTMLElement base class that was bringing in nothing different than what a MutationObserver could’ve done already everything problematic on the Web remained the same, but new not-polyfillable “ ” such ShadowDOM landed on developers’ shoulders features To me, V0 API was the classic example that is better than , but also that (and V1 is everything but perfect anyway). pragmatic perfect pragmatic works Instead, in 2018, the most basic/needed specification out of Web Components is still under development and quite fragmented beside few exceptions: Chrome has nativecustomElements with built-in support Chrome also still has V0 document.registerElement around has native customElements with built-in support today Firefox yesterday Firefox never had custom elements at all (or behind a “broken flag” full of hidden issues) AFAIK, MS with built-in support Edge is developing Custom Elements Safari, and WebKit based browsers, has native customElements since long time but without built-in support …but what is that all the browsers have in common since ever? Built-in Elements Without even waiting a single day for custom elements to land on the Web, all successful, sometimes heavy, but super dev friendly frameworks, based their success on regular DOM elements such _DIV_s, _BUTTON_s, _TABLE_s, you name it. Yes, once everything boils down to an over-polluted page full of _DIV_s that “ ”, one starts wondering if Web Components have ever been an answer or, if that’s the case, what is it that such specification exactly solved. just works As of today, it surely caused an ulcera to my liver due the amount of time, stress, and discussions I’ve had since day 0 about this topic with other developers involved with this standard and its implementation. I was so happy about CE potentials that I’ve even brought CEs down to IE8! The mandatory Shadow DOM failure I think Shadow DOM is the reason #1 Web Components never shined. Even if very good in theory, the reality about Shadow DOM is the following one: impossible to reliably polyfill (and super heavy/slow if you try) no way to simplify styles definition (discussed these days after years of “ ”) developers will figure it out the only way to date to simplify styles definition within the Shadow DOM is considered wasteful, slow, unnecessary overhead. if you add slots in the mix, it’s a whole new mess to find the right moment to understand how to deal with these, because the lifecycle of a Custom Element is known only at its opening, but nobody knows when the component is ready (discussed these days after years of “ ”) developers don’t need to know this as last nail in the coffin, Shadow DOM cannot be rendered on the server, hence neither delivered from the server Accordingly, if you ever waited for Shadow DOM to land everywhere so you can start using Web Components, keep looking around at how much fun other developers are having instead, with their components solution based on regular built-in elements. It’s literally that ! easy peasy lemon squeezy And more often than it should, that also makes me wonder if I’m even stupid in just waiting for standards to become a reality … I mean, in general … It’s time to move forward with built-in extends Since at least two major browser vendors decided that custom elements built-in extend are OK, and Chrome and Firefox cover the majority of the users, and since the only one strongly opposed to custom elements built-in delivers the fastest and most expensive Hardware out there (yeah, that’s Apple), so that a tiny patch won’t hurt at all in the real world, it’s time to move on and re-write the history of custom elements once again, this time doing what is the most natural thing to do, something that gives developers pseudo shadow DOM out of the box ( , , , , ), something that implements accessibility out of the box, and something that works from the most ancient browser to the most modern one, without fearing JS incompatibilities. input button table select checkbox Strawberry on top, it’s something any Server Side Rendering can deliver. The built-in element patch Fully based on native customElements implementation, is a polyfill that , it leaves Chrome and Firefox completely untouched, and it uses modern features on Safari, which is why it’s so lightweight. built-in element weights less than 1 Kb All other old or browsers will also be unaffected, thanks to the , the one that AMP and AFrame use too, which already provides custom elements and built-in capabilities. not-there-yet document-register-element polyfill <script> if (!this.customElements) document.write('<script src="//unpkg.com/document-register-element"><\x2fscript>'); </script> Explained in my , above technique won’t ever affect modern browsers neither and it will always work in old one. bloatless Web post And because document-register-element is , and since the part of built-in-element would basically run only in Safari, or even Edge if they decide to not implement built-in for the time being, you can be sure this solution works from IE9 to latest Chrome, passing through even Android 2 phones, covering more than most FWs. based on ES3 compatible syntax eventually transpiled Can you click it? That’s it, you’re good to go. Is the button text blue? The overhead is minimal for modern browsers, and identical for battle tested old browsers so that starting from now, every browser, and every server, can deliver custom elements built-in. Yes, even your framework of choice 🎉 … but what exactly do built-in extends solve? when the component is ready, it’s alredy initialzied. Less code, less bootstrap, you focus as example on what an input does, not what it should contain and what aria attribute should use to be accessible and behave like an input. You use. a bloody. input. all built-in functionalities and methods work out of the box. You extend real built-in classes instead of extending HTMLElement only. All accessors will work as expected, and so everything else that’s natively there all default styles are already applied. HTMLDivElement is already block, HTMLSpanElement isn’t. you have the same extendibility than you had before but it will work even with browsers that don’t support JavaScript you don’t create wrappers/containers for the sake of it, with the need to inject at distance nodes or Shadow DOM with nodes, you use the minimum amount of needed DOM nodes to deliver your project. That means lighter pages, lighter DOM trees, lighter Internet. you have a stronger way to style your components via [is="my-element"] without needing Shadow DOM. If you fear other selectors might be stronger deliver !important all over and call it a day: it works!!! Otherwise add inline style: it works!!! Otherwise … well, you got it, there are various solutions, and none of them requires Shadow DOM polyfills. … but I still want Shadow DOM If you keep it simple … repeat with me … if you keep it very simple, you can forget heavy polyfills that are not super reliable and use simple solutions such but I still suggest, for any other case, to consider using instead the approach: that would rarely fail any expectation. attachshadow built-in-element
![Building A Flutter Video Sharing App With Firebase Storage, HLS & Client-Side Encoding [Tutorial]](https://cdn.filestackcontent.com/yapkAlG2SKmB4janCVLq?auto=format&fit=max&w=3840)
