I've been using React for the last 12 years, and I started using it for server-side rendering. I went through React Create class, ES6 class components, function components with higher order components, Redux, and then Hooks. But then, this big change happened recently, called RSCs. And RSCs kind of flipped the model of React, where now everything is server-first. The data is server-first. We started thinking, why ship components to the client if the output is always going to be static? We can have a smaller client bundle if a lot of our UI can be represented with data or markup in this situation. We can still have client components for interactivity.
So I started thinking, can server components themselves be interactive? Hi, I'm Naman, and I'm not a fan of HTMX. But there are some things that are still kind of interesting to me about it. So this is a very simple HTMX demo, and what I like about it is that the logic of your application is right there in the HTML. There's no extra JavaScript to load, no extra bundles. It's all boiled down to something very simple, very efficient, in terms of the data that has to be loaded in the browser. But also, HTMX has imperative logic everywhere. You're updating things by IDs and inner HTML and outer HTML. There is no declarative system to keep track of everything and no components, no consistent data flow.
But then also, on the flip side, JSX can be used without React. And there's a server framework called Hano. It's a competitor to Express, which has first-class support for JSX, but just for rendering regular HTML. And so I started thinking, could I make a declarative component model that generates something like HTMX? Hi, I'm Naman, and I'm not a big fan of Web Components. But I've been digging into the APIs, looking for anything of value in that whole thing that we've built and put into the browsers. So I started looking at what are Web Components, what makes up Web Components. So the first thing that everybody talks about, because it's the most controversial part, is Shadow DOM. Shadow DOM gives you style isolation. That is its big value. Any CSS outside of the Shadow DOM doesn't apply to the markup inside the Shadow DOM, and any CSS inside the Shadow DOM doesn't affect anything outside of it. But we have Atomic CSS now. We don't have conflicts. We don't need this scoping of CSS in most cases. It really makes SSR hard, or sometimes impossible, if you have to support older browsers.
Comments