The platform keeps absorbing the thing you built to work around it

Serguey Asael Shinder22 September 2026, 18:102 min read

Two unrelated announcements landed today with the same shape, and the shape is worth naming because it decides where engineering effort is wasted.

The first: out-of-order HTML streaming is moving into the browser. The pattern — show the page before it has finished loading, patch the holes as data arrives — has been the property of streaming SSR in the major JavaScript frameworks for years, each carrying its own client runtime to do it. The declarative proposal puts the mechanism in the HTML parser, driven by <template for="..."> and a pair of processing instructions. Chrome 150 ships it.

The second: Hugging Face added GGUF loading to transformers, and did it by reusing llama.cpp's own ggml kernels through the kernels library rather than writing new ones.

Different domains, same movement. A capability lives in a specialised tool because the general one cannot do it. The specialised tool proves the capability is wanted. The general one absorbs it — sometimes by standardising the mechanism, sometimes by simply linking the specialist's code.

The practical consequence is about where you spend effort, and it is not "stop using frameworks". It is narrower than that:

Code that exists to compensate for a platform gap has an expiry date you do not control. Not a bug — a correct, well-tested, load-bearing piece of work whose reason for existing can be removed by someone else's release. Streaming-SSR runtimes were right when written. They are about to become a compatibility shim.

The absorbing platform rarely absorbs the whole thing. The browser proposal covers the insertion mechanism; it does not cover deciding what to defer, error boundaries, or what a browser without it renders. The transformers work covers loading and kernels; it starts on Apple Silicon and one model architecture. In both cases the specialist keeps the long tail, which is where most of the real complexity was anyway.

So the durable asset is the decision layer, not the mechanism layer. Knowing which parts of a page are worth streaming survives the parser learning to stream. Knowing which quantisation holds up on your task survives any runtime learning to load the file.

The cheap test when adding a dependency: if the platform shipped this next year, how much of my code would be deleted, and how much would still be mine? If the honest answer is "most of it goes", you are writing a shim, and shims should be thin, isolated, and easy to remove. Write them that way on purpose.

There is a second-order effect worth watching. When a capability standardises, its worst version becomes free, and the floor rises for people who never thought about it. That is good for users and awkward for anyone whose product was the capability. It is also why signalled support is not shipped support: a feature with one engine behind it is still a bet, and the fallback path is the part to design first.