4 ms·

the bottom section talks about "web component frameworks", i.e., frameworks that use javascript's native web components rather than creating their own special c

the bottom section talks about "web component frameworks", i.e., frameworks that use javascript's native web components rather than creating their own special component format. the article says: > In my opinion, most projects still benefit from using a frontend framework over pure web components—or, at the very least, both together. Maybe that will change in the future, but for now, I think the tradeoffs still tilt away from a pure web component approach in most cases. but doesn't provide any real argument to justify that opinion. why would anyone want to subject themselves to framework lock-in when you can have components that are portable across frameworks? what are the arguments against? genuine question -- i've used Vue and i've used Lit, and didn't see obvious limitations in the latter, but i've also never used either for any large project.

troupo 3y ago
> why would anyone want to subject themselves to framework lock-in when you can have components that are portable across frameworks? what are the arguments against? https://twitter.com/Rich_Harris/status/1198332398561353728 https://twitter.com/Rich_Harris/status/1198332398561353728 None of these are solved, or will be adequately solved in a forseeable future. Some of these will be addressed by ~20 new JS-only specs in the various states of "not started" https://w3c.github.io/webcomponents-cg/2022.html https://w3c.github.io/webcomponents-cg/2022.html Literally none of the major (or even emergent) frameworks have these issues, or a chance of running into these issues.
- woodrowbarlow 3y ago
  thank you; these are good, specific examples. #2: maybe i'm misunderstanding, but i think frameworks can implement SSR on top of vanilla components, for instance in Lit: https://lit.dev/docs/ssr/overview/ https://lit.dev/docs/ssr/overview/
  - troupo 3y ago
    If you need framework-specific solutions to do SSR for web components... they are no better than existing solutions without them. Lit solution also lists a lot of caveats including things like "only Lit elements using Shadow DOM can be SSR'ed" and "element registry needs to be solve for interop with other custom elements" (that is, there's an issue on the standards level)
  - troupo 3y ago
    I've written a more extended response in a different thread here: https://news.ycombinator.com/item?id=37158524 https://news.ycombinator.com/item?id=37158524

troupo 3y ago

> why would anyone want to subject themselves to framework lock-in when you can have components that are portable across frameworks? what are the arguments against? https://twitter.com/Rich_Harris/status/1198332398561353728 https://twitter.com/Rich_Harris/status/1198332398561353728 None of these are solved, or will be adequately solved in a forseeable future. Some of these will be addressed by ~20 new JS-only specs in the various states of "not started" https://w3c.github.io/webcomponents-cg/2022.html https://w3c.github.io/webcomponents-cg/2022.html Literally none of the major (or even emergent) frameworks have these issues, or a chance of running into these issues.

woodrowbarlow 3y ago
thank you; these are good, specific examples. #2: maybe i'm misunderstanding, but i think frameworks can implement SSR on top of vanilla components, for instance in Lit: https://lit.dev/docs/ssr/overview/ https://lit.dev/docs/ssr/overview/
- troupo 3y ago
  If you need framework-specific solutions to do SSR for web components... they are no better than existing solutions without them. Lit solution also lists a lot of caveats including things like "only Lit elements using Shadow DOM can be SSR'ed" and "element registry needs to be solve for interop with other custom elements" (that is, there's an issue on the standards level)
- troupo 3y ago
  I've written a more extended response in a different thread here: https://news.ycombinator.com/item?id=37158524 https://news.ycombinator.com/item?id=37158524