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.
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?
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.
> 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.
Not using it in anger in any prod system right now (finding the past, prior to AI, though), but all my side projects use it. Need to check and close any security issues this may have (not that I know of any yet. Should probably ask an LLM at some point about the danger of this).
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
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.
True, but at the same time if you're building an app the number of times when you think "I want to render this HTML without hooking it into the data store, other components on the page, data fetch layer, logging implementation, etc" is literally zero.
React can't do the thing people building apps with React never do is not an argument against React.
React is for building React apps, in case that wasn't obvious.
People who enjoyed riding horses in the past would not see the benefits of cars either.
Multi-pass rendering with multi-pass template placeholder substitution is very useful because you can have an entire complex component hierarchy declared in one place, very succinctly, in one file... Different components in the hierarchy can render data at any depth below them in the hierarchy (any level of nesting) without child components having to know about it. The child components just take the partially pre-filled template as their input and fill in remaining placeholders. The logic/markup is much more succinct and the components are much more flexible and composable. It promotes better separation of concerns.
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.
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.
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.
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.
I tried to embrace web components, but when I reached "declarative shadow DOM" I really just stopped seeing the point of all that complexity just to do what I can already do with a library. The target audience of that API seems to be library developers.
For web components to be consumable across frameworks, you still have to write it to be compatible for different frameworks. Our platform team thought they could get away with just focusing on native js, but when it came time to use in React, many behavioral approaches were incompatible. Dealing with re-renders would clear the state of the WC, losing all dropdown items. The toggle button had an infinite re-render glitch when combined with setState. We lost the ability to require event handlers, and prod had a few P0’s over unhandled click events.
The ideal was to be close to the browser, but it’s mostly blown up in our face. The approach in this post would’ve been helpful, and it’s almost worth the cross-framework compatibility, but I just wish the entire web components standard didn’t come with an unbelievable amount of these and other problems
My only issue with Web Components is that, by design, they need to be registered with a globally unique tagname and can't be unregistered.
It's a reasonable compromise given the original purpose of custom elements, but in practice it ends up more maintainable to be inspired by its structures without using real custom elements despite I was initially excited that jsdom supports custom elements nowadays.
Scoped custom element registries should help with this letting you register to a shadow root instead of globally. [1] Unfortunately Firefox hasn't come to the party yet. [2]
Seems unusual that a commit with the message "Fix broken URLs" stripped out multiple sections on performance from the FAQ [1]
- How does Elena compare against other tools? (Elena vs Lit, Elena vs Stencil, Elena vs Enhance)
- What is the performance like?
The removed sections were once so prominent they were linked from the home page, however that link was not removed along side the parts of the FAQ that were stripped so it's now broken [2].
28 comments
[ 0.24 ms ] story [ 79.4 ms ] threadAnother 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.
I went a similar way: https://github.com/lelanthran/ZjsComponent
Not using it in anger in any prod system right now (finding the past, prior to AI, though), but all my side projects use it. Need to check and close any security issues this may have (not that I know of any yet. Should probably ask an LLM at some point about the danger of this).
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;
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.
React can't do the thing people building apps with React never do is not an argument against React.
React is for building React apps, in case that wasn't obvious.
Multi-pass rendering with multi-pass template placeholder substitution is very useful because you can have an entire complex component hierarchy declared in one place, very succinctly, in one file... Different components in the hierarchy can render data at any depth below them in the hierarchy (any level of nesting) without child components having to know about it. The child components just take the partially pre-filled template as their input and fill in remaining placeholders. The logic/markup is much more succinct and the components are much more flexible and composable. It promotes better separation of concerns.
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.
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.
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
The ideal was to be close to the browser, but it’s mostly blown up in our face. The approach in this post would’ve been helpful, and it’s almost worth the cross-framework compatibility, but I just wish the entire web components standard didn’t come with an unbelievable amount of these and other problems
It's a reasonable compromise given the original purpose of custom elements, but in practice it ends up more maintainable to be inspired by its structures without using real custom elements despite I was initially excited that jsdom supports custom elements nowadays.
[1]: https://developer.mozilla.org/en-US/docs/Web/API/Web_compone...
[2]: https://bugzilla.mozilla.org/show_bug.cgi?id=1874414
- How does Elena compare against other tools? (Elena vs Lit, Elena vs Stencil, Elena vs Enhance)
- What is the performance like?
The removed sections were once so prominent they were linked from the home page, however that link was not removed along side the parts of the FAQ that were stripped so it's now broken [2].
[1]: https://github.com/arielsalminen/elena/commit/2982c0f79ea113...
[2]: https://elenajs.com/#:~:text=Read%20how%20Elena%20compares%2...