top | item 28697562

(no title)

CapitaineToinon | 4 years ago

There is this article (https://dev.to/richharris/why-i-don-t-use-web-components-2ci...) by Rich Harris, creator of Svelte which explains pretty well why he personally doesn't use web components.

discuss

order

ravenstine|4 years ago

I feel like everyone has the wrong idea about web components. Perhaps it's in the name. There's no "WebComponent" class on the window object, but there is an HTMLElement you can extend and a `window.customElement` registry for tagName invocation, a thing called a shadow root, and so forth. Those are all things that I am glad exist. If I thought of them grouped together as "Web Components" and compared that to components in frontend JavaScript frameworks then yeah, I guess I'd be disappointed. Otherwise, the people who say they "don't use" web components are being as unreasonable as it would be to say to not use the `<video>` element because it doesn't support all the things that `<canvas>` does with some 3rd party library for compositing.

Custom elements are awesome for small things that don't need to appear in an SSR context (assuming you're using shadow DOMs). No, they don't support composable stylesheets, whatever those even are, but seriously, who really needs them? If what you are doing is complicated enough that the browser's native APIs are too obtuse then yeah go for something like React or Svelte. No matter what, there's going to be something that someone's JavaScript library is going to do better than the browser. I'd use uncommon browser and language features if they made sense for a task.

The `<template>` and `<slot>` elements are really dopey and hard to understand. That's where something like React or Svelte comes in. Nobody would use either of those libraries if they didn't have better templating than the browser.

dmitriid|4 years ago

> I feel like everyone has the wrong idea about web components.

What is the idea behind Web Components? Does anyone have an idea of what they are, should be, and where they are going? They've been around for 10 years now. Google has poured literally millions of dollars into trying to make them happen.

If people still "have the wrong idea about web components", it's a testament to their failure.

> Otherwise, the people who say they "don't use" web components are being as unreasonable as it would be to say to not use the `<video>` element because it doesn't support all the things that `<canvas>` does with some 3rd party library for compositing.

Well, no. People who say "don't use web components" are very much aware about the fact that web components:

- at the core are 4 different standards. One of them is already fully deprecated (HTML Imports). The other one already has a deprecated and removed version (Custom Elements v0)

- introduced so many problems by simply existing that Google (primarily Google) has been pumping out literally thousands of pages of new specs just to fix the problems that web components created.

Problems: https://dev.to/richharris/why-i-don-t-use-web-components-2ci... and https://news.ycombinator.com/item?id=28697664. And new specs? Oh, they are introducing their own new problems: https://news.ycombinator.com/item?id=28698563

- have an API that is both too high level and too low level to be usable.

It's too low level and too verbose, so after several years of promoting them as "the be all end all components for the web" the narrative shifted to "it's just an API for library authors, you're not supposed to use them by hand". It's unusable at any significant scale. Google's own AMP has switched to using Preact to author their components because they couldn't bear it anymore.

It's too high level, so in the 10 years of its existence there are hardly any libs and frameworks that have adopted Web Components as the foundation. And even the new ones tend to skip Web Components. Well, most libs and frameworks can compile to Web Components, and can consume Web Components. But hardly any framework actually uses them as a foundation.

Well, I've linked to the dozens of problems that they introduce, so no wonder.

- "Custom elements are awesome for small things that don't need to appear in an SSR context"

that don't need an SSR context, that don't need a11y, that don't need to split SVGs, that don't need...

Too many "don't needs" for a tech that has seen millions of dollars poured into it, and 10 years of development. After all that it's still "it's awesome for small things". Only for small things.

Meanwhile, w3c has unveiled its own design system here: https://design-system.w3.org It uses SASS and it uses a third-party library to, quote, "enhance a <select> into and accessible auto-complete via JavaScript."

Imagine if millions of dollars and countless man-hours poured into Web Components were instead directed to make CSS better, to enhance the crappy built-in controls etc.? Oh, you'd have a better web, and not an "awesome for small things with dozens of problems".

> No matter what, there's going to be something that someone's JavaScript library is going to do better than the browser.

Ah yes. I remember someone calling jQuery "the disappearing framework". Because its eventual goal is to be fully replaced by browser APIs.

It looks like Web Components' motto is "there's always someone doing stuff better in Javascript, so why bother, let's be crap".

> Nobody would use either of those libraries if they didn't have better templating than the browser.

Nope. People are using them not because of templating alone.