[jimminy]

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]

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]

> 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_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]

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.