Recently I was talking to my older son, who’s currently at university studying computer science, about the modern web stack. We were discussing how each layer of the stack adds different features and how the forward-thinking nature of the TCP/IP architecture is what allowed for the QUIC protocol to take over for TCP in HTTP/3.

This is no small thing - QUIC is a huge improvement over TCP for the needs of the modern web. It introduced a bunch of awesome improvements including multiple independent streams, built-in encryption, and user-space congestion control algorithms (something I played with way back in the 90’s!). These improvements though, like HTTP/2 before it, change best practices for the layers of the stack above it. And well, that’s a bit of a problem.

Today most new front-end web development uses build tools like Vite that have best practices baked into them. It’s fairly rare that web developers even think about how their files are served, let alone how they should adjust their toolchains to better fit the new best practices of lower layers.

A good example of this is the fact that front-end build tools have traditionally both minified text assets like CSS and Javascript, and concatentated all files for a site into a single file. This was because with HTTP/1.1 serving individual files was relatively expensive. Today though, even with just HTTP/2, serving many small files is actually the best practice.

So, while I think specialization when it comes to web development is a reasonable and natural thing, that doesn’t mean that web developers should stop caring at the line on the stack where HTML turns into HTTP. As each layer of the stack improves, those working above that layer would do well to understand how those changes affect their own best practices.