Rendered at 06:01:19 GMT+0000 (Coordinated Universal Time) with Cloudflare Workers.
akst 4 hours ago [-]
I think it's better to think of "Web components" as "Custom Elements" they really aren't components in the way you think of components in other frameworks (which on the web introduced them first), and I think most of the dissatisfaction with them comes from trying pretend they're an alternative as they just aren't. Components in almost every other framework are efficient (efficient rendering runtime) and expressive (the ability not to have a root element but instead a frag, or context APIs etc) in ways that web components never will be, which makes them unappealing.
But when you think of them as a suite of APIs to define custom elements, that can coexist with your framework components, this delimma goes away.
I do think it's a-shame that modern frameworks don't better support shadow dom and local styles, and local events. Understandably I also get why they also don't see that as a good use of their time either, it adds complexity to the runtimes, they need to observe events at multiple root nodes.
Besides the cost of implementation and commitment to additional complexity, assuming that was a nonissue, with the exception of those otherwise legitimate reasons, there's no technical limitation that prevents React from supporting shadow roots for arbitrary custom element. I made a proof of concept of this myself seems to work quite nicely with a stylesheet loader hook (which ensured it was loaded once and there was a shared sheet between all instances of the same element), but I had to start observing events in each elements shadow root.
troupo 3 minutes ago [-]
Support for anything web components-related is a death by a thousand cuts both for the browsers and for the framework authors.
For the browsers:
Shadow dom breaks almost literally everything. It's a parallel world that exists on its own and that needs dozens of additional web standards to patch holes introduced by it. And delays dozens of useful web standards that now have to be aware of it.
On top of that nothing in web components is ever created thinking even one step ahead, and break multiple pieces of basic functionality. It's a collection of barely fitting patches. E.g. at first they couldn't send data in forms. Enter FormData. Oops, still cannot be a custom form submit button. Here's a 7-year old still unresolved issue: https://github.com/WICG/webcomponents/issues/814
For frameworks:
Framework authors have to patch all thise holes on their own. Because unlike web components they actually do care about standards and browser functionality. If styles don't work, forms din't work, code doesn't work etc. because of web components, it's the framework that will be blamed.
I think also the lack of framework support for things like defining a shadow root probably feeds into this idea it needs to be mutually exclusive.
Elements in shadow root elements can be updated more or less the same way as elements in light doms with incremental patches and updates.
The main beneficiary of supporting shadow root and local stylesheets would likely be hobbyist projects looking to minimise their build step, as local stylesheets give you much of the benefits of many of the tools that handle localising a stylesheet to a component at build time.
Unfortunately, I haven't really seen numbers on this but I can't help but I feel the way styles are bundled by most modern bundlers (with global styles and minified classNames) will likely outperform a bunch of disparate components with their own individual local stylesheet with its own request (even with http2 or whatever). So again I can see why the framework maintainers may struggle justify spending time and energy on this.
hyperhello 8 hours ago [-]
One fun thing I did once is use the custom elements API to make a custom tag <element-template>. When the page sees <element-template tag=what-name></element-template>, it looks inside, finds any <template></template> <script></script> and <style></style> tags, and builds a new custom element with that tag name and all the powers. Cool but not incredibly simple.
Another amazing trick is to put a mutation observer on the page to detect <template> tags as they're created. (template tags parse the HTML within but don't actually create it on the page). Once the observer finds a template tag it can upgrade them to have new powers, like replacing the contents of other tags. There are ways to tame web components and make them very easy to use.
Anyone doing anything interesting to use CSS libs like Bulma, Bootstrap with web components? Definitely feels like swimming against the tide. Got a hobby project in Lit.js, can't easily wrap (e.g.) `.btn` in a component without breaking styles because the component root/host ends up between `.btn-group` and `.btn`. One can manually add classes to the root/host but that only gets you so far. Ideally I could select when to render a root and I vaguely remember that Lit allows this but I don't remember figuring this one out.
socketcluster 6 hours ago [-]
Web Components are great for doing multi-pass rendering with template placeholder substitution happening at multiple levels in the component hierarchy. The entire element HTML hierarchy can be declared in one place. It's extremely versatile.
React cannot do this. It's difficult to explain without writing a whole essay but the benefits are very clear once you try this approach.
zelphirkalt 8 hours ago [-]
The HTML + CSS first approach and JS only for enrichment sounds great, and like what should be done anyway. I wonder though, how it will play out in reality. Will web developers using this library make the effort to keep essential functionality JS free, if possible, and provide additional views using whatever web framework they use, or will they implement essential functionality as "JS enrichment", requiring JS for things that do not actually need to be done in JS at all?
microflash 7 hours ago [-]
In reality, building anything complex is a huge pain using web components, particularly because it is hard to author them with appropriate level of styling API and accessibility support. In my experience, web components are fantastic for consumers but terrible for the authors.
Still, the advantages are clear: they don’t need any special runtime and can be used with other JS frameworks.
Another thing in favor of web components is support for custom registries which make gradual migration from one version to another trivial. AFAIK, no JS framework has an equivalent of custom registries.
claytongulick 5 hours ago [-]
Try keeping them in the light dom.
Everything works like normal html + css, but you get all the benefits of reusability and encapsulated script logic.
Lit-html (the library, not the framework) gives this approach super rendering speed too.
Kuyawa 6 hours ago [-]
I like web components, the simpler the better, so I like what I see but having a strong OCD about syntax I just want to propose the use of <Button ... instead of <elena-button ...
It's just a matter of using a regex [1] and making your syntax more palatable
HTML is case insensitive, so <Button> is the same as <button>, and custom element names must have a hyphen.
Your component regex represents a JSX limitation, but web components do not need React. Plus, if you capitalize the first letter, JSX would treat it as a React component rather than a web component (i.e. custom native HTML elements)
steren 5 hours ago [-]
I don't understand your proposal
Customer elements MUST have an hyphen.
<Button> is the same as <button> in HTML
okzgn 4 hours ago [-]
The syntax looks very similar to Lit, but it's a nice application of HTML & CSS first, instead of relying entirely on JS to do that.
shinryuu 4 hours ago [-]
When you built this you probably were aware of lit. How does Elena differ from lit?
strix_varius 8 hours ago [-]
Hm, the page is unreadable on brave on dark mode.
socketcluster 6 hours ago [-]
[flagged]
6 hours ago [-]
6 hours ago [-]
shevy-java 8 hours ago [-]
Ok but ... why? With that I mean, why do we need it? What can be created with PWC specifically? Is there a gallery of web games? That would at the least make understanding the use case easier.
You can create anything and everything. Web components are about extending html to make it do more, progressive web components are about rendering that on the server and progressively enhancing with interactivity in the browser. Elena solves the major pain points in doing that. Components built this way can be used in any framework.
But when you think of them as a suite of APIs to define custom elements, that can coexist with your framework components, this delimma goes away.
I do think it's a-shame that modern frameworks don't better support shadow dom and local styles, and local events. Understandably I also get why they also don't see that as a good use of their time either, it adds complexity to the runtimes, they need to observe events at multiple root nodes.
Besides the cost of implementation and commitment to additional complexity, assuming that was a nonissue, with the exception of those otherwise legitimate reasons, there's no technical limitation that prevents React from supporting shadow roots for arbitrary custom element. I made a proof of concept of this myself seems to work quite nicely with a stylesheet loader hook (which ensured it was loaded once and there was a shared sheet between all instances of the same element), but I had to start observing events in each elements shadow root.
For the browsers:
Shadow dom breaks almost literally everything. It's a parallel world that exists on its own and that needs dozens of additional web standards to patch holes introduced by it. And delays dozens of useful web standards that now have to be aware of it.
On top of that nothing in web components is ever created thinking even one step ahead, and break multiple pieces of basic functionality. It's a collection of barely fitting patches. E.g. at first they couldn't send data in forms. Enter FormData. Oops, still cannot be a custom form submit button. Here's a 7-year old still unresolved issue: https://github.com/WICG/webcomponents/issues/814
For frameworks:
Framework authors have to patch all thise holes on their own. Because unlike web components they actually do care about standards and browser functionality. If styles don't work, forms din't work, code doesn't work etc. because of web components, it's the framework that will be blamed.
It doesn't help that there's an insane amount of work involved in figuring out all the ways they are broken. See for example: https://xcancel.com/Rich_Harris/status/1841467510194843982#m
Elements in shadow root elements can be updated more or less the same way as elements in light doms with incremental patches and updates.
The main beneficiary of supporting shadow root and local stylesheets would likely be hobbyist projects looking to minimise their build step, as local stylesheets give you much of the benefits of many of the tools that handle localising a stylesheet to a component at build time.
Unfortunately, I haven't really seen numbers on this but I can't help but I feel the way styles are bundled by most modern bundlers (with global styles and minified classNames) will likely outperform a bunch of disparate components with their own individual local stylesheet with its own request (even with http2 or whatever). So again I can see why the framework maintainers may struggle justify spending time and energy on this.
Another amazing trick is to put a mutation observer on the page to detect <template> tags as they're created. (template tags parse the HTML within but don't actually create it on the page). Once the observer finds a template tag it can upgrade them to have new powers, like replacing the contents of other tags. There are ways to tame web components and make them very easy to use.
React cannot do this. It's difficult to explain without writing a whole essay but the benefits are very clear once you try this approach.
Still, the advantages are clear: they don’t need any special runtime and can be used with other JS frameworks.
Another thing in favor of web components is support for custom registries which make gradual migration from one version to another trivial. AFAIK, no JS framework has an equivalent of custom registries.
Everything works like normal html + css, but you get all the benefits of reusability and encapsulated script logic.
Lit-html (the library, not the framework) gives this approach super rendering speed too.
It's just a matter of using a regex [1] and making your syntax more palatable
Regardless, kudos for the release
* const componentRegex = /<%[ ]+([A-Z][a-zA-Z0-9])([^%]?)%>/g;
Your component regex represents a JSX limitation, but web components do not need React. Plus, if you capitalize the first letter, JSX would treat it as a React component rather than a web component (i.e. custom native HTML elements)
Customer elements MUST have an hyphen.
<Button> is the same as <button> in HTML
You can create anything and everything. Web components are about extending html to make it do more, progressive web components are about rendering that on the server and progressively enhancing with interactivity in the browser. Elena solves the major pain points in doing that. Components built this way can be used in any framework.