JavaScript Frameworks in 2025

2024 was a weird year for JavaScript Frameworks we didn't really get some big new invention or Paradigm or framework we just kind of kept moving along to make the things that were already going go a little bit further it's weird to say but the framework that changed the most in 2024 was angular but we're not in 2024 anymore we're in 2025 and maybe if you're watching this later 2026 78 why are you here for everyone else 2025 has started and Ryan carniato the creator of solid JS and probably the single person who knows the most

about every framework wrote an awesome article all about it the article is so awesome this is my second time recording this video because the first time I recorded it I got uh six paragraphs in before I made the most intense set of diagrams I've ever made all of these are their own separate video now by the way I don't know why you ended up naming it the current plan is all the different ways to render your JS app I'll be sure to link it in the description if you want to see me making these diagrams

and in-depth explaining all of these render strategies but this video is not about the render strategies this video is about how Frameworks will change and evolve in 2025 so if you don't know what an isomorphic Spa is and you think it's important to maybe go check that video out first at the very least we'll be coming back to the diagrams and touching on it but our goal is to better understand what's going to happen to JavaScript over the next year before we do that I got bills to pay so let's hear a word from today's

sponsor today's sponsor is Prisma and they made a DB you might be tired of seeing new DB providers but there's a couple reasons you're going to love what they built first off it is literally three clicks to deploy that's so simple it's also free like really free the pricing is super generous you get five projects on the free tier and each of those gets two environments you can handle Dev and production you don't have to eat a separate database just for that they also make things easier for us serverless folks they have autoscaling connection pooling

built in so you don't have to worry about using all of those connections up just because you're running on versell or NFI they also have real time which is dope because adding that to your database yourself isn't fun now you can literally just stream in the results because it integrates directly with the Prisma omm and there are a lot of really cool things they do with that along with the connection pooling you can cash on their Edge Network you can literally make a Prisma call give it a cach strategy and now this value will be

cached on the edge you don't have to connect to a database and wait for the lookup anymore and you can directly evict it if you need to as well it's really cool having that at a database level I'd never seen or even thought about that before but for those of us that don't just have one server man this is really cool things that they're building thanks to pris for sponsoring check them out today at soy of dlink Prisma DB JavaScript framework's heading into 2025 I admit I wasn't sure I'd be writing this article this year

it's easy to write articles that excite people about the potential of new tech but 2024 was a year of coming to terms with reality past several years have been an exploration to discover the unknown we entered this year excited it was finally time for these advancements to find refinement they have but one thing is abundantly clear the Quest for Simplicity hasn't resulted in making webdev simpler yeah most people feel like webdev has gotten more complex and I understand why they feel that way I think it's checks and balances on every side but the overall Vibe

is not that web dev got simpler that sucks clearly some things have become easier to do but the overall picture hasn't simplified we already knew this but something changed in 2024 aided in part by pressuring from the global economy tightening budgets and keeping Solutions on the safe path I think it's finally been acknowledged that there are no silver bullets difficult problems are always difficult to solve there is a separate problem here where we started using the solutions for difficult problems to solve much simpler ones and now everything is more complex than it needs to be

but we can't solve difficult problems with Simple Solutions the size of the problem and the size of the solution should roughly fit each other if you're using rust or Zig for your rest apis or you're using react for your blog you're using a solution to a big problem for a much smaller one and I think that has resulted in us over indexing on trying to find Simplicity instead of acknowledging that certain things have to be complex and I love how Ryan put it here difficult problems are indeed difficult to solve we can't pretend there's a

magic Silver Bullet that will do it it isn't just the tools that are complicated but the problems themselves it has taken hitting obstacles around every corner while going back to the basics to only reinvent the wheel to return to that fundamental place it's a sobering thought but it gives me hope in 20125 that we can take some time and reevaluate and that starts with reflecting on 2024 promise of the server making things server first has been the narrative over the last 5 years in front end this is not a New Concept the web was born

on the server but after a decade of client Centric single page apps it was clear that the pendulum had swung quite a bit too far especially for page load sensitive websites which did not benefit as much from The increased interactivity the pandemic only Amplified this with both the rise of online shopping habits in the influx of capital driven by low interest rates the first time I record I went on a whole rant about how there hasn't been a new frontend framework in in a while and I'll shorten it there hasn't been a new front end

framework in a while and a good part of that is because a lot of them were being driven by investment like people don't seem to know this but like spel kit is mostly maintained by versel devs and versell raised a lot of money from Venture Capital Astro is its own separate Venture Capital backed company that has investors remix was originally invested in by OSS capital and has since been acquired by Shopify solid start is Ryan doing his own thing quick is mishko the creator of angular doing his own thing fresh is part of Dino and

I'm almost positive Dino is VC funded uh yeah Dino is very fundraised they're doing okay an analog which is similar to soloart and quick where it's just this case it's just Brandon Roberts trying to make angular usable for full stack development cool stuff oh yeah quick is Builder iio and Builder iio is also VC backed so the only things in this list that don't have VC money of some form are solid start an analog which is kind of crazy last couple years have seen single page app influenced isomorphic which is the same code running differently

on client and server approaches up against multi-page app influenced split execution models with islands and server components and those approaches are in a search to find a universal solution for all I am not sure if one exists but I'm excited to see what Ryan has to say and if these words mean nothing to you your mistake go watch the other video I recorded it for a reason that one took a while my poor editor slaved over it so it's a good one I promise you it's a diagram video those are my best ones go check

it out and do not complain about how long it is you're the worst commenter if you're about to leave that comment saying I missed when your videos were 10 minutes long my videos should be 3 hours long shut your face anyways the long ones where where their value is enjoy them it's an exercise of two opposites trying to approach each other in the middle this has resulted in some amazing developments in routing like the nextjs app router as well as view transitions in routing as well as Tech like server functions optimistic updates server Islands single

flight mutations no mention of out of order streaming Ryan that's unexpected yeah there's a lot of these pieces that allow for a URL to behave a different ways so when I go to one URL it does one thing when I click a link it does something else when I load a page all the different things it's funny I guess that's old to me this his response to me bringing up out of order streaming it's hilarious because I'm still trying to explain this like I just was at a laravel event yesterday I spent half the time

trying to explain out of order streaming to the team building inertia and building all of the routing stuff for laravel I did the same thing when I was at Elixir conf last year and I convinced the team building Phoenix as well as Elixir Jose valim himself that there was so much benefit from the outof order streaming patterns so yes to us it feels old and I know you were doing it back in 2019 with your crazy eBay stuff God Marco yeah I I know you've been doing these things forever Ryan but to the rest of

the world to most people doing webdev they probably won't even think about what out of order streaming is but the first time they've touched it is going to be next app router with suspense boundaries so I would personally have absolutely have included out of order streaming as part of this revolution with routing but I totally agree with you like the Focus right now isn't the client or the JS that we're running on our devices the Focus right now is entirely on the server and how the URL the generation of content and the client all work

together and there have been some cool things going on here quick break down of all the terms I know people are going to be confused server functions are a function that the client can call so instead of just hitting an endpoint with Json and getting back Json a server function feels more like you just wrote a function and called it on the client usually there's some compiler hack that either binds it to an arbitrary URL or creates some thing in the background that you post to but ergonomically it should feel like you just write code

then call it on the client and it behaves optimistic updates wait Ryan you didn't put out of order stream but you put optimistic updates optimistic updates I've been doing those since 2015 man optimistic updates means when a user does something we show the updated State before the server can confirms it so if I post a comment it should show me the comment before the server actually writes the comment in the database because I want have to wait for the server back and forth and just see an empty thing up until then optimistic updates are lying

to the user that a thing is done server islands are the idea of having parts of your HTML where this part doesn't come through the initial response when you go to the page instead of getting the whole HTML page you get most of it with little blocks in it that say Hey this part's not done yet this part's not done yet and then either the rest gets streamed in with out of order streaming or usually with server Islands what it means is those blocks have a little bit of JS that goes and requests the rest

of the HTML from the server to fill those parts in as well as single flight mutations one of my favorite things on the list instead of I post some data like I leave a comment on the blog the server says good job thank you and then I have to go fetch from another endpoint to get the updated content a single flight mutation is I post the comment in the server responds to that post request with the updated state somebody asked in chat this may be stupid but what does it mean when I say server that

is a a long- winded question I'll give the quick short answer first which is the server is the thing that when you go to a URL generates the response so it could be a really simple CDN that sends HTML it could be a thing that runs JavaScript in node that processes your request and responds with Json it can be a thing that is running right in front of your database and go or rust or whatever when I'm saying server here I mean the thing that resolves the content of a URL usually what we're referring to

here is a nodejs based or JavaScript based Runner that exists externally that is owned by the developer of the service you're using that a request is sent to and a response is generated by usually so a server function means you have a function that like adds a row to a database so you write that in server code and now on the client I can import that function and it doesn't let the client access the database the client can't just right to the DB arbitrarily but they can call that function and what it's actually doing is

it's hitting an endpoint that was generated to tell the server to run that function to go do something but the server in all of these is code running on a box that the developer either owns or rents that resolves a URL to something and all of these wins are effectively ergonomic wins in how we develop those relationships between the server and client and how we use the data when we get it and as I was saying with single fight the thing I love so much about it is instead of having to get a response says

hey I did my job and then go back to the server to get the rest of the content you just send the change down as part of that same request so there's no more back and forth when data changes one other thing worth considering when you think about server here is it might not be the backend that is your whole API you might have a team that wrote everything in go and Python and whatever other Technologies connecting to the database and managing all of that so you might think your front end has to just be

an HTML file that loads JS and then hits those apis it doesn't have to be there's a pattern called BFF backend for front end and I think pretty much every single website benefits some amount from having a BFF even if you want to keep all your apis and everything else on a traditional API backend written in whatever language and stack you want to having a layer that lets you build a stronger relationship between the frontend and those apis and data is great most websites benefit from having a server that is built for the website not

built to arbitrarily serve like Json because having a server that can do a little bit more with the HTML and the JS and those parts gives you all of these superpowers that make the experience for the user significantly better doesn't matter how good your company's at rust having this tiny thin backend layer that just calls the rust apis and generates the right HTML it's okay to have that little bit of JS because if you're not running some js on the server you are not giving the best experience to your users and that's not a take

that I am talking out of my ass I love JavaScript I actually stole that take from Ryan himself I remember the first time he said that in a live stream it it was one of those rare moments in recent times that broke and rewired my brain where I was thinking about it not as JavaScript backends versus the other backends anymore and like I knew the BFF like backend for front and pattern the thing that broke my brain there that I was really hyped about was the realization that every website benefits from this and it's almost

irresponsible if you're building a website with users to not have something going on in in between that and whatever else your backend is if you're hitting a database directly cool if you're hitting another API cool but BFF backend for front end it means your front end is better and yes Hobbit I am saying this if you don't use JavaScript on the server some amount you are almost certainly making a bad website like almost certainly go check out the end of HTM x video if you want a more Nuance to take about this relationship but you

have a pretty hard cap for how good of an experience you can make for your users if you're not running some js on your servers almost certainly anyways the harsh reality is once you build that BFF and then you start using all the patterns here things stop being as simple as they might have seemed in the past I would argue yes and no as we saw in the diagrams the spa way has its own levels of complexity but most devs don't even know about it and that's the weirdest thing I know for a fact the

average react Dev is building this way I would venture to Guess that the average react Dev doesn't understand how much of this is going on I even seen in chat and like my chat on Twitch isn't your average react devs they know what doing for the most part and they don't know all of this is going on they just write it but when you write with a BFF pattern and you write using these new routing things suddenly you're thinking about these relationships a bit more and that will inherently feel like complexity because previously you never

touched any of it it's a weird example but a similar thing that happened to me a while I got in a fight with the CEO of a graphql company because he did an article graphql versus trpc and in this article he was trying to demonstrate how much simpler the code was if you used graphql instead of trpc trpc is an easy way to write your typescript server functions where you can call them on client without having to write a schema graphql is a great way to make your fun and backend teams who hate each other

actually talk to each other in a way that makes some sense the article was written in a really weird way though because it would show the react client code for the graphql side and say look at how simple this is and then it would compare it to trpc showing the client code and and the server code so if we were to view this slightly differently we'll say here's the trpc Box the trpc box has these two pieces that fill it up we have the client and the server the box is as big as these things

expand it to be if we were to compare this to graphql let's say theoretically with graphql the client part is less complex so this is smaller now let's say you're a frontend Dev so you don't care about that part wow graph Q is so much less complex than trpc why would anyone ever use trpc when graphql is so much easier there's a reason I would argue first off that they're lying here someone who's implemented a lot of graphql in a lot of places and also was a keynote speaker at the last graphql comp I'm not

anti-g graphql the complexity is pretty big that said even with the graphql client side complexity being bigger if you ignore the server s side entirely it still probably averages out to being slightly smaller in in terms of the overall complexity than the client plus server side actually no it doesn't that's a lie I just did a video one at five Stacks where I built it with graphql and I built it with trpc and the full stack with trpc had less typescript code in it than the client only using graphql because setting up the cent of

graphql is complex but if you lie and pretend it isn't cool we'll do that we'll go back to what I was saying before we'll pretend the client is smaller than it actually is no one who is even kind of good faith will ever say the server is less complex in trpc or rest bace system than a graphql system the reality is you basically need a PhD to do graphql properly so if you have the goal of convincing stupid web devs that graphql is better than trpc all you have to do is make sure they don't

look past their tiny little client size box so if you write an article saying that trpc is more complex than graphql and the word resolver doesn't occur a single time in it you're a liar and a bad person and you should feel bad about it and I have let that author know how I feel long ago if you were there you were there he has since personally apologized to me because he realized how stupid he was being the point you're trying to make is it's very easy if you only look at the box that you

are currently operating within to ignore the complexity adjacent to it and the thing that makes trpc great isn't how well you can ignore the server from the client or how well you can ignore the client from the server thing that makes TPC magical is how well they work together if you want want a new API on the client you just go write a new function on the server you don't have to reshape it on the client with a different query you just make a new endpoint you copy paste it it's fine you should have a

bunch of different bespoke endpoints in trpc for the client specific needs that isn't more complex because the whole story from Back to Front is way simpler and sure if you compare the size of these two clients it's like wow trpc is more complex why would you touch it it's not that simple I think we're seeing the same thing here with single page apps one of the crazy things that react did is it made webdev able to be more complex all of a sudden when we were building applications for the web we weren't limited on the

HTML being loaded jQuery helped a lot there but tools like webpack react and typescript let us go from having 10 to 100 people working on our websites to thousands working in the same codebase which is just insane when you think about it but with that front has gotten so complex that we now have principal plus level Engineers that do nothing but live on the client their whole job their whole life their existence their decade plus of experience occurs after the network request has responded and given them their content you could make a full great career

from web pack down not touching the backend at all I am not like that most of my career was backend Dev I came to front-end late I know it doesn't seem like it now but I did so when I saw the front-end tools and Technologies starting to embrace more of what the backend could do to make the run and better what I saw was all of this complexity in chaos being reduced to a much simpler model where is it down here the isomorphic spa the complexity here has been reduced a ton at the cost of

having to understand this part the reality is that I already understood this part because I'm a backend Dev I know how these parts work but if you are a web dev that has mostly ignored the relationship between the browser and the server Beyond fetching from an API and you don't really pay attention to what goes on up until this line effectively like you don't care about how your website works until you have passed the line of it rendered then everything we're doing right now is going to seem really complex but the reason it seems complex

is because you've been ignoring the complexity you have pretended this part doesn't matter and I hope the other video I recorded helps convince you that you should understand this part I saw people in chat saying that they're going to go rewrite their apps because they finally understand certain things that were going wrong every react Dev every web dev should know about this but they don't and the fact that we are reducing the complexity here by adding a bit more pieces there does not mean the whole is more complex it just means that you can't lie

to yourself and pretend the server doesn't exist anymore and I cannot tell you like if I've learned anything being a backend Dev who moved to front end it's that the average front-end Dev from the last 10 years likes to pretend the backend isn't their problem the same way back in De I like to pretend the frontend isn't their problem it's an adversarial relationship that is centered on this idea that you're pretending the other half doesn't exist and I hate when devs do this I love having the whole picture I might not be as deep on

like memory management as primagen or Casey moror is but I know what it is and what it does I might not be as deep on CSS as someone like Josh comeo but I know it well enough to communicate his message I love piecing together the whole picture so what I see here is a lot of complexity on one side shifting to less complexity on the other what a frontend Dev sees is wait I have to know about servers now I that's so complex that's so much harder my favorite example here and if you know you

know if you don't you don't I had to teach Dan abramov what a cold start was the guy who made Redux and helped lead the education efforts into the new era of react didn't understand what a cold start was and how it would affect rendering your react apps on the server I had a Twitter space in 2022 where I explained in detail what a cold was and why it would affect him while he was boarding airplane wild experience but that's the reality you can have a deep experienced fulfilling career as a front and Dev that

barely understands servers but as the tools evolve we're being encouraged to know more about servers and most people are going to have their brain shut down feeling like it's way more complex so while I agree with you Ryan things aren't so simple anymore I think this is less that complexity has gone up and more that the complexity isn't being hidden or running in the browser anymore that's a fair point actually Ryan it's not just that it requires Ires more knowledge but also the code in the build processes too there's a whole separate rant I need

to do at some point which is like what webpack actually did because webpack making most websites built by default instead of like compiled or quickly transformed or not even just written statically by default has allowed us to exponentially increase the tooling and complexity for any given app because we now take it for granted that our JavaScript has a build process and that build process now also spits out node code for runtime and yeah the the going from the files in your codebase to an app part absolutely that's gotten more complex especially when you consider the

complexity of like this Edge worker and setting that up properly yeah you know I take it back I agree this is a great talk that Ryan did back six months ago facing front end's existential crisis highly recommend checking it out Linked In the article I remember watching this when it happened but I haven't seen it since I'm going to rewatch that later myself it's been incredibly difficult to actually measure success here we've seen benchmark fails so this is actually fun I have a whole video about this where uh a benchmark was done comparing the serers

side rendering performance across all the new Js Frameworks that do SSR and it was not good check out my videos about SSR benchmarking if you want to know more about that everyone from Rich Harris to Dan abramov to Ryan to myself all jumped in to try and fix it and make the benchmarks more useful but that's far from the only problem we've also seen performance wins being attributed to new tech when the root case was actually somewhere else for cells partial pre-rendering which I talked about PPR a little bit earlier I have a lot of

videos but if you want to understand it better it's a fun call it from Ryan I I see now why he said this is going to trigger me in hopes of understanding the nextjs partial pre-rendering as well as Astros server Islands I made soloart versions of the demo that doesn't do either no pre-render also no partial hydration deployed it to NFI in the versel edge vel's partial pre-render does outshine its Edge renderer but it's comparable with other Edge Solutions because rendering at the edge is not super expensive depending on the framework optimizing image preloads makes

a bigger difference than any of this I absolutely agree there like most things feeling slow so much of it comes from images there's actually a really fun demo a while back where remix was trying to show how much faster it was than nextjs for an equivalent site and they Ed the optimized images from next like the images in the remix version were tagged ascore next SL because they were grabbing them from the next deployment because the site despite being on the books and in the network tab faster felt way worse because the images were slower

so despite the fact that their framework was faster they relied on next's image management because it looked slower otherwise funny enough Ryan just said in chat he did the same thing he used the optimized images from next for his example here so we can see in the example NFI Edge versus vercel Edge versus verel partial pre-render the verel partial pre-render comes through it around the same speed as the netlify edge does actually I was talking a lot about this with Matt bman The netlify Edge is a much it's a much better Edge to say the

least where the netfi edge it's using some of Dino's really cool like globally distributed runtime stuff it is my understanding right now and I haven't confirmed this but is my understanding that forel's edge is using Lambda at Edge or some other crazy AWS Tech that has to be routed through a Gateway before it can start going which adds an inherent penalty to the whole process for S partial pre-render can skip some of that penalty which is nice but it also means that for cell's partial pre-render where it saves the static shell and then renders the

rest isn't meaningfully faster than nfi's Edge if anything it might be slower at times so very interesting call out and thing I need to think about more I do really like the idea of static Parts being static even if like for cell implementation isn't right yet static should be static and dynamic should be dynamic and no one's cracked the path there just yet but it is painful to see that the tech that I'm most hyped about in the space right now which is PPR isn't performing better than just rendering on the edge anyways yeah I

have feelings not wanting to wait through the mess has led the conversation back to more traditional server approaches ones that exist outside of SSR ones where you aren't trying to run a client JavaScript framework on a server it's always been a great choice for projects where it makes sense but it's also pretty uninteresting we wouldn't be where we are if there wasn't a need to improve upon what came before and that can take a lot of trial and error the simplest tool for the job is the correct answer when the problem cease being simple you'll

want options that scale with you 2021 and 2022 were a reset to a simpler base and a return to our beginnings on the server 2024 was the reminder that simple doesn't always cut it compilation to the rescue oh boy is this going to be my last framework video just a the spoiler hint for the future a video I've been planning for a bit react is the last framework I have some fun things I want to say about that we're not there yet but eventually so we have the lightweight synex in our framework but the compiler

is the one doing all the heavy lifting compilation is an everpresent aspect of JS development whenever we've hit an obstacle whether it be a browser feature that isn't supported clunky syntax or the ability to address shortcomings of the language we just build a compiler for it it's so ubiquitous at this point that standards committees are considering going in a different direction for introducing new features this is the JS zero thing I talked about they're thinking of having JS be a much more minimal set of things and letting compilers like webpack and Babel add new features

so instead of having like tary operators they would compile to traditional if statements and the tary operator would just be syntax sugar in the new Js sugar standard that can move faster and be imped by compilers instead I think it's a terrible idea but I get why they're saying it because JS is such a a weird moving language in so many people using JS or using a compiler anyways it's fair point Ryan made here that compilation and bundling are the core of how modern JS apps are created but they're also where the complexity tends to

come in JS tooling I'm sure Carson over in the htx world is laughing at us benefits are Ms though types lenting tree shaking code splitting minification isomorphism macros dsls monolithic authoring and distributed deployment if you don't think webd is way better than it used to be then you just weren't building real apps that's how I fundamentally feel I'm not saying it isn't more complex I'm saying it's just way better every advancement in the past 15 years in this field has been built on the foundations listed here there's no alternative that could even remotely be considered

adequate by comparison call it unfortunate call it a limitation of the JS language call it necessary complexity but to deny it is futile yeah we are fully aligned here as usual Ryan however if we want to understand complexity it is at least important to understand the source the most interesting development in 2024 thanks largely to both the release of react compiler and spelt five runes is how muddied the conversation has gotten fair I just posted a video about how people are getting less happy with JS over time and I think this is part of it

reail is a really interesting one because I don't feel like anyone's really talking about it despite it being so cool and fundamentally changing how we should be thinking about react no one cares and everyone's mad about spell five runes because it's forcing you to acknowledge that magic syntax only scales to the size of your framework I've definitely seen interesting things because of these though on one side we have the react compiler which is an auto optimizing compiler that transforms code in a way that reduces unnecessary re-execution without manual intervention if you haven't seen my react

compiler content you should watch it it's good but react compiler is effectively adding all the used memos and used call back calls to your code to prevent renders happening unnecessarily and it can do about as good if not slightly better job than the best react Engineers can while letting you delete a bunch of code that makes react harder to write what I'm excited about there isn't just that like oh I don't have to write memo anymore it makes maintaining my code easier it makes code reviews easier and probably most importantly makes the code easier for

AIS to generate because I don't have to worry about all the weird memoization behaviors the compiler does that so we have a simpler syntax that we already have a lot of references for as we generate and WR the code of the future and it's funny because the react compiler is actually quite similar to how spelt 3's compiler worked back in 2019 but on the other hand we have spelt 5 runes which brings a syntactical sugar over A fine grain signal renderer which is similar to what solid added back in 2018 these are two major compiler

projects that couldn't be more different that called into question the fundamental nature of both projects react acknowledging that renders do matter enough to optimize around in spelt trading away its minimal Syntax for a more expressive language with increased capability as well as better fundamental basis for performance ironically these stances are both exactly opposite of the initial selling points this was really funny I I did a meme a while back because people were saying that felt so much simpler than react it was because the syntax wasn't JavaScript they have a compiler that did that the react

syntax was a lot closer to vanilla JS now this felt syntax more clearly indicates it's doing something here by giving you that it's actually closer to where react was and reacts kind of going where spelt was we're all Trading and going back the way I describe this Everyone likes to think of change as a pendulum so if we have just js on one side and we have compil it bro on the other side people think that we have like a pendulum in the middle here that swings back and forth between the JS and the compilate

bro where we're just constantly going back and forth between the two it's my belief that these are a spectrum that has a different axis on it so the horizontal axis here is from just do normal JS syntax to compile it but vertically there is quality of tools we use and while I agree we do go back and forth here a lot I don't think it is a back and forth where we don't increase the quality I think as we go back and forth it's more of a spiral spit their case than a pendulum where we

are going back and forth to find the best Solutions between these two paths so yes it seems like spelt didn't react as traded philosophies but I think that we are constantly evolving the quality of the things we use and most importantly the quality of the apps that we can ship and the size of Team it takes to ship those things I was able to build an app that is pretty much the full functionality of Zoom myself that's insane that's so cool that something like Ping I get all the functionality working before I had a team

helping me with it I'm not going to say it was pretty but it worked it was being used by huge streamers like iron Mouse literally 5 days after I had started this as a side project project and that's because the tools and technologies have evolved there and I think we need to acknowledge that yes it feels like we're going back and forth but you need to pay attention to how bad things were previously because just vanilla JS in the 2000s is very different from feeling like vanilla JS today compilers in the old days are way

less powerful than the compilers of today like the react compiler is such an achievement that to say that it's just them copying spelt is to miss the entirety of what's going on here so yes we are going back back and forth and I know Ryan agreer even said it in chat didn't talk about it people think compile stuff is just JS that's been the most difficult thing to talk about yeah this wasn't the role of your article this is the role of me adding these nuances yeah you calling old react and compiler just JS the

compiler is not just JS I'm with you there Foley you call it the right thing I just wanted to add the Nuance of the spiral staircase versus the pendulum this is a fun call out about the spelt five runes versus compiler both increase the complexity of our tool in to existing approaches to be fair most devs are probably not going to feel that if I go to my next config for this app that is using react compiler here's all the work I need to do to add the compiler it's doing a lot more under the

hood for me but the complexity I feel I would argue that the react compiler has been the easiest technology I've adopted in a very long time you just turn on this flag and it just works which is it it's a magical feeling to the point where I think it's why no one talks about it because there's no controversy with the compiler there probably should be though and that's that's what we're here for with this article the ver is still out on whether these changes will ultimately be good moves for these projects the common ground is

the foundation that we build upon continues to get more complicated as we attempt to create solutions to make development easier yeah that is fair the difference being who owns the complexity like to go back to the analogy earlier with the trpc versus graphql if you only own the client side and trpc forces you to also own the server trpc looks disgustingly complex why would you ever touch it but if the client and the server are both things that you're thinking about obviously trpc is the easier solution What If instead of this being client server this

was react with memo calls where we have like core react syntax and here we have nuances of memoization I would argue that the Nuance of memoization are actually quite a bit bigger than the core react syntax learning how to use memos and callbacks in the render method properly is quite a bit harder than just writing vanilla standard react code so if this box represents the complexity that the dev building the app works with and owns because you have to own this react code in your code base obviously but you also have to own the nuances

of the memoization and the performance and you better be using things like react scan and the million lint stuff so you know when you're over rendering if the react compiler succeeds you only have to own the core react syntax part you no longer have to own all of that Nuance the result is more complexity as we see as we scroll to the right here a compil hand memorization for you that is a big complex thing but you don't own it react team owns this app devs own this so if you're on a front end team

and you only own the client and the backend team owns the server you're not feeling the complexity of that that graphql adds like graphql makes life for backend devs way harder so that we can have a slightly better experience on the front end react compiler makes the experience for the react team way harder so that we can write simpler code and to be clear it isn't just us this also allows for simpler code to be written by AIS because AIS no longer have to think about these nuances that makes it way easier for an AI

to write code that is fine and not have to do things wrong and I'll go a step further and say that this kind of cements react as the final framework I will do a more dedicated video on this eventually as I mentioned before where react's the last framework a lot of reasons we reach for other Frameworks have to do with this being complex not being able to do different ways of updates like signals that perform better not being able to export different things that make more sense if we just keep increasing the complexity of the

compiler via a team of experts that are really good at this and the react core syntax never has to change we never have to worry about the AI not having enough data because the data all can be collected from the Decades of code written this way we have the data we have the react code if the react code can output something that is more powerful more performant or has more functionality neither we nor the AI have to learn anything the decision here it feels like the react team has chosen to offload all of the things

that make react a worse framework until you learn how to fix them and just take those problems away server components solve a lot of the data management part this way compilers solve a lot of the syntactic and actual writing ergonomically part this way so this is one of those rare times where Ryan and I actually disagree I have the opp opinion if you con strain the language you lose the ability to express intent this is a tough one I think that react syntax didn't clearly communicate intent a lot of the time I did a video

about the react compiler and performance in apps like this it should be out by now if it's not I'm sorry it'll be linked in the description eventually this is the demo we have these three boxes we have a counter click it increases we have a Color Picker and we have a slow component this component renders 10,000 boxes all of them are part of this parent demo component we see the use State here for count we see the use State here for color when I click the increase here you'll see react scan running and showing us

when things update you see everything updates when I click and it takes almost half a second to reender that watch what happens when I use the Color Picker see how laggy that is I am just dragging the cursor around and it has to catch up because every single time it moves any amount it has to render all three components which would be fine if it was just rendering these two cuz they're fast but since one of them is slower or imagine a giant app with a lot of them even though slow component doesn't use any

of those props it will still render when either of these things change and that's the problem with the default react model and it is surprising it doesn't matter more than it does but it does if I was to go memoize all of these parts we'll even do it all memoize slow component slow component renderer and we'll wrap this with a const slow component equals react. memo slow component renderer cool wait why is it still rendering here is where we have to get into the nuances to make these things more complex see here with slow component

I have this unused prop being passed to it I added this because at the time I did this demo react scan wouldn't show you the name or the highlight of a thing being rendered unless it had props of some form so I gave it this fake unused prop there's a Nuance here though because I inlined this object it is redefined on every render so it isn't memorized because a new object is unique and even though the component is memorized it sees a new object being passed to it if I change this to a be string

like just nope instead now the memorization does what it's supposed to and if I had moved the object out so it was static so const demo object equals that and I pass that here instead now the object doesn't change between renders and it's still works but if I was to do something simple and stupid like let's say oh I want to do something else with this or oh I want to use it in effect or something so you just move this innocently here that move just nuked the performance of your app in a way that

you would not have intuitively guessed no matter how good you are at react most people would not have caught that that small change is going to destroy the performance of your app because they're going to look and they're going to go check and they'll be like oh yeah we memoed the slow component it's already memo wise we don't care but there are so many of those that when I did the video demoing it I went out of my way to write everything properly memorized and still hit like 12 cases another one here is this onchange

we're defining this function on every single render so even if we memoized it this is still going to rerun what it shouldn't because this on change is defined there same with this on click this on click gets redefined on every render so even if we memoize counter button it's going to rerun I bring this up because we're talking about intent when I move this object from here inside the function or when I inline this object here it is not my intent to render the component every single time that was not what I or any other

Dev was thinking when they put an object that is effectively a static constant here they were just doing the thing that is more readable and easier we could add a bunch of lint rules to stop us from doing stupid like this we could make our code harder to write we could force our devs to con uh like color changer equals use call back and now I have to like go deal with the types of this where the onchange here it's a value or it's a string so string set color e import use call back pass

that here then I have to go do the same thing for the counter const color uh counter changer use call back set count move that over you get the idea if you do this for all of those and you have to memorize the stuff what if you didn't just going to get stash all that now I'm running the react compiler this code is as simple as it can be we're no longer memorizing the function here the word memo doesn't occur in this code really neither does call back none of those things exist anymore the code

is simpler we can just inline things like that but now when I go here only the part affected is being rendered now none of the other boxes are actually rendering again I would argue that the intent I had as a developer here is being better handled now with the compiler than it was before because putting an inline object here was not intending to trigger this component to re render every time putting a function here wasn't intending to redefine the function every time I render the file the intent here was to write simple code that describes

what's going on react didn't let it be that simple before for the compiler I personally feel is better encoding the intent I had as the dev and that's what makes it such a magical technology and it's also why I'm excited for how this is going to affect AI stuff because AI can write simpler code and the compiler will make it more performant it's a really cool win and I seems like Ryan now is seeing it this goes back to leaks and abstraction which make complexity real yeah we get it now react is absolutely own language

it has been for a bit but this is the like tripling down on it I'm kind of disappointed that to my memorization questions on interviews everyone can now just answer with just use the compiler man very fair point you know times our are stupidly so this is why you guys got to watch my react compiler content I go so deep on these things and no one cares it's yeah the I think we're more aligned now I see why like in a literal like especially a framework author sense that the code you write with compiler less

describes what the code does than the code written without it where you're memorizing everything by hand but the the fact that those behaviors are different isn't the thing most react devs understand the intent of the average react Dev is more aligned with what the compiler does than what the vanilla react code does anyways oh I Ryan goes into the AI I think this will be fun if compilation and bundling are fundamental it's clear at this point that there are foundational pieces for giving AI the tools that it needs to create very Dynamic Solutions in the

future while we are seeing bigger impact every year on what these tools are capable of in improving our local developer experience ai's impact on JS Frameworks themselves is still pretty minimal earlier in the year we saw Devon make Headlines by creating simple apps although it did call into question what our expectations are from the technology is it simply enough to make something functional or does it need to be good by the time this video is out my project will be out I'm building the best AI chat app right now it has taken a lot of

work I'm really proud of what we have you'll get to see it very soon I think the reason that a random person like me can build a better AI chat app than open AI with chat gbt or anthropic with Claude is because their focus is on the models not building great applications and they for the most part are probably using the AI to generate half the stuff they're building anyways am I using a lot of AI gen code yes but I am Allin focused on a high quality local first really good client side experience try

it when it comes out you'll see it very soon Friday is going to be a fun announcement but yeah I I think that not every app needs to be really good and local first but some benefit from it meaningfully and I don't think the AI is going to figure out those nuances anytime soon Deon decided to build a client side rendered to do app in about 130 kiloby of JS it scored a 79 in Lighthouse as poor as that score is it is pretty representative of where things are today it will be interesting to see

how the technology grows to meet the scale and complexity I agree it'll be very interesting to see in the sense that Tech like versel v0 has been largely a success at creating prototypes maybe that's where the biggest benefit is right now the million JS Dev Aiden got our attention again with react scan which scans your app for for performance issues my react scan video will hopefully be out very soon you'll see here when you type inside of something like slack everything constantly rerenders because of their weird keyboard Focus layer that's not good that's not good

at all they should use the compiler well one might argue that reenders aren't necessarily a sign of a problem or that this exercise of finding renders in react it's like shooting fish in a barrel it definitely open my eyes to the potential of development tooling just around the corner if tasks are complicated and Cor tooling is more complex it makes sense that supporting tools rise up to meet that need it's more than a shift left in development the need is fully integrated across the whole Spectrum while biome and previously Rome set out on this goal

newer players in the space like void Zero from Vue and vs Creator Evan show that this Foundation is essential to where things need to go next looking forward server second we've already started seeing some of the swing back of the pendulum towards the middle of 2024 with single page app models since felt kit solid start and remix I I've already slightly spoiled that of building a chat app I want to show you guys something cursed I changed how I'm doing it here is the whole app it's a route named static app shell that renders app

app is a react router I'm rendering a full react router client side single page app inside of next because it is a marginally easier way for me to do the weird back and front end relationship stuff and having some static Pages it's when really nice I don't think most mere mortals should touch something as chaotic as this but I've had fun with it you'll get more explanation in the future but uh making this work was pretty simple I have this rewrite that points every path to my static app shell I brute force my own traditional

single page app into next because next did not want me to make a traditional single page app there's a future where I move this to something more sensical like a basic V setup but for now I'm getting the Best of Both Worlds by inventing them all myself but even I am going back to Spas a bit here so it's a very fair point Ryan makes remix ported back their non-server functionality to react router solid starts additive approach to server functions and single flight mutations has laid down the eventual foundations for tanack start which is a

react framework built on the same principles I don't know if you guys know how closely Tanner and Ryan work together you wouldn't think so because like Tanner's the react guy and Ryan's the creator of solid the amount of cool I've seen built between those two and the opportunities I've had to be like on the couch next to as they nerd out is some of the the coolest experiences I've ever had I owe the two of them as well as Fred from Astro so much of my career and success they were the ones who who caught

on to me before I was anybody and like pushed me to to be here today so huge thank you to all of them some of the coolest things that have ever happened in my life were seeing the Sparks Fly between those three makes so much sense that it's funny as it sound like Tanner is taking what we've learned from solid back to react with tan stack start but absolutely is this is worth calling out next is trying to lean more into building traditional Spas with it they're not ready yet I'm happy they're working on it

I like my way better we also seen an increase in local first and sync engine Tech I agree we have no idea where it's going to go because the the need for local first it's real for some percentage of apps but any three local first apps have very very different needs yeah slow and steady wins the race I wouldn't read too much into that chart the the growing dissatisfaction is an important thing to call out I have a whole video about that but it's worth noticing how many of these tools are going down right now

preact slowly plummeting angular dying and then having a huge Resurgence last year with all the changes that have been going on react slow decline as well most of these tools have sentiment going down not up these aren't tools that I necessarily talk about as much when the economy is tight and maintenance is a concern those things tend to shine stuff like view angular and OG react so all Frameworks that Ryan's had in his eye on the coming year not because I expect to be blown away by some Innovation because these tools go the extra mile

and making devs happy sometimes the best tool isn't the best tool why do you keep dropping these things that break my brain Ryan I can't process this right now I'll think about that one more he's right but it hurts me signal Growing Pains the hype cycle is this going to be about how signals were a huge hype thing and now people are rethinking it this will be fun it's no secret that pretty much all non-react Frameworks run off signals now even like angular which is hilarious some time has passed and developers are starting to understand

the depth of the trade-offs present while it's this author's biased opinion that these are minor issues you know guy who made signals a really big deal Ryan here I can get why you'd think that he does expect people to come to a new appreciation for react I know I have I did write a couple projects in solid and it is an incredible framework but there are certain things you can just do and react that are nice you don't think about when you live in those other spaces it's an appreciation that should have probably always had

and that doesn't excuse any of react's flaws everything is a series of trade-offs and you can only appreciate the choice you've made once you understand both sides that being said signals are still evolving the collective experience in this area has grown immensely over the past few years expect the collective result of smaller Innovations over the next year will showcase the unique value Prospect of this approach in ways we've never seen before the web component snipe at the end I appreciate you Ryan and the link is to his other article web components are not the future

10 out of 10 loving this the conclusion unlike previous years I'm not predicting some big technology leap in the next 12 months I don't know if the community at large would be that accepting I agree we don't want big things right now especially with AI That's going to have to learn them I've watched the conversation devolve from whether resum ability makes sense versus partial hydration to who has the best templating scox again God that tweet the like comparing the if statements across language I want to die this is part of the cycle that lends to

a reflection as well as Innovation on the horizon but not today and that's okay I am a little scared we're nearing the end of innovation for web Technologies but that's again I have decided the reacts last framework thing this will be its own video that I'll record sometime soon a lot to talk about there we have a lot of complexity to catch up with first though a lot of hard decisions to make on what technology is worth our investment and effort the raw capabilities for the next generation of solutions exist now I'm not sure we've

seen the right combination a pieces yet in a consumable form but at least we're beginning to acknowledge that in our quest for Simplicity we set ourselves on a path to add back that complexity in new unique ways a single solution hasn't shown itself HTM X is not going to take over the world but it's a great option to have re doesn't necessarily any more complex at doing things than other Solutions async and client server interactions by extension are inherently a complex thing compilers can't solve all these issues but they can do a lot react compiler

doesn't seem when you compare it to really well optimized code like it's doing great but when you compare it to react code that has no optimizations all of a sudden you realize oh yeah things were really bad pre-compiler as Ryan said here it's pretty safe to say even if the compiler won't make react itself faster it will likely make your react code faster yep that's what's so cool you can write simpler code and have faster code as a result it's funny the people who never learned memoization are the real winners because they don't have to

go gut a bunch of old we live in a world full of complexity that doesn't appear to beang changing anytime soon so 2025 feels like a good time to hunker down and get stuff done and for those looking for the next great thing look around there are plenty of interesting problems to solve between you and me this is the type of environment that I thrive in totally agree and I am genuinely really hyped for what will probably be a boring year of JavaScript but what will set us up for a long-term chaotic exciting future thank

you to Ryan as always for writing this article and thank you to all of you for sticking through these two chaotic videos I hope this helps you feel a bit better about where we're at with JS and where we're going to end up until next time peace nerds read the first comment fine react is dead I am so excited for my react is the last framework video now I this is a much better end note