Web Components
Opened this issue · 3 comments
I've been using web components at work to build a design language and I've really come to love the reusability of them. I think it'd be a perfect fit to build on top of @typed/dom and @typed/hooks to build web components.
Interesting. Could you shed some light on the pros and cons using web components?
I find the reusability aspects of them my favorite part. You can implement something like a carousel web component and be sure you can continue to use it well into the future as it's going to work with any framework of the present or future. If you're not trying to support older browsers (I'm not) you also get the benefit of not needing to send any additional framework code that will affect time to load. I've found web components to load and upgrade quite fast.
I also find them particularly well suited for creating a design language as they will work within any frontend application that could still be using any type of framework.
An initial con in my opinion is the native API being class based and having a lot of boilerplate when using the native API. I've been using https://github.com/matthewp/haunted a little at work and I've enjoyed using hooks as a way to enter the web component lifecycle and to declaratively manage things like state which makes them fun to work with.
One large goal I have with Typed is to keep everything working when you're running code on the server. I want universal rendering to be as simple as it can be. That said web components don't typically offer server support as it's a DOM API but that's still a goal of mine and the library basichtml helps acheive that goal. I also implemented hooks in a way that doesn't require the DOM API at all in order to power the context API to further that goal.
I'm planning to implement a templating library similar to lit-html and others like it that has built-in server support and doesn't rely on globals to help make all of it come together. I plan to provide rendering to a node stream to improve SSR and to implement client-side hydration to effeciently add event listeners back to the DOM. I'll definitely be measuring the performance gains or losses of hydration as it might be more effecient to just re-render.
Wow! Sounds ambitious. Thanks for your detailed answer.