Next generation React architectures with Mikael Brevik === [00:00:00] Hello, and welcome to PodRocket, a web development podcast brought to you by LogRocket. LogRocket helps software teams improve user experience with session replay, error tracking, and product analytics. You can try it for free at logrocket. com. I'm Noel, and today, Michael Brevik, CTO of Variant, is joining us to talk about his talk at React Norway, titled React Architecture's The Next Generations. Welcome, Michael. How's it going? Oh, good. Thanks. Happy to be here. Awesome. Yeah, I'm excited to chat today. But before we delve in, can you uh, give us a little bit about who you are, your background and why you're telling us about React architectures. Sure. So most of all, I like to think of myself like a web historian in a way. So I've always been interested in how things became and at one point, I think that entailed a lot of research, but as I realize now I've been doing web development with JavaScript especially since. I think almost [00:01:00] since the XRH standard was introduced. So I think like early two thousands, which is now 20 years ago but it also includes a lot of what I'm interested in. So web development and user experiences and things like that. And I've been doing web for a long time. And I also do that today, to this day as a CTO at the consultancy firm that I've started five years ago. So I do a lot of work and also some management. I do some podcasts in the region. So if you're happening to listen to this and speak Norwegian. So if you're interested, definitely check them out, but, and over the time I've done a lot of react stuff, I've done a lot of the different stuff. I like to think of myself as developer, but mostly I think people associate me with like front end developer stuff, but I don't like to categorize it in that sense, but also do some open source. So if for instance, you've been. Pasted with notifications. It's a big chance. That's my [00:02:00] work and it says I did library called node notifier back in 2013, and that's still downloaded like millions of times a week, which is. And I never liked those notifications, but in any case, so like things like you just use them and whatnot. And also in react world, I did way back in 2014, I did a library called omniscient, which is try to take those classic. At that time react had only classes instead of doing functional components and whatnot. They did all only classes. And we, me and a friend called toy guy. Yeah, we were inspired by arm in closure script. And David Nolan \ and trying to move the unidirectional flow and functional aspects into react. So we did wrappers around react to make them functional and do introduces using only functions as components. So that was in 2014 at the one point, Yeah, [00:03:00] you've given a couple of talks on writing frontends in a more functional way. I feel like that's an interesting Intersection in that I think a lot of front end devs aren't really thinking about architectures in, in that way, or just like coding practices and design. Like how did you come into this functional But I think it's at some point, architecture wasn't a big part of frontend because it was just fragments of code running on the frontend in addition. So there weren't getting need of architecture in a broader sense, but also after a while, when moving over to the client in more sense, we get more code and more needs to structure it and do more with it. And at that same point, I think just by happenstance or something, but also the functional paradigm was at a rise. So thinking more about it at bot at the functional pot patterns in a way. So it's just happened to coincide, but I also think that it's. One of the reasons is [00:04:00] that the web and how the statelessness of the web functions is also something that's good to model , in the functional aspect. So I did some talks about this for instance, at JSConf Budapest, I think in 2015, I tried to see that if we're structuring our code as composable bits of components, essentially we can. Build complex applications on top of smaller iterations or smaller fragments of code, which is like the functional manifesto in a way, but yeah, so I think it's. A merging of two thoughts that's fits together in a way. I Yeah, do you feel it's kind of, uh, the languages the languages or frameworks, sorry like react or, it's very similar. Do you feel that they're inherently functional at least today and that they, mingle with state where they need to, like inputs and stuff like that. But do you think that the frameworks are encouraging devs to write functional code inherently? [00:05:00] Or is it still something that needs to be consciously thought about? think it's getting a bit more pragmatic at least. So I think when the flirtatious period with functional program was at its strongest, when we were doing functional lenses and cursors and then immutable data structures, that's simulating how like applicative functures means and whatever, like all the. The terminology and all the academic things from the functional programming world was at its strongest, I think is where. More likely to be guided toward that thought and that architectural patterns. But I think that's regressed in the later years. So for instance, now we're having, yes, you can say it's like a functional aspect pro in, in, in a way, but it's more pragmatic. You have more escape hatches. in different ways. Fundamentally, it's functional.[00:06:00] But it's not as important to know that it's functional in a way. got it. Yeah, I think, that's probably a very concise way to put it, like a highly pragmatized functional kind of framework is interesting , how does this play into what you cover in your talk? , is this shift what you're talking about? Or is there more to it? Not really. So the main parts of functional that we're still striving towards is determinism in a way. So how to produce applications that are inherently. Like foreseeable or something that you can say that this is guaranteed to be this value, or this is something that's I can stand for in a sense. But I think that's just like the kind of , the web taking its direction or taking its paradigm in 2013 ish react world. I think that this is how we're supposed to think about it. , I think maybe my key takeaway to start with that is that we're doing a [00:07:00] lot of things in the front end world that also seems like there's a lot to do and a lot to think about, but it's variation of the different concepts that's explored user land, as I call it. So just to take an example of that. I said initially that I started programming in web in the early 2000s, and at that point you had things like mood tools, you had things like dojo prototype JS but most of all, Most people think about that period as jQuery, which was introduced in 2006. And the reason for it being introduced is we moved more client stuff over to the browser. So more of, we had a need for some sort of dynamic behavior and we moved. More code over to client to be running in the browser setting. So that's the, it was just a need for how to structure in. And from that moment on kind of jQuery and John Reisig introduced jQuery. [00:08:00] jQuery and jQuery plugins was like the de facto way to structure your code. It wasn't any bundlers. It wasn't any things like that. You just kept concatenated files. So you had a need for things like self invoking anonymous functions or immediately vote anonymous functions whether we prefer to call them, but to scope things with functional scopes. Our function scoping but that's, it's. And after a while, yeah, you moved more and more over to the client. You had single page applications created in this manner. Gmail is probably the most used example introduced the mobile client in 2006 or something. And it started. Getting so much functionality over that you had a lot of new needs for how to structure code. And that's also like moving into a new era of how to think about things. So that it started a lot of different explorations. Mind you, it was still things like mu tools and [00:09:00] dojo was still a big thing. But it wasn't as de facto mainstream as what jQuery was, even though things like dojo had async module definitions and invented the module and what was later known as common JS. But it's still like jQuery that had the best extraction of The de facto winner. But. When we're doing more spas, things like Angular, Backbone, Ember, Knockout Euralia, Durandal, everything was introduced and trying different approaches to how can we solve like structuring big applications. Exclusively on the client side. And at that point, this was probably the period that people first trying to talk about framework wars, for instance, even though there had been a framework war , previously as well. But also at that time there's a new framework every week, and things [00:10:00] like that. But again, They didn't, they haven't lasted for 10 years plus, because when react came in 2013, it's changes a lot of different things, like not only doing different approaches, but it was introducing a new way to think about solving problems. Applications. So the, the component architecture that was introduced even though you had some sort of components from before, it wasn't encapsulated and it wasn't like you couldn't think about components as self , identifiable entities in your application architecture in a way. So I think this is just like a long-winded way of saying that there is some sort of wave in the front end world that we're seeing the different explorations that we don't see in, for instance, Java, we don't see as NET. We don't see it in Python because there are big [00:11:00] actors in those environments, in those ecosystems that is driving how to solve application architecture. In a bigger, broader sense, but in the web world, this has always happened in the user land, in open source every which way we're trying to solve different things. It's been explored by individuals in trying to make something bigger, but more fragmented as well. But also you were by that observing an innocent bystander in a way you're observing all those different explorations. And I think the consequences of this is that it feels like there's a lot of things happening, especially when you're following Twitter and you have more than 800 tweets or whatever you can see. But all the different like explorations and libraries are trying to see, they're just trying to find their way into how can we solve this in a different way? And at some point it accumulates to not only [00:12:00] changing. How we're writing, but also how we're thinking about writing things and that's the like paradigm shifts and I think it's, again, waves that accumulates over time and suddenly there's a big change that's, we'll stand the test of time in a bigger way because react was interested in, 2013, That's 10 years ago this year. It's if we're trying again from the early two thousands, that's when we're started doing dynamic applications or dynamic pages, we're seeing that in the web 2. 0 era. We're doing more social interactions and we're getting the need for more dynamic inputs. So since then, up to, up until now, it's 20 years of age for dynamic web applications and think about that. There's a framework or a library that's been developed , in open source, that you can write the [00:13:00] same application code, almost. In 2013 and to this day, that's over half the time there has been dynamic pages. Right. And that's, I almost get annoyed when people joke about new frameworks every week, because I can't think of any other example. Of any other ecosystems that had such a stable, but continuously developed and evolved framework and architectural thought pattern, that's the component architecture and React has enabled the implementation of that component architecture. Yeah. Do you think that we're going through a paradigm shift now akin to that initial migration to the component architecture, or do you think this is a different beast? It's, I don't think it's the same kind of directional change because remember also, I think that 2013 was a real paradigm shift in a sense that where we're [00:14:00] trying to apply server paradigms, like MVC and MVM, MVVM model view model patterns to the client side and seeing that, but. Really the stateless nature of the web and how the DOM operates doesn't really apply to how we're thinking about view models and model view controllers. So we put that behind and went over to component architecture. So that's changed in quite literally like a paradigm shift. I think this is like same but different in a sense. One of the reasons why we're. We're moving over to the client as well, because there was a lack of tooling. It was a lack of developer experience. It was lack of how to properly create dynamic applications in the web, but now we're doing like 10 years plus. Of creating great developer experience, creating [00:15:00] great tooling bundling is immensely better now than just for three or four years ago and nevertheless, 10 years ago, but also through that development we're seeing, okay, but there has been a lot of trade offs. So let's take what we learned and try to reapply it to the other way of thinking about applications. So moving it. In a sense back towards the server and seeing, okay, could we bring all this tooling, all this developer experience back to, and use the strength of how we're doing applications from before to this. The way I like to think about this is for some reasons, I've been obsessed with hypes and trends and pendulums of technology for the last five years. So I had, I have a mental model that if the Gartner hype curve, it's essentially just like a scenous curve. That's my theory at least. So it's a cous curve. And if you're just [00:16:00] shifting a cous curve, it's actually just a panel that's moving from side to side. So that's how I try to think about hypes, because you can say that microservices is just service oriented architecture from 10 years ago. Or you can say that this is the frontend architecture now world is just p h P or whatever. But it's, yes, but it's also no, because you have been forged and changed by what you're You have experienced it at some point. So again, the metal model of the pendle that swings from side to side, I think that it swings from one side and it's get some color by hitting the wall. And then you're taking that color back towards the other end. So you're constantly pendling between different technology, you're constantly changing. And I haven't thought the analogy through, because at some point it would be a brown and just the color would be mixed, but it's [00:17:00] changed at least. So that's the change I see now. That at some point we couldn't do things like progressive enhancement, which is a thing to, to accommodate for, because it's. Most of the time you don't need it. And most of the time the developers don't need it, but there are some people who actually do need progressive enhancement. And there are things that could go wrong with your application. So doing things like exclusively on. Single page applications. There are some major drawbacks. And we can't do things like search model optimization. Accessibility is harder in Norway. There's a law that every governmental site for instance, has to be accessible by VCAG 2. 1. Uh, Which is important and it's, it's, um, it's a good law to have, but it also means that every solutions we're making that is for public consumption, it has to be [00:18:00] accessible. And some cases, things like single page applications when trying to re implement , basic browser functions. It's just the accessibility isn't as good, for instance. Trying to move some of the, all the good stuff that we're creating over back to the server is also an advantage that can accommodate some of those trade offs. Yeah. I think it's, I think you mentioned it, but I think when looking back people have a tendency to discount how much that, that developer experience you mentioned really drove this push to these. SPA single page apps and just like that separation of concerns. I feel even just beyond the actual dev experience. I think that there was utility in it, just in that, like it made the process simpler. You could break teams apart across that kind of membrane a little bit easier. That was the front end and the back end. So I think that did lead to it. And again, we had this was like this. Era this renaissance was like became super nice to develop single page applications And now that was hand in hand with just the paradigm shift [00:19:00] in general but now as we're having another one where we're getting into this era of like putting things back on the server and figuring out, how progressive apps should work now it feels like the way that We are doing that is through these kind of meta frameworks, right? Like things that are being built on top of the frameworks that have been established. Do you think that is true? And if so, do you think that is necessary? Do you think that had to be how this would happen, or is there some other future that you could have seen? At least that's my analysis of it is if you're going to back to the previous statement I had about things happening in the user land, there's a major advantage of this because it's, it allows for divergent thoughts. So you can explore many different ideas and you can get great ideas of it. What you're lacking there is progression in a way. , it's harder to make tough choices when you have to constantly try to say or make people believe you that this is the right choice. But metaframeworks or [00:20:00] as it's really just frameworks but but having bigger actors in meta frameworks or frameworks. Allows them to make choices and move faster and make more unpopular choices. That might be good on the long run, but it's harder to get people to accept. And we can see that in the pushback things like server components getting on Twitter and the Latest Twitter drama. But seeing that. There's a lot more speedy push on this. And it's getting criticisms for not being the documentation since isn't ready. Maybe it's too early to be in stable, whatever, but also we have to remember it's trying to push in a direction and by having meta frameworks that have a lot more adoption than earlier. Where you have, you can fit the front end world as a, on a cart menu where you can cherry pick different. This is what I want [00:21:00] for my state management. This is what I want for my routing. This is the Bundler. It's hard to push and force changes. in that world, but now doing meta frameworks that control the entire ecosystem of your application. You can, in larger sense, try to move and push the next paradigm shift. So that's also one of the reasons I think the entire like ecosystem or community of front end developers has traditionally. I really enjoyed the pick and choose flow of the web, but I think around like the create wrapped react app era, people also started seeing that, you know what? I don't really want to have to make all these choices. It's nice to just do an opinionated Picked stack for me. So gradually over the years, we're just getting more and more accustomed to more opinionated. So more [00:22:00] opinionated again, by definition means less flexible in many sense. So that also means that when we're doing that a lot more choices can be made for us. So I think that's a driver for this paradigm shift. A lot of cynical cynical people might say that it's also not So not by happenstance that things like Netlify by remix or that it's Versus having next JS because they are also they're getting financial. Bonuses from transitioning over to the server side. But I think if that's their main goal and we get something good from it I think that paradigm shifts and thinking how we solve applications and architecture in this way. Go across the different companies because you're seeing every other framework also move into that States like a meta frameworks. It's not only a rack thing. It's also things like solid has their own quick city. You [00:23:00] have angular has its one which called angular or something. I couldn't tell you. Yeah. Yeah, Yep. But and you have Astro, which is like agnostic to languages or agnostic to, to, to frameworks and libraries as well. And Dino has fresh, which also they are trying to provide different edge functioning computers for okay. If there are also some revenue that someone's making on this change, I think that doesn't take any. thing away from the advantages that the server first thought pattern or the streaming component architecture or what have you the new what I'm calling the new paradigm. Yeah. It is an interesting problem. And I feel like there's a lot of people are thinking about this. Cause if you have a server, uh, server needs to be hosted, someone's running it, right? Like it's a lot more intense than just the deploying a static SPA of old. So it makes sense that there is some, there's some kind of synergies that can be utilized there, like from a [00:24:00] more. Just capitalist business oriented perspective. It's like, somebody's got to be doing this. But I think I want to, I want to ask more about something you mentioned earlier. So you're talking about how React felt more, I don't remember the term you use, it was like more democratized, like it felt more open source, owned by the open source community than these I don't know, old languages of old that were more tied to a given business entity or something. Do you think that is at odds inherently with this need to move to some more workload being a like run in on a server and B having a framework that can handle that trade off elegantly, because there is like a lot of technical. Overhead there. So like someone has to be making those decisions and there's inherently going to be differing opinions going on. So I think it's hard to do it in that democratized way. Do you think that this kind of how this is manifesting, do you think that this is a healthy way for it to be going down or is there something like, is there something you've seen in the wild that you've thought it would be cool if, the more agnostic, like the cloud flares or the Deno, like [00:25:00] those kinds of hosts were more of the norm than just like using for cell and saying, okay, go. just to to tackle the question from the first point, but so react was an is famously different than for instance, Angular, which was the main competitor when it was introduced, because it was communicating quite like vividly, like we are only UI library. Which means we don't do state management. We don't do things like this. We don't do bundling and whatnot. It's just handles. It's just a function of your of your state equals some output. That's it. And now it's more yeah, but you can also look at state as a component architecture way because state is a component in itself. So it's gradually moving over to doing more. Stuff. But I think it's hard [00:26:00] to do when having 10 years of history and backwards compatibility, it's very hard to change over time. You can see that. Even things like use the hooks took a lot of time before it was introduced. And now trying to reduce, I think uh, React share components, for instance and suspense was first in an RFC five years ago. yeah, That's a long lead time before, Yeah, because you're having to do, everyone has to be in agreement and they're still having to try to get all the users to accept the changes. But when you're doing more opinionated stuff and the entire. Totality of an application. You can also move in a more, let's say soft deprecation way. So trying to do migrations over time, that's not [00:27:00] having to do abstract syntax tree code shift, a major rewrites of your applications in a massive commit that's changing one breaking change, for instance, but you can do. As you're controlling more of the architecture, you can do more microscopic changes over time because it's tied together. And if it's. Advantages exclusively. I don't think so. It has its drawbacks and it has advantages. So but at this point I think that the advantages of, for instance, getting people to think about progressive enhancement, that's a major advantage in my book. And that's not something because the. Part of the community has tried on the arise of the single page application. When everyone thinks that everything you have to do on the application or in the web distributed side of things has to be an application and has to be a single page application. So you're [00:28:00] foregoing the entire progressive enhancement thing. But people try and say, but remember progressive enhancement, this is important. Accessibility is important. But. As you're not controlling the entire stack, it's hard to enforce. And if people, for instance aren't reading the blog posts trying to convey how important progressive enhancement end is, it won't get a hold like the as a mainstream factor. But now when. For instance, next and remix are talking more about it, controlling more aspects of it and things like server actions and forum actions from next JS is progressive enhancement by default. Certainly it's more adapted for this last two months than it has been in the last seven years, even though there's been a very vocal. So part of the community saying how important progressive enhancement is, for instance, that's just one example of many, I think that's [00:29:00] things that's physically to implement or do that has to change the way you're doing it. So it's harder to get people to do it. Yeah, I agree. I guess on that point then I feel that these paradigm shifts are the times when I don't know communities or industries, however you want to view it are the most prime to have some new tool like come out and be like, okay, this is the Hey, instead of. Dealing with this old thing where they're trying to take this giant community and there's all this history and all these people care about all these things in here. And that makes it, it makes it inherently slower to update, right? You have to have all these concerns you're worrying about. And I feel like that's when these environments are primed to have somebody new come in and upstart me like, okay, we can just make all the good decisions that a lot of people seem to be calling for. We'll start with that as our baseline and we'll become the new thing. Do you, a, do you think that is happening right now? And either way, like why do you think it either is or is not? Yeah. Like I said, I think. Like the [00:30:00] majority of people just got tired of having to choose everything. Yeah. Yeah. So at some point people just, okay, I give up. Do what are your opinions? I'll just follow along. Like prettier, it's ended the discussion of how to format your code in mostly a part is still some sort of discussions, but not nearly as much because we're just tired of having the same discussions of semicolons or not semicolons over and over at some point, just, okay. Give me your opinions. I'll live with it. So I think the same thing has happened when we don't need webpack anymore with the configuration galore that's that you can do anything with it's very nice and it has done a very good job for a long time. For instance, we just want something that's more opinionated and the bundle Story is similar. I think because you're having that back. This is very [00:31:00] configurable and then you get things like Parcel and turbo pack and whatever things different that's more opinionated just handles things for you and now we just handles everything by best practice and It's literally you need to do to configure. So I think it's just, I agree with what you're saying. People are tired of making choices just ripe for something, someone to say, this is the way let's go with that and try to make that as a new baseline and again, In five years, we're probably circle back right back to, but Hey the partial hydration model is lacking sorely in, in how we're doing RPC exclusively on our gRPC on, on the client now because of something new changes. So we're moving back to the more dynamic pages again, but. Again, probably at that point with more progressive [00:32:00] enhancement or whatever web standards that's advantageous for the client. Yeah. Like you said, there'll be a little bit color added, a little bit of color added to the pendulum swinging back and Yeah. I think so. yeah, exactly. Yeah. So you say in, in your talk, does. Just to bring things back a little bit you talk about shuffling complexity around. Is this kind of complexity the, the just make the decision for me? Is that what you're talking about there? Or is there additional like technical complexity under the hood that you're covering? I think, and it's maybe a simplification of the problem, but given the same complex problem you're trying to solve it's impossible to solve it. That's not true, but given the same problem and different abstractions of the soul of the solution you're trying to implement, it's hard to say that it's less complex in a way. So for instance, now with moving over to server server side first thinking It's not less complex [00:33:00] because even though you're writing less code, for instance, or, you have to, you, you no longer have to for instance, in, in next JS, you don't have to think if it's this running on the client side, or is this is this a dead cold and eliminated because I referenced the variable for. From outside of get server side, the props whatever, which is a very complex thing to do in a traditional before the app source folder or whatever. So that's some sort of complexity and now we're reducing. Perceived complexity. I think because it's seems easier because it's easier to do, but that complexity isn't gone, it's just moved to different aspects. It's more complexity to the because you couldn't solve for instance, react server components without. A more server aspect of it, for instance. So that's means that the library and the framework has absorbed some of your complexity, the complexity isn't [00:34:00] gone and the effects of the complexity isn't gone. Because for instance, it means that they're the source code and the actual running code has a greater distance than what you were writing before. So when starting to do complex applications in distributed web applications, for instance, in single page applications, that's tough sentence to say, but you're starting to see, Oh, it's the bundles are great. There are, there the bundles are a great in size. So we have to minify and mangle the source code that's outputted and that's minification. So then it's hard to read on the application side or in the browser. So then we introduced source maps to see that, okay, here we're able to map back from that code, but still it's a step towards. You're not running in production, the same code as you're doing on the development side. And this is a step further beyond that as well, because now we are doing, we're seeing code in things [00:35:00] like react server components, but also all of their things like quick and Astro or whatever we're seeing code that is not only run in one context, but it's running. For instance, when there is a use server in, in server actions, it's actually it's extracted from that code, creating a new HTTP endpoint that's running in the server somewhere, and it's running an entirely different context. So the distance between what you're reading in the source code and what's actually running is larger. So that means that the complexity is moved into infrastructure. And it's hard to do debug issues because no longer a source maps, for instance, I think that can be done. And this is also true in normal hydration mode. But that's different because then you're doing client side code that's extracted and running From what you're sending to the client, but here it's much more a lot more larger change from what you're seeing [00:36:00] to what you, what is actually outputted to the server side to the client side or to the browser, I say it's abstract thought, but the entirety that's when having to, when your end of the code. Has reduced complexity, but you're solving the same problem. Someone else has inherited that complexity So it's just shuffle around to the server side or to the framework implementers but the consequences of that complexity is still Yours, because they won't disappear. Because that means for instance, that what if that code fails or what if the HTTP endpoint that's created by server actions is you're trying to call something in the context that you think is local state, but it's actually transferred over the wire to HTTP. So it's as some different time semantics of behavior. So the complexity is. While code wise, shuffled around, it's still something you [00:37:00] have to compensate for in your mental model. Yeah. I largely agree. I think that even though we've, it is weird because I feel like we've made this compromise. We're like, okay, we'll use these meta frameworks if we can use the term to like handle that complexity for us. But I also agree that all of them I've used, I've never not had to worry about. That kind of duality of where my code can be running like very much still is on the onus to develop like you still have to think about this, right? Like you still have to. This is something you're concerned about it. I think there are probably there's one can probably find cases where it's yeah, I wrote this little app and everything just worked and there was stuff running on the server underneath to be and stuff running on the client when it needs to be. But I don't think that is a super common story. I think devs are still, yeah, they're carrying that in their mental model. So yeah, it's it is an interesting space. Do you think it's making it harder for, more difficult for new devs to jump in? To get started? That's a good question in a way, but if it's harder or just different that's the [00:38:00] hard part of it. So It's different, but is it different or harder because you have baggage of the other thought patterns, or is it easier because it's less things to think about, or you're guided towards best practices by default. And if you're trying to, for instance, let go of what the transition you have had as a developer for entirely new developer is it easier to adopt for a first timer that doesn't have the baggage and I think forms, for instance. Is a great example of this. No one has ever. For the last five, six, seven, eight years, people have forgotten that forms are a thing. So if we're asking them, can you do a post request from HTML? Now you need JavaScript or an Ajax for that. Oh, no, you can use a form versus you can get accessibility by default. If you're just using a form and buttons instead of trying to have an on click handler on the Stop event propagation [00:39:00] all these things, right? Yeah. Yeah. But you can say that Moving towards this and moving towards web standards. It's easier to do best practices. So it's easier to do the right thing. And harder to do the wrong thing, but that's also a good thing. Yeah. I think that makes sense. Yeah. I think so as well. So I guess on that note, do you think that. We'll continue like this kind of trend in general over the next five years or so. Do you think frameworks will keep pushing us towards more web native stuff, this new paradigm of using the standards, maybe again, like a little bit more developer overhead, potentially debatably. Or do you think that this is we may like you said, like the pendulum might swing back for a bit and we'll regress on At some point it will probably swing back and maybe we get new like surfaces to, to add the applications for, or the edge function stuff requires us to do different things, but. I think [00:40:00] use the platform as a term and as a like best practice isn't something new. It's been repeated and said many times because, but it's been hard to enforce it. I think now we're seeing again, because of the opinionated nature of and adaption rate of meta frameworks. We're seeing greater push towards the web standards. Using things like response objects and using things like URL search in web APIs, instead of having your own query string implementation, that's just a little example, but. Again, that's also, by definition, standardization across different things. So that can also mean that it's easier for newcomers, for instance, to have interoperability across different implementations of things. So now we're having the exact same architecture with different implementation details. And using [00:41:00] a lot of the. Same common building blocks of the web standard. So I think maybe, and it's maybe famous last words or whatever, but I think maybe it's getting simpler to move across different implementations over time in a sense. Yeah. Yeah. Interesting. Yeah. Cause I, it does. I think I agree. It does feel like the, there, there is similarities. I don't know. I don't know how easy it is necessarily, but it, I think you could logically port an app. Maybe a lot simpler kind of once we're, once you're in this space between these kind of, meta frameworks that are handling all this for you and doing this building. But yeah, like you said, I think time will tell, we'll see where we go. So all the way I think about this is that all these paradigm shifts that are more permanent because they change how you think about writing code instead of just how you're writing things. And I think we're often in between those paradigm shifts. We're focusing on [00:42:00] improving how we're writing things, but when the paradigm shifts happens and we're, which makes them much more permanent, which we're changing the way we're thinking about. Or I think them, and that's much more powerful. In a sense yeah, for sure. It's a different, we're viewing them from different angles. The, our code, we're looking at our, the stuff we're writing day to day with kind of different perspectives for sure. Yeah, that's, I think it's probably a, as good a note to leave listeners with as any, is there anything else you want to point, point people towards or shut up before we sign off? That's No, I'm sorry it took so long. And I always in my Norwegian podcast, I tried to make them 20 minutes. I think I failed miserably, at this point. It's But I think it was a good discussion and if anyone has any questions or want to be to disagree, I'm still in you and in Norway threads aren't released yet because of privacy issues. So I'm still on Twitter. So if there's any [00:43:00] questions at Michael Breivik is the place to direct them. I see. I will, we'll get the we'll get that handle in the show notes as well. Thank you so much for coming on and chatting with me, Michael. It's been a pleasure, Yeah. Thanks for having me.