←back to thread

277 points merqurio | 1 comments | | HN request time: 0.326s | source
Show context
Muromec ◴[] No.45113989[source]
I had lit in a project at work and not having to deal with it anymore is just great. We already have another heavier component framework to do the actual application stuff anyway, so having two just because somebody wanted to optimize their resume was such a drag.

It all looked nice in theory, but one thing shadow DOM makes worse is A11y, because element ids are now scoped and all the missing describe-by, label-for for things that should link to other side of the fence are a massive pain in the ass.

Big part of it is just skill issue on our part of course.

replies(4): >>45114885 #>>45117839 #>>45127177 #>>45149778 #
kubb ◴[] No.45114885[source]
Shadow DOM is optional in Lit - you can just disable it on a per-component basis.
replies(2): >>45116012 #>>45116762 #
jazzypants ◴[] No.45116762[source]
It should not be the default. This is almost certainly Lit's biggest flaw.

I am currently working on a web components framework, and I scrapped everything halfway through after I realized that you very rarely want that much encapsulation. Now, you can turn it on if you really need it, and I even made a way where you can pass references to DOM elements and stylesheets and such into each component so you can pierce the shadow veil easily. I have one demo to show it off, but I'm really having trouble imagining when someone would actually want to use it. The only time I can imagine it being useful would be building component libraries inside of large organizations.

I'm not ready to show off my framework yet, but I'm very certain that this leads to a better DX.

replies(2): >>45116920 #>>45117544 #
1. Muromec ◴[] No.45117544[source]
>The only time I can imagine it being useful would be building component libraries inside of large organizations.

That was our use case and we are migrating away from custom elements to a more conservative approach.