Every few years the web decides it has been doing things wrong. The last correction pushed almost everything into the browser — routing, state, data fetching, rendering — and called the result an application. The correction now underway is quieter, and it is mostly about taking that work back off the user's device.
The clearest sign of where things have landed is what teams have stopped arguing about. Server-first rendering is no longer a position to defend; it is the default in every major framework, and the interesting question has moved on to how much of a page needs to be interactive at all. Most of a marketing site, a documentation page or a product listing does not — and the frameworks now make it possible to say so, sending markup for the static parts and script only for the parts that genuinely respond.
That reframes how a page's cost is measured. Not in requests, which have been cheap for years, but in JavaScript the browser has to download, parse and execute before anything on screen will answer a tap. It is the metric that most closely tracks how a site actually feels on a mid-range phone on a bad connection, which is the device most of your users are holding.
Edge delivery, minus the hype
Edge computing spent a couple of years being proposed as the answer to everything, and is now settling into being the answer to some things. The correction was arithmetic: running your code in three hundred locations does not help if it has to wait on a database in one of them. Teams that moved everything to the edge found they had traded a short trip to the server for a long trip to the data, and moved much of it back.
What survived the correction is the work that genuinely belongs close to the user and carries no state — redirects, authentication checks, feature flags, geo-aware routing, caching decisions. Used for that, the edge is unambiguously good. Used as a default execution target, it mostly relocates latency rather than removing it.
The platform absorbed the tooling
The least discussed trend is also the most useful: a large amount of what used to require a dependency now ships in the browser. Container queries let a component respond to the space it occupies rather than the size of the window. Modern CSS selectors express state that previously needed a class toggled by script. View transitions animate between states without a library. Dialogs and popovers are native elements with focus handling and accessibility built in, rather than something each team reimplements slightly wrong.
The same consolidation happened underneath, where build tooling has been rewritten in compiled languages and does in seconds what used to take minutes. Both shifts point the same way — the dependency you do not add is the one that never breaks, never needs a security patch, and never has to be removed by whoever inherits the project.
The through-line across all of this is not a technology, and that is what makes it easy to miss. It is a narrowing of what teams are willing to ship: less client-side JavaScript, fewer dependencies, less machinery between a request and a rendered page. The web spent a decade proving it could behave like a native application. The more valuable lesson of the last few years is how rarely it needs to. The most modern thing a team can do in 2026 is send less.