3 ms·
I love seeing a wider adoption of webcomponents, but I have some complaints about this library, mainly because they're really pushing the whole, "lightweight an
by jjcm 6y ago
I love seeing a wider adoption of webcomponents, but I have some complaints about this library, mainly because they're really pushing the whole, "lightweight and low memory" lines.
Take a look at the accordian component (the very first one in their system) and check it out in the dom inspector - it has a shadowroot that has precisely one child: a <slot> element. In this situation a shadowroot does nothing to help. All it means is instead of just creating children for the element, you have to create them and add "slot='item'" to all of them. Shadowroots are great when you need encapsulation of styles or static non-content UI, but with this outer element neither of those are true. There isn't any additional UI, nor styles. This is something I see a lot in lazy libraries - they automatically create a separate dom tree even if it isn't needed whatsoever.
This tells me either the library requires this every time (going against the "lightweight / low memory" motto), or the developer for this one didn't have enough understanding of when to use shadowroots.
That's not to say this is all bad though - their design system tokens are really nice and provide a lot of flexibility. I'll probably emulate a lot of them for the next webcomponent based design system I'm working on. Their algorithmic color palettes are interesting, but so far I've never found a solid algorithmic color generator - color is simply too tied to trends and too subjective to be algorithmically made. Curious to see it work in practice, and a shame they don't provide examples of it.
- infogulch 6y agoTo clear my understanding of your first statement, you're saying that their "lightweight / low memory" claim is invalidated by components having one unnecessary level of nesting in DOM?
- jsf01 6y agoNo. They’re saying that it’s creating an entirely separate DOM tree unnecessarily by using shadow DOM where it isn’t needed. On a related note, I’m curious if anyone has a benchmark comparing performance and memory consumption when attaching a shadow root vs not.
- jjcm 6y agoIt's more than one unnecessary level of nesting in the DOM, it's that they're creating an entirely separate DOM tree they aren't using. I threw together a test using tachometer to demonstrate the differences: https://github.com/jjcm/shadowTests https://github.com/jjcm/shadowTests The results are here: https://raw.githubusercontent.com/jjcm/shadowTests/master/result.png https://raw.githubusercontent.com/jjcm/shadowTests/master/re... TL;DR - the withShadow element takes about twice as long to render as the withoutShadow element. Don't use them unnecessarily.
- WorldMaker 6y ago> Shadowroots are great when you need encapsulation of styles or static non-content UI, but with this outer element neither of those are true. There isn't any additional UI, nor styles. To my understanding of these components, because they are meant to be styled by the user or a downstream design system the component authors don't know ahead of time where style encapsulation needs to happen, so this approach makes sense for that.
- jjcm 6y agoFor sure, and that's a pretty cool feature of this library. Nonetheless they should be checking whether or not there are included templates/designs before generating the shadowroot. I put together a small demo of this in action: https://github.com/jjcm/shadowTests/blob/master/withOptionalShadow.html https://github.com/jjcm/shadowTests/blob/master/withOptional... The results speak for themselves: https://raw.githubusercontent.com/jjcm/shadowTests/master/resultsForOptionalCreation.png https://raw.githubusercontent.com/jjcm/shadowTests/master/re... Creating a shadowroot conditionally has nearly equivalent performance to no shadowroot at all, but always creating a shadowroot is about twice as slow.
- jumby 6y agoAnother funny thing with the accordion component: the icons for expand and collapse seem to my mind to be reversed (- for expand and + for collapse)?
- rckoepke 6y agoJust curious - where did you learn this level of detail w.r.t DOM, and what would you recommend I take a look at to learn it the right way?
- jjcm 6y agoHonestly just by making components and benchmarking them. Webcomponents are too new to really have a solid best practices guide at the moment and there's a lot of varried opinions out there. My main recommendations are to benchmark early and often. Tachometer is a library from the polymer team that I find does this very well: https://github.com/Polymer/tachometer https://github.com/Polymer/tachometer I.e. for testing shadowroot performance, I threw this together: https://github.com/jjcm/shadowTests https://github.com/jjcm/shadowTests You can see the results here: https://raw.githubusercontent.com/jjcm/shadowTests/master/result.png https://raw.githubusercontent.com/jjcm/shadowTests/master/re... TL;DR - a custom element with no shadowroot is about twice as fast.