Written by Bryan Powell, a hybrid developer building a better web with Pakyow. Founded Metabahn. Follow me @bryanp or email me here. Subscribe to the feed for updates.

!Magic

Minified Assets and the Long Web

February 17, 2015

A couple weeks ago I was watching Jeremy Keith's talk on the long web. It got me thinking about a tangential topic that's been floating around in my head for a long time now. That is, minified assets seem to oppose the idea of the long web.

The long web is this idea that we should publish knowledge on the web in a completely open way. To quote Jeremy from his original blog post on this subject:

Think about the qualities that I've listed as being beneficial for long-term thinking: simplicity, openness and standardisation. These qualities are desirable not just for the future but also for the present. These are the qualities that allow data to be portable.

To fully explain, I need to back up a few years.

In the early 2000s I was teaching myself web development. One of my favorite methods of learning was finding sites I liked and deconstructing the front-end to understand how they built things. This is how I learned CSS-based layouts and a host of other techniques that leveled up my skillset quite quickly.

It's harder to learn this way now because assets (JS / CSS) are almost always minified. Minifying assets is something that most folks would consider to be best practice. But it got me thinking — minifying an asset also obfuscates the knowledge embedded in it.

What if there was a way around this?

A Possible Solution

Ideally we could have the best of both worlds. If a browser requested the asset, we could serve the minified version. When a human requested the asset (e.g. by navigating directly to the asset) a non-minified, learning-friendly version would be served.

There might actually be a way to do this using the HTTP_ACCEPT header. In my test, when a browser requests a stylesheet that's referenced in an HTML document, the header value sent to the server looks like this:

text/css,/;q=0.1

However, if I navigate directly to the stylesheet, the header value looks like this:

text/html,application/xhtml+xml,application/xml;q=0.9,/;q=0.8

It seems feasible to decide which version of an asset to serve based on the value of the HTTP_ACCEPT header. This could be done inside the application stack or even by the HTTP server (if you're like me and let Nginx or Apache server your assets).

There are still issues with this, like handling CDN-hosted assets.

Conclusion

I'm still undecided if building a technical solution for this is a good idea. Regardless, I think we should consider the consequences of obfuscating the knowledge that's inherent in things like assets. Even if there's not a great technical solution, there's still the option of making user-friendly assets available through some separate URL.

Something to ponder. In the meantime, I recommend watching Jeremy's talk. For additional background, you can read the original blog post entitled The Long Web.

PREVIOUSLY full archive