4 ms·
Theoretically, yes, but that means you need a pretty complicated setup to serve static assets. Also, this solution can be built into a Javascript shim for olde
by lukeschlather 13y ago
Theoretically, yes, but that means you need a pretty complicated setup to serve static assets.
Also, this solution can be built into a Javascript shim for older browsers, something header-based would be much harder to do as a shim.
- hcarvalhoalves 13y ago> Theoretically, yes, but that means you need a pretty complicated setup to serve static assets. Why? There's no difference on the server side, you would have multiple versions of the same file anyway. You're just exchanging the responsibility of getting the right file from the markup to responding with the right file on the server (which is way easier to keep consistent, IMO).
- lukeschlather 13y agoThe way I see it, keeping it in the markup makes it more straightforward to debug. If it's server-side, all of our developers need direct access to the asset server as soon as there are content negotiation issues. If it's client-side, we can share a highly-available asset server and each developer has their code sandboxed. In an ideal world, it would be server side. But it would easily mean twice as much work to get there.