3 ms·

Overall I'm not super happy with web components to solve the issues of reusability, conciseness, and self-containment. The most direct problem is styling issue

by sbjs 3y ago

Overall I'm not super happy with web components to solve the issues of reusability, conciseness, and self-containment. The most direct problem is styling issues. Cross-component CSS in either direction has some serious limitations. I've written a little bit about it[1] in my blog but the short version is that there are some things that simply become absolutely impossible when using web components. My main other gripe with them is the need for a build phase. The nature of WC almost begs for them to eventually become zero-build-time, but right now this just isn't practical. It requires too much boilerplate in every .html file (utf8 is broken on my site), the syntax isn't natively there even with tagged template literals, and there's no concept of data-list-fetching or data-based file generation. There's a branch on my personal website[2] where I tried to start using web components, and it was so problematic that I long abandoned it. Overall, I abandoned web components entirely in favor of making my own customized JSX-based SSG from scratch[3] which solves the same problems Lit, Next.js, et al. are intended to solve, but in a completely different way: using components for convenience, conciseness, and reusability, but only at the build-phase time. So far it's a well kept secret, which is probably good since it's been evolving so quickly that I wouldn't have been happy with any iteration being widely adopted so far. (Though I think this morning I finished off most of what I was unhappy with.) [1]: https://sdegutis.github.io/articles/2023-08-07-modern-90s-web-dev.html https://sdegutis.github.io/articles/2023-08-07-modern-90s-we... [2]: https://github.com/sdegutis/immaculatalibrary.com/tree/reset/new https://github.com/sdegutis/immaculatalibrary.com/tree/reset... [3]: https://github.com/sdegutis/immaculatalibrary.com https://github.com/sdegutis/immaculatalibrary.com

claytongulick 3y ago
I'm curious about this - are you using shadow DOM? If so, I completely understand your frustration. IMHO shadow dom isn't really useful for application authoring, it's beneficial for library authors and such. Web Components become a lot easier if you just stick with the light dom.
- spankalee 3y ago
  Shadow DOM is what enables interoperable composition. Without it you don't get <slot>s and without that you can't put children into a component without some very ad-hoc hacks.
  - claytongulick 3y ago
    Yeah - I've been writing native web component applications for many years now, and I have never, not a single time, needed slots. I have WC scenes, which are top level components that are able to be accessed by a url/deep linking/router outlet. Scenes are built from html and css that lay out smaller components - sometimes WCs, sometimes vanilla html, depending on what makes sense. Components mostly take care of themselves, load the data they need, and maintain their own state. Unless that doesn't make sense, in which case data is passed to them via properties. I have hundreds of thousands of lines of high performance, quality production code running this way and again - have never needed a slot. Slots are mostly useful for library authors, IMHO.
    - brainbag 3y ago
      That sounds like an interesting approach haven't heard of before, do you have it documented somewhere?
      - claytongulick 3y ago
        You may have motivated me to write something about it.
spankalee 3y ago
We're trying to advocate for greater flexibility in cross-component styling. One proposal is "open styleable shadow-roots" which would be an opt-in to let styles from above a component to apply to it's shadow root. I think this would help migration in situations where app teams are currently using global stylesheets. Feedback and support of the need for something like this would help a lot: https://github.com/WICG/webcomponents/issues/909 https://github.com/WICG/webcomponents/issues/909

by sbjs 3y ago

claytongulick 3y ago

I'm curious about this - are you using shadow DOM? If so, I completely understand your frustration. IMHO shadow dom isn't really useful for application authoring, it's beneficial for library authors and such. Web Components become a lot easier if you just stick with the light dom.

spankalee 3y ago
Shadow DOM is what enables interoperable composition. Without it you don't get <slot>s and without that you can't put children into a component without some very ad-hoc hacks.
- claytongulick 3y ago
  Yeah - I've been writing native web component applications for many years now, and I have never, not a single time, needed slots. I have WC scenes, which are top level components that are able to be accessed by a url/deep linking/router outlet. Scenes are built from html and css that lay out smaller components - sometimes WCs, sometimes vanilla html, depending on what makes sense. Components mostly take care of themselves, load the data they need, and maintain their own state. Unless that doesn't make sense, in which case data is passed to them via properties. I have hundreds of thousands of lines of high performance, quality production code running this way and again - have never needed a slot. Slots are mostly useful for library authors, IMHO.
  - brainbag 3y ago
    That sounds like an interesting approach haven't heard of before, do you have it documented somewhere?
    - claytongulick 3y ago
      You may have motivated me to write something about it.

spankalee 3y ago

We're trying to advocate for greater flexibility in cross-component styling. One proposal is "open styleable shadow-roots" which would be an opt-in to let styles from above a component to apply to it's shadow root. I think this would help migration in situations where app teams are currently using global stylesheets. Feedback and support of the need for something like this would help a lot: https://github.com/WICG/webcomponents/issues/909 https://github.com/WICG/webcomponents/issues/909