Ryan: They showed me Marco and I just, my, my jaw dropped. I was just like, is this possible?
The streaming and. All the stuff and I I already knew I was in a place where SSR was going to be important. Like it was very clear at that point.
I actually pushed back solid 1. 0 was released until I
was confident there would be a good SSR solution.
[00:00:21] Introduction
Andrew: Hello, welcome to DevTools FM. This is a podcast about developer tools and the people who make them. I'm Andrew and this is my co host, Justin.
Justin: Hey everyone, uh, really excited to have Ryan on. Uh, Ryan, you are the creator of SolidJS, uh, and I'm so excited to talk about that. Uh, Solid is a pretty interesting front end framework, um, and I would love to hear how you describe it and talk about how it contrasts React and the evolution of the ecosystem and all those things.
Uh, but before we dive in, would you like to tell our listeners a little bit more about yourself?
Ryan: ~~Um, ~~yeah, uh, it's funny cause these days I am mostly defined by my work on solid JS, but, um, I was just a developer. I've been building on the web since, uh, the nineties when I was an early teen. Um, and I actually. Built, um, a lot of like JavaScript early days, and then I kind of went through the whole dot net thing through the two thousands and, uh, came back to JavaScript around 2010 around the beginning of the single page app framework.
So, um, and I've been very invested in front end again, never since then, but, um, yeah, I, I built products and built websites for, um, God, it's. I don't even know, it's like 30 years now or something, almost, yeah, I guess 20, 28 years, so.
Andrew: Cool. Let's just pause for a second. I have to stop, restart the recording because I'm on the wrong mic.
Andrew: ~~Cool. ~~So
[00:01:30] The Origins of SolidJS
Andrew: , uh, let's start off with the, the big framework you're mainly known for solid, uh, you told me before the recording, it was actually created a lot, a lot further in the past than people might think. So can you tell us about like the conditions of like when you started it, why you started it?
Ryan: Yeah, um, 2010 getting back in JavaScript was amazing for me. I had been doing all this dot net programming a little bit of Ruby and PHP before that and. It was fine, but there was something really awesome about going back to just building, um, with, you know, HTML in a sense in JavaScript and single page apps were like that all over again.
And I found, um, a JavaScript framework that I really, really liked, um, called Knockout JS. Um, and I don't know what about it appealed to me. Um, there's just something. weird about its model. It had these things they called observables. Um, it's funny because these days we call those signals, but it basically let you kind of write your state, um, in this way that you could just update it and it would, you know, just make those exact updates on the DOM.
And it was really cool because it didn't really care about much else. It was just all based around, um, these observables. And, um, I don't know, it was, yeah. Something clicked for me. I, I, I'd always made, tried when I first got into programming, I really wanted to go into game programming and, uh, I spent a lot of time, you know, playing around with DirectX.
That's how I got into dot net and whatnot and something about Knockout, funnily enough, pulled out a different, um, old influence of mine, which was, um, programming circuit boards. I'm actually, uh, yeah. Um, computer slash electrical engineer by trade, um, not computer science. And, um, there was this whole idea of like, if you apply to change, it would apply everywhere at the same time, like when you're modeling hardware.
And, um, I just knew instinctively how to program that way. It was just something that always made sense to me where your data itself was. Also like declarative is the best way to put it. It wasn't just your like you UI, but your data, um, anyways, jumping forward a bunch, it was a cool concept. It was a bit messy.
There's lots of problems with Knockout. js. I'm not going to hide those. If you fast forward like four or so ish years, um, no one was doing this anymore. Um, mostly because of, uh, React come out at that point and they were like, You know, worrying about state changes and all this is really complicated. Um, you know, just forget about it.
We've made it. So it's good enough to just rerender everything, right? Like instead of worrying about stuff, ping ponging all around your app and stuff changing and not know what's going on, we'll just. Wipe it out and start over again, essentially. And the funniest thing is this is, this is an old thing in graphics.
So actually there's, there's an idea of something called retained and immediate mode and, um, react was, um, immediate mode. It means you don't keep the artifacts around from time to time. You just replace them as you go. Where retain mode is about mutating an existing model and in. Game programming, almost everything at that point had gone to immediate mode, right?
Um, it had some benefits like constant frames per second and all those things were, uh, retained mode could be incredibly performant when nothing changes, but it was unpredictable what would happen when stuff did change. So there's a lot of philosophy or ideas already behind these different approaches.
But as it turns out, the Dom itself is retained mode, right? You have this. Model that you update and mutate. So there is this kind of discrepancy of trying to apply something almost like a game engine on top of the Dom because the models they have to abstract, like they're, they're not one for one. And when react got popular, it irked me a bit that, There's a lot of claims about performance and all these things. And I'm like, no, I'm, I'm pretty sure stuff like knockout that leverages the retained mode approach are more performant. And personally, I just liked the model, the whole class components we had back then, like, and, um, the whole, um, kind of re rendered data.
I mean, sure, that fits fine for some people, but for me, I'd gone really. I really like that thing from Knockout where I could just go, like, create an observable, create some state, create some derived state, and then just put it in my UI and only those pieces update. Um, there's just something that just felt natural to me.
I admit at that time period, I didn't think anyone else was on the same page. Um, to be fair, the other popular frameworks, like, uh, Angular even, um, was like, look, we don't have special data. You just update normal JavaScript objects. React state looks like normal JavaScript objects. I didn't think anyone was going to bother trying to do this kind of special data.
And the problem was Knockout JS. No one was really updating it anymore. So I was kind of like sitting there. I used to professionally at my work in production. We had these Knockout apps and we kind of built our own patterns on top of Knockout to make it more predictable. Old Knockout. I mean, as I said.
There was problems. It would ping pong all over the place and, um, the rendering was not very performant. Every time you added, they had these weird data bind things. I don't know if you've ever seen this, but whenever you added a new template to the page, it would have to, like, make the HTML elements and, like, parse for these data bind attributes and then apply them and then apply the transformer.
It was not. particularly performant. So when I kind of stepped back, I was like, yeah, React got a lot of things right, both from like, um, tooling perspective, things like JSX, things that allow us to like, not to do work ahead of time, not parse through these. Big Dom, you know, trees and also just like unidirectional flow, all those kind of philosophies about, about control and expectations of how your app should be the early days of JavaScript on the web were ones where we really had no set way of doing stuff when we were just doing, you know, jQuery imperative type stuff, as the need got greater, we tried to build frameworks, you know, around 2010, um, but we didn't really have an idea of what.
Best practices are right. And I mean, the very first big react talk was rethinking best practices, right? This is the kind of thing that I realized react had a lot of really smart ideas in terms of bringing predictability and consistency. Um, And it was easier to work with the teams, but I still like the other models, um, regardless.
So, you know, I was looking at these things and around, uh, 2015 ish. I was like, very clear that knockout wasn't going to get updated. I was looking at some other projects, like a technical knockout or whatever. And I had this problem. I had knockout of production code and my work. And I was like, maybe I could just make like a lighter weight or alternative, like maybe something use compiled templates, updated the tooling and kind of get like knockout.
Um, back again, and, um, that would become solid JS eventually. I, I didn't work, I've worked on it like here and there, like little ideas played in little examples. And then I finally was like, okay, um, it's on a private get our sort of actually bit bucket, I think, but at a certain point, about mid 2016, I just made a commit where I just like made a repo called framework and I just put in these ideas that I had.
And at that point, I, I didn't have stuff like JSX. I had like. Templating that looked a bit like views or angulars, like S if and S for, you know, um, I had like, you know, I was just kind of playing around with these ideas, but I had, uh, A system where the, the signals were in the forefront, uh, so to speak, where the, the, the reactive data was right there in your face.
It wasn't hidden, like, even view at that point, tried to make their stuff look like plain objects. Um, so I was like, I found a pattern that I liked from my work and then I decided like, okay. Let's let's give it a shot to be fair again. I said, no one would like it. So I just spent a couple years there playing with it, you know, in my own little private, uh, repo and, um, a certain point I was like pretty proud of what I'd done.
And I was like. I want to prove that this approach has wings. So I started looking for online benchmarks. Um, there'd been some in the past, like these funny, like circles, demos and stuff. There's lots of ones. There's a, uh, uh, Ryan Florence, um, remix, uh, react router had actually made this like DB Mon database monitor one that showed like reactively fast because of the way it could dip the whole page of data, like multiple times a second, and I just.
Collected all the benchmarks that people used and was like, okay, does this have wings? And that actually forced me to actually open source the project because in order to actually put the thing in the benchmarks, I needed, I need to actually have it released. So, um, that's what I did. And that was, I guess, April, 2018.
It was shortly after I'd made the decision to switch to JSX. Um, I actually had come across a different library called. Um, or surplus and no one, it's not a particularly popular one, but they had actually used signals with JSX. And I, it blew my mind. I was like, this is what I wanted to do. I almost just dropped my project.
It was like, can I work with you? Adam was the name of the maintainer. Let's let's do this. Um, and. He was like, I'm very busy with my startup right now. I wanted to add all these features because I was really into proxies. I was like, in my head, I was like, I told you no one wanted declarative data. So I was like, maybe there's a way that I can make proxies, like the baseline and then people won't feel it like the difference, but the trick, the hard part about making proxies, the baseline is he had a very smart heuristic where he'd look at the JSX and look for any place where a function was called.
And if a function was called, then it would know to like, make that a reactive expression. Um, If I added proxies, then every single property access in the JSX would also become a reactive expression. So there was changes that had to be made. I started realizing that when I took my react patterns and people would You know, access data at the top level in the component, like destructuring props, like it would cause whole sections of the tree to re render randomly because it's a little bit complicated, but like, there was, there was a bunch of like issues with reactivity and nesting and, you know, this unpredictable ability, basically, and I was like, okay, no, I needed to solve this.
So, um. Uh, it took a little bit of time playing around with it. Um, for the most part, I wasn't too worried about components because I was a big fan of web components. Um, that was like how I thought the future was going to be. So I was like, okay, I'm just going to focus on the reactivity. I'm going to use web components for the components and, you know, let's go.
And, that was basically the start of solid. Um, no one really cared that much. I mean, to be fair, we started winning at those benchmarks. Um, right. And, uh, not just the ones that we'd expect to win, but even the ones that were good, like based on diffing, like VDOM, like, uh, the proxies were the key. I realized that using proxy data diffing, ~~um, ~~we could also have performance where diffing was required.
Things like Ryan Florence's benchmark. And. I guess coming into 2018, ~~uh, ~~coming to the end of 2018, I was pretty happy that I'd come up with a pretty performance solution that worked for me and if no one else liked it, who cares? Um, but the big changing moment for, for, for the project was actually, uh, October 26, 2018.
I remember this date, um, because that was a huge date for us and it was when Dan Abramoff came on stage and introduced the world to React Hooks. ~~Um, ~~because when that came out, it was like being in the eye of the storm. If you, uh, solid had JSX and signals, it basically looked like modern react with react hooks, and I didn't think anyone would like these patterns.
But when they were like here, you know, use state, use memo, use effect. It looked identical to what we were doing with solid. Um, and I was like, wow, I mean, I did take the JSX from them, but they're actually telling people that they should like mark and make their data look declarative and bigger shock for me at that time was even though it looked the same, it didn't work the same.
I was like, I actually think what we're doing might be better. Um, like they, they simultaneously pointed people in a direction where the, the kind of way you authored components look the exact same, but the mechanics behind the signals, um, are~~ really, really,~~ really powerful. And I wasn't the only one who noticed this, um, right after that announcement, um, Rich Harris was like. Started going, Oh, we could do something like this. And he's like, well, screw it. We're a compiler. And that was what triggered Svelte 3. Um, and also within that same week, Evan knew from Vue was like, we're going to expose our reactivity system. I said, Vue had signals under the hood the whole time, but they didn't let you use them.
They were like, just use these option data objects that they saw the hooks. Oh, we can just use our reactivity directly, like, like the old knockout days, basically, and this changed everything because suddenly solid was not only, um, top of the benchmarks for an ergonomics DX standpoint, it looked like the, the best practice for how you should author UI.
Um, so it was, uh, it was, it was definitely that's when it put on the map. I started writing articles on Medium trying to teach people about these concepts because there are differences in React components. We render and in a reactive framework with fine grained render like solid. They don't. It's only the expressions where there are signal reads.
I'm not sure how familiar the audience is with this at this point. Um, it's kind of funny because. Outside of the react ecosystem. Now, these ideas have almost completely taken over. But, uh, back in 2018, that was not the case, or even 19, or even maybe 2020. Um, people were like, Oh, no, you're bringing the magic back.
It took A couple of years with hooks for people to go, Oh yeah, this is more tricky. You know, I used to say that was like the, the, the line when you started having to use ref for things that were not DOM elements, you've known you've, you've, you've crossed this line. Cause once you have to stop putting stuff in state, cause you're worried about re renders happening, um, or to share state between different effects or different, you know, calculations, you know, that, ~~um, ~~React has gotten away from those classes components.
So like, yes. It re renders, um, and that part's simple, but you're no longer can ignore the way your components update, which was the React's original selling point. And given that my perspective has been that it's actually easier with a reactive model to see what updates, because it's like, it's right in front of you.
There's no outside of the hook. It's this hook depends on this. It, it updates. There's, there's, there's no like stale closures.~~ So, um, yeah, sorry, take a breath of water. Those talk in there for a bit. Yeah,~~
[00:16:19] Ad
Andrew: We'd like to stop and thank our sponsor for this week, but we don't have one. So if you'd like to sponsor DevTools FM, head over to DevToolsFM slash sponsor to apply. And if you want to find another way to support the podcast, head over to shop. devtools. fm, where you can buy some merch and rep the podcast.
With that though, let's get back to the episode.
Justin: ~~in. ~~So you've also been the, uh, one of the. I'
[00:16:41] Marko.js
Justin: m the core maintainers of Marco JS and Marco is a very fascinating framework that I feel like was very ahead of his time too. I actually talked to Patrick back in 2016, 2017, maybe. I don't remember exactly when.
Uh, so Marco was sort of made at eBay. That's my understanding. And they were kind of using it and it had all these like incredible features that like, I remember trying to do. Uh, the server side rendering story for frameworks like react and view and everything used to be not great. And there was like no streaming server side rendering in particular.
It was like all blocking for basically all modern frameworks or modern at the time. And I remember like Marco had like a really elegant solution to this, like way before other teams were like really being able to get to it. So I'm interested to hear about the story of like how you started working on that and how it shaped your thoughts on solid too.
Ryan: definitely. Marco has been a huge influence and Marco, ~~I, ~~I couldn't believe it when I was, when it was shown to me that this existed. Um, it actually, the story and Marco actually. Picks up almost right after what we were just talking about. I started writing articles on Medium and I was doing performance, um, testing on components, but the bigger implication of the work that I was doing with solid was that component model doesn't have to be the update model. Basically, yes, you write your code as components. It helps you modulize, you get all the benefits, you know, from code organization that you get from something like react, um, you know, you can have these reusable pieces, but there's no need to say when you update some state that the component and all the components underneath it all have to like re render.
And what was important about this is as I was testing these extreme kind of more benchmark testing things, looking at the. Real cost of components when I called it, um, I kind of came to the conclusion that in a lot of frameworks, components were. Pure overhead. Um, a lot of classically, a lot of reactive frameworks made components really expensive.
They made them like an interfacing point where, you know, it was doing all the like reactivity was resolving and the coolest thing, but a virtual bomb is that you can just call the function over and over again. And there's like. There's costs, but it's not as much. And I borrowed that concept from react also because I used web components at the time.
So when I introduced my own component model and solid, it was very lightweight. I was like, Oh, if people want like the thing, they'll use web components over time. My benchmarking, I was like, Oh, actually I just don't need or want the web components, but essentially this basis meant that I was looking at how to do these little.
Pinpoint updates, um, and ways of keeping the code really small and efficient, um, without, um, this kind of overhead of components, but with the DX of it. And this was actually very interesting to the Marco team. They actually found me through my medium articles. Um, because I was writing these like concepts, looking at these benchmarks.
And, um, by the point Patrick had moved on from eBay, um, and the team was in the middle of doing a big, big migration from, um, Marko three to Marko four, um, and essentially they saw that the work. Getting rid of the components and using this fine grain, uh, reactivity also applied to the problem of hydration.
They were actually the first ones to see it. They realized that if you had this knowledge of the graph, what data updates, what data you could tree shake away all the other code. Like it doesn't need to come to the client Marco was popular, although I didn't understand it at the time for inventing a concept these days known as islands, where you essentially have client only components kind of sitting inside this server tree server components are actually kind of a similar concept as well.
And this allowed them to ship a lot less JavaScript for mostly static things. Like if you look at a site like eBay, there are interactivity points. It's a cart, um, buy buttons, these parts, but there's also a lot of just static markup. And it's really important for eBay to get good SEO, to have stuff come at, uh, very performant at load time.
They needed to reduce JavaScript. And the reason there, um, was because they had really old backends in Java. And they knew they wanted to move fast and do modern stuff to move to JavaScript. And because performance is so important, they basically couldn't make that move unless they could show that a JavaScript web, uh, uh, sorry, web server could be as performant as the Java one.
And that was pretty steep.~~ Uh, they, they,~~ they had to work really hard, uh, to come up with technology approaches that we haven't seen. They had. Uh, their own bundler called Lasso at the time, which basically was doing dynamic on the fly bundling, both in dev and prod. It's funny, we haven't seen that actually again until Vite came out.
Like there was like between Lasso in 2014 and Vite in around 2020, like the whole web package was not that, um, and they had these islands and then they also, the other key was, uh, out of order. And in order streaming, they had to be able to send the HTML down as is ready. So the, basically if you have, you're talking to like dozens of different services, you can't have the slowest service on the page, slow down the whole page for rendering.
This is not a new technique. Um, we've been able to do this kind of chunked encoding, uh, since 97, I think. And it's funny because frameworks have always. Even on the back end, played around with it, but maybe not embraced it in the same way, like big companies, definitely, but it's like a base feature when you go pick up PHP or Rails, they're not like, here's your out of order streaming.
Um, and Marco team in solving this really inspired by actually Facebook of all places. Um, they had something called big pipe. Um, uh, and this was a way of streaming and assets. And streaming in, um, the views and stuff for all these different services and kind of weaving them together. It might sound a bit like microservices to you, but it's not necessarily about microservices.
It's about understanding that, um, you know, parts of the page, part of the assets can be loaded in, streamed in. Um, as they're ready and this means that your long tail gets a lot better. Like you don't have this problem of like the whole thing getting blocked and uh, Marco was such a framework and they released it open source, which is even crazier, 2014, 2015, like the thing that these are the features that we got really excited about in 2021 Marco had it back in.
2014, of course, I didn't know this when I, I started talking to guys in 2019 and, and, you know, they were kind of, I didn't even realize they're looking at hiring me at the time. I was just, you know, chatting shop, talking frameworks and stuff.
Ryan: They showed me Marco and I just, my, my jaw dropped. I was just like, is this possible?
Ryan: And like
Ryan: the streaming and. All the stuff and I was like, okay, I already knew I was in a place where SSR was going to be important. Like it was very clear at that point.
I actually pushed back solid 1. 0 was released until I
was confident that there would be a good SSR solution.
Ryan: So I was ready to push.
Pull the trigger and release solid 1. 0 in 2019. But I, I didn't because I was like, I want to make sure the APIs and stuff are right. Cause I saw Marco and I was just like, like some people are like being nerd sniped. I was just like, this is incredible. Like, how does no one know about this? ~~Um, ~~In any case, uh, it was an amazing opportunity.
They offered me a job to work on the team, um, relocate to San Jose. I'm a Canadian, I'm from Vancouver. So it was like a whole different thing. I left my startup and ended up, uh, you know, working for big tech in California and, um, complete life change. And it was incredible. The amount of stuff learning, seeing how the, you know.
Performance mattered at scale for these kind of companies because we'd have product teams coming This is my first time on the other side because like I was a product guy. I was a product lead Um, you know, I I delivered products and being on like the platform side You suddenly have all the product teams, you know Blaming you for every possible thing that they end up doing wrong or you like support efforts were huge You know, you can understand how stuff, you know takes forever in these environments why they have so many developers But the marco team was actually when I joined I was the third member.
Um, so Supporting basically all of eBay. It was, it was, it was a lot. There was also a team that did UI and components that we worked adjacent with, but this was not a big team. And it was an interesting time because, you know, a lot of like contractors knew people coming in, we're like, why can't we use react?
And it's like, React is, would not be suitable. We wouldn't be able to keep our performance, uh, you know, so there was a lot of resentment against Marco, not from like the people have been there for a while, but, and people understood, but from, you know. These, you know, contracts, people coming in. It was, it was, it was an interesting balance and the leadership had shifted around when I joined in 2020.
Um, there was some kind of scandal. I don't know the details, but the CEO of eBay was replaced. Um, so, like, it was, it was an interesting time because. What the team needed, funnily enough, even though I got, uh, joined for a technical reason was that they needed some of those, you know, go to bat and make sure that people understood the importance.
So I actually worked a lot on education and training materials, which are also spreading the word out to the wider ecosystem. Because like Marco had these crazy concepts, things like, uh, async fragments that they introduced, which these days we call that suspense. Like it was like. Almost a decade ahead of its time.
Um, and it was available in open source and no one had any clue. And I started realizing, looking at this, that there's a lot of technologies out there in open source that have that kind of potential, but they just aren't popular. So no one. Knows about them and sure they might eventually, uh, get adopted in part and stuff, but like, can you picture, you know, being able to build your site, have this kind of power at your fingertips, like a decade before, you know, it becomes semi common practice.
Like it's, it's a complete game changer if that mattered for you. And, um, uh, it just inspired me to do, do more. Right. Um, I, I took that learning from how to do server stuff and applied to the solid. Um, so solid did eventually 1. 0 in, uh, 2021. I, I, I started working on salt start, which is a metaframe for solid also kind of pulling in that server side rendering knowledge.
Um, but yeah, Marco is incredible. ~~Uh, we, we, we've been, ~~we'd been working on the next version of it. Uh, which is not out yet. Um, Uh, which I told everyone I stopped talking about it until it came out. It's just, it's really hard when you, you're sitting on a technology that seems so incredible, uh, um, Mark, the, that fine grained signals based stuff that I was working on, but inspired the work for the next version of Marco is it hasn't been released.
Um, but, uh, it actually got released by another framework first, um, called quick, um, which essentially, uh, is resumability we realized. That, um, this technology, uh, doing the fine grained, um, signals with this kind of hyper, ~~um, ~~narrow hydration and, um, uh, compiler analysis would allow us to ship even less JavaScript run less.
It's, it's, it's crazy. This was the first time ever that I'd seen taking a very interactive. Something like a to do MVC, something where you're like clicking on every possible interactive, like a simple demo, and it actually gets smaller when you SSR, like, it kind of makes sense. You're like, oh, yeah, you're offloading work to this server.
But like, how much can you offload to the server when you have a counter and buttons and rows that need the change and toggled state and all this stuff? How much can you can you offload to the server? Well, as it turns out more than you would think. And, um. In most SSR, that isn't the case. When you add server rendering, your JavaScript gets larger.
Um, which is interesting. Um, yeah. Marker was really important, uh, for development, at least in Solid. It's just understanding that we were nowhere near where we need to be. Um, there's just, there's a lot of places and space um, in this. I don't want to call it like in this kind of front end zone that, um, is still left to be
explored.~~ ~~
Andrew: why why do you think Marco never caught on? It's so far ahead of its time for so long. Uh, it, it's kind of sad that it never got a wider appeal.
Ryan: Yeah, there's, there's a couple of things. Uh, Patrick left, um, which is hard when, when you have frameworks, I mean, if eBay pushed the same way, maybe meta pushed, it might've been a bit different, but that when you, the primary author leaves, like what would have happened? If rich Harris left before spelt three came out, um, or, you know, like, I I'm not sure it's, it's tricky.
Um, the other thing is Marco was a bit extreme on his templating. I mean, If we want to talk about pioneering or being innovative again, they had single file components, but they also really heavily used their compilation in terms of special templating syntax could Marco kind of view themselves as like an HTML plus kind of scenario.
It's funny these days. I think it would be much more accepted, um, so to speak. Uh, but like. We're talking again, Svelte 3 kind of brought compiler to the masses. Marco was doing this back in like, I'd say Marco 3 on 2015 onwards. So about four years before Svelte and sorry, Svelte 3. And like people were just not ready.
Like the syntax, I'd see something in it. People are very sensitive to that. Um, it was there for mechanical reasons for compiler analysis, but. Um, yeah, I think it was just a weird zone. And we're talking about a time period when everyone was talking about single page apps. So when Marco, I mean, I even hit this in 2019, 2020, we kind of talked to people, Marco, you'd be like, Oh, here, check out this framework.
And they're like, okay, so, uh, what, what's the go to state management? And it's like, uh, whatever you want. I mean, state management isn't really the focus, but I guess you could pull state management. Okay.
[00:30:09] The Router Debate: MPA vs SPA
Ryan: How about the router? And we're like, Uh, there is no router, um, and you're like, what it's, it's, well, because it's an MPA framework, like Astro, you don't need a router.
~~Um, ~~and also the conception is like, oh, MPA, like that old stuff, you know, you full page reloads like for type of Things that you want fast page loads. ~~Um, ~~that is fine when you're loading product pages, you can Google search results, but yeah, if you're building a highly interactive app, you probably don't want to reload the page.
The thing is browsers have gotten better over time and the streaming made it very obvious. It's very cool that with an MPA, you could be on a page, click on the next page. And the quick stuff, you know, like the shell could load almost immediately, almost like a CDN. And then the content could stream in and you'd see the loading indicators.
So the difference between a single page app and MPA in those zones didn't feel as big because you just switch the page, the, the stuff they paint hold until like content's available. So it would, the browser would paint hold, then you'd see the header almost immediately again. So there's no flicker of white and the loading state.
It looks pretty interactive, but you know, We've been kind of sold for quite a while that client side rendering was the end all be all. And don't get me wrong. There's a huge benefit to it, but it's just like, there's enough things that made it different than everything else at the time. Um, and yeah, I don't know.
It's, it's, it's one of those interesting things because like, similarly, I don't know how the mentality changed so quickly in 2020, where people were like, suddenly okay with it when Astro or Fresh came out or why people, you know, with server components and stuff, like why, why. Why did this model suddenly come back and people accept it?
I think it was because of COVID and e commerce and increased buying, you know, there's this whole interesting time period where everyone thought that they could like make money on e commerce and interest rates were low. So they shuffled a bunch of money into companies that were selling products and they would build the frameworks.
I, I give lots of examples of that, but if you look at the meta framework movement of 2020, um, between, uh, what next JS or remix and like, you know, you start thinking about, um, how companies have been instrumental in pushing, uh, this kind of mentality in terms of, uh, SSR, you start kind of understanding maybe that's why, but.
At the time, Marco was like the thing that no one thought they needed. You kind of sandwiched between backend developers who were like, why do I want this JavaScript stuff? And then like, um, front ends that are like, Oh, you don't have the latest Hawk. You know? Approach to state management is like, it wasn't fashionable.
Justin: back at my PRs, I had like a few couple PRs to mark it, it was like back in 2015. And I think like at the time, like I was saying, server side rendering wasn't really a thing for front end frameworks. Uh, well I mean it was a thing, but like streaming server side rendering was definitely not.
I think the server side rendering story in particular was just like, poor. Um, it was also like, Other things is like, we have LSP now, uh, the language server protocol and like, which is fantastic. Cause like basically any editor that you use gets like all these nice features from all these languages.
Whereas like Marco at the time, you know, depending on what editor you use, you're not going to have a great syntax highlighting or like auto complete and stuff like that. And it was just like, that was a, a part of the times that made it harder to do that. Um, but like. Yeah, I don't know. It is really, like, revolutionary, though, because, like, I remember stumbling upon it, and I think one of the things I was looking at for, at the time, is, like, I work on a team with designers who know how to do HTML and CSS, and a lot of the front end frameworks are, like, pretty crazy, and then, if you cared about SEO at all, Like server side rendering was a must.
So you were often using some like backend service, you know, like that's like completely different where there's PHP or, you know, some other thing. Um, and this is like, this was really first in class and like establishing like the sort of isomorphic pattern, single file components, like hydrated. Like, I mean, all the things that it does is like insane.
Ryan: We have a meme like on my stream, uh, which is like hashtag Marco did at first, uh, cause like the, the list is extensive. Um, it's, it's, it's actually kind of crazy. Um, as you said,~~ like, and the, yeah, it's,~~ it's like they made a certain set of trade offs that gave them incredible power, but it was really.
really difficult. Um, the, the tooling stuff still, still to this day, I actually, I do my own stream and I had Dylan on one time and we spent the whole time building a language and it was literally showing how he came up with all the different tooling, like how to do, uh, syntax highlighting, how to do auto completion, how to do linting tools, how to, um, you know, parsing like every compilation, every part of the of the package to like what it takes to build your own language.
Cause it's kind of funny, like on one hand, people are like, Oh, you know, when they see something like, Oh, why can't you just fix JSX, right? Or why can't you just like add this feature? And it's like, do you understand like how many things do you have to touch to be able to do that? Um, you kind of, there, there isn't a little step you either like try and use what's there.
Or you basically go like, this is important to me. I'm going to go all in on it. Um, and Marco was one of those first ones to do that. ~~Um, ~~Svelte is also one that's kind of like that as well, where they're like, yeah, let's go all in on it. I've had enough experience with that to be like, that's not where me, especially as a single developer, you're going to spend time, you know, it's things about solid, some people think that we copied react, it was more like, okay, templating.
Okay. What what's available. Okay. JSX. Good. You know what I mean? As I already mentioned, we had the signals approach before hooks came out. So like, and the, you know, like basically the, the function components beforehand. So like there it's a lot of work. Like it's, it's just like when you sign up for that, ~~you're, ~~you're basically.
It's like triple the amount of effort, but what Marco can accomplish and it's going to be very obvious in the next version is, is something that, uh, people have never seen, it's just, it's just incredible.
Andrew: You're hyping it up so much, I can't wait for it to come out, but like How, how long has it been a closed source at this point, like four years,
Ryan: This is why, this is why I'm not allowed to talk about
it. ~~That's why I'm not allowed to talk about it. Yeah. Yeah. ~~I mean, we, things look like we finally had solved the key problems and we were kind of pushing forward around, uh, 2022, but it's always hard when you have something that you have to. First and foremost, make work internally at eBay or at your platform.
So like there's like the client side version. Um, could be released today, you know, kind of thing, but like, then you're like, okay, how do you make all the streaming, all this stuff, like there's features that are dependent on by the ecosystem and it's like, uh, you know, like it's, it's, yeah, it's going to be interesting.
I, I, as I said, this, I don't talk about it because it's, the potential here is so high. I, again, I, I don't know if it will be received any better than it was in 2015. You know, like it's, it's still an alien and like an. Otherworldly creature, but, um, it was a great experience for me because it gave me this ability to be on two extremely opposite ends of the design spectrum space, not just server and client, but like language and just Javascript.
Um, in a lot of ways, React came into popularity as being just JavaScript. I don't think that's the case anymore. I think Solid is the most just JavaScript framework these days. Um, and Marco is like, you know, when people like Svelte wear language, Marco is the most of that. So it gave me this ability to experience the extremes on both sides and sort of flank around all the other solution spaces and kind of understand, arguably, in my opinion, in a non compromised way, the best way to approach Um, both sides of space and it helped me understand, you know, elements of that.
I did like, didn't like what the trade offs are and like, help me figure out where I want solutions
to set.
[00:38:08] The Role of Compilers in Modern Development
Andrew: drilling deeper on that, just JavaScript point, uh, one, another thing that Marco kind of pioneered in this space was a compiler first approach where like a compiler is a very integral part of the workflow Svelte continued on with that solid has that now react even has that now, and I feel like we have these like, Um, Two competing thought spaces where people are like compilers, good, make, make code easier.
And then the other side, that's like, I don't want to compilation step anywhere near my application. So in your opinion, where do you think the future lies? And like, will there be a world where we don't need the compilers anymore? Like I saw that solid has like an optional compiler, but with a whole bunch of trade offs.
Ryan: Yeah. Um, no. Yeah. I mean, that ship has sailed to a certain thing, but it's still the long, long, long, long time ago. Like there are extremes like Marco and arguably like Svelte, you know, uh, especially Svelte 3 that felt even more extreme because it literally like the whole language inside there is like the pseudo language of like, as much as, you know, people might like it and it looks like JavaScript.
Let X can never in JavaScript mean that it will reactively trigger updates. That's just not a thing. Um, but on the other hand, compilers have been in JavaScript since. In different forms forever. First of all, I mean, we can look at stuff like CoffeeScript or like different languages and extend that onto TypeScript, right?
Um, TypeScript is compiled. JavaScript is not like some people like, Oh, we will bring types into JavaScript. So maybe, maybe there, there is a solution there, but it go, um, bundling. Bundling to me is a form of compilation. Um, you know, there's a whole build versus no build, but like essentially it's not. Tree shaking can happen at a, at a crazy granular level.
For those who aren't aware, that's when you basically drop out unused code out of your bundle. But the unused code isn't just what you import. Um, modern tree shaking, you can literally, based on features that can be used, can drop code out of the middle of functions. Like, it's, like, one of the reasons Solid's so small is that if you don't import, um, certain feature like suspense, we actually can be like, okay, it's impossible to ever ever Set this variable, which means every switch inside the whole app, um, can basically go like, if suspense, or if there's transitions, because that global that we have, that we set on this, when you run the function, it's false and can never be set to true.
The, the, the build tools can go, okay, I can just, this is always a false. I can remove this whole block of code, like literally right out of the code. We, we can, we can act like based not just on, like I only use this signal and not this effect, or this type of like primitive, not only based on imports, but the combination of the imports and what features are used can actually change the code of the actual imports themselves.
This is something like. Yes, import maps or whatever it is not solving. So, um, purely from like, uh, uh, like bundle size, purely from like, um, uh, like I'm just trying to think of like other examples, minification, um, like, like there is a whole slew of, of, of build tools, ones that happen in your idea, almost like linting.
To, uh, to ones that happen at build time. Um, and this whole stack is now so ingrained. I don't feel we're getting away from it. Babel was really the first piece when, you know, we went and we're like, we needed to modernize or standardize our JavaScript people that want to write. Code like it was 20 or 2006, just because one browser didn't support it.
We've gotten better. So like there is a possible path without these tools, but it's kind of like the challenges. It's, it's, it's almost like a identity statement. Something with the compiler is always better than something without the compiler. Like this is, this is always kind of like a fact, like our build tools are bundling every aspect of it.
It's just, is it good enough? Maybe, but like it will always be better. We can always do better with this extra level of analysis. So it's, it's, it's very. Now, not all things are equal, right? When I was talking about solid being just JavaScript, I, some people might there's like scoff at me a little bit, but like templating is arguably the oldest place where we've had compilation from the beginning of time.
You know, even when we weren't doing re uh, reactive frameworks, when you look like pug or Jade templates or whatever, we were taking these, um, String things. And, uh, you know, the output wasn't just a pure string template. They were smart. Uh, there's an old one that Marco was, um, influenced by called dust that actually had streaming, uh, built into the templating engine.
And yeah, you wrote code pretty simply as you know, it looks like strings, but what you were getting out was like generators, basically like a mechanism. So templating is even on server classic place of compilation. So, um, and some people. I guess they view it differently, but JSX was always compilation. So React always had compilation.
Remember, I said we avoided those old data bind statements and knockout. That was a compilation step. It was a way of representing the view in a different language than JavaScript. Some people say that's synonymous, but JSX is not JavaScript. So from that perspective, there are different levels. There's a very different level than saying, like, here's a template syntax.
And then there's a different level when you're like, look, um, your component code now gets changed from what it was and what it wasn't, or your whole app or these specific files, um, there, there's a scale to, to compilation. Right. Um, I think these days, um, except for maybe something like lit or what, or whatnot, um, essentially every framework has, uh, compiled templates, right?
That's the baseline. What we're seeing now is people doing compilation outside of the templates, like the react compilers felt, um, some of the stuff that Marco does, all the single file component stuff. Um, I, so it's not even these days, but to a degree. That is where like a whole different degree. So, in a sense, when I talk about solid being just javascript, it's because it's actually in a sense closest to the reactor.
Our JSX compiler is different than the react compiler, but that's all that we compile and solid everything mechanically works runtime. So it's, it's, uh, it's, it's a different kind of perspective. Now, there is a group of people, as I said, who would like to see everything be, say, tag, template, literals, um, um.
They work well in lit, they work well in preact, for example. So there is that kind of mentality. Challenge is, um, fine grained rendering doesn't work like template literals. It, it works on executing individual expressions. It's not a re render model. Which means you can solve it by passing a bunch of separately wrapped functions into template literals, but they're not a good enough solution on their own.
And I think it's been an interesting conversation, um, with that side, because people are like, Oh, get rid of the build goal, the stuff. And I'm like, you guys wouldn't want us to get rid of the build. Because, you know, if you want to get the kind of performance, you want to get the kind of stuff and you want the ergonomics, you want the build, at least on the template.
Um, so it becomes an increasingly difficult, um, proposition from my perspective. We don't all necessarily, like, I'm very skeptical of compilers, um, funnily enough, because every time there's a new feature and like, we can solve that compiler, I'm like, hold a moment. Let's think about it. Compilers have this.
under the hood complexity that, um, isn't obvious at first. You're like, Oh, let X. Um, but what does that even mean anymore? You have to consider now that you have this abstraction, that there are holes in that abstraction. Right. And that is. A challenge. ~~Um, ~~so it's funny. I have a philosophy that's like tries to keep the compilation right to as low as I can be.
Now, there's people out there who said that's still too high. I'm never going to be able to satisfy everyone on that. But I am very cautious here because it is easy to just keep on throwing compilers at things and get into a mess. Uh, you have to really look at it. If you can create that
consistent abstraction,
Justin: Yeah, I think that's a good point. It's like there are a lot of competing things. And I mean, I kind of go back to this. A lot. It's like the technologies of the web, javascript, I don't think we're, I mean, obviously weren't initially designed to be used in the way that we're using them. And obviously they've evolved over time and they've added more capabilities, but a lot of the ergonomics that we want from building you are very different from how browsers end up consuming the output and sure, you can write your whole website in an html file.
You can do it, but like, that's not. Yeah. A great or scalable experience. And, you know, it's like figuring out the tradeoffs between runtime costs or build time costs. And, you know, all these variables, but it's like, ~~you, ~~you have to make a trade off at some point. If you're building anything of sufficient complexity, that's the only reason why.
We've been able to ramp up these experiences more and more where you feel like it's almost like a desktop like experience on the web because browsers have gotten better. Yes. But also the tools that we use to build UI have improved, improved significantly. Um, so it's like, I think ultimately the goal should always be what, what makes the best for the user.
You know, it's like, that's what we're here for. It's a service, the, you know, people consuming the sites or whatever.
Ryan: ~~ ~~yeah, I mean, it's, there isn't a single solution here. Um, that's why there's like so many differences in perspective on what it takes, which means that even as sometimes we go through periods where technical solutions, um, Kind of, what's the term, uh, consolidate, uh, we, we, we end up in a, in a place where there's still different versions of them just because of syntax or because of familiarity or some kind of piece.
And those are all valid reasons for choosing different types of technology, even if they aren't actually all that different.~~ Um,~~
Ryan: ~~You're muted Andrew. Sorry, my water bottles loud. Yeah, it's fine. We can edit all that out. Uh, ~~so let's move on to like more future facing questions. U
[00:48:08] React's Dominance and Future Prospects
Ryan: h, one that's on my mind is we have all these great frameworks besides react, but react still reigns King. And in my eyes, like solid seems like better on so many different levels. So what, what do you think it takes to get to a place where react is dethroned from being like orders of magnitude, more downloaded than other things?
Andrew: Like, how do we how do we beat
React?
Ryan: ~~It's ~~yeah, it's hard. Um, it's really, really hard because there's, there's a certain, um, momentum that comes with being so popular. The popular solution continues to be the most popular solution. It's pro it's, self propagating. You have the most training, you have the most, you know, education, every piece of the puzzle ecosystem.
So, I mean, this is why when people are like, what about ecosystem? I'm like, It's a chicken and the egg problem. Like I, you can only be so concerned about it at a certain point. Something has to get popular enough to, you know, take that risk in order to, for anything to change. Otherwise things are set up so that they will never change.
That's just the reality of things. So taking react on head on is hard. And it's something that's much on my mind with solid because solid is fundamentally the other model, right? The retained versus immediate mode thing. And so it's like. Stuff that benefits. React, uh, doesn't benefit solid and vice versa.
Like we can learn from each other and I have learned a lot from React. Um, but like taking something that's like solid mentality and putting on React doesn't get you the same results. And you might even be able to get the DX to look kind of the same. But honestly, it would have been better if you just used React straight.
I mean, this has been the actual challenge recently. React is getting stricter, its compiler, concurrent rendering, all these kind of pieces. And you have solutions like MobX. MobX is a signal solution in the React space. It's been there forever. Um, and it kind of does the thing where, you know, it only re renders the components that update.
We have things like Joe Ties, kind of similar zone. That one's a little bit more aligned with React's way of thinking. But the challenge has been with a lot of these libraries, um, is that React is like getting more, uh, stringent, like more like, no, this is the way to handle state and react. It's funny.
Early days, they were not like that. They're like, bring anything. We are just a view library. Um, that ship sailed quite a while ago now, like watching state management, not even state management. Pretend you're Tanner Lindsley and you're building like a table thing. If you need to be able to do any kind of granular state updates that go out beyond, uh, reacts model, it's getting increasingly more difficult because they're trying to streamline things.
They, they have a specific view point, a specific model in mind with react and. Which makes it very hard to say, take something that's like the solid way and apply it to React. We don't, we don't get to fix React. This isn't, React is exactly the way it should be, which is interesting because it means that if it's to optimize, it has to follow different paths.
That's why they have things like the React compiler, right? Um, there's been, you know, discussion about that. And it's like, well, we, where's the solid compiler? And it's like, We, we don't need it. Like when, like when you, like the, the problem that the React compiler solves is something that just writing solid as is already works that way and is already solved.
It doesn't do anything. Um, but that's again, because of the difference model. Does it do something for React? Yeah. It, it improves your ability to write good code. It actually doesn't make react faster. It just improves your ability to write good react code and like that's valuable to react. Completely useless to us because if you write solid as is, you already get good solid code.
So it's like, there's this kind of awkwardness where react can kind of, if it wanted to stagnate and never change and still just sit there with, you know, these, these things, as long as people are okay with that or complacent. So I think if we're to beat react, so to speak, it's hard for solid alone, because it is something that competes with it right at the fundamental level.
What's interesting is. These things aren't alone. There is an ecosystem. So even though I was complaining a few moments ago about the whole ecosystem argument and being like, you know, it's tired, everyone knows. It's like, is the popular framework popular? Clearly. But, but on the other hand, ultimately, I think this is where, you know, potential.
Can happen because the next level up of abstraction is, you know, when you get to meta frameworks, when you get to these other kind of tools at this point, you know, your choice of router and data fetching library matters more than your choice of react itself, you know, are you using next with its app directory and RSCs are using remix with its loaders, um, are using 10 stack with 10 stack query and 10 stack router, these levels of abstraction now, um, Are at a higher level and they kind of the, the reactiveness, even though react is there, it's the core of it is kind of hidden a bit more.
I'm not sure if it stays that way. We're getting the react has a team has a very specific vision. You've seen it coming out through next JS and maybe everything will shape to it, but there's a tension between that, you know, being open and being too opinionated at the framework level. When you raise the bar of what you accomplish, Uh, you know, what you want to your ambition on what you want to achieve.
Sorry, you can make the process more streamlined, which is what they're looking for, but you also make yourself bigger and less, um, maneuverable. A lot of people chose react in the first place because it wasn't angular. Right. Because it wasn't the full framework and now reacts like, uh, sorry, we're not a framework necessarily, but we think that you should install a framework to use react, right?
VEET isn't good enough. We, this is why create react app is still sitting there. Well, like there was no good solution out there. They don't want people just building their frameworks anymore. They want to streamline the process. They want to make it smooth. VEET might be the most obvious choice, but VEET is not taking responsibility for that framework part.
And React wants new users to have a happy smooth path, which means we're stuck right now with, uh, getting a starter that's basically completely broken. So like, this is where I see stuff because I, I think React has matured. React is like, take us seriously. We have a good streamlined solution that covers all the bases.
You know, we were going to, they're getting to a point where they've done enough to kind of rest on their laurels. I'm happy. They didn't before they've been continuing to innovate, especially over the last few years, stuff like server components, things like the compiler to push that forward, but they're getting to a point where React is the Java of web frameworks.
That like, and I think they're okay with that. There's a, they don't need to worry about the front of the curve anymore. They have the mainstream, they have the trail off, they have the biggest volume under, and their goal probably is to take out jQuery or, you know, uh, eventually. You know, the WordPress, the world, I mean, that's why RCS have such a, uh, uh, uh, push, you know, the, the, the, the, you can still do the other stuff, but like they have bigger fish to fry.
Um, and what that means though, is that React isn't standalone anymore, really? Like, even when you get to stuff like Astro, where you have islands, like Astro appears on the second page of recommendations. It's not next to yes, because it's not fully React. I think it's funny that I tried so many years to look at this from a technical perspective and like talk to people, like, you know, just choose the solution that works for you better, blah, blah, blah, the, the, the, what's the, the actual movement and consideration here isn't so much a technical thing.
It's, it's the fact that, you know, react next 13 was the real react 18 release. We've gotten to a point that react isn't this just the small little library. It's this huge thing. And it means that. Um, there is a space where if you have other things like a meta framework and then it has its opinions, it's that level of abstraction that you're aiming for.
One could foreseeably just swap React out under the hood and maybe not be a huge difference. You know, there, there's, there's part of it is like looking at. Um, could you just like, want the small thing again, choose solid or svelte or something instead of choosing react, but that's, that's going to be slow people, you know, people just go with what's popular, but is it possible that a solution like next gets so popular or popular enough that something like next, but that didn't use react.
Could actually make the swap. You can't go at react head on, but, um, I think it's possible to, to actually have better almost internals on the next abstraction level, which is, again, this is going to be a big plug shout out from my buddy, Tanner Lindsley. Um, I, if you, if anyone's been paying attention, um, 10 stack start and solid start are.
Um, sister metaframeworks, and that's very much intentional. And we should see that progress over time. Um, I would not be surprised at a future when you start up a new TanStack start project, you just choose the solid option instead of react. And everything just kind of works except it's solid. Um, so I think.
I think that's going to be a big part for the existing ecosystem. I think with new development, I think there's a lot of interesting technologies that are on the forefront that specifically benefit from signals. We talked about finer hydration with resumability, um, but local first is another area that I think is incredibly interesting and one where it's the opposite of that old variance Florence demo.
They're not in a, we're not in a world where you're going to hit the backend and send your whole. Like you might be sending your database, but you're not going to be sending your whole database every multiple times per second and trying to get the framework to render it that that isn't the right kind of benchmark.
Instead, we're going to live in a world where the back end aware of what changes sends these partial diffs. And if we can forward that partial different information to the client, and the client can propagate it through, we don't need to waste our time re rendering everything we know what has changed.
And if we know what has changed. It should have the same kind of performance characteristics as fine grained updates in the client. There's no reason to worry about diffing. And if we want to talk about the best performant, most easy to reason about way to handle fine grained updates in the client, we're talking about
signals.
A
Andrew: Well, I'm interested to see where it goes. I think your idea that like the meta framework being kind of the changing point for all of this makes a whole lot of sense, especially given the push from the react team to only go framework.
[00:58:58] Conclusion and Final Thoughts
Andrew: Uh, but that wraps it up for our questions this week. Thanks for coming on, Ryan.
This was like incredibly interesting to hear the history of all of this and how it evolved in your point of view. So thanks for coming on and talking about it. ~~ ~~
Ryan: lot of fun.
Thanks. I always love talking
about this stuff. I'm super passionate about this topic, as you guys can tell.
Justin: Yeah, Ryan, it's great to have you on. Solid is awesome. Uh, I've used it in a few of my personal projects. Really love it. Uh, it's so cool that you're working on the Marco team. I didn't realize that you were still doing that. Uh, Marco was, has been a huge inspiration for me across my career. Really excited to see what y'all come up with next.
Uh, can't, can't wait for that. Um, the future is bright. So yeah, thanks for coming on. Thanks for sharing.
Ryan: Thank you.