4 ms·

This was an eye-opener for me too. As a web dev, I had been thinking "there's no reason anyone would be running anything but the latest version of Chrome" -- b

This was an eye-opener for me too. As a web dev, I had been thinking "there's no reason anyone would be running anything but the latest version of Chrome" -- but here's a reason. Should we be trying to support old versions of Chrome? The author thinks so. > This is a problem with the people who make that website. They should be making their website’s code more accessible to legacy devices. I'm not sure how likely that is to happen. Where do we draw the line? Most tools oriented towards helping you do legacy browser support (like caniuse) don't even have UI's oriented toward helping you figure out what version of Chrome is when and where a good line to draw might be. (At what point would the OP author think we could stop transpiling down to ES5? Literally never?) Just cause I'm curious... Version 76 is what his mom's chromebook had. When did that come out? Looks like July 20 2019. So about 2.5 years ago. But this does make me re-think what appropriate browser support policy should be... mostly I just have questions not answers though. The author was so clear that it was the websites fault and they should be supporting this 2.5 year-old Chrome... I'm curious what other HN readers are doing, is anyone testing on or making sure to support this kind of old "evergreen" browsers, and if so how?

jimminy 5y ago
As someone who started doing web development in 2003-2004, I've always aimed for a 5 year support window. This is largely because of how long IE6-IE8 upgrades took for many SMB's and governments to upgrade from in those days. Back then browsers updated closer to 2-4 times a year, with far lower inertia in how drastic the changes would be. You could learn and mostly remember what features were safe for roughly that period. These days, I tend to look at feature release dates and support on CanIUse or MDN, to see if somethings been in broad use for the past 4-5 years.
- jrochkind1 5y ago
  Thanks for response! So are you looking at Chrome (and Firefox) back to 4-5 years past (via caniuse?), and not using something if they don't support it back that far? (at least ES6 is, generally, in all current browsers (not IE) as of more than 4 years back at this point. But are you delivering ES6 to browsers, or still limiting yourself to ES5?)
  - zdunn 5y ago
    > So are you looking at Chrome (and Firefox) back to 4-5 years past (via caniuse?), and not using something if they don't support it back that far? I don't think that's whats the author meant, since they mentioned progressive enhancement. The site in question was for making a reservation to volunteer. This could have been written as a simple HTML form and it would have worked on any version of Chrome/Firefox/Safari and most other browsers. Any dynamic feature the site authors wanted to add should have used [feature detection](https://developer.mozilla.org/en-US/docs/Learn/Tools_and_testing/Cross_browser_testing/Feature_detection https://developer.mozilla.org/en-US/docs/Learn/Tools_and_tes...). You can also use JS modules and `nomodule` script tags to deliver the latest and greatest JS to modern browsers and a compiled ES5 script to older browsers (though that wouldn't work in the case of an older evergreen browser that does support modules)
  - jimminy 5y ago
    These days I look up individual features, and use the date-relative view, to assess how long it's been available. Normally I'll start porting features once they're solid across the main browser set, but with a polyfill or some alternative based on feature detection. I held off on delivering ES6 native until 2017-2018, and used mainly Bable or sometimes hand written polys up to that point if I wanted to use features from cutting edge. There's some influence from your user-agent analytics as well to determine if there is a meaningful regression to leave people behind. 5 years is just the rough grasp, sometimes the new features are worth integrating sooner if they provide actual functional improvements for users. Generally, syntactic sugar is given less precedence especially when it would negatively impact usability of the product. Saving a few hours for development is far less valuable than saving even a few hundreds of users hours of frustration.
dmitriid 5y ago
> As a web dev, I had been thinking "there's no reason anyone would be running anything but the latest version of Chrome" -- but here's a reason. And this way of thinking is increasingly a huge problem, as the web becomes not just Chrome-only, but latest-version-of-Chrome-only > I'm curious what other HN readers are doing, is anyone testing on or making sure to support this kind of old "evergreen" browsers, and if so how? You'll find both ends of the spectrum on HN. From "we must absolutely have all the latest and greates from Chrome shipped in all other browsers as possible" to "if it's newer than 5-7 years, for the love of god transpile and polyfill it". I'm more in the second camp. There are several reasons for that: 1. At a previous gig at a large company three years ago IE 11 brought us up to 4 million views a month. While not directly convertible to users, it's still the size of a small country 2. The world in general doesn't run on the latest Chrome. You have a huge amount of devices across the world, and not all of them will be the latest Macbooks Mx or Galaxy/Pixel <whatever the latest version number is>. Just for Android you'll find that more than half of your users (depending on your target audience) may be running software that's three years and more older: https://www.androidpolice.com/googles-latest-android-version-distribution-numbers-show-11-in-dead-heat-with-10/ https://www.androidpolice.com/googles-latest-android-version... Samsung Internet and UC Browser which are very weird versions many versions behind and sideways from mainstream browser engines may be anywhere from ~7% to 50-60% once again depending on your target audience.
- jrochkind1 5y ago
  Is someone using a three-year-old Android OS... using a three-year-old version of chrome? Or can an old version of Android still be using a more recent Chrome? I don't actually know how it works!
  - dmitriid 5y ago
    Many Androids stop receiving updates after just two years. I don't know if it affects the browser :) However, there are also many users who don't update either the OS or the apps (because they don't know what it is, afraid it will break, afraid it will change functionality etc. )
nelgaard 5y ago
It is a trade off. How much did they really gain by using ?. A year ago I helped a small company with some issues. One was that some people working with them had some problems using their app with older phones. After some investigation it turned out that I just had to replace "let " with "var " on a few lines of javascript code. I used an an Iphone 4S for the testing and the browser could not be updated. I you make something that could work on older devices and it is not too much trouble, you should make it work on those devices. I have a drawer full of old devices that I use for all kinds of things (besides testing) where it is not a big deal that the software cannot be updated. I do have an old chromebook. It runs Debian sid and has updated browsers.
sangnoir 5y ago
We can stop transpiling to ES5 when a (window youre comfortable with) has elapsed since the last ES5-only browser was released and hopefully your users have upgraded. Additionally, you can check the User agents in your access logs (or analytics) to see what fraction od your users are still on ES5 browsers I think once you've correctly configured your CI transpiler, you wont even have to think about it, so it's a small cost, IMO.
sangnoir 5y ago
We can stop transpiling to ES5 when a long enough time-window (one you're comfortable with) has elapsed since the last ES5-only browser was released and hopefully your users have upgraded. Additionally, you can check the User-agents in your access logs (or analytics) to see what fraction of your users are still on ES5 browsers. I think once you've correctly configured your CI transpiler, you wont even have to think about it, so it's a small price to pay, IMO.

jimminy 5y ago

As someone who started doing web development in 2003-2004, I've always aimed for a 5 year support window. This is largely because of how long IE6-IE8 upgrades took for many SMB's and governments to upgrade from in those days. Back then browsers updated closer to 2-4 times a year, with far lower inertia in how drastic the changes would be. You could learn and mostly remember what features were safe for roughly that period. These days, I tend to look at feature release dates and support on CanIUse or MDN, to see if somethings been in broad use for the past 4-5 years.

jrochkind1 5y ago
Thanks for response! So are you looking at Chrome (and Firefox) back to 4-5 years past (via caniuse?), and not using something if they don't support it back that far? (at least ES6 is, generally, in all current browsers (not IE) as of more than 4 years back at this point. But are you delivering ES6 to browsers, or still limiting yourself to ES5?)
- zdunn 5y ago
  > So are you looking at Chrome (and Firefox) back to 4-5 years past (via caniuse?), and not using something if they don't support it back that far? I don't think that's whats the author meant, since they mentioned progressive enhancement. The site in question was for making a reservation to volunteer. This could have been written as a simple HTML form and it would have worked on any version of Chrome/Firefox/Safari and most other browsers. Any dynamic feature the site authors wanted to add should have used [feature detection](https://developer.mozilla.org/en-US/docs/Learn/Tools_and_testing/Cross_browser_testing/Feature_detection https://developer.mozilla.org/en-US/docs/Learn/Tools_and_tes...). You can also use JS modules and `nomodule` script tags to deliver the latest and greatest JS to modern browsers and a compiled ES5 script to older browsers (though that wouldn't work in the case of an older evergreen browser that does support modules)
- jimminy 5y ago
  These days I look up individual features, and use the date-relative view, to assess how long it's been available. Normally I'll start porting features once they're solid across the main browser set, but with a polyfill or some alternative based on feature detection. I held off on delivering ES6 native until 2017-2018, and used mainly Bable or sometimes hand written polys up to that point if I wanted to use features from cutting edge. There's some influence from your user-agent analytics as well to determine if there is a meaningful regression to leave people behind. 5 years is just the rough grasp, sometimes the new features are worth integrating sooner if they provide actual functional improvements for users. Generally, syntactic sugar is given less precedence especially when it would negatively impact usability of the product. Saving a few hours for development is far less valuable than saving even a few hundreds of users hours of frustration.

dmitriid 5y ago

> As a web dev, I had been thinking "there's no reason anyone would be running anything but the latest version of Chrome" -- but here's a reason. And this way of thinking is increasingly a huge problem, as the web becomes not just Chrome-only, but latest-version-of-Chrome-only > I'm curious what other HN readers are doing, is anyone testing on or making sure to support this kind of old "evergreen" browsers, and if so how? You'll find both ends of the spectrum on HN. From "we must absolutely have all the latest and greates from Chrome shipped in all other browsers as possible" to "if it's newer than 5-7 years, for the love of god transpile and polyfill it". I'm more in the second camp. There are several reasons for that: 1. At a previous gig at a large company three years ago IE 11 brought us up to 4 million views a month. While not directly convertible to users, it's still the size of a small country 2. The world in general doesn't run on the latest Chrome. You have a huge amount of devices across the world, and not all of them will be the latest Macbooks Mx or Galaxy/Pixel <whatever the latest version number is>. Just for Android you'll find that more than half of your users (depending on your target audience) may be running software that's three years and more older: https://www.androidpolice.com/googles-latest-android-version-distribution-numbers-show-11-in-dead-heat-with-10/ https://www.androidpolice.com/googles-latest-android-version... Samsung Internet and UC Browser which are very weird versions many versions behind and sideways from mainstream browser engines may be anywhere from ~7% to 50-60% once again depending on your target audience.

jrochkind1 5y ago
Is someone using a three-year-old Android OS... using a three-year-old version of chrome? Or can an old version of Android still be using a more recent Chrome? I don't actually know how it works!
- dmitriid 5y ago
  Many Androids stop receiving updates after just two years. I don't know if it affects the browser :) However, there are also many users who don't update either the OS or the apps (because they don't know what it is, afraid it will break, afraid it will change functionality etc. )

nelgaard 5y ago

It is a trade off. How much did they really gain by using ?. A year ago I helped a small company with some issues. One was that some people working with them had some problems using their app with older phones. After some investigation it turned out that I just had to replace "let " with "var " on a few lines of javascript code. I used an an Iphone 4S for the testing and the browser could not be updated. I you make something that could work on older devices and it is not too much trouble, you should make it work on those devices. I have a drawer full of old devices that I use for all kinds of things (besides testing) where it is not a big deal that the software cannot be updated. I do have an old chromebook. It runs Debian sid and has updated browsers.

sangnoir 5y ago

We can stop transpiling to ES5 when a (window youre comfortable with) has elapsed since the last ES5-only browser was released and hopefully your users have upgraded. Additionally, you can check the User agents in your access logs (or analytics) to see what fraction od your users are still on ES5 browsers I think once you've correctly configured your CI transpiler, you wont even have to think about it, so it's a small cost, IMO.

sangnoir 5y ago

We can stop transpiling to ES5 when a long enough time-window (one you're comfortable with) has elapsed since the last ES5-only browser was released and hopefully your users have upgraded. Additionally, you can check the User-agents in your access logs (or analytics) to see what fraction of your users are still on ES5 browsers. I think once you've correctly configured your CI transpiler, you wont even have to think about it, so it's a small price to pay, IMO.