5 ms·

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 nothin

by qwtel 4y ago

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...)

microflash 4y ago
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.
- dmitriid 4y ago
  > but it is still better than being in a continuous churn of UI frameworks. Is there a continuous churn? React is 10 years this year. Vue is 9 years. Angular which feels positively ancient is 7 years (if we only count Angular 2.x). Yes, there are newcomers like Svelte and Solid, but it's hardly a churn. Besides, they explore valuable corners that are left untouched and unexplored by other frameworks. Things like granular reactivity and removing components as a unit of UI in its entirety. Meanwhile the "non-churn" in web components has already resulted in two deprecated standards (custom elements v0, html imports), and is rapidly churning out dozens of new standards requiring more and more javascript to paper over their egregious design (form participation, constructible stylesheets, declarative shadow dom...)
  - microflash 4y ago
    There's definitely a churn in the frameworks like React, Angular, Vue, etc. New APIs, breaking changes, etc are certainly a thing every year. But as always, this is both downside and upside: you get great features and valuable advances at the cost of such rapid changes. The good news is that the tooling around the Web components is evolving even when the standard itself may moving at glacial pace.
    - dmitriid 4y ago
      React is compatible to its first version :) > The good news is that the tooling around the Web components is evolving You mean web components are growing their own frameworks at the same pace :) With new APIs and breaking changes In 12 years web components had: - original lib, polymer. Breaking changes 1.0-> 2.0, then completely deprecated - lit is 4 years old, already had breaking changes in each version update 1.0->2.0->3.0 (and "potential breaking changes" even in patch releases), and adds new APIs with every release - stencil is 5 years, has already had breaking changes in 1.0->2.0, but is probably the most stable of them all etc. Looks on par with the rest of the industry :) The sad thing is that web components as a standard don't allow is for actual iteration of ideas. While Solid, S, Marko et al are exploring granular reactivity, web components are stuck in 2010. And all the tools around them are doing what the rest of the tools have been doing for the DOM since time immemorial: invent new, better ways that are only hampered by the underlying platform.
AgentME 4y ago
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).
- mark_and_sweep 4y ago
  Take a look at Declarative Shadow DOM: https://github.com/mfreed7/declarative-shadow-dom https://github.com/mfreed7/declarative-shadow-dom This is basically the SSR spec for web components.
jongjong 4y ago
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.
- nathias 4y ago
  are you normally a c# or a java coder?
- tekkk 4y ago
  Are you serious? Using vanilla Web Components is just god awful and I can't recommend them to anyone with a straight face. Not having had experience with "normal" web frameworks like Svelte, React or Vue. You have to invent all your own wiring and passing of events, state-management et cetera if you go that route.
  - replygirl 4y ago
    it's not that much to invent. have frameworks really made it so easy that we can't bear to work with native events, manage the dom, or build reactivity with proxies or subjects? gp says there's a performance objective, sometimes it's worth building a solution that only does what you need edit: no one is saying a purpose-built framework needs to do everything that a mass-market framework ecosystem does. it's disingenuous to think there aren't circumstances it would make sense, not all of us make forms for a living.
    - tekkk 4y ago
      Hah hah. You make me laugh. Sure boss, not much. If you're doing it for fun and on your own time, okay. For real work, don't know who wants to pay you to invent your own framework.
    - dmitriid 4y ago
pjmlp 4y ago
Thanks to React, everyone else already has Web Components support built-in.
- azangru 4y ago
  This is wrong on so many levels :-) As of now, React is probably the only major frontend framework that doesn't interop well with web components, requiring various hacks for doing so. Proper support is hopefully coming in version 19. What you have with React is its own, React-specific way of encapsulating parts of UI into stateful functions that helps to think about them as components. And to have web components support built-in would mean to have them in the browser anyway, not in a third-party library.
  - pjmlp 4y ago
    They are already built-in, and if one doesn't like the boilerplate something like lit is enough. What WebComponents support in SPAs bring to the table is a migration path to native support.
dmitriid 4y ago
> 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. They do love working on standards though.
- Existenceblinks 4y ago
  I got tricked into following a standard (something something about data) and had read their github issues for 2 years! Omg such a waste of time they barely ship anything. Yes, they also write mediocre (or terrible) codes. I have to stop whining I'm getting mad .. was losing my years.
x98asfd 4y ago
>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.
lordgroff 4y ago
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.
Existenceblinks 4y ago
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.
- psygn89 4y ago
  One of the key goals in components is the ability to use it anywhere. Shadow DOM helps with that but also feels like a big thorn in the side for a lot of designers and developers to operate within. It makes more sense to design components this way when you're starting fresh and creating a library to be used anywhere. Controversially, I'd say it's often easier to just write CSS rules that fixes these conflicts and that the Shadow DOM is not really worth bending over for if you're designing within a controlled environment like your own product.
  - Existenceblinks 4y ago
    Even as a 3rd party, somehow reusability here strangely is in form of unconflict instead of shared functionality. Reusable should include customizable style, headless is probably even better. I think Custom element's light DOM with Bring-Your-Own-Style is better for party interop.
  - TeMPOraL 4y ago
    From the POV of a user, I consider Shadow DOM a menace, as it creates areas of the DOM that cannot be reached by CSS from outside - defeating my ability to fix UI blunders and bad design with a tailored userstyle.
    - spiralx 4y ago
      I hadn't considered that at all because they're so little used, but it would be an issue if they became so. I'm using Stylus for user styles nowadays which provides an option to allow you to target the CSS within an IFRAME using html[stylus-iframe$="twitter.com"] h1 { display:none } and I guess they could provide a similar sort of hack to select the Shadow DOM of an element to apply CSS e.g. .comment:shadow .title { font-size: 1.1rem; } Seems pretty likely to be be a performance hog to do that though.

by qwtel 4y ago

microflash 4y ago

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.

dmitriid 4y ago
> but it is still better than being in a continuous churn of UI frameworks. Is there a continuous churn? React is 10 years this year. Vue is 9 years. Angular which feels positively ancient is 7 years (if we only count Angular 2.x). Yes, there are newcomers like Svelte and Solid, but it's hardly a churn. Besides, they explore valuable corners that are left untouched and unexplored by other frameworks. Things like granular reactivity and removing components as a unit of UI in its entirety. Meanwhile the "non-churn" in web components has already resulted in two deprecated standards (custom elements v0, html imports), and is rapidly churning out dozens of new standards requiring more and more javascript to paper over their egregious design (form participation, constructible stylesheets, declarative shadow dom...)
- microflash 4y ago
  There's definitely a churn in the frameworks like React, Angular, Vue, etc. New APIs, breaking changes, etc are certainly a thing every year. But as always, this is both downside and upside: you get great features and valuable advances at the cost of such rapid changes. The good news is that the tooling around the Web components is evolving even when the standard itself may moving at glacial pace.
  - dmitriid 4y ago
    React is compatible to its first version :) > The good news is that the tooling around the Web components is evolving You mean web components are growing their own frameworks at the same pace :) With new APIs and breaking changes In 12 years web components had: - original lib, polymer. Breaking changes 1.0-> 2.0, then completely deprecated - lit is 4 years old, already had breaking changes in each version update 1.0->2.0->3.0 (and "potential breaking changes" even in patch releases), and adds new APIs with every release - stencil is 5 years, has already had breaking changes in 1.0->2.0, but is probably the most stable of them all etc. Looks on par with the rest of the industry :) The sad thing is that web components as a standard don't allow is for actual iteration of ideas. While Solid, S, Marko et al are exploring granular reactivity, web components are stuck in 2010. And all the tools around them are doing what the rest of the tools have been doing for the DOM since time immemorial: invent new, better ways that are only hampered by the underlying platform.

AgentME 4y ago

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).

mark_and_sweep 4y ago
Take a look at Declarative Shadow DOM: https://github.com/mfreed7/declarative-shadow-dom https://github.com/mfreed7/declarative-shadow-dom This is basically the SSR spec for web components.

jongjong 4y ago

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.

nathias 4y ago
are you normally a c# or a java coder?
tekkk 4y ago
Are you serious? Using vanilla Web Components is just god awful and I can't recommend them to anyone with a straight face. Not having had experience with "normal" web frameworks like Svelte, React or Vue. You have to invent all your own wiring and passing of events, state-management et cetera if you go that route.
- replygirl 4y ago
  it's not that much to invent. have frameworks really made it so easy that we can't bear to work with native events, manage the dom, or build reactivity with proxies or subjects? gp says there's a performance objective, sometimes it's worth building a solution that only does what you need edit: no one is saying a purpose-built framework needs to do everything that a mass-market framework ecosystem does. it's disingenuous to think there aren't circumstances it would make sense, not all of us make forms for a living.
  - tekkk 4y ago
    Hah hah. You make me laugh. Sure boss, not much. If you're doing it for fun and on your own time, okay. For real work, don't know who wants to pay you to invent your own framework.
  - dmitriid 4y ago

pjmlp 4y ago

Thanks to React, everyone else already has Web Components support built-in.

azangru 4y ago
This is wrong on so many levels :-) As of now, React is probably the only major frontend framework that doesn't interop well with web components, requiring various hacks for doing so. Proper support is hopefully coming in version 19. What you have with React is its own, React-specific way of encapsulating parts of UI into stateful functions that helps to think about them as components. And to have web components support built-in would mean to have them in the browser anyway, not in a third-party library.
- pjmlp 4y ago
  They are already built-in, and if one doesn't like the boilerplate something like lit is enough. What WebComponents support in SPAs bring to the table is a migration path to native support.

dmitriid 4y ago

> 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. They do love working on standards though.

Existenceblinks 4y ago
I got tricked into following a standard (something something about data) and had read their github issues for 2 years! Omg such a waste of time they barely ship anything. Yes, they also write mediocre (or terrible) codes. I have to stop whining I'm getting mad .. was losing my years.

x98asfd 4y ago

>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.

lordgroff 4y ago

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.

Existenceblinks 4y ago

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.

psygn89 4y ago
One of the key goals in components is the ability to use it anywhere. Shadow DOM helps with that but also feels like a big thorn in the side for a lot of designers and developers to operate within. It makes more sense to design components this way when you're starting fresh and creating a library to be used anywhere. Controversially, I'd say it's often easier to just write CSS rules that fixes these conflicts and that the Shadow DOM is not really worth bending over for if you're designing within a controlled environment like your own product.
- Existenceblinks 4y ago
  Even as a 3rd party, somehow reusability here strangely is in form of unconflict instead of shared functionality. Reusable should include customizable style, headless is probably even better. I think Custom element's light DOM with Bring-Your-Own-Style is better for party interop.
- TeMPOraL 4y ago
  From the POV of a user, I consider Shadow DOM a menace, as it creates areas of the DOM that cannot be reached by CSS from outside - defeating my ability to fix UI blunders and bad design with a tailored userstyle.
  - spiralx 4y ago
    I hadn't considered that at all because they're so little used, but it would be an issue if they became so. I'm using Stylus for user styles nowadays which provides an option to allow you to target the CSS within an IFRAME using html[stylus-iframe$="twitter.com"] h1 { display:none } and I guess they could provide a similar sort of hack to select the Shadow DOM of an element to apply CSS e.g. .comment:shadow .title { font-size: 1.1rem; } Seems pretty likely to be be a performance hog to do that though.