The web platform, 2020 to 2026: what we adopt, trial and skip

Between 2020 and 2026 the web platform quietly rebuilt itself. Rendering moved back toward the server, build tools became fast enough to disappear from your attention, and the browser absorbed jobs that once needed heavy libraries, from sign-in to transport to graphics. This is our working review of those six years: what we now adopt by default at OlDevs, what we trial on real projects, and what we skip without regret.

What actually changed between 2020 and 2026?

In 2020, the default new project was a single-page application: a large JavaScript bundle, client-side routing, and a server whose main job was to hand over an empty div. It worked, but the costs kept compounding: slow first loads, fragile hydration, and a webpack configuration nobody on the team wanted to touch. The years since have been one long correction. Frameworks moved rendering back to the server and started treating client-side JavaScript as a budget to spend rather than a default to assume. The most-used tools were rewritten in faster languages. And the platform itself, from the browser to the protocol layer to the credential system, took on work that used to belong to application code.

None of this arrived as a single revolution. It arrived as a hundred sensible decisions made by different teams pointing the same direction, which is exactly how the web tends to improve.

Did the frameworks converge on the server?

Largely, yes. React Server Components went from a research demo to the backbone of Next.js's App Router, and after a genuinely rocky adjustment period the model has matured: components that never ship to the client, data fetching that lives beside the data, and interactivity added deliberately rather than everywhere by default. Caching semantics were the sore point for years; recent releases have made them explicit and much easier to reason about, and the framework, current at the time of writing, is in a far calmer place than it was in 2023.

Svelte answered differently. Svelte 5's runes replaced compile-time magic with explicit, fine-grained reactivity: signals you can see and reason about. The result feels simpler and more predictable as an application grows. For content-heavy sites, Astro made the strongest argument of all: render everything to HTML, hydrate only the islands that need interactivity, and treat zero client JavaScript as the starting position. For marketing sites and documentation we now reach for Astro first; for product interfaces we weigh Next.js and SvelteKit against the team that will maintain them. That decision sits at the centre of our web app development practice, because the framework a client inherits matters longer than the framework a developer enjoys.

Why does the toolchain finally feel fast?

Vite is the quiet winner of the decade so far. It began as a Vue-adjacent dev server and became the default build tool for almost everything, powering SvelteKit, Astro and a growing share of React projects. The bet on native ES modules in development and esbuild-speed transforms paid off so thoroughly that the argument is over. Nobody starts a webpack configuration from scratch in 2026 by choice.

Tailwind CSS v4 rebuilt the framework on modern CSS: configuration moved into the stylesheet itself, the engine became dramatically quicker, and features like container queries and wide-gamut colour that once needed plugins are simply present. TypeScript, meanwhile, is midway through its own rewrite: the team is porting the compiler from TypeScript to Go, with much faster type-checking of large codebases as the goal. The port is still rolling out across editors and CI, with version numbering current at the time of writing, but the direction is unmistakable. The tax on large TypeScript projects is being repealed.

Fast tooling is not a luxury. It is the difference between a team that experiments and a team that hesitates.

What does the browser now do for free?

Passkeys are the clearest win of the period. Supported across the major operating systems and browsers, they replace passwords with device-bound cryptographic credentials: phishing-resistant by design and genuinely easier for users than the thing they replace. We now raise passkeys in every project that has a login, alongside the rest of our security and compliance checklist.

Performance measurement grew up too. In 2024 Google replaced First Input Delay with Interaction to Next Paint as a Core Web Vital, and the change had teeth: INP measures the responsiveness of every interaction, not just the first, so the long tasks and heavy hydration that FID forgave now show up plainly. It rewards exactly the server-first architecture the frameworks converged on, which is not a coincidence: the metric and the architecture describe the same user.

Underneath it all, HTTP/3 and QUIC quietly became normal: better behaviour on lossy mobile networks with no application changes required, just a CDN or server that supports it. WebGPU is the more specialised story. It gives the browser modern GPU access for 3D scenes, data visualisation and on-device machine learning, and where it matters it matters enormously. For a typical business site it does not, and pretending otherwise is how projects acquire dependencies they never needed.

Did AI assistants change how we build?

Yes, though not in the way the louder predictions suggested. AI coding assistants are now part of the daily texture of the work: drafting boilerplate, writing the first pass of tests, migrating code between APIs, explaining an unfamiliar codebase in minutes instead of days. What they have not done is remove the need for judgement. Assistants sound confident whether or not they are correct, so review, architecture and taste matter more than they did, not less. Our experience is that they compress the boring middle of a task and widen the gap between teams that verify and teams that merely trust. We treat them as power tools with the guards on: real code review, real tests, and a named human who owns the result. That stance also shapes the advice we give clients in our AI development work: automation earns its place by being checkable, and a helpful draft is not the same thing as a finished system.

What do we adopt, trial and skip in 2026?

Our default stack is boring on purpose. Boring means documented, hireable and still maintained in five years, which is what most clients are actually buying. Here is the current picture, in the same spirit as our technology radar:

Trial means a real project with an exit plan. Skip means we have looked and decided, not that we have not looked.

What happens next, and how OlDevs can help

Expect the convergence to continue: more of the framework layer absorbed into the platform itself, faster native tooling as the Go and Rust rewrites land, passkeys displacing passwords by default rather than by exception, and AI assistance shifting from writing code toward reviewing and maintaining it. The teams that do well will not be the ones chasing every release. They will be the ones with a clear default stack and the discipline to revisit it deliberately, on a schedule, with reasons written down.

That is how we work at OlDevs. Since 2014 we have built for the web from Vancouver with one accountable team and a working demo every week, and our clients own all of their code, designs, accounts and IP. Every build meets WCAG 2.2 AA accessibility, and we work in English and French. If your platform choices are overdue for an honest review, or you have a build in mind, request a quote. We reply to every enquiry within one business day.