When I first stepped into the world of web development after university, I took one thing for granted: React together with Next.js would be my bread and butter. It seemed like the obvious choice, not just personally but also for the majority of our projects at work. Back then, I remember that I didn’t really question why — for me, it was just obvious to use it these days. What else was there to use, right? But Philipp, I hear you scream. What about Angular, Vue, Svelte… ? They are fantastic frameworks too, no doubt, but compared to the widespread adoption and large community of React, they always seemed like smaller fish in a big pond. But then, when talking about big fish, why don’t we use jQuery anymore? After all, even in 2024, it is still part of 77% of all websites out there [1].
This got me confused. Why are we “all” using React? What happened to jQuery and why was it never taught to us in university? Will we continue to use React forever, or is the next big thing already on the horizon?
In this article, I’ll give you a rough breakdown of modern frontend architectures, covering their beginnings, where we stand now, and what possibly lies ahead. I am not trying to explain everything in exhaustive detail nor to compare frameworks directly, but rather step out and give a general trajectory. You can see this article as a source of inspiration, a reminder, or a starting point — if you want to dig deeper, check out the links at the end.
Let’s start by looking back in time and see where it began.
Some shortcuts and implications taken: It all started with Multi-Page Applications (MPA), where basically everything lived on the server, and the UI feedback was handled by the client’s browser. Each user action (e.g., a click on a button) that requested a view change or a server update triggered a new page to be loaded from that very server.
This was also the time of PHP, which was the so to say first server-side rendering (SSR) tool that allowed content management systems (CMS) to be possible. JavaScript (JS) was also present (both first appeared in 1995) but played a rather supportive role by allowing some simple interactivity to the pages. The slow internet and low performance of end devices (browsers) at that time dealt solely with displaying the static pages received by the server.
Of course, this came with some problems: the frequent page reloads were expensive and caused bottlenecks, while developers were limited in UI feedback control.
At times, when consumer devices became more capable and JavaScript gained popularity, developers made use of “Progressive Enhancement”. This technique allowed developers to deliver essential core and content functionality to all users. More advanced features were only provided to users with modern browsers that were able to handle the code.
This marks the era of the infamous MooTools (2006) and jQuery (2006), which became a default for websites at the time. jQuery addressed the challenges of cross-browser compatibility while offering a concise and intuitive syntax for DOM manipulation, event handling, AJAX, and much more.
Developers were now able to handle UI feedback by themselves (and not the browser) and presented a better user experience. However, this came at a cost: there was a lot more code to manage, and it resulted in a lot of duplicated code with regards to rendering logic because both the backend and frontend had to deliver the same UI. This duplication occurred as code on the client’s side needed to ensure that the UI updates just like the backend code would after a change. With different languages in place, this was an exhaustive task, which was error-prone and non-trivial.
With browsers getting better and better, more of the logic that used to run on the server was moved to the client side and fully interactive pages based on JavaScript were becoming the standard. At that time, the release of HTML5 (2014) and ES6 (2015), and the end of Internet Explorer 6 (2016), resulted in a shift from jQuery back to vanilla JS. AngularJS, Backbone.js, and Knockout (all released in 2010) supported the transition and popularised the Model-View-Controller (MVC) pattern that splits the domain models from the interface (view). Then, React (2013), Vue.js (2014) and Angular 2 (2016) emerged with the same goal of a singular app that would do it all: fetching data, rendering new sets of components, navigation, state management, and so on.
These SPAs led to the user experience we are used to today and are still — with all its variations — the most used strategy by the industry today. Their best part might be the great developer experience, which could have been the main reason why the whole transition happened so quickly.
However, while SPAs already sound promising, they come with some crucial downsides as well. One of their biggest is the large bundle size of the app since lots of JS needs to be loaded to the client. This not only results in longer loading times but also has adverse implications for search engine optimization (SEO), since search engines favour pages that load fast with respect to their Largest Contentful Paint (LCP). Furthermore, SPAs only include a minimal set of HTML since JS is on the client and responsible for fetching and rendering their content. The crawler (responsible for creating the search index) might not be able or does not have enough time to run the whole application, resulting in incomplete indexing due to missing content. Ultimately, this results in a bad rank of the website on search engines.
Code Splitting and Lazy Loading are two common techniques to help with minimising the initial bundle size, which improves the user experience and minimises the initial server load.
Another drawback of SPAs are their issues related to state management. The architecture’s reliance on rendering on the client side might lead to difficulties in maintaining and synchronising application states with the backend, potentially causing inconsistencies and errors in user interactions.
To address these challenges, special libraries or frameworks such as Redux, MobX, or Vuex can help to manage the application state more effectively.
Additionally, when taking a step back, it’s somewhat questionable trying to solve everything with JavaScript. The traditional web architecture had a clear separation between the declarative website structure and content (HTML), declarative styling (CSS), and functions (JS). The web was designed to load pages and submit forms, but now this model is being overruled. SPAs bypass browser functionalities and rely on JavaScript with a virtual DOM and CSS-in-JS. This shift led to overcomplicated solutions and a deviation from the original web design principles.
SPAs might be a good solution for various websites, e.g. for back-office applications where SEO is not a matter of concern. However, the drawbacks often seem to outweigh the benefits for most use cases. Rather than addressing the fundamental issues, the proposed solutions often feel like band-aids, struggling to tackle the real root causes effectively and the attempt to solve everything with JS might have been a misguided approach. This ultimately resulted in yet another transformation.
Besides the popularity and presence of SPAs, a new trend has arisen: the return of (pre-)rendering content on the server with server-side rendering. Angular Universal, Next.js, and Nuxt.js were all released in the same year (2016) and have had one common goal ever since: to address the issues of SPAs. Their architecture style quickly gained popularity and success by delivering pre-rendered pages from the server to the client instead of running code exclusively on the client. This immediately decreased the bundle size and improved SEO performance.
Some call this type of application PESPA, which stands for Progressively Enhanced SPA — with progressive enhancement having a different meaning than in earlier years [2]. There exists a wide variety of frameworks and variations of PESPAs, like Static Site Generation (SSG) or Hybrid Rendering that follow the same architecture style, all of which have their unique benefits and downsides.
This was also the time when I entered the world of web development — around 2018. For me, it was obvious to care for SEO when building modern customer-facing web applications. And since everyone was using (and teaching) PESPAs, I quickly got used to their architectural style and benefits. There was no more practical reason to use libraries like jQuery or to learn classical SPAs unless we had to deal with legacy code.
But soon after, I witnessed an ongoing progression beyond PESPAs and even some further drawbacks and criticism on some of the most popular frameworks — take Kent C. Dodd’s article for example on why he won’t use Next.js anymore [3], or why Thoughtworks cautions against the use of web components [4].
So… what’s the next evolution? Will it redefine the web development game again? Or perhaps, be the ultimate solution for every scenario?
We are way past the point where JS and full-blown client-side applications had their peak, going back to less complicated and easier models that focus on speed. It is almost like we’re doing a circle back to websites where JS is playing a less relevant but rather supportive role. And while PESPA approaches and architectures already deliver sufficient performance, the SEO race continues. One can observe a clear trend towards further minimising JS as much as possible to improve its ranking against the competition.
Astro [5] and Qwik [6] are two modern examples of pioneers who aim to further minimise JS. Both frameworks were released in 2022 and quickly gained popularity by introducing new concepts called “Partial Hydration” and “Resumability,” respectively.
Qwik
Most modern PESPA front-end frameworks make use of hydration to make their page interactive by recovering their application state, event handlers, and component hierarchy.
Each hydration step requires downloading and executing more JS code. When using hydration, the code execution time will become proportional to your page’s complexity, resulting in longer loading times.
Qwik apps skip hydration altogether and tackle their problems by starting on the server, serialising their states into pure HTML, and resuming execution in the browser where the data is already present. JS is only downloaded and executed on the client when needed for rendering or user interaction.
Astro
Astro’s approach to using partial hydration is to render everything on the server and to deliver plain HTML when possible — so even routing is happening on the server. Only component islands — as they’re called in Astro — that require interaction are receiving JS when needed.
Summary
Both frameworks are doing a great job of feeling like a SPA while minimising their bundle size and reaching incredible performance. Check out this demo of Astro’s animated view transitions and how seamless its navigation looks and feels: https://live-transitions.pages.dev
But if you happen to click on the link using a browser other than Chrome, you’ve immediately observed one of its downsides, which is that most browsers are not quite there (or supportive) yet to ensure the SPA-like feeling. This highlights the ongoing transition we’re in right now, and might be a reason why such next-generation frameworks might not be a suitable option for some larger-scale enterprise websites just yet.
However, Astro and Qwik are still able to serve full pages, ready to be interacted with in minimal time. Therefore, it’s no surprise that their SEO scores are nearly perfect and a great choice for smaller commercial or editorial sites that have only a few components requiring user interaction.
Nevertheless, they’re explicitly aiming for larger enterprise applications as well, which would ultimately gain a performance boost. This is argued because their bundle size does not increase proportionally to the app size, which would eventually slow down the application.
Probably the most extreme example is HTMX [7]. It tries to omit JS altogether by extending HTML elements with additional attributes and utilising the browser’s functionalities — here, it really feels like we’re going full circle back to the old days of the web.
With HTMX you’re able to perform requests from every element or broaden your event capabilities beyond submit and click. It even allows WebSockets or AJAX through extensions. However, most importantly, it enables you to manipulate the current document by replacing, adding, or deleting certain elements rather than fetching an entirely new one. Together with CSS transitions, HTMX allows you to achieve a SPA-like user experience with optimal performance and minimal bundle size.
What’s beautiful about HTMX is that it reopens a door that was kind of closed for years: Since you’re just sending plain HTML syntax back and forth, you can use any language together with HTML. This independence of JS is actually one of the fundamentals of HTMX and is called HOWL: “Hypertext On Whatever you’d Like”.
While HTMX might not be suitable for high-end enterprise applications (and doesn’t aim to be), it’s slowly becoming a serious alternative for smaller websites or back-office applications, since it’s extremely lightweight and is able to achieve nearly perfect SEO performance scores. However, it requires some getting used to when coming from other modern frameworks.
React has undergone a transformative journey, evolving significantly from its original form to adapt to the rapid trends of web development. React counts as one of the founders of SPAs by introducing its component-based architecture. Over the past 10+ years, it has continued to adapt, set, or popularise new trends, which is the reason it is still so popular today. After the shift from SPAs, the evolution of React together with Next.js built on top of it has been marked by the importance of SSR in today’s web ecosystem. And following other frameworks and the current trend to minimise JS, they’ve also acknowledged that for components that do not require client-side interactivity, there’s no need to load additional JS for hydration to the client. This led to the introduction of React Server Components, enabling the rendering of parts of an application on the server without sending extra JS to the clients.
But even though current Next.js follows a similar strategy to Astro or Qwik, it still can’t reach their level of minimal JS bundle size because it still acts as an SPA once the page is loaded. This might be a good example of Next’s fast evolution, which becomes more and more complex and delivers so quickly, that it even took experimental features from React and shipped them as production-ready, just to beat the competition [3]. This — among other factors — results in some developers turning their back on Next.js and searching for alternatives.
Nevertheless, React together with Next.js are on the frontier of today’s web development and will possibly continue to be so to avoid being replaced by the “next big thing”.
Trying to look ahead into the future of React, it seems to be turning towards a more minimal and flexible core or even a standard, around which we can build and select our toolkits, depending on our project requirements. A so-to-say one-in-all solution that could do it all. Such a direction would not only reinforce React’s position as a leader in the web development race but also ensure its adaptability and relevance in a future where the needs and expectations of web applications continue to grow more sophisticated.
We’ve definitely come a long way and gathered ups and downsides from every step of the road. I recently stumbled upon a comment that sums up the whole evolution of web development pretty nicely:
And while I hope that we won’t have to live through this journey again with WebAssembly, I think that the number of frameworks and solutions will continue to grow depending on our adopting requirements and learnings and that it’s unlikely that there’ll ever be one ultimate framework which could do it all. But that’s the exact beauty of it: a large variety of frameworks to choose from — depending on the application and developers’ preferences. Not every website needs SEO, and not every website needs to be an app. Backend devs should not depend on JavaScript. The world of web development should not solely contain React and Next.js. Browsers need to evolve to the next generation and allow more support for JS-less applications.
And finally, some frameworks like jQuery are likely to persist indefinitely. By the time of writing this article, jQuery had released its first Beta for its fourth version eight years after releasing jQuery 3. This underscores its ongoing relevance on the web and its commitment to staying current with modern development practices and standards.
Unfortunately, the answer remains as elusive as ever: It depends! 🙄
I know that this might be an unsatisfying conclusion to this article, but there simply is no one-size-fits-all solution, which is why it needs us developers to carefully think through a project’s needs and select the best tools available. Here are some questions that I often use before starting a new web project:
Thanks for joining me on my journey through the history and future of web development. If you have some questions, or input, or want to discuss this topic further, feel free to reach out to me via philipp.stoeger@andamp.io.
We at & are building all kinds of applications — from classic SPAs to next-gen PESPAs. We understand that projects have different requirements and preferences. We find strengths and capabilities in every framework and choose the ones that fit best to you, the project, and the team. If you want to work with us, get in touch!
[1] https://w3techs.com/technologies/overview/javascript_library
[2] https://www.epicweb.dev/the-webs-next-transition
[3] https://www.epicweb.dev/why-i-wont-use-nextjs
[4] https://www.thoughtworks.com/radar/techniques/summary/web-components-for-ssr-web-apps
[6] https://qwik.dev
[7] https://htmx.org
[8] https://totheroot.io/article/the-history-of-modern-web-development