JavaScript Frameworks - Heading into 2023
Ryan Carniato

Ryan Carniato @ryansolid

About: Frontend performance enthusiast and Fine-Grained Reactivity super fan. Author of the SolidJS UI library and MarkoJS Core Team Member.

Location:
San Jose, California
Joined:
Jun 25, 2019

JavaScript Frameworks - Heading into 2023

Publish Date: Dec 29 '22
750 32

The wonderful thing about glimpsing into the future is that the path is never completely clear. We can look at trends, and look at innovations and try to chart a course. Better still we can be part of those innovations to guide the direction. But nothing is certain.

2022 had a ton of big releases that push web development forward. We saw the 1.0 releases of both Astro and Sveltekit. SolidStart, and Qwik entered Beta. React 18 was released adding streaming support that found its way into Next and Remix, as well as powering React Server Components and the Next 13 app directory. And I'd be remiss to skip the impact TypeScript has had on how we design framework solutions. From tRPC and Tanstack Router to the opinionated Next.js meta-framework create-t3-app.


How We Got Here

Image description

"Focus on the Server", they said. "Solve the tradeoffs of Single Page Apps", they said. This isn't new, but what often isn't understood is how it isn't a panacea.

Server Side rendering allowed us to render pages sooner by fetching data sooner (and usually closer to our data source), but it wasn't without compromise. It slowed down our response times and didn't help with the ever-growing size of JavaScript bundle sizes. It often actually increased our bundle sizes as now we need the code not only to client render but to hydrate the page.

There are some partial solutions: We can cache more aggressively, stream our HTML responses, and we can invest in smaller/faster frameworks. There are some red herrings: We can think progressive enhancement is a substitute for hydration or that moving away from client-side caches meaningfully changes the math. Spoiler: It doesn't.

I'm not convinced everyone is on the same page yet, but many leading minds in the space actually agree on a particular thing. This is not something to take lightly.


Where We Are At

Image description

Single Page Apps aren't the most suitable architecture for everything.

I mean this shouldn't come as a surprise, but after the past decade, it takes some convincing. And perhaps I need to elaborate a bit on what I mean by Single Page App. I mean any of the typical JavaScript client routed and rendered architectures. Even the ones that boast server rendering. Everything from React, Next, and Remix to Vue and Nuxt, through Sveltekit, and SolidStart.

This is a natural evolution. Create a solution that pairs great UX with great DX and people want to take it with them everywhere. Even where it doesn't belong. Where is that? Well, any place that cares about page load performance to make its bottom line, any place that cares about low-end devices and networks, and arguably anywhere the complexity isn't justified.

If I could sum up the greatest alignment between framework thought leaders in 2022, it is that routing belongs on the server.

We're not suggesting we do away with client-side routing (although that is an option). Just that client-routed and rendered architectures are pressed again the limits of where they can be effectively used.

Whether you are looking at Marko, Astro, or Fresh and their Islands of interactivity, or Next and SolidStart's Server Components you see the server stepping up on routing duties. Rendering the next page in response to navigation after the initial load. Even Qwik, which could legitimately start as an optimized partially loaded application and scale up to full-blown SPA, prefers server routing(MPAs) in all their examples and demos.


Reflecting on 2022

Image description

Conquering Hydration

With server rendering being the focus, it is no surprise that hydration has been a topic of importance. This is a cost that we pay for every server-rendered application that is authored with a declarative JavaScript framework. Or so we thought.

Both Qwik and early Marko 6 resumable demos showed that hydration is something that one day soon may be something in the past.

Hybrid Nesting Routing

Before the end of 2022, we saw 2 experimental technologies that seem to offer the best of both worlds. We get client-side navigation paired with after-the-fact server rendering. Next 13 app directory saw Server Components paired with Nested Routing.

I wrote about Solid's approach which blew bundle size expectations out of the water.

While not everyone is sold on Server Components it's hard to argue with delivering significantly less JavaScript than even the smallest SPA frameworks are capable of while maintaining that SPA UX. It's a testament that another way drastically reduce Hydration is simply not to send the code.

Signals Everywhere

Fine-grained reactivity has made a comeback in 2022. The Vue community would (correctly) tell you that for them it never went out of style. But only in the past year have we seen it make its way in a much wider scope and under the new banner of Signal. From Solid's unique fine-grained renderer to Preact and Qwik using it to augment their Virtual DOM solutions. Marko 6's compiler shows how fine-grained reactivity can be compiled in a Svelte-esque way and even the Angular team is strongly looking into adding these primitives.

TypeScript Driven Development

2022 saw TypeScript go from being an option to the default to many meta-framework CLIs.

Having type-safe APIs across the client-server boundary isn't even a consideration anymore. tRPC was a game changer, but over the year we saw this being considered in JavaScript meta-frameworks. From SolidStart's compiled type-safe RPCs to improvements to Remix and Next's data loading mechanisms.

Tanstack Router showed us what type-safe routing looks like and now there is no turning back. We are still seeing these technologies propagate outwards but the gains are so significant people will not accept developing the way they did before when these technologies exist.


Forward to 2023

Wrangling in Complexity

Image description

This will continue to be a theme coming into the new year. You don't dump a bunch of innovation in a space in a short time and not expect something to give. Astro and Remix's return to "it is just PHP/Rails" for MPAs and SPAs, respectively, have been largely successful, even if they both lack important benefits of more sophisticated solutions.

Having spent a lot of time in Qwik and Marko for MPAs and React and Solid's flavor of Server Components for hybrid-routed solutions, there is something that still needs to be learned here. When a custom language server plugin is the only way to keep Server Components in check, or you need to be an expert on where serialization boundaries happen in your code, you need to start questioning things.

These technologies are the future. But we need to remember we aren't the first ones to try this. Backend technologies were tried in the mid 2000s, and instead, we largely moved to SPAs. We need to answer "What's different this time?"

And it might still come down to answering the question: Do we believe that what could be shipped to the browser, should be eventually, or is the server a place we should uniquely leverage? As the barrier between MPA and SPA melts away it's quite possible this division just takes a new form.

Edge: The Unexplored Frontier

Edge function support has rolled out to pretty much every meta-framework over the past 12 months. At this point, the vast majority of them can deploy to a variety of serverless and edge offerings. However, that hasn't changed how we develop.

We are quick to point out that data isn't on the edge. And we should assume that not all data will be on the edge even as solutions solve for it.

The edge needs to move beyond monolithic deployments. We need to figure out how to distribute compute to where it makes sense. I am not talking about micro-frontends or micro-services. But monolithic authoring with distributed deploys. I'm not sure what that looks like but I'm sure we will find out in the next 12 months.

Other Technologies

Will 2023 finally be the year of Web Components?

About as likely as it will be the year of the Linux desktop. Take that how you will.

Will 2023 be the year of WASM?

Probably not yet. But quietly WASM has been finding itself applicable in more spaces than ever. That includes DOM rendering. The overhead we thought we understood was not what we thought and the fastest WASM Rust libraries have closed the gap with JavaScript on client-side rendering.

Page load is still a prohibitive metric for many things, but you can still do progressive enhancement with WASM. So if it's good enough for Remix it might be good enough for you.

Will AI/No-Code take my job in 2023?

No. But it might help you migrate your code from one framework to another.


Conclusion

Image description

No one has a crystal ball but it doesn't take one to see we are at a time of change. New frameworks have been emerging in the last year or so after about 5 years of relative silence for good reason. It isn't that we stopped making them, but the time is right.

Even the big players are flirting with ecosystem resetting technologies like Server Components, new Virtual DOM-less compilers like Vue Vapor, and new change mechanisms like Signals.

But there is no clear direction yet. Existing approaches are at their limit. Radical new approaches are incomplete and pass complexity on to the developer in whatever form they take. Attempts to bury this in meta-frameworks have only been somewhat successful.

Developer experience expectations have never been so high while the demand on user experience isn't lessening. So whether you are waiting for the next revolution or living at the bleeding edge, buckle up because you are in for a ride whether you signed up or not.


Banner credits: ©️ Original concept artwork (https://www.artstation.com/artwork/nqrYo) by Alex Feliksovich based on Ghost in the Shell.


Appendix

If you are unclear on any of the terminology and technology I refer to in this article I recommend:

Comments 32 total

  • Alex Lohr
    Alex LohrDec 29, 2022

    Insightful as always, Ryan. I find it inspiring that we are using tried-and-tested patterns and put them inside a new abstraction that allows for isomorphic front-ends without making too many compromises in terms of bundle size and performance.

    I too think that we'll see a convergence of frameworks towards reactive signals. I also think that tools like Mitosis will help people to become more mobile between frameworks.

    Looking forward to 2023 and I'll see you on the other side of this year!

  • Nick Taylor
    Nick TaylorDec 29, 2022

    Great write up Ryan! Excited to see where 2023 takes us. 😎

  • Giorgio Boa
    Giorgio BoaDec 29, 2022

    This article is food for thought, thanks for sharing it Ryan!

  • Magne
    MagneDec 29, 2022

    Thought I’d also share my JS framework predictions for 2023:

    (growth in terms of npm downloads and github stars)

    1. React, React Native, SolidJS, Svelte, Vue, Astro and Qwik will all experience enormous growth during the year.

    2. Redwood and Remix will struggle to grow as much, but still grow some.

    3. Remix will grow more than Redwood. (Not a very spicy take, but still).

    4. React and Next.js will still dominate all competitors in absolute terms, and continue to grow,

    5. but React Native, Svelte and Qwik will grow much much more (percentage wise).

    6. «The year of React Native» on native/crossplatform, and

    7. «The year of Qwik» on web, certainly mind share wise, but also growth wise.

    Styling:

    1. Tamagui will be pretty hyped, mostly in React Native and mobile crossplatform circles, and grow greatly (more than 3x amount of npm downloads and github stars).

    2. But will be dwarfed by the meteoric rise of Nativewind. «The year of Nativewind» on native/crossplatform. Which will be fuelled by the fact that

    3. TailwindCSS is still dominating amongst modern web styling tools, and will >2x its amount of downloads, and grow around 18% in github stars by year end.

  • Jen Chan
    Jen ChanDec 30, 2022

    This article is where I'm getting my "how good is Rust" updates from LOL. Thank you.
    I appreciate the overview of trends and reasoning behind rise/falls.

  • Yoav Ganbar
    Yoav GanbarDec 30, 2022

    Loved this post @ryansolid !

    Well written and insightful as always.

  • Tyler Smith
    Tyler SmithDec 30, 2022

    Great post.

  • Dhruv Joshi
    Dhruv JoshiDec 30, 2022

    What do you think about AI and automated code generation? btw it was nice read.

  • ThemeSelection
    ThemeSelectionDec 30, 2022

    Informative...!!
    Good Job.

  • Arek Krysik
    Arek KrysikDec 30, 2022

    Great article! Curious about what 2023 is going to bring us!

  • cubiclesocial
    cubiclesocialDec 30, 2022

    I generally have always tried to build for the lowest common denominator. And that means people who have turned off Javascript in their web browser should not break the app. Some organizations disable Javascript for organizational security reasons (e.g. defense contractors working in Classified environments). Javascript is nice when it is enabled but I don't just assume it is. Server-side rendering has gotten a lot faster in the last two major PHP revisions (7.x and 8.x) due to major rewrites of fundamental data structures to take advantage of the design of hardware features (e.g. CPU pipelining).

    Yet, I think people should write code in whatever way works for them. Unless someone is actually a massive entity like Google or Facebook with 10,000+ servers across hundreds of data centers, rendering everything on a single server is fine for 99% of all websites. Server-side is also a lot easier to work with and correctly handles application security scenarios.

    Javascript frameworks are largely a hack until the browser vendors pick the best bits and integrate them into the mainline browser. jQuery had that effect (i.e. how native event handling was improved). Bootstrap had that effect too (i.e. how we got CSS Flexbox and Grid). So future predictions should probably be more along the lines of what is likely to make it into a future web browser release from existing frameworks. That's the sort of game-changing future that matters. Everything else is stuff that can change on a whim.

    • Karl Krasnowsky
      Karl KrasnowskyJan 1, 2023

      I used to feel as you, but given the nature of the industry, I've adjusted my attitude.
      I prefer to target the 80% in my application development and don't believe that necessarily includes the "lowest common denominator", (nope, I don't believe it's worth spending any time supporting diehard IE users either) nor do I find considering that audience particularly interesting, so I'll leave leave the coverage of those folks up to those who feel as you..

      • peerreynders
        peerreyndersJan 1, 2023

        given the nature of the industry … prefer to target the 80% … nor do I find considering that audience particularly interesting.

        From a business perspective any audience that can be cost effectively reached is interesting.

        So far "the industry's" preoccupation has been on developer convenience as it relates to time to market.

        Meta frameworks like Remix, SvelteKit and SolidStart aim to deliver developer convenience while also creating the opportunity to create solutions that reach the broadest possible audience over the web.


  • bherbruck
    bherbruckDec 30, 2022

    Great article! I'm loving solid-start!
    My DX wish is if createServerAction$ form.get() could be fully typed from a generic.

  • SG Digital
    SG DigitalDec 31, 2022

    Great insightful article. I always stick by 'its what you create not how you create it that counts' . Frameworks will come and go, but they all produce the same thing, html, CSS and Js. Frameworks should be used where appropriate and not always the defacto go to. Quite often, inexperienced Devs think they need to use one, even for the smallest amount of JS where the footprint (or point) of the framework does not fit. As Devs we have to be mindful that business often don't care about the latest framework, just productivity, hence the rise of low code platforms.

    That said it's nice that articles like this share latest thinking to allow people to make the decisions as to whether it's just more of the same (so stay as is) or it's a significant enough shift to take more notice of.

  • Rense Bakker
    Rense BakkerDec 31, 2022

    I just hope that 2023 will be the year when java and .net devs will finally stop looking down on javascript/typescript devs. I know its idle hope :P

  • ૮༼⚆︿⚆༽つ
    ૮༼⚆︿⚆༽つDec 31, 2022

    Htmx and AlpineJS made quite an impact on existing workflows. Language diversity will be a thing to get the job done in novel/groundbreaking works.

  • Aghiles Lounis
    Aghiles LounisJan 1, 2023

    What a great great article !

  • Mujan9856
    Mujan9856Jan 1, 2023

    i think so

  • Harlin Seritt
    Harlin SerittJan 1, 2023

    What does this mean? "now we need the code not only to client render but to hydrate the page." Perhaps, refreshing the state? Thanks, good read so far.

  • KC Development NSD
    KC Development NSDJan 3, 2023

    Oh why did I bother... lol Every year we change this. I'm always skeptical, then I come around mid-march, start to learn and believe in april/may, develop it into a new system or platform by July and compete it by November/Dec, or implement composed based development in some form or another which is good. Just modules and now going back to server side. I came from Serverside I should have stayed serverside. I'm grateful for learning all that i have though I've been raking it in with #Next #Nuxt and #Gatsbyjs fast optimization-based libraries and frameworks coupled with typed-script driven language libraries like react. Not regretting Gatsby or Next one bit.

  • Conor Gibson
    Conor GibsonJan 4, 2023

    Good thoughts, thanks for this article!

  • David Woodward
    David WoodwardJan 8, 2023

    What did you mean by “moving away from client-side caches [doesn’t] meaningfully changes the math”? I really have no idea…

    • Ryan Carniato
      Ryan CarniatoJan 9, 2023

      The micro-trend to refetch everything on any mutation or use browser in built cache. In contrast to JSON cache like you'd find in React Query, URQL, or Apollo.

      I realize these are both client side. But I meant cache in managed in JavaScript. This can reduce the size of data fetching libraries. But more commenting on the savings might be in the range of 5kb or something and doesn't really impact size much overall.

      • David Woodward
        David WoodwardJan 9, 2023

        Got it! So all you are saying is that moving from artifical JS caches to built in browser one's doesn't save much in terms of bundle size?

        • Ryan Carniato
          Ryan CarniatoJan 9, 2023

          Yeah, I mean the savings on library size is something. Apollo is 30kb, but URQL is 9kb, and SWR is 5kb I think and it isn't like the libraries using the browser cache aren't a few kb themselves.

          It's been suggested that this somehow saves more but that is the result of just moving more logic to a backend API, you could do that regardless of the mechanism. Like saving on using moment or something in the browser.

          So I think the win is that people are conscious enough to do better things but not so much that the technology itself changes very much in terms of bundle size. This portion of the win can be done at any step, but I suppose it gets more obvious.

          By default everything ends up in the client. These cacheless solutions suggest doing stuff on the server. Things like Partial Hydration end up dropping enough peripheral code that those things and more don't end up in the browser.

  • Beep LIN
    Beep LINMar 6, 2023

    Less js for client.
    More duty on server.
    Server sending html and fine-grained event handlers and incremental data to client.
    Sounds like all is going to qwik.
    ;))

    • Beep LIN
      Beep LINMar 6, 2023

      Or furlther, then no need to use nodejs
      on server side... Finally we will get a qwik written in go or rust. 😂😂😂

Add comment