Future-Proof Your UI: Building With Web Components

Today, I'm going to be talking about futureproofing your UI using web components. Now, my talk is somewhat related to a recent Twitter drama, but I promise it predates that drama and I wasn't really looking to stir up anything with this. And another confession, the title is a bit of a bait, but we'll probably agree that something like, and I quote, we had a specific use case best solved with web components to make our stuff futureproof, well that's kinda long, right? So we're rolling with this one instead.

My name is Darko. I love Linux. I'm a Linux nerd by any measure. I love anything open. Open source, the open web, standards and so on. I'm currently doing the DERL thing for SuperTokens, the open source authentication company, check that out. And I'm writing at Darko.io. Now I'm on most of the socials, if you wanna follow me and my work. And I'm also on BlueSky because BlueSky is awesome.

To give you some context about why I started doing this thing in the first place. Now this started as a journey and an R&D experiment from my job at SuperTokens. We had a question in front of us. How do you support, with a UI library, all of the UI frameworks out there? Well you can answer that question one of two ways, usually. One of them is like employing an army of engineers which allows you to support Angular, React, Vue, Svelte, Solid and the rest of them out there. There's plenty. Or you can go for something like Web Components. Now don't get me wrong. Web Components are kind of a compromise in many senses. But given the right problem, well, they're the perfect tool for it. As it turns out, this experiment ended up a success. And we'll see why that ended up being a success. We may actually publish a library related to UI, related to authentication, based on this experiment.

A bit of story time related to the Twitter drama I mentioned before. Now don't get me wrong. I completely respect Ryan and his work. And I love anything Solid. I firmly believe that SolidJS has been one of the best things that happened to the web in the past couple of years.

But if you contrast this title, Web Components are not the future, which comes from Ryan's blog to the title of my presentation which is Future-proof your UI building with Web Components, you kind of get like contrast. It's really not going the same way. And frankly I was just trying to help with the title here. But his title aside, I kind of agree with most of what he wrote there. So keep that in mind while we go through this presentation.

The interesting thing that happened out of this title was like this Twitter drama. And you see like this phenomenal artistic rendition using my phenomenal artistic skills. Well, on one side we have framework people that were like Web Components suck! Like we don't like them. And the standards people on the other side were like Web Components all the things because like reasons. You know, there's plenty of reasons to do that. And there's the rest of us like referring to the peasant meme down there. But you know like some of us use both. And like if you're involved in a Twitter drama it makes you feel a bit like weird let's say because like Twitter dramas tend to be very polarizing. Ignoring that hey there is a middle ground here. You know you can use both right tool for the right job and all of that. So from the point of view of like non-framework authors and non-standards people that's like kind of the point of view I'm talking from. I realized that framework people problems are real and standards people problems are real but statistically speaking they're not the most common kind of problem. So just keep that in mind during the presentation.

So okay enough drama. Let's get into what Web Components actually are. So in a sense you can consider them DIY custom tags. Have your own you know HTML tag for whatever use case you might imagine. They can be distributed via script tags, via import statements, via all the regular ways you can import anything into a web page, web application. These work across frameworks. For the most part. React wasn't very.. wasn't fully supporting them up until 19. 19 supports them very well. So like you can use them pretty much anywhere actually. So they are standard as we've established and but under the hood you can split them in like three thematic things in general.

Like there's the custom elements API, the API that allows you to register those things in the DOM. There's the shadow DOM API which kind of encapsulates and hides some of the stuff under the hood and there's the HTML, Slot and Templates elements which together create what we refer to as the web component family of APIs. But we're not gonna get into a lot of that. If you're interested in theory just check out MDN. There's plenty of resources there.

We do have some problems though. Well the APIs are... well how do I put this gently? They're not pretty. In my experience or like in my opinion at least. And like it's biased, I know. But getting used to a developer experience such as JSX's, well there's no option of going back from that unless you introduce something better. And again, in my very biased opinion going for like class inheritance and the very old school way of writing components feels like a step back to me, honestly. And there's another problem.

As we've established recently through that chain of drama blog posts, like the idea of web components doesn't exactly translate well to the idea of a framework component. So those are kind of two of the biggest issues currently. Now in my opinion web components are significantly closer to HTML elements. To like the idea of an element. And web components can be a lot more complex, can do more stuff. It's not that web components can't, but the complexity you can manage via framework components in my opinion is a bit bigger than what you can do with web components. Now due to this thing, the idea of compiling down to web components from a framework component doesn't always translate well. And we'll see why later.

Now first off, the problem of developer experience is very easily addressed. We have plenty of modern tooling that allows you to write a component in, like, SolidJS, in Vue, in Svelte, whatever, and compile it down to a web component which you can distribute anywhere. Now my weapon of choice is Solid Element, because like I love Solid. It's awesome. So you can use stuff like Signals, all of the good stuff that come with Solid, and like package it inside a web component and ship it anywhere. And like, the example we have over here on the left feels kind of old school to me, like, no offense, but like Java circa 07. And like the right one over here feels very modern. You get to write some JSX, it gets packaged as a web component, what's not to like, you know? I'd have the right experience, the right developer experience, any day of the week, compared to the left one. OK, but you know what, enough with the drama and the theory.

Let's build some stuff. OK, now for our demo, we're using Vite, and we're basing our demo on the Solid scaffold, which you can find in the regular Vite Solid scaffold, but with two differences. It's going to get built in the library mode, meaning that we get a JavaScript file out of it which we can embed in maybe a React project, and we're using this plugin over here which helps with bundling CSS.

Now, CSS, there are a couple of ways to bundle CSS together with a web component, but for demo purposes this is probably one of the simplest ones I've found, so we're rolling with that one. If we have a look at the index file, because like every Vite project sort of comes with an index file, we can see all of the regular stuff we expect from a Vite scaffold, but we have this C basic component over here, we'll have a look at what that is, but in short, that's how custom components look like, or rather, web components.

Now our entry point into the entire thing is this main file in which we import everything else, and it currently just imports something called basic, so let's have a look at basic. Basic is, well, sort of a solid component in a sense, but it's wrapped inside this thing called custom element, coming from solid element, which is this library that helps us build web components using solid js. The way it works is by taking a bunch of input arguments, the first one being C basic, which gives this component the name under which we can reference it inside the HTML, or anywhere else for that matter. The second has to do with props and attributes, but we'll get into that one in the next example, and the third one is a function, which allows us to basically write some JSX over here, this is JSX, and compile it down to HTML, which can be injected inside any DOM.

So let's have a look at that in the browser. Now we already have the development server running here, and if we have a look at the page we have this hello world over here, if we inspect it, we see the C basic component with this thing called a shadow DOM, because we're using the shadow DOM. We'll get a bit more into that later. And let's go back to index. If we copy this a couple of times, it's going to behave exactly the same as in the HTML, so basically what you can expect from a tag that already has some pre-defined functionality, styles, whatever, and we have three hello worlds on screen, so let's get rid of that one and let's move on to the next example.

Next up we have props. Now, one of the ways by which we can pass data, maybe even modify behavior, is props. No matter, anywhere, like, whether we're using React, or whether we're using Solid, whether we're using Vue, it kind of works everywhere like that.

If we have a look at the props file over here, we'll see that it's very similar to the basic example, we give it a name, but we are passing some props down. So, this prop, myMessage, is kind of the default, let's say, and we reference it by props.myMessage, which is the input argument of the function that's the third argument of custom element.

We get to use this data if we don't overwrite it in the HTML, so let's have a look at how that actually looks like. Just pass some props without any props, and we're probably going to see another hello world, right. Not too exciting. However, if we do, like, something like this, we get to customize the message. Of course, hello from the other side. And if we pass it something else, this cursor being a bit smart, sure, why not. And we are getting something more.

Now, there's a caveat here. The only two types that we can reliably use here are strings, because attributes get passed as strings, or rather HTML supports string attributes, or booleans, having the presence or the absence of a certain thing. There are ways to pass other kinds of data, we can't really show that here, it's a bit more involved, but I'll try to do an example with that a bit later.

Now next up are slots. You're probably familiar with slots under a different name. In React land slots are sort of equivalent to React children. Now let's have a look how slots look like in this very weird world of solid-to-web-components compilation.

Now, we can use a slot tag. And slots come in two flavors in general, like named slots and default slots. Default slots are what you can just put in between the tags of your custom element and it appears in here, in this particular div. And if we use a named slot and pass it a slot attribute on the other side, it gets rendered inside this one. So let's see how that looks like in action. So if we use cslots and let's say we want to do Hello World, sure. Let's do this. Let's remove this one for now, we're not going to need it. And let's actually have a look at how this translates from the HTML over to the JSX we have on the other side. So we're registering this under cslots, sure, which returns a div with a bunch of slots here.

So we're registering this under cslots, sure, which returns a div with a bunch of slots here. We pass it an h1 with a slot of header, which replaces this part over here. We have a paragraph which would go into the default slot. And we have a named h2, which goes down to the slot named footer. So okay, if we have a look at this real quick. Let's have a look, inspect element, and we have header. It's referencing this element over here. And this one references the paragraph over here, so we're doing the right thing, and this one references this element over here.

Now this is, we have shortcuts to this so that we know we're doing the right things in the DevTools. And if we add something else in here, let's say we add a div here with, I don't know, goodbye world, kind of dark but sure, it works. We get to see like this thing inside the shadow root and here it goes, goodbye world, right. So it's in the default slot again. So it all works, right, we get some slots, it works. We have a caveat though. The only way that this works reliably is by using the shadow DOM. That's not always convenient because the shadow DOM encapsulates, styles encapsulates a bunch of other stuff from the outside world. And that's not always appropriate for what we may be trying to build. For example, at SuperTokens this didn't really work for us so we're kind of polyfilling slots, but that's not too bad so I guess it ends up okay. Like I said, this is a compromise.

For our next example, we're going to have a look at event handling. So our event handler should be here and we are trying to not use the shadow DOM over here, just to change things up. And we are registering this under C event handler to drive the point home about how this thing handles events. And we're just returning the simple button which does the following thing. It binds this onclick function, which logs onclick and shows us an alert if we don't have an element.handleClick. Now there is an important difference from the previous example. We're accessing another argument here, another input argument here called element. We're destructuring it. What element is is a reference to the actual DOM node in which like this custom element gets rendered. Now, how that looks like in practice is something like this. If we go for C event handler, we have just the basic event handler.

So that means that the default behavior is going to get triggered from here. And if we click the thing over here, it says I'm a fallback alert. Which means we didn't pass it any data or any way to override the behavior of this event handler component over here.

Now the way we can override its behavior is something like this. So sure, okay, let's see how far we get with copilot here. So it has like a handleClick, alright. So, okay, it gets properly what I'm trying to do. Even like by any measure like this stack and approach is kind of exotic but kudos to cursor I suppose. So we're selecting the C event handler element from over here. We're passing it this handleClick property and we're making, we're assigning a function to this handleClick property. And if we have a look at the event handler file over here, we're expecting exactly that. Like we're checking if this element, the exact DOM node we are expecting from here to have and if it has a handleClick property, we are executing that. Sure, this is a bit of like, this is any of course, so it doesn't have a type, whatever, but hey, it works. We're experimenting here. We're not trying to appease typescript. So if we do the click thing over here, it's going to override the default behavior and it's going to say I'm on alert from the parent. Now if you're into signals, for example, you can do something like, you know, pass the signal to the outside, make it like inject stuff inside the component and so on, but that's going to take a bit of time to showcase properly and we are going to move on with the demo.

Our final example here is basically a full example. It does everything. It has CSS, it has a bunch of other stuff. It doesn't use the shadow DOM, because like, I want to complicate my life, I don't know. And let's just try it out. Let's see how like ccounter, if you reference it over here, it says ccounter, c-counter, did I uncomment it, yes I did, and let's have a look at how that looks like. Yeah, we have an entire counter over here, which you know, just adds count. But here's the interesting thing over here. It's not really a solid element at this point, it's a whole web component. So the way that we can use this, everything that we produced here inside the React project, I luckily have something like that already setup, we can just do an npm run build from here, and like it's going to build like these two files, which we can find in dist. We have an ES variant of that module and a UMD, I'm going to copy both. It's not that we need both, but you know, you can. We're going to have a very basic Vite React project setup here, to showcase this thing.

I have these in components, we're going to rewrite these with the latest version of what I just built. And let's have a look at what we actually have in there. So we're going right into demos. And inside demos, we have what you might expect from a Vite scaffold. And let's check what we have inside app.tsx. Now, just for the record, TypeScript is going to complain. It is. We don't have any types. There are ways to introduce types, but hey, we're just trying to showcase something here. Let's first of delete this stuff from up here.

We're importing Solid Web Components.es, which is this file over here. It's a Javascript file, but it doesn't matter, it's going to work. And let's just first try C.basic. And this is also going to be a closed C.basic. In order to have this run, we'll have to do demos. And we'll go into React demo, and we're going to do an npm run dev. And again, at localhost 5173, we get a Hello World! Is that the thing we're looking for? Let's check it out. Let's have a look via inspect element. Yes! This is our C.basic component.

So, okay, like React understands Web Components. Cool as for us. So like, what we can do next here is like, let's try out the full example, like let's say C, we want to do a C.counter here. Because we already had it registered in the main file, which means it already has been registered to the DOM. And yes, we have an entire Web Component produced from solid over to a React project. Now if we want to do something like, let's say, I don't know, let's try C.props. So that we can do something weird. Try C.props and let's say we go with MyMessage equals Hello from the other side. It's probably going to show the Hello from the other side. But here's the neat part. We can do something like this, which will trigger from React.

It's not going to work inside the component, but it's going to work from outside of it. And here we have the clicked alert. This in turn has the nice side effect of us being able to combine parts of what we want to execute inside the Web Component, meaning compiled from Solid Land, and what we might want to execute all the way inside our framework code. So you can mix and match depending on your use case.

So finally some takeaways. Web Components are great, I would say, for some use cases. They aren't a silver bullet. As you might have seen, the developer experience gets a bit awkward. I certainly wouldn't write an entire project with Web Components. I would just go with something like, I don't know, SolidJS for example. But they're great for some use cases. Especially when you're trying to produce something that you would be able to import anywhere. There are already a couple of those use cases that we might make a great case for, but we'll see some of those in the next slide. They're not a silver bullet. Far from it. No matter what people may say. They aren't bad, they aren't the greatest thing ever. They're just a tool which can be used to solve problems that are appropriate for that kind of tool. If you love the idea, because I love the idea of Web Components, but I'm not really a huge fan of the APIs, just use Solid, use Preact, use Lit. You can even use React starting from 19. So you're good, you can produce stuff in a developer experience you're familiar and comfortable with.

Okay, fine. That might be like that. But what are Web Components actually good for? So here are some use cases which I think that are a perfect fit for stuff like Web Components. One, the very obvious one, design systems. Like Shoelace does a great job out of this. You can use Shoelace quite literally anywhere. Whether that's like a static HTML page or something like Next.js, you can use it. It's fine, it's going to work. It might not fit perfectly in every case, but it will work.

And if you're trying to solve such a problem, that's kind of a good case for it. Projects like SuperTokens, which aim to cater at the widest possible audience in web development. We want to support everybody, we want to help everybody build their authentication in the easiest way possible. So it's a great fit for us. We have a bunch of React developers on board and they might not like writing stuff in classes using the already available APIs, but we can kind of rectify that by giving them something like Solid Element. So everybody's kind of happy in the end.

They're good for widgets and embeddables. If you just want to integrate a speech bubble or something like that, instead of going through that whole awkward dance of including a script and then including an init script, with selecting a DOM node and running some weird functions and stuff like that, instead maybe you could just use a script and use a custom component somewhere in the DOM tree and it's just going to work. Sounds a bit better and cleaner, doesn't it?

Just for leaf components. Leaf components are an interesting case. Leaf components are quite literally the last thing that gets to render inside the tree. For things that have very specific functionality that don't need to wrap anything like web components are good for that too. Thank you and enjoy the conference.