Reactivity: There and Back Again

Good morning, everyone. I'm glad to be back here. And I'm going to talk about everything old is new again. You know my passion is reactivity. So I'll be telling a bit more about that but first I will go to an entirely different story. An entirely different era, actually.

200 years ago, the whole new technology field of civil engineering. And it was changing all the time. They invented steam engines, and ships, and trains, and stations, and railroads. And why one guy became particularly famous. Because he was probably the best civil engineer of all time. And his name is Eisenbart Kingdom Brunel. And what made him so great? I give you three reasons. First of all, he built loads of stuff. He built the first tunnel under Thames River. He built the big bridge near Bristol. He built the biggest ocean steamers of the time. And also, he dressed himself properly. So, sadly, we didn't stick with that tradition, if I look at myself, you all. But I think we can learn something from that. Thirdly, he had the most profound, eloquent quote about programming. Now, you might be wondering, what is that quote? I'll tell you in a bit, so stay tuned.

Meanwhile, while I was reading up on civil engineering, a lot of things changed in the front-end world. So, first of all, apparently, AI is about to get our jobs. Secondly, this thing happened. Suddenly, we had React components, and they were reading from the database in front file system. Apparently, they moved back to the server. And so, are we now back to writing PHP? Anyway, like, if I combined those two things, I'm not sure if that's a good thing or a bad thing. Not sure to hate the AI or pity it. In other words, are we going in circles? And I think that's not the case.

I think what's happening here is very interesting. I mean, it's very easy to joke about it, but this is serious stuff. So, if I look at front-end engineering, how I know the evolution of it, as we started with all those serverless things, server-rendered pages, then we sprinkled some interactivity on top of it with some JavaScript, jQuery, and then it got out of hand and we built a proper client-side framework. And now we're making the move back again to do more on the server. So, it makes you wonder, is technology just going in loops? And this loop seems now to be closed, almost.

But here's the interesting thing. Often we start out a problem and two things have to happen simultaneously. On one hand, we have this big revolution where we suddenly approach a problem entirely different and at the same time, we evolve existing technologies in small steps. And interestingly enough, in the end, they often come back together again.

Dan Abramov gave a great talk a couple of weeks ago where he was basically posing that if React would have started at server with server components and only added client-side interactivity later on, we would still have end up at the same place. And this loop, I think, exists in many places.

Think about how we think about states over the years. First of all, we started with mutability, which is how JavaScript works out of the box, but then it became messy. It's easy to write spaghetti code with it. And for frameworks, it's very hard to efficiently render UI. So we went to this immutability paradigm and we took a very radical different approach to how we manage states.

But then it turned out we can also sometimes overdo it. This was an interesting example a couple of months ago, where 10-stack table, which is a really good, a well-known library, in very specific cases, certainly became a thousand times faster. Why? Because they changed some immutable stuff back to immutability and internal administration. And we discovered again that, like, immutability is actually really efficient when it comes to changing objects etc. Anyway, that made us conclude, okay, let us do some immutability. Maybe in local places it is fine. Emur is taking that approach. It has, like, temporal, local immutability, and it makes things a lot more efficient.

But in parallel, there were also evolutions going on. So we also figured that, like, with the introduction of proxies around 2015, 2016, we can have observable immutability. Well, we still have immutability, but actually frameworks can know what is happening with those objects. And now we have recently a new hot thing, which is signals. It is pretty much inspired by both paradigms. And frameworks like Soled and Quick are making it popular. That's interesting to see where this goes. It exists both immutable and immutable flavors. And one of the interesting things I'm sometimes thinking about is, if you start to compose our signals and we have trees of signals, are we then basically back at the mutable programming model? But now different. So maybe there's a circle closing here. Here's another of one of those circles, reactivity.

So 10 years ago, it was already briefly mentioned in the intro, we had those reactive frameworks like Backbone, Angular, Knockout. And at some point we figured, hey, they're very unpredictable, unreliable. Let's take a very different approach. And that's very different approach was Reacts, introducing this idea that you have like mutable trees and conceptually render top-down and type tree and it should be fine. And it's also a very radical change and a very big improvement. But at the same time, reactivity itself was developed further as well. So we got frameworks that actually were predictable and examples of this are Vue and MobX, Felta, Quick and Solid again. So we had also this evolution going on at the same time. And the interesting question is, where will we end up next? And there are some things I'm intrigued about, what I think might happen.

So what does the next generation of reactivity look like? First of all, within React, there's this really interesting thing going on of React Forget. It still sticks to the same model, but it gives you as a developer the experience of reactivity basically, where you have pretty straightforward code and you don't have to think about how to optimize, how to build dependencies, those kinds of things.

The other very interesting development that is going on is basically that the boundary of the server and the client is blurring. We see that with React Server components and React Server actions. We see it also in something like Quik, where we can have closures on the server, serialize them, and run them on the client. And so what I think would be really cool, and I'm really waiting for the FUSH framework to standardize this or make this popular, is where reactivity goes across the network boundary, and we can subscribe to changes directly on the server and vice versa.

Anyway, so this might be another circle that's closing. And it makes you wonder, does everything become new again? And is it a bad thing or a good one? And I think there's three interesting lessons to take from this. One, is I truly believe we're not going in circles. I think we're spiraling. I think we're spiraling into something bigger, where we learn from everything we did in the past, but also take benefits from everything we did in the past. Secondly, it means that for us as engineers, we have to be able to act in the light of uncertainty. We don't know exactly where we're spiraling towards. But in the meantime, we have to do our work and serve our users. And so don't worry if you're not perfectly sure which one of the frameworks is exactly the best one. And thirdly, a very important one, is that like dogma skill innovation, at the point where you become fixed on one solution, you basically stop the spiral. If you are at a point where like everything should be immutable, or everything should be mutable, that's where progress stops. And that does bring me back to Brunel. So remember, Brunel was building bridges. So he has this quote. And I think he was talking about programming, but it didn't exist yet at the time. Because he was building bridges and so that's a very responsible thing to do. It doesn't have version control. And if you don't build them right, people might die. That's how bridges work. So this quote must have been about programming. And he basically said, I am opposed to the laying down of rules or conditions to be observed in the construction of bridges, lest the progress of improvement tomorrow might be embarrassed or shackled by recording or registering as law the prejudice or errors of today. So I think that's one very radical view of engineering. And so that's what I want to leave you with. Everything old will be new again. And in that light as well, one very small announcement, MobX will have decorators again now that they're standardized. And with that I will leave you.