Engineering
The Frontend Is Calm Now. Ship Like It.
Something happened to frontend development while everyone was watching the AI discourse: it got calm. The churn that defined the field for a decade has slowed to a stroll, the browsers ship remarkable things on a steady cadence, and half the libraries we reached for in 2022 now have a native equivalent that is faster, smaller, and maintained by the platform itself.
We just wrapped a site rebuild for Møller, the home goods brand, and the dependency diff against their previous build tells the story: the old site shipped 41 production dependencies. The new one ships 9. Nothing was lost. Here is where the weight went.
The platform ate the utility layer
A partial list of things we used to install and now just use.
- Page transitions: the View Transitions API handles cross-document animation that used to require a client router and a small religion. Møller's catalog now has the smooth product-to-detail morph everyone wants, in about thirty lines.
- Scroll-driven animation: CSS scroll timelines replaced an entire category of JavaScript observers. The parallax and reveal work on the new site runs off the main thread entirely.
- Popovers, dialogs, anchored tooltips: native popover and anchor positioning killed our floating-UI dependency.
- Container queries and :has() ended the era of resize listeners masquerading as responsive design.
- Typed, cached, streamed data fetching: fetch plus platform caching semantics, doing what a client cache library used to.
The pattern: complexity did not disappear, it moved into the platform where someone else maintains it. Our job shifted from assembling machinery to knowing the platform deeply, which is a better use of senior attention anyway.
Less JavaScript is a brand decision
The argument for the light build is usually framed as engineering hygiene. On a brand site it is more than that. Performance is perceived craftsmanship. A luxury home goods brand whose product pages stutter on a mid-range phone is contradicting itself in the first two seconds, and no amount of art direction recovers it.
The new Møller build ships under 60 KB of JavaScript on the critical path. Largest Contentful Paint sits around 1.2 seconds on a throttled mid-range device. The design team's response to feeling the site for the first time was the correct one: this is what expensive feels like.
There is also the second audience to consider. Server-rendered HTML with real semantics is what agents and answer engines parse most reliably. The same discipline that makes the site fast for humans makes it legible to machines. One decision, two payoffs.
Where we still spend complexity
Calm does not mean austere. We spend our complexity budget deliberately, in the places where the brand actually lives.
@view-transition { navigation: auto; }
::view-transition-old(product-hero) {
animation: 320ms var(--ease-settle) both fade-scale-out;
}
The motion language, the typography loading strategy, the image pipeline: these get real engineering attention because they carry the brand. A configurator gets an island of interactivity with a real framework, hydrated only where it stands. The point was never zero JavaScript. The point is that every kilobyte should be doing brand work or product work, and almost none of the old 41 dependencies were.
The uncomfortable question for teams
If your stack still assumes 2021, the question worth asking is not "should we migrate frameworks?" It is "which of our dependencies is the platform already better at?" Run that audit honestly and the roadmap writes itself. The frontend got calm. Teams that notice get to spend the reclaimed attention on the parts users can feel. Teams that do not will keep paying maintenance tax on machinery the browser made obsolete.
Building something this could apply to?
We take on a small number of flagship projects each quarter.
Start a project