2 ms·

The vast majority of the code you'll be "shipping to the client that won't work on it anyway" will be to old browsers. In almost all cases with modern browsers,

The vast majority of the code you'll be "shipping to the client that won't work on it anyway" will be to old browsers. In almost all cases with modern browsers, the amount of code we're talking about is small enough that it will almost certainly not have a perceptible impact on latency. So you aren't slowing down those hundred million users. You're slowing down the rapidly shrinking minority users with ancient browsers.

nostrademons 13y ago
If you're not doing server-side browser detection, how do you avoid shipping the code to support old browsers to new browsers? Pre-IE9, most browser-specific hacks weren't of the form "Old browser X doesn't support new feature Y". They were of the form "IE does things differently." That required shipping a version for IE, and shipping a version for everyone else. If you gate these with feature detection on the client, you need to ship the IE code and the conditionals to gate it to the client. Post-IE9, most browser-specific hacks are of the form "Emerging web standard X would be very handy but isn't supported in browser Y, so I'm going to emulate it with Javascript." That involves shipping JS to old browsers, not to new browsers.
- mistercow 13y ago
  You could use UA strings to serve the shims and workarounds, I suppose, but you could also use client-side feature detection to do the same thing more reliably. If certain features are missing, you load in the extra code. If not, you don't, and page load time is unaffected, except for the tiny amount of code required to do the feature detection. In either case, what you're doing is more graceful degradation than progressive enhancement. But the idea of progressive enhancement is not just about supporting everybody's browser so that you will get more conversions in the short term. It's about the long term. Targeting the majority and saying "screw the fringe demographics" is what led to Microsoft having control over web technology years ago, and it's important to our livelihood to prevent that from happening again.

nostrademons 13y ago

If you're not doing server-side browser detection, how do you avoid shipping the code to support old browsers to new browsers? Pre-IE9, most browser-specific hacks weren't of the form "Old browser X doesn't support new feature Y". They were of the form "IE does things differently." That required shipping a version for IE, and shipping a version for everyone else. If you gate these with feature detection on the client, you need to ship the IE code and the conditionals to gate it to the client. Post-IE9, most browser-specific hacks are of the form "Emerging web standard X would be very handy but isn't supported in browser Y, so I'm going to emulate it with Javascript." That involves shipping JS to old browsers, not to new browsers.

mistercow 13y ago
You could use UA strings to serve the shims and workarounds, I suppose, but you could also use client-side feature detection to do the same thing more reliably. If certain features are missing, you load in the extra code. If not, you don't, and page load time is unaffected, except for the tiny amount of code required to do the feature detection. In either case, what you're doing is more graceful degradation than progressive enhancement. But the idea of progressive enhancement is not just about supporting everybody's browser so that you will get more conversions in the short term. It's about the long term. Targeting the majority and saying "screw the fringe demographics" is what led to Microsoft having control over web technology years ago, and it's important to our livelihood to prevent that from happening again.