[admax88q]

Serving different content for the same URI based upon various metadata fields in the request goes completely against the spirit of a URI.

[hypertele-Xii]

No it doesn't? Ever heard of Accept or Lang headers? Or cookies for that matter? Dynamic content?

[billyhoffman]

Agreed, and thanks for bring up the Accept header. The author seems uninformed about HTTP's built in Content Negotiation. They write about servers using the User-Agent header, specifically talking about WebP. Accept: "image/webp" works just fine for the major CDNs regardless of the UA.

[admax88q]

Accept and content negotiation has a long established history, and content negotiation is different than the server making decisions based upon metadata.

It's one thing for the client to say "give me this resource in this format" its another for the server to say "oh you're coming from version X.Y of OS Z, I know what you really want."

[ocdtrekkie]

This is unfortunately the world of web apps, where a URI just gets you to the app, and the content within is dynamic.

[admax88q]

Even with web apps, you can serve the same app from the same URI. URI doesn't imply static content.

Serving a slightly different web app from the same URI based upon other random metadata on the other hand. Makes caching all the more complicated.

[ocdtrekkie]

I get that. I do think by and large, the user's agent (the browser) should be making display and format decisions based on itself, rather than the server serving different content. Though I think the exception is mobile, where we probably shouldn't serve the client endless garbage it doesn't need.

I mostly think the replacement for user agent should be a boolean of mobile or not mobile. And everything else should be dynamically handled by the client.

[admax88q]

Honestly though, if its enough content for mobile, its enough content for desktop as well.

The "garbage" we don't want to serve mobile, is often also garbage for desktop, autoplay videos, too many tracking scripts, etc. If we force people to optimize their site for mobile and desktop then maybe we'll actually get good desktop sites.

[ocdtrekkie]

Eh, navigation layout should definitely be different for mobile, and we shouldn't ship the desktop navigation to phone browsers, and I still think it's reasonable to offer phones smaller/more compressed image sizes and stuff by default.

I agree tracking scripts and the like should be blocked and removed across the board. But I think there's probably a suitable amount of visible UI and content that should be shipped differently or less to phones, because of how they're interacted with.

[admax88q]

I hear you, but I'd wager the size differences are actually pretty minor. Absolute worst case you have 2X the CSS and HTML but much will be redundant so it will probably compress well with gzip.