Facing Frontend's Existential Crisis

I'm incredibly honored to be here today. I did not expect to be opening a React conference right off the bat, got to say that. But yeah, I'm actually not talking specifically about Solid. If you want to hear more about Solid, listen to Achille's talk a little bit later.

Today, we are going to be talking a lot about front-end technology. I think probably it is safe to say it feels like a lot has been changing in the last couple years and it wasn't that long ago the web turned 30. So it might be a little bit too early for a midlife crisis, but it definitely feels like it.

The truth is the way we've developed on the web has changed pretty dramatically every decade that it has been around, and it is pretty fair to say that the past decade has been dominated largely by single-page apps. You can tell by all the React developers here today. But single-page apps redefined how we looked at building on the web. They gave us the ability to look at the web not just as a server client model but as an application, almost like mobile. We could build experiences that didn't require doing these full-page reloads and by relying on rendering in the browser, however, when the CEO of a company behind arguably the biggest React framework in the world makes a comment like this, people have got to go, you know, what's going on here?

It should give a little surprise that over time the tool size of web pages has grown. We've added more interactivity, more images, more styling, more of pretty much everything. We expect it to give the experiences that we come to get used to, right? I'm actually pretty happy that these graphs all exist. I didn't have to make any of these. This is from the web album. Great stuff. The size on our page comes in many forms, HTML, CSS, JavaScript. JavaScript is not the biggest thing on the page. It only usually makes up about a third on average. But it is what we are going to focus on a bit today, because it happens to be one of the most expensive assets per byte. I love that there are so many existing diagrams for this. This is from Addy Osmani's cost of JavaScript article from several years ago. It's a classic. If you've never read it, you should read it. The whole idea is he took a low-end device on a low-end network, and he kind of showed back then, I think it was 2018, that loading JavaScript byte for byte was about 35 times slower than images, just because of the parsing and execution time. This is on Moto G4 or something. I think they are still floating around today. This is from Alex Russell. He had this chart where he was showing that on the low-end side of devices, things haven't gone up the same way as others.

It's almost like going back in time eight years. Don't get me wrong, this might not be your customers, you might not need to worry about any of this, but it has kind of started this focus, I would say since around 2020, right? And the big part of this is that when you have a site that's client rendered, like a single-page app, you are doing a round trip again to the server right away. You send the HTML and you have the script tag that says load my JavaScript. Most of the time you're doing another round trip to the server, these waterfalls, which we will learn aren't a good thing, basically multiple before you even get to see the main content of the page.

So we thought, okay, let's server render it. You skip out that whole thing and see the content right away. But that's not the end of the story. These are all old diagrams. I'm just loving this. Just stick with me, I will be getting to a point at some point. But there's that time between when you see the page and when you can interact with it. They call it the uncanny valley. It's because when you server render a page, you actually end up sending more JavaScript generally, not less JavaScript. Kind of confusing but now you need to be able to hydrate the page and render the page. It's not only that you send more JavaScript, you actually send more HTML. Your payload actually gets bigger because now you have this lovely thing on your page. I'm not making fun of Next.js here. Every framework has this. The Next data blob, or the Svelte data blob, or Remix, or solid start, it doesn't matter. We all spit out this giant piece of data, so we send everything to the browser twice. Once is data, once is HTML. So yes, we see it right away, but now we've actually doubled our effort pretty much everywhere.

All right. So, at a certain point a few years ago, everyone was kind of going back to the drawing board. Now, as I said, not everyone is Amazon.com or eBay. I actually worked at eBay for a couple of years and that's where a lot of this insight came from me. But the thing is, our desire for interactivity has only increased during this time. At the same time, friend and frameworks want to be more, I guess, accessible to a wider market share.

They want to simplify their appeal to handle what I call the left side of the spectrum. What is this spectrum? Well, I can think of, Fred K. Scott drew this for me a couple of years ago. I don't think he ever published it. He was trying to put the frameworks in here, and he was a little controversial on Twitter.

But we've seen this kind of thing that there's kind of a spectrum from the very simple portfolio content sites all the way to Airtable, very app-like. The thing is, React was developed, the most single-page frameworks, to handle the right side. That's why they exist. But over time, even while there's a desire across the whole spectrum to shift more to the right, business needs have pushed us farther left. People who built apps with React want to build their websites with React. And understanding these businesses helps you understand what is pushing the direction of the web the last couple of years.

So what can we do? We probably can learn some stuff from the past, but this is not what we want to learn from the past, just straight up here. I don't know if anyone's had the pleasure of layering something like Knockout.js on top of ERB templates from Ruby. This was not fun. There are lessons here, but we can't do things exactly as we did back then. It's not as good as any better now than it was 13 years ago. Not really. We need these solutions to be more integrated, right? We also kind of have to identify where the bottlenecks are. I talked to a bunch of experts in the field and realized we need to solve three problems that impacted load performance without giving up what we like about single page apps. To be fair, we need to know if we can meaningfully change these things. For me, what that's coming down to is we need to talk about the code cost. I'm talking a lot about initial speed here. There are other metrics like INP that I think ultimately would be more important for sites in general as a unifying metric, but right now I'm talking about what drove a lot of these changes.

There are other metrics like INP that I think ultimately would be more important for sites in general as a unifying metric, but right now I'm talking about what drove a lot of these changes.

Code execution costs when your page starts up, code bundle size, so how much JavaScript you're shipping, and then the payload, the data size.

Testing code execution or benchmarking these things is pretty easy. You just need a large page to render. With lots of components, a lot of interactivity. You can just generate it. Same way, testing the payload is pretty easy, because if you have a lot of data, you can just generate pretty large pages.

And luckily both, or not luckily, unfortunately, both of those are areas of things you just have to deal with. You don't get the really... There's not like cheap ways to get around this. Ultimately, if you have a lot of data, or a high need for interactivity, the developer can't do much about it.

Bundle size. That one's harder to test in these kind of benchmark scenarios, because you need a lot of different code, and you're not going to write all that code in every single framework, and it has to be useful, because otherwise things are pretty efficient these days. You can tree-shake, you can drop it out, and you can code split. And a lot of those things you can do yourself. In a way, developers do have a little bit more control over that area. Just keep that in mind when I talk here, because I'm going to talk very high-level about these things.

For the last couple of years, I've been live-streaming and doing a lot of looking into different frameworks and how they work. I was very curious about how every framework works. I invite most of the framework authors onto the stream to build stuff with me. We all built the same Hacker News demo. I have Hacker News demos in dozens of frameworks at this point. It's a simple app. It doesn't do very much, but it has this really nice kind of hidden quality. Let's see if I can pull it over to see if we can see this. Check this out. This comment page has a ton of comments, but they're recursive, right?

They're indented. There's a bunch of touch points where you can compress and collapse them, and you see they're nested. This is a page that is very basic but has thousands of points of interactivity, and also thousands of items of data if you get a large enough page. I understand you would not load 1,500 comments off the bat if this is your actual website, but we are stress-testing here.

This helps me get an idea of how things are going, right? This is not an exact science. Did I get a ... no, I didn't completely get off the screen. Two seconds. All right. This is not an exact science, so to speak. Runs very ... I just use Lighthouse. It's the quickest way to test these things. Just to kind of show high-level architecturally what we are dealing with, right?

This is the same kind of thinking I went into when I was developing signals. I just wanted to know, like, are we doing the right things? How do I possibly evaluate all the different options in front of me? Okay. So, I took a baseline, and I basically took every server rendered single-page app framework that I had done, and they all actually scored pretty similarly on this page. I will give you ... I'm not going to tell you all the scores right off the bat. I will just tell you that the top corner is next page directory and the bottom corner is solid-start, but these things vary.

That was a pretty good run for solid-start, I think. You can kind of see that single-page apps score in this range, generally speaking. The real question is what can we do? Can we improve upon this? Because if this is your website, and you actually cared about loading, maybe your business, like in e-commerce, which got very popular during COVID, again, you're starting to see the connection, who's building the frameworks, where are they being built, e-commerce, customers, kind of start seeing these things.

This is probably the simplest thing. Islands have been around for quite some time. They got popularised by frameworks like Astro and Fresh the last couple of years, but eBay has been shipping open-source islands since 2014 in their Marco framework which not many people have heard of but definitely was very ahead of its time in this area. Basically, multi-page apps. This is about learning from the past, right? The trick here is, if you're going to do most of your rendering on the server, and you're never going to navigate on the client, then you never need to re-render most things in the client, and you never need most of the JavaScript code, you never need to send most of the data, and it starts making sense. The way you do that is break up your app into a bunch of sections and then decide these ones need to be interactive, these ones don't. This is from Jason Miller's article a few years back about they introduced and named it, coined it Islands Architecture. Different companies have been doing this for years but this is when it became its own thing. This is a bit like the past, but the key difference is islands are responsible for server rendering. You're not getting the ERB on top of knockout or react in an HTML partial. You're getting full responsibility.

You're getting full responsibility. It's like your React component on that page. Server client rendered. It's quite a different experience. If you've ever used Astro, you get great experience with HMR, and you can basically render islands in the framework of your choice. The win is you don't need to send or execute the JavaScript or even send the data for the parts that are server rendered. This minimises pretty much all the costs.

Before you go, Ryan, don't islands just grow? You can picture you add more features, you can do more things. The real trick here is that, and this is kind of like a code snippet, kind of fake, I've used React syntax here, is that you can project server content through islands. Everything that I'm showing you in front of you here is actually server content, so to speak, right? The client interactive parts are hidden behind those client island components I put. In this simple example, I'm rendering a bunch of headers on the server, and I'm even rendering a list on the server. It has client components in it, but the actual list data never needs to get passed to the client because the client components never get it as a prop. They just get essentially the HTML passed in as a prop, right? This means we can reduce, as I said, those costs at a very small level. In our Hacker News example, we can just make the toggle a client component or an island, and all the comments like the actual internals, the whole list, even hierarchically can be rendered only on the server. I tested it. It did pretty well comparatively.

This is a simple example where I used solid with Astro. I think it was, I mean, you could use React, or whatever, but the idea is the code execution disappeared. We had to hydrate 1,000 nodes but the cost of that wasn't too bad. The code size disappeared. This happens like 4.9 kilobytes. And most importantly, that payload shrunk. No double data because the list is rendered on the server. All right. I guess we're good. Solved it. I can go home now. Not quite. This only works because we don't have client-side routing. Now, don't get me wrong.

Multi-page apps have come a long way. The browser helps incredibly. There's something called paint-holding, so if you're on a page and go to the next page, the browser doesn't show the next page until it's ready. You can do cool tricks with streaming where you can have the app shell show right away the content and show loaders and stuff in multi-page apps. It feels almost like a client-side app. But there are trade-offs. You are loading all your ad scripts again. You can't do cool animations, right? There are still reasons you'd want client-side routing, right?

Luckily, you might have heard some news, this gif looks terrible large, but essentially, what about view transition API or flamethrower or turbo? They've been using this in the Rails community for a few years, right? It basically replaces your HTML without reloading the whole page. Well, on the surface, this makes a lot of sense. If you have a static site that you built where each page is independent, and now you want to switch between those pages, this works great. But it's a little bit more complicated when you want to persist state, when you're trying to build something that's actually an app. I don't mean keeping your video player playing across pages. You can do that. I'm talking about shared state, like things you put in a global store, right? You can even keep islands or references across pages. It is a little bit tricky in some of these frameworks, you have to be explicit about IDs, but these are solvable.

What do I mean about the state problem? If you've ever wondered, I'm using React-type syntax, but I want you to understand if you go and render a page on the server, initially, the client state is going to be nothing, right? If you could pretend we had a counter that started at zero, you render on the server, it shows the first path of code, and you're fine. But if you're now on the client, and you click the counter ten times, and now the count is ten, and you go to the next page and you load this component, how does the server know that it's ten? It doesn't, generally speaking. Unless you encode it into the URL. Basically, it will see zero again, render in this case, if it is zero, it will render some other component, and then you get to the client, and the client goes to wake it up to hydrate it, and it thinks some component should be there, and what do you think we get? I don't know if you've seen this one before. This is from Next, to be fair, but I think we've all seen this error if we've done any server rendering, generally speaking. Hydration errors are kind of painful, and the truth is lazy hydration is pretty much always dangerous prospect, because, at any point, if the data on the client changes between the time you server-rendered it, and you interact with it, it is probably going to break. This isn't restricted to routing. This is something we have to be conscious of. Now, again, we can solve this. We can be selective when to render components on the server or when to render them on the client. My point is, you start going down this path where something that is simple like throw an island on the page starts becoming tricky, right, because you break them into smaller pieces, now you need to share a state. You want to share it across pages. You basically end up building a framework on top of a framework. So what if you just started with all these assumptions already in place, and maybe take care of a few others? You might end up with something like this. Right? And those additional things that I didn't mention before, like how do you handle, you know, async data? How do you handle things like out-of-order streaming, coordinating between the different islands? It could be done with islands, 100 per cent.

But you need to do this extra work which you probably wouldn't expect, and maybe those frameworks don't even support for you. So React's solution is pretty easy. Take islands but instead of communicating in HTML, communicate in your own diffing format. Basically treat everything as a normal React, VDOM tree. Guess what? Then you get a whole bunch of stuff for free. You get context, you get handling of, you know, async data. Basically, everything that you get from normal React you now get in this kind of architecture. Right?

The whole trick to this is that server components generally, by their name, you can tell, they render on the server. But client components only render on the server initially. As a second pass. Every other time, client components only render on the client. So we don't have that weird state-tearing problem that I was talking about a moment ago. This kind of solves a lot of the problems with islands when trying to build applications. So it's pretty cool.

But unfortunately we've kind of regressed in our goals again. Well, this does score slightly better than our next pages directory, and this is next app directory version, because the code execution definitely reduced, and the code size actually had the potential of reducing, but in this example, it didn't, because we've kind of raised the floor. Now we have more code as an up-front cost. Yes, additional static components will reduce the size of the page, but generally speaking, you need a bit extra code to do server components in the first place. I think even the older page directory version was slightly smaller in this case, but generally, that's not going to be what is going to happen.

It's important to recognise that server components would scale better. But again, for some people, maybe using a different framework, let's say, something maybe smaller, that gap actually still might be so big that it never catches up. But the most important reason we end up back here is because we introduced that diff format. Hydration is really awkward. It's one of the most awkward things you ever have to deal with for everyone. But in the future, in order to be able to diff, React needs to know what to diff from. You end up with sending both the HTML and the diff. Double data again. We're sending all that data. Can we solve this any other way? Last year, I believe we had a talk from Misko Hevery talking about resumability, which is a pretty cool idea. Instead of eagerly hydrating things, you serialise the state of the framework so no hydration needs to happen.

This means in many cases, code doesn't even need to be in the browser initially. It's pretty impressive. For the cost of needing to serialise a few extra client-server boundaries, we can reduce the execution cost on the page to basically zero. This is the scaling thing. I mean like basically nothing.

Does it work? Making this demo in Quik got me this, which is pretty impressive if you've ever used Quik. There is no concept of islands, you just write your application codes and it spits out results like this. It addressed all three challenges while letting me write my application as this single app model. Code execution reduced, code size reduced, and most importantly, you stopped double-serialising again.

Except, I noticed something. My site was an MPA again. In fact, most Quik sites are MPAs. So I was like, okay. They released a client-side router, so I updated my anchor tags to links. And guess what? This happened. Are you guys starting to notice a pattern here? It basically scored the same as my RSC demo and scored the same as my Solid Start demo.

The reason is the double data came back. Obviously, I made this example, so, you know, put that testing bias in place. But clearly, the cost of serialising a lot of data is pretty big impact when you consider Quik basically runs no code when it starts up, right? So the hydrating the 1500 or whatever comment components actually didn't make a dent compared to doing this data serialisation. And the reason that it happens like this is unlike islands which have specific boundaries, Quik was using its smart compiler, the tree shake-out, that extra data. It could tell, you know, oh, this could never update, let's not send it to the browser. But a router has a funny way of moving all the decisions to the top of your app, right?

You have an app bar and the very first thing you hit is should I show this page or this page? If you're in the browser and you're not explicitly like this is server only, then you might end up with a case where you don't know what you're going to show in the future, so you're going to need all that data, right? That's the only thing that we do know, that we may need that data in the future, so we have to send it.

All right. So what am I trying to say here? There's a lot of innovation going on since people are trying to solve real problems, and we've seen a lot of successes. But we still have that site versus app split today. It might not be there tomorrow, but these solutions are still not quite there yet. And to me, actually, that's not a problem. That's an opportunity. Both from the perspective that the answer is still out there, and that things aren't so cut and dry. Every framework actually is benefiting from all the innovation going on right now.

You're seeing this right now. All the frameworks are actually getting the same features as other frameworks, right? As this exploration is going. Getting out-of-order streaming, use server-style RPC calls with advanced crazy serialisation. Seamless waterfall-less data fetching, single-flight mutation and fetching, right? None of this is specific to any one of these approaches. You could do it as readily with RSCs as you could do with solid start, or maybe Tanner Lindsey is working on a new framework I heard.

All these approaches start somewhere. And what it means is we're not done yet. For many of you, that might be a scary proposition. If that's you, don't pay this much mind. No-one is going to force you to use RSCs or adopt signals. But if you're interested in seeking out the future, you know, come find us. We're building.

I'm Ryan Carniato, creator of SolidJS. If you want to continue the conversation, follow me on Twitter, check out my YouTube where I explore this stuff in depth almost every Friday, or come talk on the SolidJS Discord. Thank you! Thanks a lot. It was a solid talk, but not a bad solid. I just love making that joke. Sorry. It never gets old. I'm probably not alone in that. I hope. I'm a dad, so I'm allowed to make these kind of jokes.

So if there's any more questions, you can do so still on Slido. And please take a moment to also rate the talk of Ryan for any positive and negative feedback. But probably only positive. All right. First question is from our valued audience member Anonymous. Have you compared the JavaScript frameworks with WASM framework like Laptop for Rust? Yeah. I mean, WASM frameworks are... If you're walking out, please try to keep your voice down a little bit.

Because else we can't understand the Q&A. WASM frameworks have actually come a long way in the last couple of years. They... How should I put it? They've gone to a point that their update performance in the browser is similar to JavaScript frameworks. In fact, more performant than some of the more popular JavaScript frameworks.

The tricky part with WASM is you still need to load all the code in, and they tend to be very large. But I've seen some really cool projects in that space. Stuff like Leptos was one of the ones I'm familiar with. It's similar to Solid, so I'm more familiar with it. But they even built islands in WASM and partial hydration solutions to kind of help with code size. They've been learning from the JS frameworks. We spend so much time trying to optimize. They need that optimization even more in terms of loading. So yeah. I think if you have a specific need for the performance of WASM, it's a good fit. As a general-purpose framework, the impact of the initial load might be prohibitive to you. Yeah. All right. Thank you. Let me get rid of this. Next question, also from Anonymous.

What's the ideal future outcome for frameworks and the web? I mean, that's a pretty wide question. We actually have a panel about that this evening. So you might want to check that out. I do think, though, and the point of my talk is that this change is still going. We haven't slowed down. I know that's, again, scary, but we're still learning things, and we're still evolving, right? It's a tricky problem to have a network between you and your user. So it takes a lot of work and a lot of incremental back and forth until we get to a point where we can actually solve this in both ways that are easy to develop for everyone to come on and being performant enough to deliver the experiences that we want. Cool. So everyone, check out that panel later on today.

Next question. How has React 19 changed or impacted and empowered Solid Start? Are you guys just setting up questions? There's a panel on React 19 literally right after this as well. We'll ignore this question for now then? Maybe. You want to answer there? I'll answer there. Cool. Yeah. So next question. What about new partial pre-rendering next is? Isn't this the same as islands? Same as what? What about new partial pre-rendering next is? Same as islands, no. Islands are more similar to React server components. Partial pre-rendering is a technique almost like the old purple pattern. It's the idea that you conserve the static shell right away and bring the rest of the dynamic parts of the app in, stream it in. It's very, very similar to out-of-order streaming from the edge, which a lot of frameworks actually support. It's a proprietary technology mostly currently because it uses the infrastructure to do this, but from like an architectural standpoint, from a software side, it is basically the same as out-of-order streaming. Okay. Thank you. A question from Harry. What exactly did you get, what did you do to get to 63 and audit with Quick, use Quick navigation? We did not have that issue. No, I literally added a link tag. I shared my results on the Quick Discord with members of the community a few weeks ago, and we went over it. Honestly, what I did was make a page with a lot of data. That's not supposed to happen. Yes. All right. Ryan, what is your thought on HTMX? I get this question a lot. To be fair, HTMX is a primitive in a sense. It gives us the ability to do kind of basic stuff, you know, where we can just ship these HTML partials. My opinion is it's a lot like that ERB plus Knockout.js that I was showing earlier. It's one of those things where you take one step backwards and go two steps forwards. I think there's potential that a lot of sites don't need the interactivity, they don't need the things that we strive for in front-end frameworks, and it's a great fit there. It takes a lot of pressure off people being told they have to use React, so to speak.

But it's something I'm generally not interested in at all. Since you mentioned the blast from the past, did you also ever work in Flash? Not a ton, to be fair. I guess I worked in Silverlight. I was in Microsoft's shop back then. So kind of the same thing, I guess. No, no. Not the same.

Next question. I want to use Solid Start on our project but lack of tools supporting it makes it hard to switch over, and I cannot reinvent all tools myself. What can we do? I mean, this is always good. These adoption questions are always interesting because, yes, it's a real problem people face. You create something new, you have a fraction of the community behind it, you're not going to have the same amount of support as you have from larger tools or frameworks. But it's also the catch-22, you know, someone has to do it first for it to happen, so, I mean, if that's not you, that's okay, I respect that. But someone is and is going to. It might take some time, but when you do good things, good things happen. I mean, this is an old quote from Wayne's World 2 or something, or maybe even Field of Dreams, you build them, they will come. That's all I can look at here. Our community has been growing a ton, we have a lot of great component libraries. Solid Start, it's interesting, good point. It just got to 1.0 two weeks ago. So again, people are already asking for this stuff. I think that's a good sign. Is there any user that you know of, Solid or Solid Start that you're really proud of? We know from React, they got the Netflix buy-in. Is there anything that you're really proud of? Mostly a lot of start-ups have been getting into it at this point. Again, it takes a lot of buy-in, we have internal customer usage, but a lot of the external stuff might not be as big companies. We've had stuff like Post.News build their start-up on Solid Start. We've had, but again, during the beta phase, it literally just released like two weeks ago. Stuff like Stashpad, there's a lot of smaller sized start-ups that have been building stuff on that. I hope to have more news on some of the bigger projects coming out soon.

I hope to have more news on some of the bigger projects coming out soon. Solid itself has been stable in production now for four or five years, and you see it on a lot of stuff. Solid Start is just freshly coming out at this point. For the people that don't know Solid Start, can you give like a five sentence run-down? It's a meta framework that hates meta frameworks. I wanted to take the essence of something like Vite or create React app, where you didn't feel like you were using a framework, and give people the tools they needed to be able to render stuff on the server. We support single-page apps only, we support server rendering, but the idea is even the router doesn't need to ship with it. Solid Start starts at 5 kilobytes, and you can add whatever you want to it from the Solid ecosystem as you go. It's basically designed for builders. We want to create T3 apps for the world and the redwoods, and those kind of meta frameworks come and build on us because we give them the most power and flexibility and performance.