Just awful. 10 years in the making (if you can call endless bikeshedding committee meetings the "making" of anything) and still barely usable.<p>It offers nothing in way of ensuring that custom elements behave like builtin HTML elements. Half the elements I've come across will break or perform no-ops when you update an attribute or set a propety after it was attached to the DOM. Nevermind detaching and reattaching to the DOM, which will break virtually all of them (including my own sad contributions to this space).<p>The exception to this are those built using a 3rd party library like lit-element or stenciljs, which fill in the obvious omissions of these specs. Perhaps in another 10 years, a mangled version of half of one of them can be standardized? In the meantime, each component shipping its own frontend library or inlining the same core functions over and over again does nothing in the way of interoperability. You can bundle every popular JS framework and mix their components today. The reason you don't do it then or now is bloat, not the lack of a minimally viable shared component interface.<p>Besides, if you're going to use a 3rd party library and associated bundler/compiler, you might as well pick a good one such as React, Vue, Svelete, Solid or even jQuery UI. Using any of these, you can design and build an entire app faster than the bikeshedding commissars from goog and aapl can agree on whether "open" or "closed" should be the default for attaching a shadow DOM (at the risk of ruining the joke: there was no agreement; the developer has to provide a value in each instance...)
It obviously hasn't happened, but I hope that web components eventually make serious inroads. A UI library for React, Vue, Svelte, Solid, whatever... Imagine being able to have a component library that works with any of them (or none of them).<p>Since I really like mithril and there's one UI library, I've been playing with Shoelace and Crayons and they're pretty nice to work with, but I remain a bit puzzled why there's so few players in the space.
My biggest gripe with web components is an inability to sandbox them. That forces me to put reusable "components" within iframes for security reasons.<p>That said, generally speaking, web standards really suck at offering sandboxing capabilities for third party integrations.
Why is there no standard/widely used vanilla-js based webcomponent for creating a table with filtering+sorting+pagination? It's such a common and useful thing.
One of the problems with native encapsulation is that UI frameworks almost never fully satisfy the product requirements for a given application, so in some cases it’s always necessary to override either behavior or styling. If you remove that capability with a shadow DOM, you damn well better be sure that your abstraction is perfect.
I’ve been playing with webcomponents for a month or two and really love them. I do wish that IntelliJ would play nice with the formatting of them though.<p>Question: when and or if they gain in adoption, could you see them replacing react? If not, what’s the use-cases that you believe they wouldn’t work for?
I really hope some day we can appreciate that webcomponents are the best way to give users agency. Its an ok dev tool, but it takes so much invisible chaotic nonsense that JS does on modern sites & it can make it real, make it represented & visible & malleable on the site. It makes the web co-programmable, alike the better visions of what hypercard &al were maybe heading towards.<p>Treating the web as a low level platform that we can extense on top of, grow & further, with new, creative higher-level layers of hypermedia: that is a path to software with a soul, not just for big companies hacking out features, but genuine good for society. A malleable cohesive comprehendible connected information space.
Web components have their place but they're no panacea and the ecosystem is still pretty young. This is coming from someone that has been leading a decently large StencilJS web component project for over a year now.<p>Documentation and Google-ability of the subject isn't great so prepare to some digging and experimentation.<p>The current native feature set is somewhat lacking so you're definitely going to want to augment with some sort of helper framework/library. Building any significantly sized project purely native with vanillaJS would be challenging.<p>There are also some unique hurdles with this type of project that our org had to work through-mainly on the integration and design side of it.
I evaluated web components a few months ago. Everything was great except event propagation. Let’s say I have a component which is a DIV that wraps a label and an input. How can a consumer listen to the onchange event of the component which should map to the inputs onchange event. I could never come up with a holistic solution that would work for all components. It’d require a lot manual work mapping the input event to a new event that is triggered on the web component. I’d be interested if anyone found a better pattern
I'm optimistic about Web Components at the design/behavior level. It's nice to see us inching towards a world where the web stack has the native tools to handle all of the design/application responsibilities we've heaped on them at the right level of abstraction.<p>I did have some early hopes that it would also be a good way to enable content authors to coin and style markup within their posts/articles/etc., but the JS required makes me feel like it'll be too heavy for that use-case for most.
Lack of <import> ruins web components. Still need js to go fetch your component if you want it in a separate file. So you end up having to use webpack or whatever. Sigh.
I’m curious how often you encounter web designers with enough experience with CSS to make web components worthwhile but not enough “JavaScript know how” not to.
Everyone (me included) is discussing web components, and no one is discussing the contents of the site itself:<p>- extremely light on content<p>- goes out of its way to <i>not</i> present anything more complex than non-functional pieces of code or static examples<p>- while advertising that they are "easy to use", the Writing section immediately skips to comparing and using frameworks and libraries<p>- I guess is a front to get the courses at $39/month, but the only link is on the front page<p>This is a horrible, bad, no good resource that offers nothing of value.
Have been using Stencil.js extensively in recent months, and after understanding how it works, I find it a viable and indeed preferable alternative to using react. It has functional components, uses JSX, is based on top -> bottom propagation of state etc., but outputs a web component library that can be used without any dependencies except for the JS script tag.
I've found Web Components to be a very nice way of adding interactivity to a server-rendered application (e.g. server-side Blazor). Lit works quite well and has options to avoid an extra build step (<a href="https://lit.dev/docs/getting-started/#use-bundles" rel="nofollow">https://lit.dev/docs/getting-started/#use-bundles</a>)
Web Components are a good concept but the implementation is terrible even as designed. OOP JS is itself terrible, but the end result are files of thousands of lines where vanilla JS + html would require just a few. I'm currently working with lit, Web Components and TS and it feels like coding C# or Java.