Just awful. 10 years in the making (if you can call endless bikeshedding committee meetings the "making" of anything) and still barely usable.
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).
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.
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...)
I used Web Components (HTMLElement) recently and did not encounter any of these issues. I found it more snappy and reliable than frameworks like React or VueJS in terms of adding and removing components dynamically.
I did find that it provides a lot more flexibility than front end frameworks (more ways to make mistakes?) and the code was more verbose.
If I had to start a project from scratch today, I would consider going straight for Web Components.
There's also a lack of standard server-side-rendering support. From last I looked at it, some of the web component libraries have their own SSR support, but that only works with web components authored with that specific library, negating the supposed universal compatibility of web components, and they involve using heavyweight simulated DOM libraries on the server. I'm not going to bother with something that doesn't take SSR seriously when React aces that so well (especially with the newer server components support) among other things (like giving you a code model that ensures by default that updating a prop at runtime causes the same result as setting it on creation).
> 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
Because very few of the people developing web standards are web developers. And of those who are very few have done anything of note in the past 20 years or more.
In almost a decade I never understand why anyone would use Shadow DOM. What's the point of scoped style solution here. Why can't I just™ <tag adoptedstyle="style.css">styff</tag>? .. admittedly I never scope style because I never have to add 3rd party components with style in it.
>Just awful. 10 years in the making (if you can call endless bikeshedding committee meetings the "making" of anything) and still barely usable.
This seems like the norm for tech now days. A lot of meeting and work and nothing major or significant really gets done. Seems like the the whole industry is about making it easier and simpler for new developers to get develop.
Regarding React, ES should just stick and simplify E4X that would just really make all these front end lib not necessary.
I don't get this comment. I don't care if a usable web component is built with stencil, lit or not, what I care about is that I can use that same library WHETHER I'm using React, Vue, Svelte, Solid or whatever.
I've been working with webcomponents for a while. I agree that ergonomics are horrible (particularly when it comes to state management and style inheritance) but it is still better than being in a continuous churn of UI frameworks.
Unfortunately, it is the same churn that has vastly improved the ergonomics for many UI frameworks while we're stuck with the terrible workflows for authoring web components.
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).
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.
Stencil and consequently Ionic are all Web Component based.
Svelte fully supports compiling to Web Components with 100% test coverage.
Vue fully supports Web Components as well, the only issue I've run into there is with CustomEvent.detail not being copied into the Vue event payload properly.
Web Components are widely used on the web, just under the covers sometimes.
> 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).
That seems to be a worthy goal, but I don't see that being usable in prod projects, at least not in the near future.
The closest I've seen is something like PrimeFaces, which has components for Angular, React and Vue, which is the majority of projects I've seen out there: https://www.primefaces.org (I've also used the Java JSF variety, it was... sometimes problematic)
If you need something that works the same (or as close as you can get) across multiple front end frameworks/libraries, while still having most of the components you could possibly want, I don't think there are many other options out there.
> 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).
You don't need web components for that. You need https://open-ui.org (started, of all people, by Microsoft). Unfortunately Google et al are too busy sinking hundreds of millions of dollars and countless man-hours into web components (with no final goal in mind and increasingly arcane and complex workarounds for their deficiencies) to be interested in this.
> but I remain a bit puzzled why there's so few players in the space.
In which space?
In UI libs for the web? There are thousands, all busy re-implementing the same dozen-or-so primitive controls.
In UI libs for web components? Because they are a badly designed tech that still requires you to reinvent the same dozen-or-so primitive controls and combat the issues of styling, a11y, no SSR etc. that they bring.
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.
Possibly the same reason there's no standard way to get a file browsing widget from a linux native applications, despite it being 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.
That’s what CSS parts and slots are for. Your component can style its own boundaries, provide parts to allow customisation, and use slots to inject components that are styled from outside (be it another ShadowDOM or the light DOM)
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.
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?
Anywhere you actually need React (and also React lite solutions like Preact or Alpine), which is essentially where your page isn't just a static page, web components by themselves don't do anything to handle the complexity of state. But what they allow you to do is to use the same component in whatever framework you pick.
Frameworks like react/angular/backbone/vue solve the problem of creating a single page application with a nice architecture and sharing code between components within the SPA.
Web components solve the problem of sharing code between any application.
There are opportunities to share code (eg/ data binding) and I believe that is the case (they use the same underlying browser APIs where available)
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.
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.
Documentation and Google-ability of the subject isn't great so prepare to some digging and experimentation.
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.
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’ve been working on https://webcomponents.guide/ with some fellow experts in order to improve the documentation side of things. Hoping to offer guidelines and best practices to limit the amount of searching and experimentation required. Please take a look and provide feedback if you can!
> Web components have their place but they're no panacea and the ecosystem is still pretty young.
And yet wc proponents keep pushing them as if they were panacea.
And "ecosystems is young" is a funny statement for something that is entering its 12th year of development (and fifth year of wide availability in browsers).
> The current native feature set is somewhat lacking so you're definitely going to want to augment with some sort of helper framework/library.
If any of the existing solutions had the same amount of issues that wcs have, they would never have gotten of the ground. And yet here we are 12 years and hundreds of millions of dollars of effort later
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
That's handled by shadow dom event retargeting. When the events pass over the boundary of the component the target becomes the component itself instead of the input.
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.
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.
Although not vanilla HTML, server side includes are the closest to this that we've got. I use them quite extensively. This is basically what my boilerplate looks like:
I'll put all my favicon, CSS, and other common head data in the /ssi/head.html file. Nice and simple and good enough for me. Can make it even more minimal by moving the <header> and <footer> tags into their respective SSI files.
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.
You'll likely still need someone with sufficient JS skills. The key will be for the designers to think in such terms (i.e., components).
In nearly every (marketing) agency I've worked at, the designers envisioned themselves as creatives. "Boundaries? Not us. We live outside the box..." Trying to get them to understand you can have the same underlying structure and just bend it with CSS wasn't something they've wanted to imagine. The idea of reusing (read: not creating from scratch) isn't in their DNA.
Again, this isn't all web designers. But marketing agencies do a lot of non-enterprise design and dev.
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 (https://lit.dev/docs/getting-started/#use-bundles)
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.
qwtel|3 years ago
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).
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.
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...)
jongjong|3 years ago
AgentME|3 years ago
dmitriid|3 years ago
Because very few of the people developing web standards are web developers. And of those who are very few have done anything of note in the past 20 years or more.
They do love working on standards though.
Existenceblinks|3 years ago
x98asfd|3 years ago
This seems like the norm for tech now days. A lot of meeting and work and nothing major or significant really gets done. Seems like the the whole industry is about making it easier and simpler for new developers to get develop.
Regarding React, ES should just stick and simplify E4X that would just really make all these front end lib not necessary.
lordgroff|3 years ago
microflash|3 years ago
Unfortunately, it is the same churn that has vastly improved the ergonomics for many UI frameworks while we're stuck with the terrible workflows for authoring web components.
pjmlp|3 years ago
lordgroff|3 years ago
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.
claytongulick|3 years ago
Svelte fully supports compiling to Web Components with 100% test coverage.
Vue fully supports Web Components as well, the only issue I've run into there is with CustomEvent.detail not being copied into the Vue event payload properly.
Web Components are widely used on the web, just under the covers sometimes.
KronisLV|3 years ago
That seems to be a worthy goal, but I don't see that being usable in prod projects, at least not in the near future.
The closest I've seen is something like PrimeFaces, which has components for Angular, React and Vue, which is the majority of projects I've seen out there: https://www.primefaces.org (I've also used the Java JSF variety, it was... sometimes problematic)
If you need something that works the same (or as close as you can get) across multiple front end frameworks/libraries, while still having most of the components you could possibly want, I don't think there are many other options out there.
For example:
- Angular calendar: https://www.primefaces.org/primeng/calendar
- React calendar: https://www.primefaces.org/primereact/calendar/
- Vue calendar: https://www.primefaces.org/primevue/calendar
nileshtrivedi|3 years ago
lscharen|3 years ago
https://github.com/Esri/calcite-components
dmitriid|3 years ago
You don't need web components for that. You need https://open-ui.org (started, of all people, by Microsoft). Unfortunately Google et al are too busy sinking hundreds of millions of dollars and countless man-hours into web components (with no final goal in mind and increasingly arcane and complex workarounds for their deficiencies) to be interested in this.
> but I remain a bit puzzled why there's so few players in the space.
In which space?
In UI libs for the web? There are thousands, all busy re-implementing the same dozen-or-so primitive controls.
In UI libs for web components? Because they are a badly designed tech that still requires you to reinvent the same dozen-or-so primitive controls and combat the issues of styling, a11y, no SSR etc. that they bring.
leoff|3 years ago
apatheticonion|3 years ago
That said, generally speaking, web standards really suck at offering sandboxing capabilities for third party integrations.
unknown|3 years ago
[deleted]
colecut|3 years ago
The_Colonel|3 years ago
Just take filtering - there are so many possibilities of how filters can look like, how can they be combined (AND, OR, nested) etc.
PaulDavisThe1st|3 years ago
buildingsramen|3 years ago
unknown|3 years ago
[deleted]
Existenceblinks|3 years ago
danielvaughn|3 years ago
Keithamus|3 years ago
_boffin_|3 years ago
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?
lordgroff|3 years ago
asurty|3 years ago
Frameworks like react/angular/backbone/vue solve the problem of creating a single page application with a nice architecture and sharing code between components within the SPA.
Web components solve the problem of sharing code between any application.
There are opportunities to share code (eg/ data binding) and I believe that is the case (they use the same underlying browser APIs where available)
rektide|3 years ago
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.
misterbwong|3 years ago
Documentation and Google-ability of the subject isn't great so prepare to some digging and experimentation.
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.
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.
Keithamus|3 years ago
dmitriid|3 years ago
And yet wc proponents keep pushing them as if they were panacea.
And "ecosystems is young" is a funny statement for something that is entering its 12th year of development (and fifth year of wide availability in browsers).
> The current native feature set is somewhat lacking so you're definitely going to want to augment with some sort of helper framework/library.
If they are lacking, have glaring unsolved issues, https://twitter.com/Rich_Harris/status/1198332398561353728), and you still need to augment them with a framework/library,... what's the point then?
If any of the existing solutions had the same amount of issues that wcs have, they would never have gotten of the ground. And yet here we are 12 years and hundreds of millions of dollars of effort later
logankeenan|3 years ago
esprehn|3 years ago
abathur|3 years ago
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.
fergie|3 years ago
VoodooJuJu|3 years ago
tiagod|3 years ago
foobarbecue|3 years ago
POPOSYS|3 years ago
hyperhello|3 years ago
chiefalchemist|3 years ago
In nearly every (marketing) agency I've worked at, the designers envisioned themselves as creatives. "Boundaries? Not us. We live outside the box..." Trying to get them to understand you can have the same underlying structure and just bend it with CSS wasn't something they've wanted to imagine. The idea of reusing (read: not creating from scratch) isn't in their DNA.
Again, this isn't all web designers. But marketing agencies do a lot of non-enterprise design and dev.
dmitriid|3 years ago
- extremely light on content
- goes out of its way to not present anything more complex than non-functional pieces of code or static examples
- while advertising that they are "easy to use", the Writing section immediately skips to comparing and using frameworks and libraries
- I guess is a front to get the courses at $39/month, but the only link is on the front page
This is a horrible, bad, no good resource that offers nothing of value.
globalise83|3 years ago
rado|3 years ago
metta2uall|3 years ago
nathias|3 years ago
unknown|3 years ago
[deleted]
lloydatkinson|3 years ago
WhiteBlueSkies|3 years ago