HTML with Superpowers: An Introduction to Web Components | Better HN

HTML with Superpowers: An Introduction to Web Components | Better HN

126 comments

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

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.

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

are you normally a c# or a java coder?

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

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

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

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

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

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.

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

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

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

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

pjmlp3y ago

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.

lordgroff3y ago

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.

claytongulick3y ago

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.

nileshtrivedi3y ago

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.

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.

> 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

lordgroff3y ago

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.

nileshtrivedi3y ago

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

Esri’s Calcite Component library is another.

https://github.com/Esri/calcite-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).

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.

lordgroff3y ago

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?

prox3y ago

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.

leoff3y ago

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

apatheticonion3y ago

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.

The_Colonel3y ago

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.

Existenceblinks3y ago

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

PaulDavisThe1st3y ago

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.

buildingsramen3y ago

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

kgwxd3y ago

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.

Existenceblinks3y ago

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

danielvaughn3y ago

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.

Keithamus3y ago

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)

danielvaughn3y ago

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?

lordgroff3y ago

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.

bobthepanda3y ago

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.

asurty3y ago

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)

pjmlp3y ago

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

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.

misterbwong3y ago

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.

Keithamus3y ago

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!

pjmlp3y ago

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.

That marketing copy ugh.

"New! Powerful!" It's neither

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

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

logankeenan3y ago

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.

logankeenan3y ago

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

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.

fergie3y ago

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

VoodooJuJu3y ago

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.

fergie3y ago

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?

tiagod3y ago

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

fergie3y ago

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?

foobarbecue3y ago

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.

hyperhello3y ago

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.

chiefalchemist3y ago

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.

bobthepanda3y ago

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.

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.

globalise833y ago

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.

rado3y ago

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

metta2uall3y ago

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.

lloydatkinson3y ago

Web Components were and still are a failure.

WhiteBlueSkies3y ago

39$ per month? That's insane.

j / k navigate · click thread line to collapse