11 ms·

What's the issue with web components that they have never took off?

texodus 6y ago
My $0.02, this was mostly due to historical lagging a more out-of-the-box 'complete' solution like JSX/React, specifically in: (1) Poor native browser support until recently, Firefox originally refused to support Web Components v0 at all (now called Custom Elements in v1, they are supported in all evergreen browsers mostly). (1a) Available polyfills were initially buggy and had severe performance issues on older browsers. (2) Lack of proper templating, though I personally quite adore template literals and approaches like e.g. `lit-html`. (3) Lack of robust styling API - custom styles felt coarse and tacked on in v0 especially, and were poorly supported by pre-processors like LESS/SASS. (4) Lots of impedance mismatch issues connecting standard JS/HTML/CSS libraries with the Shadow DOM.
spankalee 6y ago
They have taken off. They're widely used for enterprises and design systems, and currently used on ~8% of all page views in Chrome.
FlorianRappl 6y ago
Besides the poor browser support (supporting IE11 is still quite a pain) the API is just so bad that you'll need another abstraction on top anyway. The main use right now is as target for framework independent design systems / component libraries.
- flowerlad 6y ago
  Here's an example of a Web Component: https://github.com/wisercoder/uibuilder/blob/master/WebComponentsDemo/elements/ZxListEditor.tsx https://github.com/wisercoder/uibuilder/blob/master/WebCompo... Looks pretty straightforward, and there isn't much of an API to begin with. It's just plain HTML, CSS, JavaScript and DOM APIs.
  - dmitriid 6y ago
    > It's just plain HTML, CSS, JavaScript and DOM APIs. Exactly. The entire history of web development has been about finding good abstractions around the horrendous DOM APIs. And that's before you start talking about the need to roll out your own solutions like state management for WebComponents.

My $0.02, this was mostly due to historical lagging a more out-of-the-box 'complete' solution like JSX/React, specifically in: (1) Poor native browser support until recently, Firefox originally refused to support Web Components v0 at all (now called Custom Elements in v1, they are supported in all evergreen browsers mostly). (1a) Available polyfills were initially buggy and had severe performance issues on older browsers. (2) Lack of proper templating, though I personally quite adore template literals and approaches like e.g. `lit-html`. (3) Lack of robust styling API - custom styles felt coarse and tacked on in v0 especially, and were poorly supported by pre-processors like LESS/SASS. (4) Lots of impedance mismatch issues connecting standard JS/HTML/CSS libraries with the Shadow DOM.

spankalee 6y ago

They have taken off. They're widely used for enterprises and design systems, and currently used on ~8% of all page views in Chrome.

FlorianRappl 6y ago

Besides the poor browser support (supporting IE11 is still quite a pain) the API is just so bad that you'll need another abstraction on top anyway. The main use right now is as target for framework independent design systems / component libraries.

flowerlad 6y ago
Here's an example of a Web Component: https://github.com/wisercoder/uibuilder/blob/master/WebComponentsDemo/elements/ZxListEditor.tsx https://github.com/wisercoder/uibuilder/blob/master/WebCompo... Looks pretty straightforward, and there isn't much of an API to begin with. It's just plain HTML, CSS, JavaScript and DOM APIs.
- dmitriid 6y ago
  > It's just plain HTML, CSS, JavaScript and DOM APIs. Exactly. The entire history of web development has been about finding good abstractions around the horrendous DOM APIs. And that's before you start talking about the need to roll out your own solutions like state management for WebComponents.