5 ms·

> This is a problem with the people who make that website. They should be making their website’s code more accessible to legacy devices. Just because you don’t

> This is a problem with the people who make that website. They should be making their website’s code more accessible to legacy devices. Just because you don’t have a browser that can run ECMAScript 2020, you should still be able to access and use this website. I don't follow the reasoning here. Why does the onus lie on the web developer and not on Google or Apple?

akkartik 5y ago
"I can’t open this website I always use to make a reservation to volunteer." Regressions are regressions. You don't get to make excuses if you unilaterally changed something for someone.
- programmer_dude 5y ago
  What's the point of releasing new language features if you can't use them? Web-developers don't deserve quality of life improvements but the developers working for Google and Apple do?
  - rossipedia 5y ago
    You absolutely can. The issue isn't _using_ the optional chaining operator, the issue is that it wasn't compiled down to something that older platforms can understand. Developer quality of life doesn't have to conflict with what's supported on older platforms.
    - programmer_dude 5y ago
      Sounds like a good solution to the posted problem. But the device user should be allowed to upgrade their browser and OS too.
      - Bilal_io 5y ago
        Sometimes users use older browser because of ignorance, they don't know how to upgrade, or because they don't want to.
    - teawrecks 5y ago
      And what do you do when the only way to support a new feature on a legacy system necessarily introduces a security risk? Special case it?
      - rossipedia 5y ago
        That's a hard problem to solve, and I don't think there are any easy answers. It depends on many factors. What kind of business, what the risk/threat model is, cost/benefit analysis, all that kind of stuff.
  - Falell 5y ago
    You can use the latest goodies in environments that you control. Server side node, client side node, etc. This is a common thing when working on library-like-things outside the web too. Widely used C++ libraries generally aren't taking hard dependencies on C++20 features right now without continuing to support e.g. C++11/14/17.
  - slotrans 5y ago
    > Web-developers don't deserve quality of life improvements Don't you think the customer experience is strictly more important than the developer experience?
    - urthor 5y ago
      Essentially, no. Especially if the developer is giving their time for free website. The developer is putting in the hard yards to make the website for their community event. Why shouldn't the user make the effort to have a web browser that's updated to 2022? It's a complex conversation, but "the customer is always right" is not always the case.
  - mrweasel 5y ago
    There's a few things that makes it a little different, but the lack of updates is certainly an issue. The developers do have access to statistic about exactly how many clients they'll break. They might have felt that it's so few that the ease of development justifed breaking the website for just a few users. They could tell them that their browser is too old, saving many a lot of headache. In this case, the problem, making a reservation to volunteer, is simple enough that you could have solved it with a CGI script in 2001, and it would still work. So it only broken, because someone felt it needed to be more modern. Remember, this is people who volunteer their time, they're not forced to do anything, so you have to be as accommodating as possible.
- teawrecks 5y ago
  The site supports the recent browser versions. Always has, always will. That behavior has not changed.
  - hannasanarion 5y ago
    Optional chaining was only introduced to javascript in April 2020, 18 months ago. That's a pretty gnarly upgrade cycle to demand all your general-public users maintain.
    - teawrecks 5y ago
      Alright, I agree, that is probably too recent to be breaking stuff. But I maintain that no one should be running an out of date browser in the first place. In fact, browsers that are more than X months old should automatically pop up a warning telling the user that it hasn't been updated recently and they're running a security risk by continuing to use it, including/especially on these old EOL devices. Browsers that have reached this point shouldn't be expected to be supported by websites.
- zamadatix 5y ago
  Sure you do or you eventually find your project goals turn into "supporting the one user who still wants to connect via IE 5" instead of whatever the project goals actually were. I'm not going to say how old a browser your site should support, that depends on the situation, but I will say I've never seen a case where terms as small as "someone" was the right balance. Optional chaining however is missing for something like 8% of users https://caniuse.com/?search=optional%20chaining https://caniuse.com/?search=optional%20chaining so for this specific situation I'd say that's probably a bit too high to not transpile/have a fallback for most anything but a tech demo.
  - hannasanarion 5y ago
    But this isn't just one user. CanIUse says that only 90% of browsers support optional chaining, so you're potentially losing 10% of all of your users. For an American company, that's like refusing to serve black people, or people from Texas, and it's just as outrageous.
    - zamadatix 5y ago
      That's what I commented about this particular situation in the second point, right down to the caniuse reference. The first part about a cutoff point was in response to "Regressions are regressions. You don't get to make excuses if you unilaterally changed something for someone" which is not true or the problem in this situation.
- nathancahill 5y ago
  There's also a "know your audience" factor. If you're developing a SaaS for a tech product, maybe supporting the latest couple browser versions is fine. Websites for volunteering probably have a wider audience among older generations using older devices. Ideally you'd know what browsers are visiting your site from analytics and support the relevant percentages.
lhorie 5y ago
It's not an either-or proposition. There's a spectrum of things that are supported to varying degrees by various browser platforms and a spectrum of degrees of caring about compatibility. On one end of the spectrum, you might have questions about supporting IE9 (i.e. EOL software that the maker no longer updates but that you as a web dev might have to care about), on the other you might have questions about supporting untranspiled JS class properties or top level await (i.e. software features that you as a web dev may feel entitled to use despite knowing about limited adoption). It can be argued that browser vendors ought to do their best to align with standards, while simultaneously arguing that old devices do exist in the wild and some amount of onus falls on web developers to cater to segments above some threshold of usage.
rossipedia 5y ago
I think it's spread out here in this instance. The realities of the web are that a non-trivial amount of people are going to be using older, outdated devices. That's just a hard fact. The web dev's responsibility here (or possibly his manager's) is on deciding what level of support they're going to give for those outdated devices. Do Apple/Google/etc also bear some responsibility here? Absolutely. They can (and should imo) support older devices, much more than they do. But they're gonna chase profit, and at some point the costs of that support outweigh the benefit. That's just another hard fact of life on the web, one that developers should take into account when deciding what kind of support they want to give to outdated browsers with their code. Luckily, for most things down-compiling to something like ES5 isn't incredibly difficult and can be automated.
indymike 5y ago
> I don't follow the reasoning here. Why does the onus lie on the web developer and not on Google or Apple? Because you can easily support newer JS features in older browsers with Babel? https://babeljs.io/docs/en/index.html https://babeljs.io/docs/en/index.html. 8-14% of your users probably have something that will not work with the latest-greatest JS features it is your choice as a developer to not support them.
GuB-42 5y ago
The onus lies on both the web developer and Google and Apple. Web developers should be considerate in case people don't or can't update their browsers. Google and Apple should make sure their systems are up to date. If it doesn't work, both are to blame, and should both do something instead of blaming each other while the user suffers. Why have new features if it is not to use them? Consider them a preview, as in "this is what users will have in 5 years", or use something like Babel. Personally, if possible, I like to target 10 year old devices, more if the cost is low. It may seem crazy but I think that now, 10 years is a reasonable lifespan for a computer, including phones and tablets, 15 for a desktop PC or a good laptop.
mnutt 5y ago
There's an argument to be made for a tradeoff between legacy device support and cleaning up cruft, but the part that stands out to me is that optional chaining is such a trivial thing to break backwards compatibility over. It's one thing to require async/await: transpiling async->generators->regenerator turns into loads of ugly/inefficient code. But optional chaining saves a couple dozen characters, and if the developer really wanted it they could add a very simple babel transform. Having seen code break over this exact thing before, I'm almost certain that the developer was unaware they were breaking anything for anyone.

akkartik 5y ago

"I can’t open this website I always use to make a reservation to volunteer." Regressions are regressions. You don't get to make excuses if you unilaterally changed something for someone.

programmer_dude 5y ago
What's the point of releasing new language features if you can't use them? Web-developers don't deserve quality of life improvements but the developers working for Google and Apple do?
- rossipedia 5y ago
  You absolutely can. The issue isn't _using_ the optional chaining operator, the issue is that it wasn't compiled down to something that older platforms can understand. Developer quality of life doesn't have to conflict with what's supported on older platforms.
  - programmer_dude 5y ago
    Sounds like a good solution to the posted problem. But the device user should be allowed to upgrade their browser and OS too.
    - Bilal_io 5y ago
      Sometimes users use older browser because of ignorance, they don't know how to upgrade, or because they don't want to.
  - teawrecks 5y ago
    And what do you do when the only way to support a new feature on a legacy system necessarily introduces a security risk? Special case it?
    - rossipedia 5y ago
      That's a hard problem to solve, and I don't think there are any easy answers. It depends on many factors. What kind of business, what the risk/threat model is, cost/benefit analysis, all that kind of stuff.
- Falell 5y ago
  You can use the latest goodies in environments that you control. Server side node, client side node, etc. This is a common thing when working on library-like-things outside the web too. Widely used C++ libraries generally aren't taking hard dependencies on C++20 features right now without continuing to support e.g. C++11/14/17.
- slotrans 5y ago
  > Web-developers don't deserve quality of life improvements Don't you think the customer experience is strictly more important than the developer experience?
  - urthor 5y ago
    Essentially, no. Especially if the developer is giving their time for free website. The developer is putting in the hard yards to make the website for their community event. Why shouldn't the user make the effort to have a web browser that's updated to 2022? It's a complex conversation, but "the customer is always right" is not always the case.
- mrweasel 5y ago
  There's a few things that makes it a little different, but the lack of updates is certainly an issue. The developers do have access to statistic about exactly how many clients they'll break. They might have felt that it's so few that the ease of development justifed breaking the website for just a few users. They could tell them that their browser is too old, saving many a lot of headache. In this case, the problem, making a reservation to volunteer, is simple enough that you could have solved it with a CGI script in 2001, and it would still work. So it only broken, because someone felt it needed to be more modern. Remember, this is people who volunteer their time, they're not forced to do anything, so you have to be as accommodating as possible.
teawrecks 5y ago
The site supports the recent browser versions. Always has, always will. That behavior has not changed.
- hannasanarion 5y ago
  Optional chaining was only introduced to javascript in April 2020, 18 months ago. That's a pretty gnarly upgrade cycle to demand all your general-public users maintain.
  - teawrecks 5y ago
    Alright, I agree, that is probably too recent to be breaking stuff. But I maintain that no one should be running an out of date browser in the first place. In fact, browsers that are more than X months old should automatically pop up a warning telling the user that it hasn't been updated recently and they're running a security risk by continuing to use it, including/especially on these old EOL devices. Browsers that have reached this point shouldn't be expected to be supported by websites.
zamadatix 5y ago
Sure you do or you eventually find your project goals turn into "supporting the one user who still wants to connect via IE 5" instead of whatever the project goals actually were. I'm not going to say how old a browser your site should support, that depends on the situation, but I will say I've never seen a case where terms as small as "someone" was the right balance. Optional chaining however is missing for something like 8% of users https://caniuse.com/?search=optional%20chaining https://caniuse.com/?search=optional%20chaining so for this specific situation I'd say that's probably a bit too high to not transpile/have a fallback for most anything but a tech demo.
- hannasanarion 5y ago
  But this isn't just one user. CanIUse says that only 90% of browsers support optional chaining, so you're potentially losing 10% of all of your users. For an American company, that's like refusing to serve black people, or people from Texas, and it's just as outrageous.
  - zamadatix 5y ago
    That's what I commented about this particular situation in the second point, right down to the caniuse reference. The first part about a cutoff point was in response to "Regressions are regressions. You don't get to make excuses if you unilaterally changed something for someone" which is not true or the problem in this situation.
nathancahill 5y ago
There's also a "know your audience" factor. If you're developing a SaaS for a tech product, maybe supporting the latest couple browser versions is fine. Websites for volunteering probably have a wider audience among older generations using older devices. Ideally you'd know what browsers are visiting your site from analytics and support the relevant percentages.

lhorie 5y ago

It's not an either-or proposition. There's a spectrum of things that are supported to varying degrees by various browser platforms and a spectrum of degrees of caring about compatibility. On one end of the spectrum, you might have questions about supporting IE9 (i.e. EOL software that the maker no longer updates but that you as a web dev might have to care about), on the other you might have questions about supporting untranspiled JS class properties or top level await (i.e. software features that you as a web dev may feel entitled to use despite knowing about limited adoption). It can be argued that browser vendors ought to do their best to align with standards, while simultaneously arguing that old devices do exist in the wild and some amount of onus falls on web developers to cater to segments above some threshold of usage.

rossipedia 5y ago

I think it's spread out here in this instance. The realities of the web are that a non-trivial amount of people are going to be using older, outdated devices. That's just a hard fact. The web dev's responsibility here (or possibly his manager's) is on deciding what level of support they're going to give for those outdated devices. Do Apple/Google/etc also bear some responsibility here? Absolutely. They can (and should imo) support older devices, much more than they do. But they're gonna chase profit, and at some point the costs of that support outweigh the benefit. That's just another hard fact of life on the web, one that developers should take into account when deciding what kind of support they want to give to outdated browsers with their code. Luckily, for most things down-compiling to something like ES5 isn't incredibly difficult and can be automated.

indymike 5y ago

> I don't follow the reasoning here. Why does the onus lie on the web developer and not on Google or Apple? Because you can easily support newer JS features in older browsers with Babel? https://babeljs.io/docs/en/index.html https://babeljs.io/docs/en/index.html. 8-14% of your users probably have something that will not work with the latest-greatest JS features it is your choice as a developer to not support them.

GuB-42 5y ago

The onus lies on both the web developer and Google and Apple. Web developers should be considerate in case people don't or can't update their browsers. Google and Apple should make sure their systems are up to date. If it doesn't work, both are to blame, and should both do something instead of blaming each other while the user suffers. Why have new features if it is not to use them? Consider them a preview, as in "this is what users will have in 5 years", or use something like Babel. Personally, if possible, I like to target 10 year old devices, more if the cost is low. It may seem crazy but I think that now, 10 years is a reasonable lifespan for a computer, including phones and tablets, 15 for a desktop PC or a good laptop.

mnutt 5y ago

There's an argument to be made for a tradeoff between legacy device support and cleaning up cruft, but the part that stands out to me is that optional chaining is such a trivial thing to break backwards compatibility over. It's one thing to require async/await: transpiling async->generators->regenerator turns into loads of ugly/inefficient code. But optional chaining saves a couple dozen characters, and if the developer really wanted it they could add a very simple babel transform. Having seen code break over this exact thing before, I'm almost certain that the developer was unaware they were breaking anything for anyone.