Florian Hehlen
@zenwork.bsky.social
Reluctant architect and software engineer at heart. I work in the digital healthcare world and looking for a way to make a difference with https://hl7.org/fhir
People complain a lot about shadow Dom. I think it's a matter of adoption. Once you are used to them they deliver some advantages. I generally like to have strong boundaries with CSS, event propagation, slots, strict API, and reactivity. I can remove it when it truly is in the way.
October 24, 2025 at 6:55 PM
People complain a lot about shadow Dom. I think it's a matter of adoption. Once you are used to them they deliver some advantages. I generally like to have strong boundaries with CSS, event propagation, slots, strict API, and reactivity. I can remove it when it truly is in the way.
Brings back memories. Is this the version of the browser that included dialup software directly into the browser.
August 20, 2025 at 7:26 AM
Brings back memories. Is this the version of the browser that included dialup software directly into the browser.
And the shadow DOM is a feature too. The cascade can lead to lots of issues in complex/large apps or libraries.
August 18, 2025 at 5:04 PM
And the shadow DOM is a feature too. The cascade can lead to lots of issues in complex/large apps or libraries.
I don't think that the cascade is inherently bad. I think that the shadow DOM now gives me a choice. And it's a useful choice.
Choice makes it more complicated. You have to learn about loading CSS in components. But coping with the cascade can also lead to a lot of complexity in bigger projects.
Choice makes it more complicated. You have to learn about loading CSS in components. But coping with the cascade can also lead to a lot of complexity in bigger projects.
August 18, 2025 at 6:53 AM
I don't think that the cascade is inherently bad. I think that the shadow DOM now gives me a choice. And it's a useful choice.
Choice makes it more complicated. You have to learn about loading CSS in components. But coping with the cascade can also lead to a lot of complexity in bigger projects.
Choice makes it more complicated. You have to learn about loading CSS in components. But coping with the cascade can also lead to a lot of complexity in bigger projects.
You can call using the shadow DOM to encapsulate CSS js-centric, but I do not think this is helpful. Shadow roots are part of the DOM and CSS models. What can and can't penetrate (IE: fonts, properties, parts, etc.) is part of the CSS spec. I am just using JS to define boundaries.
August 16, 2025 at 11:55 PM
You can call using the shadow DOM to encapsulate CSS js-centric, but I do not think this is helpful. Shadow roots are part of the DOM and CSS models. What can and can't penetrate (IE: fonts, properties, parts, etc.) is part of the CSS spec. I am just using JS to define boundaries.
What you present as disadvantages are relative. I don't see global styling as an absolutely great thing. And, I think that creating web components without JS doesn't make much sense to me.
August 16, 2025 at 9:13 AM
What you present as disadvantages are relative. I don't see global styling as an absolutely great thing. And, I think that creating web components without JS doesn't make much sense to me.
Full disclosure: I 💕 all coffee!
August 15, 2025 at 1:49 PM
Full disclosure: I 💕 all coffee!
I was wondering if this indicates that people finally get that WCs exist, so they don't need hello world examples anymore.
August 15, 2025 at 1:44 PM
I was wondering if this indicates that people finally get that WCs exist, so they don't need hello world examples anymore.
Looking forward to this working in webstorm/intellij . This is a missing link for WC adoption
August 15, 2025 at 1:36 PM
Looking forward to this working in webstorm/intellij . This is a missing link for WC adoption
I agree that you have to leave your favourite framework paradigm at the door. I don't agree that slots and shadow DOM should be ignored. Understanding them as a browser-primitive is key though. Their quirks become something that you can leverage then.
August 15, 2025 at 1:04 PM
I agree that you have to leave your favourite framework paradigm at the door. I don't agree that slots and shadow DOM should be ignored. Understanding them as a browser-primitive is key though. Their quirks become something that you can leverage then.
I agree. Although I like my components with Lit. OOP + events is what OOP was always supposed to be.
August 7, 2025 at 6:16 AM
I agree. Although I like my components with Lit. OOP + events is what OOP was always supposed to be.
Oh. Hmm... I didn't know about these issues. I almost never do any initialisation in the constructor other than initializing default state on variables when necessary.
August 4, 2025 at 5:53 PM
Oh. Hmm... I didn't know about these issues. I almost never do any initialisation in the constructor other than initializing default state on variables when necessary.
I knew it was red. I did not know I could call super() later or that super() retired a reference.
August 4, 2025 at 8:52 AM
I knew it was red. I did not know I could call super() later or that super() retired a reference.
I guess you have all the answers you want at this point, and don't seem interested in any other experience. For what it's worth I think you misunderstand what Justin has been doing and proposing for over a decade.
July 26, 2025 at 11:56 AM
I guess you have all the answers you want at this point, and don't seem interested in any other experience. For what it's worth I think you misunderstand what Justin has been doing and proposing for over a decade.
I followed v0 in 2016 or so. I started with v1 when released. I think you are ignoring the flux the whole space was in back then. The framework authors were not speaking with one voice at all. The disagreements between Angular, React, and Vue, Svelte, etc. universes was a big deal.
July 26, 2025 at 11:37 AM
I followed v0 in 2016 or so. I started with v1 when released. I think you are ignoring the flux the whole space was in back then. The framework authors were not speaking with one voice at all. The disagreements between Angular, React, and Vue, Svelte, etc. universes was a big deal.
I have agreed and disagreed with stuff all three of these people have written. To say that the vitriol has come from one side ignores a lot of the story. To assert that there's some kind of collusion by one side and imply only good will and good intentions on the other is pretty simplistic at best.
July 26, 2025 at 11:29 AM
I have agreed and disagreed with stuff all three of these people have written. To say that the vitriol has come from one side ignores a lot of the story. To assert that there's some kind of collusion by one side and imply only good will and good intentions on the other is pretty simplistic at best.
That's a fair point. But you are also conflating the initial discussion raised in the article about having template support in the browser as some kind of concession by the WC community.
July 26, 2025 at 11:20 AM
That's a fair point. But you are also conflating the initial discussion raised in the article about having template support in the browser as some kind of concession by the WC community.
lit-html is a template lib you can use any where. Lit is the WC lib. The markup is 100% valid html. It extends html with extra syntax. JSX does it differently. MyComponent as a tag name is non-conformant. JSX doesn't distinguish between attributes and properties. "className" instead of "class". Etc.
July 26, 2025 at 11:17 AM
lit-html is a template lib you can use any where. Lit is the WC lib. The markup is 100% valid html. It extends html with extra syntax. JSX does it differently. MyComponent as a tag name is non-conformant. JSX doesn't distinguish between attributes and properties. "className" instead of "class". Etc.
Really. It's been that bad? And there's been no conflation and strong opinions by anyone in the big frameworks? There's been no outright criticising of web components for not being close enough to their favourite framework?
July 26, 2025 at 11:07 AM
Really. It's been that bad? And there's been no conflation and strong opinions by anyone in the big frameworks? There's been no outright criticising of web components for not being close enough to their favourite framework?
For everyone else, Webawesome is successor Shoelaces which will soon be released and exist as a base Oss library complimented by a for money pro version.
webawesome.com
webawesome.com
Web Awesome
Build better with Web Awesome, the open source library of web components from Font Awesome.
webawesome.com
July 26, 2025 at 7:06 AM
For everyone else, Webawesome is successor Shoelaces which will soon be released and exist as a base Oss library complimented by a for money pro version.
webawesome.com
webawesome.com
One and the same! I have been using it since the early days. I am also a Kickstarter participant in Webawesome.
July 26, 2025 at 7:00 AM
One and the same! I have been using it since the early days. I am also a Kickstarter participant in Webawesome.