I'm literally begging you to take a look at the suite of UX components in the Shoelace library. They're gorgeous out of the box, and fully customizable. Plot twist: they're written with web components. PLEASE WAIT DONT LEAVE 🧵

Even if you don't give a shit about web components. Even if you've been annoyed by the Lit / web component community in the past. Even if you're 100% happy with your current framework. A web component-based ux library offers a huge advantage: it's framework agnostic.

I can tell you from experience it fucking sucks trying to replace a modal, auto-complete, date picker, etc etc every time you want to use a new framework. Depending on how new it is (ie Solid, or frankly even still Svelte) your options on npm might be ... lacking.

I cobbled together this dogshit a few years ago so I could build something w/ Svelte. It works, but not great, and not remotely accessible (honestly don't know how: PR's welcome, or better yet just don't fucking use it - use something good like Shoelace)

What happens if Lit dies and the new version of these components uses another lib, and now you import 2 runtimes? Also the compat later for react and others will be a factor that doesn’t make it truly agnostic, if they don’t support your framework of choice it’s all manual work

Sigh. If my library has a good UI component library, why would I eat potentially extra bundle cost? If I’m using a fringe framework then sure. Why do I feel like we’re forcing WCs just because? Still having trouble understanding the benefits. Nice UI though!

Are you all in on your library / framework? Are you certain you won't want to start integrating a different framework in a few years? If yes then godspeed. But I don't have nearly that confidence.

Pretty feeling solid in my framework choice. But yeah that’s still not really a good reason IMO. If I’m porting my app the components are my last problem.

Oh how about SSR. How do I solve that? I think that’s a common question for WCs though

Ah fuck - yeah that’s still a gaping hole with web components still.

I mean I like what you’re selling as an idea haha. Agnostic is great! I’d love to see a comparison of bundle size and full SSR. I’d even eat the bundle size for something *good* tbh.

SPA / app shell is still a valid, frankly desirable pattern for some apps, so I don’t think all is lost either way

Re: SSR –– On the chance you haven't seen it, I think @passle_ has done some cool writing on this topic It's possible to achieve a form of SSR-ed web component by taking advantage of the :not(:defined) CSS selector and some of the behaviors of slotted children

Here's @passle_'s article that discusses the idea further

I've also written about this too –– it's mostly a rehashing of the same ideas but phrased a bit differently for a slightly different context

I will say, I don't think this wouldn't work super well with a component library that you don't have full control over like Shoelace I think it's technically possible would get really jank really quick...

Clearly, a world with full declarative shadow DOM support is still desperately needed ...but if you absolutely need SSR support in your web components today it is ~ technically ~ possible

*I don't think this would work 🤦🏻‍♂️

I have never tried it but shoelace has docs on integration with next.js to start. SSR support with components like in shoelace should not generally be an issue because they are all small stateless components.

From the looks of it this would result in a content shift as the wc registration scripts kick in

that true?

SSR features are the responsibility of framework devs who, up till now haven’t considered web components at all. the Lit team is currently working on SSR for Lit components in NextJS. the WC Community group is working on proposals for declarative shadow dom. SSR is coming

Lit was just recently updated to add being able to be safely imported in node without a DOM shim. twitter.com/buildWithLit/s…

That’s cool for Lit users. Wish this existed everywhere else.

That said … @claviska any chance you built all this with Lit, which might make it SSR friendly in the future?

im not Cory :) but shoelace is all Lit

So … does it work with SSR out of the box?

i think there would be some cleanup. the current implementations of SSR i’ve seen require stuff like “no DOM access (querySelector or addEventListener) in the connectedCallback”. im sure shoelace is currently doing some of that stuff. but it would just be a cleanup, not a rewrite

Ughhhh this is such a mess.

maybe. personally i don’t see SSR sticking around all that long. it’s new and hot, but i’ve already seen articles and videos saying that SSG + incremental refresh is “better” in many cases than SSR

ie: Vercels own post heh:

SSR isn’t really new, it’s been around for a while. It’s just picked up in importance/complexity/usefulness. @RyanCarniato wondering your opinion on incremental refresh.

i’ve been looking at the same sort of cleanup for my design system

Mostly. Some edge cases still exist.

Oh nice. And I’m told the Lit team is working with the Next team. I assume once that’s done the Next interop will get a lot simpler

Just like React compat is a must in 2022 (hence @ lit-labs/react which works with any WC not just Lit) Next interop is also a must. Lit 2.3.0 is the first release towards this with ongoing work in the bg

We're also working on releasing our SSR test suite which will test your WCs for basic SSR support.

Disagree that it’s the responsibility of framework devs; they’re busy enough. This shit needs to be built into the platform and turnkey. It’s not, currently. I hope it gets there.

for now it’s the responsibility of framework devs *until* it gets built into the platform. declarative shadow dom will be the “it’s in the platform” part. and web component folks are working on getting the DSD concept specced and implemented

I’m confused. You’re saying that the framework providers/ecosystem will have to adapt them into their SSR process pipeline? That’s never going to happen. I suspect people rather just use their native framework abilities at that point.

it will happen. it IS happening. reacts current events system just doesn’t work with native events. but react@experimental currently has WC/native event support built in. when experimental becomes react 19, the react devs will have incorporated WC interop into react

React’s event system has nothing to do with SSR of web components…

true, but it’s an example of a framework team taking web component interop seriously and implementing it rather than just only supporting their own proprietary framework approaches

SSR should follow a similar pattern. frameworks saying “you can SSR but only “our” components” and ignoring WCs is kinda like saying “you can write HTML but we don’t support div tags”

There *is no* generalized way to SSR web components. If there were, there wouldn’t be ongoing work / collaboration going on between the Next and Lit folks. None of this is framework authors’ fault.

i agree, but they could have held back the SSR implementation until it worked for web components also, right? i don’t necessarily blame framework authors. they make their own decisions, but web components have been ignored in a lot of ways not just SSR

> but they could have held back the SSR implementation until it worked for web components also, right? That would be absolutely insane.

i think it how insane it is depends on how important interop is. and that’s my whole point. interop hasn’t been very important until very recently

Blame the platform spec authors, not the framework authors working with what they have.

I hear your frustration. The industry has been looking at SSR for ~10 years (someone correct me). WCs have needed to evolve/mature in that time. It’s not just about timing it’s about unifying SSR. There are too many approaches and for good reasons.

We can’t oversimplify it. We’re not going to wave a magic wand standardize SSR. It’s complex. Even if you get the render mechanic operational how do you solve things like hydration? Also SSR aint going away when modern are frameworks going all-in.

We’re just waiting for this

the NextJS team is working with the Lit team on SSR for web components in addition to server components etc.

The problem of Web Components since the inception: there are too many "will" and "in the works", and yet we *have to* use them right now or your business lose something 😕 I agree though that frameworks should work with WCs without any issues and portability wrappers (React👀)

SSR isn't a binary yes/no when it comes to web components. Content in "light DOM" can be SSR'd by any template language in any framework. That's not unique to WCs. Generally what we're particularly waiting for is SSR of shadow roots. Work there has happened and is underway.

Right, but that applies to most wc’s, and is necessary to prevent content shift. So absent that what we’re left with is not great when it comes to SSR

I hesitate to make any kind of blanket statement like that. You really have to measure what specifically is happening on any given page, and then take steps to mitigate any any serious issues (including basic styling of undefined components before they're upgraded).

Fucking Twitter. *feeling pretty 🤦‍♂️

Feeling pretty… solid… I see what you did there

For example if your library updates force you to drop IE11 even though you can't afford to do that as a business (hi React 18).

OK, where to start?

Looks like a decent set of components. Presuming someone from it is looking though, the site feels a bit sluggish and the menu doesn't open first time on mobile sometimes, don't know if that's hit target or sluggishness.

Looks great! Perhaps the "framework agnostic" deserves more visibility, as understanding the value requires a lot of experience e.g. evolving products, teams, etc. I'd love to know more about best practices you recommend for layout and bundling size.

I had realized the potential of web components long ago, but due to strong dependence on existing frameworks/libs never got a chance to use them in real projects. If you like the way of web components than I suggest you should look at this library. component.kitchen/elix

Here is the brilliant talk on the components by the author

Just my opinion, someone going on elix site to look at components such as Alert Dialog and Dropdown List, would probably leave the site because of how ugly and barebones the components look. Shoelace on the other hand looks nice and would keep the visitor's attention.

Can we extend the Tree and TreeMap components with CRUD easily?

💯 couldn’t agree more! I’ve been using Shoelace for the past year and you can drop the components into any app and they just work. I wire them up with vanilla JS, AlpineJS, or Vue; and even convert them into server-side Laravel components.

There are a couple of reasons I stopped looking at WC as a way to build atomic agnostic UI: - no SSR support, causing FUOC for certain types of elements - no platform available framework, meaning different WC will use different lib, adding to runtime size (it grows linearly)

I reviewed this further, it’s amazing work, but I’m unimpressed. It still has FUOC problems (no, visibility hidden doesn’t solve it, it just moves the problem). Setting complex objects or event is not great either as you have to select the element, creating another block to SSR.

Yeah it doesn’t surprise me that SSR doesn’t work. That appears to be a wip for web components in general.

To clarify - you’re rendering some of these components with Next, and you saw a FOUC? Absolute worst case, if you wanted to, you could put the script / link tags for shoelace (ie to the cdn) in head, and force your page to block on them. That’d avoid fouc, tho hurt perf right?

Not really, the main issue is shadow dom. You’d have to wait for the JS to be downloaded and evaluated, effectively causing rendering in phases rather than all at once. In which case, I’d consider then lazy imported, but imagine a skeleton for each button and link…

Having to declare events and complex props separately from the html definition can also break SSR, depending on implementation. Imagine using a effects to define props that lead to rendering more elements. The server needs to run this as well to get the declarative shadow dom out

It just feels a lot like jQuery. AMP has the same issue, they pre-render pages and hydrate elements instead of re-creating them if available already. I never had this issue again since I moved away from client side only dom implementations onto declarative alternatives like React

Sure but that’s true without web components. React effects only run on the client iiuc.

Yes exactly, that’s what I’m saying. Imperative code cannot be used for SSR precisely for that reason, all render needs to come from the component definition

Right. I’m saying, what if the script registering the web components was blocking. Put it in head, and the doc blocks until that parses. Wouldn’t that fix the fouc at the expense of perf?

Not really, again this is shifting the issue. Now you have a slower paint as you wait for JS, plus depending on browser implementation, JS still needs to run after first render to create the shadow dom, so the first render still has FUOC, at least until declarative shadow dom

“JS still needs to run after first render to create the shadow dom” Does sd not get created synchronously if the wc has already been registered? I could have sworn it did. @slightlylate sorry to bother - can you lend some wisdom here?

It doesn’t matter if your app is client side only of course, but that’s not 95% of web apps (only a bunch of apps don’t benefit from SSR really, admin panels and utility softwares a la gmail / spotify / netflix)… as soon as you move to e-commerce or content apps, you need SSR

This immediately turned on the lightbulb for me. We’re already often pulling in css component libraries. Why not use light highly unopinionated custom element libraries as your baseline?? Thanks for this post!