I won't be the first to say it, but I will say it nonetheless, 2023 was quite the year for JavaScript frameworks. Between new technologies we've been watching finally showing they can deliver, and older frameworks making a resurgence if you weren't paying attention you may have missed a pretty significant shift.
I anticipate that 2024 will continue to see even larger changes across the board. This time it isn't about new technology, but refinement. Now that the base is present there is so much more to deliver on.
Server First
If I were to pick a theme for the past couple of years this would be it. This has been a source of contention, but it is undeniable. A few short years ago everyone was talking about Progressive Web Applications and offline first. But that dialog has all but disappeared.
Instead, we are subject to the sharp wit of HTMX explaining why JavaScript is just a mistake. And Astro unapologetically taking over content site development. Even the React Core team embraced the simplicity of server with React Server Components, expressed convincingly by Dan Abramov's talk that looked into what if React had always been Server first.
So what happened to our Single Page App darling in such a short time? Is it still alive or do we live in the age of Multi-Page Apps and server-rendered HTML only?
Reflecting on 2023
Last year I wrote a very similar article looking at the trends in JavaScript frameworks coming into the new year and I think that is a good place to start.
The three major technology trends identified in that article became a significant part of the discussion this past year.
Signals Everywhere
What started at the end of 2022 with the adoption of these Reactive primitives by Preact, and Qwik, following in the footsteps of SolidJS and Vue, only continued stronger into 2023.
In February, the Angular team announced their adoption. This announcement shook social media. Not only that. It was one of a few factors that played into a very notable change in Angular's presence. One some even call it an Angular Rennaissance. And it was the first time in the past few years that we saw the React team join the fray as the very real question being asked was, "Signal's in React, When?".
There is a lot longer answer to that question that I wrote about in the following article (and a discussion with Dan Abramov in the comments).
But the short answer is Signals, at least as an API, is not something they are interested in, and their much anticipated "Forget" compiler would be serving a similar role.
Signal propagation didn't end there though. Lit, the web component framework from Google, unveiled Lit 3 with first-party support of Signals. And Rich Harris unveiled the future of Svelte, their new Signals-based "Runes", to be the main source of reactivity in the upcoming Svelte 5.
Ending 2023 Signals are a major part of most front-end JavaScript frameworks.
Hybrid Routing
Server-based routing has stepped up and taken on a new role this past year. Again starting from the end of 2022, and coming into its own this year, we've seen people get used to this paradigm shift with things like React Server Components and Astro's View Transition API integration.
The premise is that server rendering after initial page load shouldn't prevent client navigation and client navigation shouldn't mean that we need to send all the JavaScript to render parts of the page that could be statically server-rendered.
It is important to note that not all solutions are equivalent and this is an area that is still very much under construction. We are moving into a new space that isn't quite a Single Page App and isn't quite a traditional multi-page site. There are new tradeoffs and new understandings to be had. And we are in no way done navigating the pitfalls.
Edge Networks: The Final Frontier
Edge functions seem like one of those obvious wins. Move your server closer to your end user and you drastically reduce latency. Use a lighter runtime and you drastically reduce cold start time. We finally can deliver the web experience we've always dreamed of. Dynamic at the speed of Static.
Well if anything 2023 was a year of growing pains with the edge. We started incredibly enthusiastic. After all, Cloudflare was releasing Edge Databases, all our favorite providers started offering Edge functions, and our favorite frameworks were adding out-of-the-box support. The providers had formed a committee WinterCG to talk about standardizing the platform. The future was here.
Where we ended up was the realization that certain Node APIs were essential even in these edge functions. You can thank or hate Next and Vercel for pushing AsyncLocalStorage into every runtime, but we needed it.
We also realized Edge Databases would never suffice for all applications. And even with streaming, Server Waterfalls are real and impactful. Yes, even with React Server Components.
But this did forward the goal I put forward last year, of monolithic authoring with distributed deploys. We saw Server Functions(server$, use server) and even variations like Worker Functions show up early in the year to show that we could distribute how we deploy our APIs, adopted by Solid, Qwik, and Next.
By the end of the year Next 14 released the new experimental Partial Pre-rendering which allowed a single request to serve static content from the edge while proxying through to Server-less Functions closer to the database all being streamed to offer an Edge-like experience without deploying your whole app there. It is awesome to see some ingenuity offer a best-of-both-worlds solution.
Forward to 2024
The Year of Signals
I know I've talked about Signals enough for one article already, but the real payoff hasn't happened yet. We've had fine-grained Signal-like primitives in JavaScript for 15 years, so why now?
It isn't about just having them, it's about what you do with them. Vue has had these primitives under the hood for years, as has React with MobX but that barely touches on where things are heading. And that thing is fine-grained rendering. What was popularized by SolidJS, now is finding its way into Vue in the form of Vue Vapor, and Svelte in Svelte 5. And these are just the ones that have been announced.
I expect the others that have adopted Signals to work them more natively into the framework to better benefit from them.
There is so much excitement in this area on the potential, the group working on the TC-39 proposal for bringing Signals into the browser includes representatives from every major JavaScript framework, a group not always associated with working closely with standards.
Infrastructure-Led Development
Now that Server side rendering frameworks have gotten a shot in the arm the next logical place to go is to continue to look at maximizing what this new capability gives us. Standards are slow and WinterCG will take some time, but that will not stop the flow here.
To differentiate I expect pressure for frameworks and infrastructure providers alike to offer unique features that may only work on specific platforms. While 2023 saw a push for equalization across providers to offer similar features beyond their base static and function hosting--things like Key Value Storage Blobs--I only see the competition here to provide unique value heating up.
Frameworks' role in this is to keep a consistent authoring experience and mental model while finding ways to leverage the new abilities presented to us. It isn't unlike browser wars of the late 2000s and there is still a lot to come.
AI
Last year was too early to talk about AI from a framework standpoint. And next year might be too. But it is on the horizon. Code migration and generation tools are all great ideas but they suffer the same issue we've had for years with visual No or Low Code editors. Human interface points are still essential. After all, code is a living thing. It grows and is maintained over time.
Talking with other framework authors the past year we've seen it catch the fascination of those around us, but hadn't gotten to a point where it was clear our role in this. But that is changing.
Yes, that AI is answering the eternal question of why your application is slow.
The impact on developer tooling is one thing. But we are also seeing increased potential of real-time being built into our frameworks. I don't just mean Websockets for persistent backends either. APIs in meta-frameworks have evolved beyond simple JSON to fully streaming cross-network JavaScript execution with "Server Functions" in SolidStart, Qwik, and Next. It isn't hard to picture generative technologies creating your UI in real time.
Conclusion
2024 is likely to continue on the maturing trend we've seen in the last couple of years. From 2020-22 we saw a lot of new JavaScript(and WASM) frameworks (Qwik, Million.js, Astro, Next 13, Remix, Hydrogen, SvelteKit, SolidStart, Leptos, Dioxus, HTMX), but that hasn't been the case the last year. We've found the approaches and now we need to take them to their full potential.
I'm not sure we've succeeded at wrangling the complexity yet, which gives big nods to solutions that simplify like Astro or HTMX. But I'm still hopeful.
It may be too much to expect everyone to agree on what exactly a "Single Page App" is or when they should be using the various options laid in front of us, but every day these solutions are getting more capable of delivering on what they set out to do.
It is no longer a question of whether web development as we know it is going to change. Even if the direction isn't completely clear, the revolution is already here. Look forward to seeing you there.
Top comments (36)
Just drop React, it's just bad as a framework. Messy coding
First of all its not a framework. Secondly, sure.
first of all what is the definition of framework. secondly even if they proclaim themselves as library, the way we using react is like framework (and really opinionated one). we put our code on top of react and their non-sense rule, not the other way around
This stands the same for literally all the libraries out there. Wanna use ffmpeg? Oh opinionated. Wanna use sharp? Oh still opinionated.
React is a library and we have been using it as library. Even if you say we put code in react renderer in a specific way and it "renders". Because that's all it does. It doesn't handle server side rendering for you, if you want to do that you gotta build it. Need internal navigation? Too bad. Build it. Wanna use image optimization? Do it manually, yourself.
OR
Pick a framework that does all those things for you under the hood. Like an abstraction. That glues a lot of libraries and abstracts that away from you. Maybe alongside provide a nodejs runtime too so you can access fs for sharp image optimizations and all the runtime specific globals.
Think about your argument again. You are trying to change the definition of a library by the argument that disproves the very existence of said entity.
Please dont do that. Let the bigshots in science department do the defining.
Over and out.
I can't imagine you're making the comparison between React and ffmpeg. I'd say your take on whether it's a framework isn't taking the subject seriously.
ffmpeg has rules around inputs, and doesn't affect how you use other libraries that might handle its output. You can't say the same for React.
You have to jump through hoops to get React to play nice with non-react libraries that have to deal with its output.
I mean... Thats what i said. You stuck to the ffmpeg's part like a bible?
No that's not what you said. And why include ffmpeg if it had no value to the point you were making.
Alright forget about ffmpeg for a sec. Do you agree to the rest?
If you knew the author, You may wrote some better comment... Ofc he know react is not a fully framework...
First of all, it's not a framework. Secondly, no.
Some people like to suffer I guess
Some as in the majority of web developers? Also, what makes React messy but not other frameworks/libs like Svelte or Solid?
React doesn't guarrantee messy code. Lousy dev does. Just ignore them, they don't understand what they are talking about.
Anyway, check out my good work with ReactJS, open with desktop
quanla.github.io/macos-demo
Agreed, but hooks are part of the problem. Svelte and plain JS at least free you of the necessity of having to deal with the one way data flow. It just works. Hooks and the render cycle exacerbate the problem of lousy devs not organizing code.
Hooks is a clumsy patch, no elegance at all
Framework, library, tomato, tomaato… bad is bad. React has served, deserves a thank you. Time to say bye.
React is a decade framework just drop it. Why developers don't drop it because there is easier solutions out there which means less billable hours or putting longer hours in time-sheets
That's ridiculous. Managers would want to hire people that are productive, not just messing around with React flaws. People don't have their priorities straight
Interesting comment. What framework would you point out its the best out there if its not React? ( Honest question dont take it offensive )
I love the nods and acknowledgements of the other frameworks any pointing out how they are good in their own ways. I started dabbling with Solid, and I do like it a lot, I have been dabbling with Qwik and really really love it, thought being new lacks a lot of the libraries that things like react and stuff have because they have been around for years and years. I still generally work in and grab NextJS as my default, but I really hope that changes soon. Their docs IMO have gotten significantly worse, the DX IMO is also a lot more cumbersome with needing to seperate out client/server components, so hopefully soon, I can just say, hey lets build this new project in Qwik/Solid and just be done with it
Astro + HTMX + Alpine / Qwik (Svelte in Astro Island if one day I need to use Island) I liked Qwik very much and I believe that when Alpine feel the weight, probably Qwik will hold. It would be Qwik or Svelte in Astro Island, with a right configuration I believe that even using Svelte, version 5 now with a new toys Runes (very interesting toy) with Astro still can ve better than go with full (Sveltekit), but I have more tests to do, with Qwik instead Alpine, and Svelte 5 in Astro Islands. I want to test AstroDB too, because Astro is awesome and I want to try its limits, HTMX + .NET 8 has a easy integration too for enterprise projects, and I have to be a middle term to middlewares and other thins that I think would be Golang ;) and I want to get start with Rust to be a better prgrammer and understand things better, Rust and F# a different world for me :)
I encourage everyone to give Nuxt a try.
Great post! 👏👏👏
I'm also doing my best to have some impact on better 2024y for developers by releasing state management library - Awai, where all the events are thennable. What are your thoughts about this approach?
I hope there were improvements in SPA as well.
REST API + SPA (SSG) is simple and intuitive, but it seems like the recent direction in web development is moving towards SSR.
Instead of executing fetch requests for initial data through events like onMount when transitioning between pages, how about having a feature that sends these fetch requests in advance when downloading JavaScript for page transitions?
hey , also check out this new amazing CSS framework (created by me* )
NextGenCSS ( github.com/rudransh61/NextGenCSS- )
Pls tell your feedbacks
Thank you for using it for a day (or an hour)
Docs and guide : nextgencss.gitbook.io/
Thanks to all contributors and stars
Nice article!
Do you have al link to "the TC-39 proposal for bringing Signals into the browser". I would be interested to have a look, but a Duckduck search didn't give me anything.
I just read about that yesterday, you can check it: github.com/webcomponents-cg/commun...
Hey, thanks for the link.
Off topic; I didn't realize the cover image was from Tomorrowland (2015) which also contained this speech from the antagonist:
For which type of project do you think its worth using Qwik for ?
Qwik is cool but the adoption rate is slow. Svelte is very easy to learn but I am not sure about version 5 its very different.
Yeah it looks like SolidJS. Which of course I'm not going to complain about.
In all seriousness it addresses a lot of the shortcomings Svelte had. While not everyone felt those I think this is a big step in it becoming a much more capable framework.
ecommerce for sure
Some comments may only be visible to logged-in visitors. Sign in to view all comments.