Hacker News Reader

Comment by azangru | Hacker News Reader

> This isn’t your problem Mom. You should’t have to go buy new hardware. This is a problem with the people who make that website. They should be making their website’s code more accessible to legacy devices.

And here is me, a web developer, thinking that using a feature supported by the latest versions of all major browsers should be fine...

I don't know what a proper strategy should look like; but it's hardly a case of "progressive enhancement" that the author is talking about. You might — if the functionality of the site allows — progressively enhance from no js to full js; but you can't progressively enhance from old js to modern js. One could, of course build different bundles with different javascript targets; but how many such targets should one have? How many legacy browser versions would the author want web developers to support?

View on HN

> 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.

> 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.

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.

> 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.

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)

The use case for this website has been solved via server side scripting and accessible for any user since before I was 5.

You don't need to use every js feature on every website.

I would go so far as to say it's irresponsible.

Reply on news.ycombinator.com