Skip to content
This repository has been archived by the owner on Sep 19, 2023. It is now read-only.

Web Components #3

Open
TylorS opened this issue Aug 2, 2019 · 3 comments
Open

Web Components #3

TylorS opened this issue Aug 2, 2019 · 3 comments
Assignees
Labels
enhancement New feature or request

Comments

@TylorS
Copy link
Owner

TylorS commented Aug 2, 2019

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.

@TylorS TylorS self-assigned this Aug 2, 2019
@TylorS TylorS added the enhancement New feature or request label Aug 2, 2019
@Frikki
Copy link
Collaborator

Frikki commented Aug 7, 2019

Interesting. Could you shed some light on the pros and cons using web components?

@TylorS
Copy link
Owner Author

TylorS commented Aug 7, 2019

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.

@Frikki
Copy link
Collaborator

Frikki commented Aug 11, 2019

Wow! Sounds ambitious. Thanks for your detailed answer.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants