Tane Piper ⁂If you were starting a new project and wanted to build all #webComponents - what would be your goto tool for this?
Lit? StencilJS? Something else?
Asking for my team
An Agora
Alex Russell@tanepiper: try Lit and FAST and see which one you take a shine to!
Stencil is great for teams that like JSX, but that just feels like baggage to me, personally, and it's a bit slower.
@slightlyoff We're already looking at Lit, but really just want to check if it's still state-of-the-art or have we already moved on 😅
Fast looks interesting, but ultimately BIGCORP™️ needs the security of the larger project here as it has move governance and a clear roadmap I guess.
So it seems like Lit it is.
@slightlyoff Ohh - different Fast! Turns out there is also a Fast JS library that isn't Microsoft
Benny Powers@tanepiper @slightlyoff There's also hybrids (weird!)
@i @slightlyoff Oh big ExtJS vibes for defining components 😜
Mark Derricutt (talios)@tanepiper @slightlyoff Only just discovered Lit this week after the new Gerrit came out using it. Haven't touched web UI since the dawn of the millenia but it looks.... interesting to me.
Justin Fagnani@tanepiper @slightlyoff Lit's definitely state-of-the-art and will only get moreso. We're pretty involved with WC standards work and adopt things pretty rapidly as they ship. Ex: we've had support for constructible stylesheets and native CSS modules for years already.
Jason Galea@tanepiper no actual experience on my part, but after I read this recently I was left thinking Lit would be a good option.. https://www.phase2technology.com/blog/web-components-our-journey-from-lit-to-stencil-and-back-again
Charles Roper@tanepiper Depends on the project but should give a shout out to @zachleat’s WebC here:
@charlesroper @zachleat Yes one of the team has been looking at 11ty and WebC and it's on the recommendations - but as far as I can see WebC doesn't go to shippable components, just internal ones?
And it's got it's own templating, directive, etc - which I couldn't see how to do complex stuff or even loops - we're trying to remain as agnostic as possible here.
@tanepiper @zachleat If you’re considering all angles, definitely have a read of this fun series of posts: https://dev.to/tigt/making-the-worlds-fastest-website-and-other-mistakes-56na
@charlesroper @zachleat Thanks will do.
FWIW we have a design system with components, but as we move to SSG they are less and less useful.
For our team, this is about reducing the need to rebuild components time and again (e.g. same component can be used in SSG, SSR, SPA or in 3rd party tool like Contentful.
Hunter Loftis@tanepiper @charlesroper @zachleat
In that case I'd consider Lit, since SSR is important to the team building it and intra-framework compatibility is important to many contributors.
૮༼⚆︿⚆༽つ / Wildan@tanepiper in the past I would use a framework but now I go on vanilla path and choose some reactive library then encapsulate it in shadow root while keep my eyes on FOUC.
@drsensor RxJS? (Familiar with it, so could be a good fit).
Vanilla is an option, but I guess the question is how much are we custom building vs getting some OOTB benefits of some of the libs.
@drsensor I wanted to suggest vanilla, but sometimes I worry it's less maintainable and more to learn and test.
I'm not against it, but it's up to the team to pick - I just to offer all the suggestions
@drsensor the FOUC we might be able to solve with ESI and edge computing.
At the moment in our SSG Astro site I have in the head a small snippet that checks session storage for the dark mode setting - but if it can be moved to the edge it solves a those issues.
@tanepiper nah, just something like SolidJS reactive library or S.js.
I go vanilla for personal project and because recently I deal with existing project that use template engine. So component/island-ing the UI can be prone to FOUC. AlpineJS solve my problem but it can't do async rendering and I have less control on what it do.
I go vanilla for personal project and because recently I deal with existing project that use template engine. So component/island-ing the UI can be prone to FOUC. AlpineJS solve my problem but it can't do async rendering and I have less control on what it do.
Ryosuke@tanepiper I'd honestly stay away from web components nowadays unless you need to make a truly lightweight cross browser component (like a 3D viewer or something). And even then - you could prob do vanilla/Svelte.
if you're building a UI library or app, I'd recommend something like Vue or React. Vue specifically follows a lot of the web component model (if you dig it), and both have a lot better ecosystems (like more modules on NPM to install -- or better support for SSR)
@whoisryosuke This is a decision for the team, I'm just here to support them.
FWIW I built our current site in Svelte, after trying out React design system components and finding them not for SSG.
The design system has React, Vue and some WC, team doesn't like React but doesn't want to rebuild the entire system in a UI framework.
Our middle ground is web components. We can then just build light wrappers around them.
@whoisryosuke Then can then be used in other places, and 3rd party tools like Conentful (that only supports React in it's interface)