HTML with Superpowers: An Introduction to Web Components | Hacker News Reader

HTML with Superpowers: An Introduction to Web Components

htmlwithsuperpowers.netlify.app

155 pointslysergia126 comments

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

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

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

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.

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.

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.

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.

> we can't bear to work with native events, manage the dom, or build reactivity with proxies or subjects

I mean, you can do all that. And either spend your time writing tons of boilerplate code, or reinventing half of those frameworks and libraries anyway.

And still having to deal with issues like having to remember that they don't participate in forms (more JS to each component), that a11y can suddenly be broken (when your label references an element inside shadow dom), that wcs are not extensible to SVGs (which is important if your field is data visualisation) etc.

At which point you will go "why bother".

I wouldn't say that you need to reinvent any framework. I was able to build a simple application using HTMLElement directly. I just had to define a handful of utility functions to do things like escape HTML tags for user-generated content... The main critique I can think of is that Web Components provide many ways to do things; for example, you can create elements using vanilla JS or using template strings (or even a combination of both)... When it comes to event handlers; you can also define them using vanilla JS or inline inside the tags as part of the template string (or both). There is no single standard way to do anything so that was the real challenge but this can easily be solved through project-based coding style guidelines. There aren't that many gotchas.

> I wouldn't say that you need to reinvent any framework.

You do, when you need at least slightly more complex.

> The main critique I can think of is that Web Components provide many ways to do things

Nope. The main critique is that Web Components is 2010s tech solidified in the platform when the rest of the world has moved on and is now exploring fine-grained reactivity and trying to remove components as a unit of work/ui. That they are 12 years in the making and still have issues that no framework has (see links here: https://news.ycombinator.com/item?id=34346269). That their design now poisons the rest of the platform that needs to add countless new workarounds for their shortcomings, and seemingly unrelated standards (like scoped CSS) now have to take them into consideration...

Well, there is not just one main critique, there are many main critiques

> There aren't that many gotchas.

Just because you haven't run into them it doesn't mean there aren't any gotchas. And there are plenty.

are you normally a c# or a java coder?

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

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.

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.

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

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.

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

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.

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.

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.

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.

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.

Yeah, I don't see Shadow DOM often, but there are couple sites I use that employ it - most notably Gerrit. Since I use it almost every work day, I wanted to fix a bunch of UX annoyances it has. Those fixes would've normally been trivial, but Gerrit UI has everything wrapped in multiple levels of Shadow DOM, making those fixes near-impossible instead to do in Stylus alone.

Some combination of Tampermonkey, MutationObserver and IntersectionObserver almost always gets there in the end, but despite having a default user script template with this exact skeleton it's a lot more of a pain in the arse to achieve what a simple CSS selector and some properties does in a few lines...

Exactly. And for me, that difference in PITA is the difference between fixing up websites in Stylus incrementally, spending a couple minutes for a CSS rule or three when something annoys me, vs. making a note on my TODO list to write the necessary code later, and never getting around to doing it.

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.

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

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.

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.

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.

Esri’s Calcite Component library is another.

https://github.com/Esri/calcite-components

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.

VueJS actually fails some advanced tests for WebComponents: https://custom-elements-everywhere.com/

So, VueJS docs are actually incorrect when they say it scores 100%. The actual score is 91%.

I had reported this 8 months ago.

For people too lazy to look into what the issues are: lack of support for CAPScase, camelCase, and PascalCase DOM events. Only lowercase and kebab-case work.

Why is this getting downvoted? Did I miss something? I only found those 6 errors (each occurs in two tests, so 3 types)

Svelte will remove compiling to web components into a plugin.

In general, none of the major frameworks, and very few of the new frameworks use web components as a foundation for their functionality for many extensively described reasons that wc proponents literally couldn't care less about.

Microsoft has a library called FluentUI: https://learn.microsoft.com/en-us/fluent-ui/web-components/

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

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

Still the same issue though. What about Svelte? What about solid? What about mithril?

I know this might seem like a "who cares" sort of thing since the industry has standardized on the three listed, but I find all three overkill for a lot of things and, for example, keep my small projects in Mithril. But then I'm hit with either using Construct UI (which is honestly ok, this is all internal stuff), or having to make all the components myself.

What makes it such an impossibility for production? Even if, as in the case of Ionic, they provide web components but also wrap them up for React, Vue and Angular.

> I know this might seem like a "who cares" sort of thing since the industry has standardized on the three listed

It is that sort of thing and it breaks my heart that this is the case.

And yet, supporting solutions that would work with any front end solution and do so well without death by committee is some ways off, if not outright impossible.

It's very much the same way how I love Firefox but when >95% of your userbase is on Chrome, you need to pay additional attention to testing and compatibility against it.

It's also very much how many of the SaaS solutions or even self-hostable tools and such might have integrations for most of the popular languages/frameworks/libraries out there, yet keep the niche ones unsupported due to a lack of market share.

So for now, I'll just take what I can get, in lieu of better options.

Kor UI is an open source UI library, if you want to check: https://kor-ui.com/introduction/welcome

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

And here I am, just using vanilla JS to add functionality to default HTML. Recently did a few simple fetch and render functions and it worked fine. I guess if you go with large data structs it might be a different ball game I guess.

Can you explain how open-ui solves the problem? I went on the website, and to be fair I didn't really get it, but say for <breadcrumb /> component they give a proposal of what the HTML would look like in their proposed solution with nav, ok, li elements. How does this replace the idea of having a breadcrumb web component which is a higher level abstraction?

> Can you explain how open-ui solves the problem?

It doesn't solve the problem, but would solve the problem if it was started 10 or 20 years ago.

This is what needed in the browser: an actual properly specified comprehensive set of controls. Web Components are not it, as they continue re-inventing the wheel with the same components that libraries where defining since the dawn of the web: buttons, avatars, tabs etc. All of them different, all of them incomplete, all of them inaccessible etc.

> but say for <breadcrumb /> component they give a proposal of what the HTML would look like in their proposed solution with nav, ok, li elements. How does this replace the idea of having a breadcrumb web component which is a higher level abstraction?

Because if you go to any UI library for the web, it's one of the components almost everyone defines. As you can see in the research for each component. What does having it as a web component give you? Nothing. It gives you fifteen hundred different incompatible re-implementations [1]

Having a higher level abstraction you don't need to re-implement it, you don't have to to manually provide additional things (like accessibility hints etc.)

In general, if everyone attempts to implement the same elements in the browser, it makes sense to have them as a part of the platform, doesn't it?

[1] https://shoelace.style/components/breadcrumb, https://web-components.carbondesignsystem.com/?path=/story/c..., https://vivid.vonage.com/?path=/story/alpha-components-bread..., https://sap.github.io/ui5-webcomponents/playground/component..., https://ionicframework.com/docs/api/breadcrumbs ...

Ooooh I see. So the idea is to add all the extra (standardized) components to the browser itself! Yes, that is a worthy goal indeed.

My biggest gripe with web components is an inability to sandbox them. That forces me to put reusable "components" within iframes for security reasons.

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.

What do you mean? There are tons of these around. Are you complaining that none of them are popular enough?

None of them are standard. It should be baked into the cake. It's been a puzzler to me since I started programming over 20 years ago. Every third-party library existed basically just to provide a usable grid because most everything else was good enough. Combo boxes and date pickers too but those were less of a pain to implement.

There's various bits and pieces around the margins of grid/table/sorting that make it so it doesn't surprise me that it's not natively provided.

But the lack of a combobox in HTML, I don't get at all. datalist kind of sort of does it but not quite, plus it's inconsistently implemented as to what it actually shows.

The eventual aim of Open-UI is to establish a set of standard UI components like this.

> The purpose of Open UI to the web platform is to allow web developers to style and extend built-in web UI controls, such as <select> dropdowns, checkboxes, radio buttons, and date/color pickers.

> Today, component frameworks and design systems reinvent common web UI controls to give designers full control over their appearance and behavior. We hope to make it unnecessary to reinvent built-in UI controls

https://open-ui.org/

> None of them are standard.

If there were a standard, you'd probably still complain that it doesn't match your use-case.

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.

I assume that it's because there's basically no upper scope limit, and it's not obvious where the cut should be done.

Just take filtering - there are so many possibilities of how filters can look like, how can they be combined (AND, OR, nested) etc.

That. Basically a `f` in `filter(f, collection)` is code which can be arbitrary business logic.

Notion table seems to be close to generic. Basically let users provide a `f` in `filter(f, collection)`.

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)

Yep, though what I’m getting at is that those slots/parts better give you near-infinite flexibility. Because if you encounter a scenario where the slots don’t provide what you need, then you’re screwed.

Source: I fought with Ionic code for months over this. Really soured me on native encapsulation, but I see the benefits still. I just think it has to be approved very very very carefully.

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?

IMO they are complimentary to react.

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)

With exception of React, all those frameworks have options to generate WebComponents for their component model.

That is cool, didn't realize that! I wonder why React lags behind ( ? )

I think it is a culture issue, as far as I understand the underlying issue, the React community is not so impressed with having to deal with Web Components.

Realistically, there's almost no community that is impressed with having to deal with Web Components.

In this discussion I keep reiterating: there are multiple reasons why none of the major frameworks and very few of the new frameworks have WCs as their foundation. At best they can consume/embed them and perhaps compile to them. And even that is rife with problems.

If we ignore the fact that everyone else supports them, regardless if they are their foundation or not.

https://custom-elements-everywhere.com/

> everyone else supports them

That's what I said: At best they can consume/embed them and perhaps compile to them.

> regardless if they are their foundation or not.

And the fact that they are not forming the foundation of these frameworks should be examined and fixed, not ignnored. However, wc proponents ignore this entirely.

Maybe because those frameworks don't want to be rewritten from scratch?

It is like asking why so many graphics engines get written, instead of using raw OpenGL/Vulkan calls and extension spaghetti all over the place.

> Maybe because those frameworks don't want to be rewritten from scratch?

The absolute vast majority of new frameworks don't use web components as the foundation.

Perhaps instead of burying their heads in the sand people pushing web components would should finally start asking why?

Usually I use https://angular.io/guide/elements, https://vuejs.org/guide/extras/web-components.html#using-cus... or https://lit.dev/

I only need to ask why, when I have to deal with React based stuff.

AngularJS doesn't use web components as their foundation.

VueJS doesn't use web components as their foundation.

So you're not asking why. You're ignoring the question and burying your head in the sand.

Yeah, because yelling against Web Components in every forum thread is so much more productive.

We use them with the frameworks that have first class support, regardless if they are at their foundation or not.

Who is actually being ignored here?

> Yeah, because yelling against Web Components in every forum thread is so much more productive.

I'm not yelling. I'm pointing out facts.

> regardless if they are at their foundation or not.

So why are they not used as a foundation? Why are they used at best as a second class citizen? Why is it these frameworks don't produce web components by default?

> Who is actually being ignored here?

Framework authors, who have been pointing out the very many deficiencies and shortcomings for years. Most developers who need things like scoped CSS and open-ui.org more than fifteen hundred new standards, each requiring JS to work, barely.

I only see React framework authors ignoring Web Components.

Angular and Vue framework authors considered them good enough to spend development resources on adding support for Web Components, they didn't do it for fun and glory.

> I only see React framework authors ignoring Web Components.

See how you ignore everything I write even though I wrote it in the very first reply: "there are multiple reasons why none of the major frameworks and very few of the new frameworks have WCs as their foundation. At best they can consume/embed them and perhaps compile to them."

All you keep saying is "oh they support web components only react doesn't support that's the only question why"

Full on denial and ignorance.

Angular's "support", for example, is slapping on a wrapper, and ignoring everything about web components entirely by loading the angular runtime and everything else Angular behind the wrapper. But sure. Support.

Goes hand in hand with you ignoring that except for React, everyone else supports Web Components in some form, so that you can keep bashing them.

We are done here, it is quite clear were we stand.

See how you're completely blind to what I'm writing.

My very first comment says this:

- There are multiple reasons why none of the major frameworks and very few of the new frameworks have WCs as their foundation.

This is a fact

- At best they can consume/embed them and perhaps compile to them.

This is also a fact

Somehow you saw me saying "React" in there. Which says a lot about you.

> We are done here, it is quite clear were we stand.

Oh yes, it's crystal clear.

Web components seem like a good idea to me. I would imagine there are a lot of libraries out there (eg/ calendars, styling frameworks) that would benefit from reuse across applications. The browser could cache it even if served from a different CDN.

I'm curious what the problems are with web components that you see? Is it specifically related to how they might be used (or useless) in the major frameworks?

> I'm curious what the problems are with web components that you see?

Bitesized explanation from Rich Harris, the author of Svelte: https://twitter.com/Rich_Harris/status/1198332398561353728 It's from 2019, but all the issues are still there. When/If they are going to be solved, it will be by increasingly complex standards that require more and more Javascript for them to just barely function (like they couldn't even participate in form events without additional Javascript).

See also a larger discussion by the author of Solid: https://youtu.be/BEWkLXU1Wlc?t=5837 (if the link doesn't open at the timestamp, skip to "Failed Promise of Web Components" at 1:37:17). It's a bit rambling because it was unrehearsed and on stream, but still good. He also shows and discusses other articles like Rich Harris' https://dev.to/richharris/why-i-don-t-use-web-components-2ci... and his own https://dev.to/ryansolid/maybe-web-components-are-not-the-fu... You can read them directly, but Ryan gives excellent additional context.

Thanks for taking the time to find/share these links! Very informative.

It sounds to me like most of the criticism's outlined are solvable. Perhaps the people behind the standard should be engaging the framework community more.

I wonder if you think web components (and the problem they set out to solve) is wrong from a fundamental/architectural standpoint?

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.

Yeah, what I like about React is how declarative component writing is, and how you delegate state changes to escape hatches. Plain old HTML is supposed to be declarative but updating with vanilla JS quickly gets you into the weeds.

I tried to get into WebComponents, but the MDN tutorial has you writing a lot of `document.createElement` and `document.appendChild`, which is the sort of imperative stuff I don't like about vanilla JS DOM manipulation.

> delegate state changes to escape hatches

Ay.

Can you please explain what this means in simple, 5th grader English?

React says what things should be, given a limited state. (These elements read X, and update when X changes.)

Vanilla JS says how to do things (find these HTML elements and update them by doing X).

It is much simpler to track and mutate a state object, than it is to find all the nodes you need to update and update appropriately.

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!

No amount of documentation will help if React keeps acting as if Web Components don't exist.

Other than that, the website looks quite nice.

React 19 is likely to ship with Web Components support. https://github.com/facebook/react/issues/11347

That marketing copy ugh.

"New! Powerful!" It's neither

"Standard JS so it works where HTML works" says a lot about your experts

Thanks for the feedback! If you have the time, I'd love for you to contribute and improve the marketing copy: https://github.com/WebComponentsGuide/webcomponents.guide

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

Examine html source of such sites as github, youtube, redhat, adobe — you will find web components either sprinkled there or being a principal building block. They are certainly a workable solution.

> Examine html source of such sites as

Just because someone uses a technology, doesn't mean it's good. I could point to plenty of sites still using first versions of Angular. Is it workable? Yes. Is it good?

Also, I'd skip youtube as an example. No idea what incentives they had internally to re-write everything in web components, but they (and the web) paid dearly for it:

- Youtube was re-written in v0 of Custom Components. Which was deprecated as soon as they re-wrote it. Chrome couldn't remove v0 from the browser until Youtube was re-written (undoubtedly at great expense) with v1 four years later

- The polyfill for v0 was famously extremely slow in Firefox. Given that Youtube is one of the most popular websites (if not the most popular), you can imagine what it did to Firefox's image.

If you have an extra billion of dollars for such shenanigans, sure, knock yourself out (especially if it helps to cripple your competition).

Also IIRC GitHub is using React as well now, but I can't find the relevant link and discussion right now.

> Just because someone uses a technology, doesn't mean it's good.

At least it shows that the technology is both scalable and battle-tested.

> I could point to plenty of sites still using first versions of Angular. Is it workable? Yes. Is it good?

It's legacy, as I think we will both agree. Just as jQuery is, and just as React will become sooner or later. Meanwhile, web components are the browser standard, which means that they are a model of UI code encapsulation that is here to stay.

> Also IIRC GitHub is using React as well now, but I can't find the relevant link and discussion right now.

On their promo sites, yes. And maybe in the project management tools as well. Developers of the main site are heavily into web components.

> At least it shows that the technology is both scalable and battle-tested.

So are all other technologies used on the web sites. It still doesn't make it good.

You keep pretending that if something is used somewhere means it's good.

> It's legacy, as I think we will both agree. Just as jQuery is, and just as React will become sooner or later.

So what? Neither of these technologies have the laundry list of issues that web components have. And jQuery is still used on significantly more sites than React and Web Components combined. I'd bet on survival of jQuery more than on survival of Web Components.

> Meanwhile, web components are the browser standard, which means that they are a model of UI code encapsulation that is here to stay.

Unfortunately, yes. They are here to stay: a badly designed, barely working technology that needs increasingly complex and arcane hacks to make up for its deficiencies, sucking up human resources and making browser engines incomprehensibly complex. Oh, and they also infect other standards that have to cater to them now. E.g. Scoped CSS covers 80-90% of use cases WCs are used for, but now it has to be butchered to accommodate Shadow DOM.

But yeah. It's here to stay.

As Rich Harris, the author of Svelte said, "it's almost as if congealing 2010-era best practices in the platform before we'd finished exploring this territory was a mistake" [1]

There's a reason why very few, if any, of the major frameworks, and very few of up-and-coming web frameworks use web components as the foundation. Well, not one reason, but multiple extensively documented, discussed and debated reasons. However, WC proponents couldn't care less about these reasons because "but look, it's in the browser now".

So. What.

marquee was in the browser. Custom elements v0 was in the browser. Many things were, or indeed still are, in the browser. Doesn't make them good technology. We're here 12 years after they were introduced and they still have the issues that a non-wc library by even a first year CS student wouldn't have on the first try:

- form participation, "solved" by throwing more JS at the problem

- a11y boundaries, will through more JS at the problem when AOM arrives perhaps 10 years from now

- incorporating SVGs, will never be solved. That is, doing <svg><y-axis></y-axis><x-axis></x-axis></svg> will never be possible. Not an issue for literally any non-wc framework.

- SSR is barely solved by DSD if at all

- etc. etc.

And 12 years later people are actually exploring ideas without components as those are pure overhead: https://dev.to/this-is-learning/components-are-pure-overhead...

[1] https://twitter.com/Rich_Harris/status/1513668040784814084

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.

Yea, that’s been my biggest problem. The target is now different, so I can’t call event.target.value

Right, if you want `value` to be part of the public interface of your component you need to add a value property to expose it.

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.

But I just want to be able to specify a header or a footer in vanilla HTML...

What's stopping you? We've had flexbox and grid for quite a while now.

Pretty sure that you can't define an HTML snippet in one file and then include it in two or more other files using flexbox or grid? Or maybe I am wrong?

I do this using PHP. It gets the template file, the data and off you go.

Right- but you cant do it in plain HTML

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:

  <!DOCTYPE html>
  <html lang="en" class="no-js">

  <head>
    <!--#include virtual="/ssi/head.html" -->

    <title></title>
    <meta name="description" content="">
  </head>

  <body>

    <header>
      <!--#include virtual="/ssi/header.html" -->
    </header>

    <main>
    </main>

    <footer>
      <!--#include virtual="/ssi/footer.html" -->
    </footer>

  </body>

  </html>

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.

Unfortunately SSIs dont work on s3 and some other plaforms, thereby negating their utility for running static sites on CDNs or keystores. But YES- why isn't there an SSI equivalent in the HTML spec?

> why isn't there an SSI equivalent in the HTML spec?

Because HTML Imports died in the spec drafting process. Unless you want a client-side SSI equivalent that doesn't require any JavaScript, HTML Imports wasn't that. I'm not aware of an alternative proposal that doesn't.

https://www.w3.org/TR/html-imports/

https://webmasters.stackexchange.com/questions/127482/on-wha...

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.

This is just an ad for a course - can be removed.

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.

Marketing is one portion of web design.

At a lot of BigCos, the designs are supposed to be standard outside of the once in a generation refresh. One of the advantages of a big brand is a consistent, known quantity, and so things have to be harmonious; Starbucks is not out there making crazy new cups for every new drink they sell, every McDonald's location looks more or less the same, etc.

A lot of the variation we've seen in the early web was because web was something that a lot of people were outsourcing, but these days web is more integral, theoretically.

Yes. To my point and yours, SB's hero or product card can have exactly the same underlying markup as McDee's. Where those brands, and brands, are able to part is the CSS.

The irony is, marketing agencies that do web design work for multiple clients should be looking to leverage web component bricks. The majority I've seen, are not; at least not yet.

Eh, brands are internally consistent but rarely consistent with each other to the point where that would be less trouble than it’s worth. If you tell a client they’re not compatible with you, they’ll just find someone else to hire.

They're not deciding. The FE dev team is. Look at Bootstrap or Tailwind. Those tools have been adopted by many teams across many companies. A solid library of web components isn't going to be all that different. Who wants to reinvent the wheel then you can pull one off the shelf and get going?

There is not a single soul in marketing at any company - small or big - that's going to see, "Before you deploy I want to see the markup..." :)

Everyone (me included) is discussing web components, and no one is discussing the contents of the site itself:

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

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.

Still waiting for declarative (JS free) support in all browsers.

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.

Web Components were and still are a failure.

39$ per month? That's insane.

Reply on news.ycombinator.com