[zdunn]

> but it's hardly a case of "progressive enhancement" that the author is talking about.

This is definitely a case of progressive enhancement. If the site had started out with a basic form, it would have worked on the referenced devices/browsers when the javascript broke.

> but how many such targets should one have?

2. You should have your main script which can have the latest features and compile it down to ES5, which will work in nearly every browser. Compiling to ES5 is one of the easiest web development tasks to automate so laziness isn't a valid excuse. Just using this technique of ES5/ESNext would support nearly every legacy browser/version.

[azangru]

> and compile it down to ES5, which will work in nearly every browser

And how do you load it, as opposed to the modern bundle? I've heard about the script nomodule technique; but that would become less and less relevant as more and more browser versions start being able to load and execute ES6, but not ES_current_year.

[zdunn]

the es5 build will reach less and less users over time, but it has no cost for other users or even the developer. Load it with a script nomodule tag and you always have a JS fallback that covers weird edge cases like the one described in the article.

And building with the right HTML foundation, means you have a fallback for any breaking javascript, that will cover even more edge cases.

[azangru]

> Load it with a script nomodule tag and you always have a JS fallback that covers weird edge cases like the one described in the article.

I'm confused.

How would this have helped the author's mom who is stuck on Chrome 76? Chrome 76 is modern enough to have ignored the script nomodule, but too old to understand the optional chaining operator.

[zdunn]

You're right, my bad. I was getting ahead of my self. The JS fallback covers older, non-evergreen browsers and the HTML fallback covers everything (including the described issue)