9 ms·

HTML with Superpowers: An Introduction to Web Components

155 points by lysergia 4y ago

apatheticonion 4y 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.
- deleted 4y ago
  [deleted]
rado 4y ago
Still waiting for declarative (JS free) support in all browsers.
hyperhello 4y 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.
- chiefalchemist 4y 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.
  - bobthepanda 4y 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.
    - chiefalchemist 4y ago
      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.
      - bobthepanda 4y ago
        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.
        chiefalchemist 4y ago
        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..." :)
fergie 4y ago
But I just want to be able to specify a header or a footer in vanilla HTML...
- tiagod 4y ago
  What's stopping you? We've had flexbox and grid for quite a while now.
  - fergie 4y 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?
    - prox 4y ago
      I do this using PHP. It gets the template file, the data and off you go.
      - fergie 4y ago
        Right- but you cant do it in plain HTML
- VoodooJuJu 4y 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>  <title></title> <meta name="description" content=""> </head> <body> <header>  </header> <main> </main> <footer>  </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.
lordgroff 4y 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.
- lscharen 4y ago
  Esri’s Calcite Component library is another. https://github.com/Esri/calcite-components https://github.com/Esri/calcite-components
- claytongulick 4y 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.
  - nileshtrivedi 4y ago
    VueJS actually fails some advanced tests for WebComponents: https://custom-elements-everywhere.com/ 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.
    - Semaphor 4y 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.
      - Semaphor 4y ago
_boffin_ 4y ago
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?
- asurty 4y 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)
  - pjmlp 4y ago
    With exception of React, all those frameworks have options to generate WebComponents for their component model.
    - asurty 4y ago
      That is cool, didn't realize that! I wonder why React lags behind ( ? )
      - pjmlp 4y ago
        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.
        dmitriid 4y ago
        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.
rektide 4y ago
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.
logankeenan 4y 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
- esprehn 4y ago
  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.
  - logankeenan 4y ago
    Yea, that’s been my biggest problem. The target is now different, so I can’t call event.target.value
    - esprehn 4y ago
      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.
colecut 4y ago
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.
- buildingsramen 4y ago
  What do you mean? There are tons of these around. Are you complaining that none of them are popular enough?
  - kgwxd 4y 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.
    - zerocrates 4y ago
      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.
    - jamessb 4y ago
      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/ https://open-ui.org/
    - tiborsaas 4y ago
      > None of them are standard. If there were a standard, you'd probably still complain that it doesn't match your use-case.
danielvaughn 4y 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.
- Keithamus 4y 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)
  - danielvaughn 4y 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.
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...)
- 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.
abathur 4y ago
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.
misterbwong 4y 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.
- Keithamus 4y ago
  I’ve been working on https://webcomponents.guide/ 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!
  - dmitriid 4y ago
    That marketing copy ugh. "New! Powerful!" It's neither "Standard JS so it works where HTML works" says a lot about your experts
    - Keithamus 4y ago
      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 https://github.com/WebComponentsGuide/webcomponents.guide
  - pjmlp 4y 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.
foobarbecue 4y 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.
nathias 4y ago
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.
dmitriid 4y ago
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.
POPOSYS 4y ago
This is just an ad for a course - can be removed.
globalise83 4y 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.
WhiteBlueSkies 4y ago
39$ per month? That's insane.
deleted 4y ago
[deleted]
metta2uall 4y 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 https://lit.dev/docs/getting-started/#use-bundles)
lloydatkinson 4y ago
Web Components were and still are a failure.

155 points by lysergia 4y 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.

deleted 4y ago
[deleted]

rado 4y ago

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

hyperhello 4y 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.

chiefalchemist 4y 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.
- bobthepanda 4y 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.
  - chiefalchemist 4y ago
    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.
    - bobthepanda 4y ago
      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.
      - chiefalchemist 4y ago
        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..." :)

fergie 4y ago

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

tiagod 4y ago
What's stopping you? We've had flexbox and grid for quite a while now.
- fergie 4y 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?
  - prox 4y ago
    I do this using PHP. It gets the template file, the data and off you go.
    - fergie 4y ago
      Right- but you cant do it in plain HTML
VoodooJuJu 4y 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>  <title></title> <meta name="description" content=""> </head> <body> <header>  </header> <main> </main> <footer>  </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.

lordgroff 4y 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.

lscharen 4y ago
Esri’s Calcite Component library is another. https://github.com/Esri/calcite-components https://github.com/Esri/calcite-components
claytongulick 4y 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.
- nileshtrivedi 4y ago
  VueJS actually fails some advanced tests for WebComponents: https://custom-elements-everywhere.com/ 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.
  - Semaphor 4y 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.
    - Semaphor 4y ago

_boffin_ 4y ago

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?

asurty 4y 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)
- pjmlp 4y ago
  With exception of React, all those frameworks have options to generate WebComponents for their component model.
  - asurty 4y ago
    That is cool, didn't realize that! I wonder why React lags behind ( ? )
    - pjmlp 4y ago
      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.
      - dmitriid 4y ago
        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.

rektide 4y ago

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.

logankeenan 4y 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

esprehn 4y ago
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.
- logankeenan 4y ago
  Yea, that’s been my biggest problem. The target is now different, so I can’t call event.target.value
  - esprehn 4y ago
    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.

colecut 4y ago

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.

buildingsramen 4y ago
What do you mean? There are tons of these around. Are you complaining that none of them are popular enough?
- kgwxd 4y 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.
  - zerocrates 4y ago
    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.
  - jamessb 4y ago
    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/ https://open-ui.org/
  - tiborsaas 4y ago
    > None of them are standard. If there were a standard, you'd probably still complain that it doesn't match your use-case.

danielvaughn 4y 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.

Keithamus 4y 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)
- danielvaughn 4y 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.

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

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.

abathur 4y ago

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.

misterbwong 4y 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.

Keithamus 4y ago
I’ve been working on https://webcomponents.guide/ 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!
- dmitriid 4y ago
  That marketing copy ugh. "New! Powerful!" It's neither "Standard JS so it works where HTML works" says a lot about your experts
  - Keithamus 4y ago
    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 https://github.com/WebComponentsGuide/webcomponents.guide
- pjmlp 4y 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.

foobarbecue 4y 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.

nathias 4y ago

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.

dmitriid 4y ago

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.

POPOSYS 4y ago

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

globalise83 4y 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.

WhiteBlueSkies 4y ago

39$ per month? That's insane.

deleted 4y ago

[deleted]

metta2uall 4y 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 https://lit.dev/docs/getting-started/#use-bundles)

lloydatkinson 4y ago

Web Components were and still are a failure.