Florian Hehlen

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.

Lume, the static site generator for Deno Support for multiple file formats like Markdown, YAML, JavaScript, TypeScript, JSX, Nunjucks etc.

Hi all... Sunday, feeling good about my progress helping out with the Lume (lume.land) project (#Deno SSG engine) and the underlying Vento (vento.js.org) templating engine. I am wrking away on a plugin for #Jetbrains #IntelliJIDEA and #Webstorm

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.

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.

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.

Full disclosure: I 💕 all coffee!

Hot holiday take: an Americano coffee is a terrible thing to do to an espresso and makes it nothing like an actually good cup of Jo!

#holiday #coffee

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

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.

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.

*returned

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.

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.

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.

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

One and the same! I have been using it since the early days. I am also a Kickstarter participant in Webawesome.

Customizing Learn how to customize Shoelace through parts and custom properties.

My go to reference for web components done right is Shoelace.

Custom properties are mostly a flat list of tokens a d global properties.

Well designed and documented CSS parts are used to provide access to override components at well defined points.

shoelace.style/getting-star...

I think it's interesting that one of the trendiest frameworks out there is adopting web components. It doesn't make me like Tailwind more though

I see a difference. BEM relies on convention and practices. When Custom Properties are combined with shadow Dom, then nesting is maintained. Throw in CSS parts and it becomes even more solid.

I see more real world use than ever. I also see more recognition of the value. That said, it's still an uphill battle for people to separate market/popularity driven arguments from other aspects of the debate.

JSX without react is a thing but it's certainly not what made it popular. I mentioned the virtual DOM because lit's approach to reactivity and incremental Dom updates is intimately bound to the lit-html template. This template implementation fully respects html semantics.