The Platform Is Absorbing What Frameworks Used to Do
A recurring pattern in web platform evolution: capabilities that once required a JavaScript framework and a lot of glue code eventually get standardized into the browser itself, cheaper and more reliable than the userland version. Three areas where that's playing out now are page transition animation, compiled languages targeting the browser with real garbage collection, and compute that runs at the network edge rather than in a single origin data center. None of these are speculative — they're shipped, standards-track, and worth understanding even if you're not adopting them this quarter.
View Transitions: Native Animation Between States
Single-page apps have used animation libraries to fake smooth transitions between views for years. The View Transitions API does this natively, and it now works two ways: same-document transitions (within an SPA) and cross-document transitions (a full navigation between two separate pages, MPA-style), which is the more significant addition — it means you can get app-like transition animation without giving up multi-page architecture and its SEO/caching/simplicity benefits.
For a same-document transition, wrap your DOM update in startViewTransition:
function navigate(newContent) {
if (!document.startViewTransition) {
renderContent(newContent);
return;
}
document.startViewTransition(() => {
renderContent(newContent);
});
}The browser automatically captures a screenshot of the old and new states and cross-fades between them by default. To customize the animation — a slide instead of a cross-fade, for example — give the elements you want to animate a stable view-transition-name and target the browser-generated pseudo-elements in CSS:
.hero-image {
view-transition-name: hero;
}
::view-transition-old(hero),
::view-transition-new(hero) {
animation-duration: 0.4s;
}Cross-document transitions work the same way but require opting in on both pages with a single CSS rule:
@view-transition {
navigation: auto;
}WebAssembly GC: Compiled Languages Without Shipping a Runtime
Wasm's original memory model was linear and manually managed — great for Rust and C++, painful for languages like Java, Kotlin, Dart, or OCaml that expect a garbage collector, because those toolchains had to compile an entire GC implementation into the Wasm binary itself, bloating output size and duplicating work the host JS engine already does internally.
The WasmGC proposal fixes this by adding managed reference types and structured data (structs and arrays with garbage-collected lifetimes) directly to the Wasm type system, so the host runtime's existing garbage collector — the same one already managing JS objects — can manage Wasm objects too. The practical effect: a Kotlin/Wasm or Dart-compiled binary no longer needs to ship its own GC, shrinking output and improving startup time significantly compared to the pre-WasmGC approach.
You don't write WasmGC by hand in practice — you target it through a toolchain. Kotlin/Wasm, the Dart-to-Wasm compiler, and Java-via-TeaVM/CheerpJ-style toolchains all emit WasmGC modules when targeting modern browsers. From the JS host side, calling into a WasmGC module still goes through the standard API:
const { instance } = await WebAssembly.instantiateStreaming(
fetch('module.wasm'),
importObject
);
instance.exports.someExportedFunction();The interesting shift isn't the API surface, which is unchanged — it's that a much wider set of languages can now compile to Wasm and produce output competitive in size and startup latency with hand-tuned Rust/C++ Wasm, because they're no longer paying the tax of shipping a redundant GC.
Stateful Edge Compute
Edge functions started as a stateless idea — run a small piece of request-routing or transformation logic geographically close to the user, with no persistent state, because state meant a round trip back to a centralized database anyway. That constraint is going away. Platforms now offer strongly consistent, geographically distributed primitives that live at the edge alongside the compute:
- Durable, single-instance objects that pin a piece of state (and the logic that mutates it) to a specific location, useful for things like a WebSocket coordination point, a rate limiter, or a per-user session that needs strict ordering.
- Edge-native key-value and SQL stores that replicate globally with read-your-writes consistency near the point of access, rather than requiring every edge function invocation to hit a single regional database.
A minimal example of an edge function handling a request with a co-located key-value store looks like this (platform-agnostic pseudocode reflecting the common shape across Cloudflare Workers, Deno Deploy, and similar runtimes):
export default {
async fetch(request, env) {
const url = new URL(request.url);
const cacheKey = url.pathname;
let value = await env.EDGE_KV.get(cacheKey);
if (!value) {
value = await computeExpensiveResult(url);
await env.EDGE_KV.put(cacheKey, value, { expirationTtl: 3600 });
}
return new Response(value, {
headers: { 'content-type': 'application/json' },
});
},
};The architectural consequence is that "edge compute" is no longer just a CDN with a scripting hook — it's a legitimate place to run application logic with real state, which changes where you draw the line between "runs in a data center" and "runs at the edge" for a growing set of workloads: authentication checks, feature flag evaluation, A/B routing, and even simple CRUD APIs for latency-sensitive reads.
What This Means for How You Build
None of these three features require a rewrite to benefit from. View Transitions layers onto an existing site with a few lines of CSS and JS. WasmGC is a toolchain concern if you're already compiling a managed language to Wasm — you get the benefit by upgrading, not rearchitecting. Edge compute with real state is the one with actual design implications, since it changes where consistency guarantees live in your system — but even there, it's additive: you can move specific latency-sensitive paths to the edge without abandoning your existing origin architecture for everything else.
Discussion & Insights