The optional chaining operator, “modern” browsers, and my mom
blog.jim-nielsen.com
blog.jim-nielsen.com
This is the most surprising part of the article. If ChromeOS does not allow the browser to be updated after the hardware has reached end-of-support, I would recommend it to nobody, ever.
https://www.androidpolice.com/2020/02/07/chromebooks-will-now-get-up-to-eight-years-of-chrome-os-updates/
https://www.google.com/search?hl=en&q=average%20laptop%20lifespanGoogle's consumer hostile behavior is kneecapping any chance they have at future market dominance, it's entirely self correcting.
Controlling search, Android, Chrome as the dominant browser, and YouTube are much bigger parts of their power over the Internet than ChromeOS.
I think there's a Google Classroom thing as well.
Tight browser integration was not illegal in and of itself.
It's true, but it was only "bad" in the eyes of the law because of their monopoly. If Microsoft hadn't had a monopoly then their strong arm tactics would have been fine. No one would care if I went to Dell and said "you can only sell computers with my OS on them if you also include my browser."
In the US you can be anti-competitive if you don't have a monopoly and you can have a monopoly as long as you don't engage in anti-competitive behavior. It's only when you have a monopoly AND engage in anti-competitive behavior that you get in trouble.
Microsoft: abuse market monopoly status () to force and scare OEMs into special bundling deals (*).
() Chrome OS, iOS: not monopoly status - "monopoly for this brand+device" doesn't count, unless the device has the monopoly of its market. Microsoft had aroun 98% of the desktop
(*) Google, Apple: don't do that. And even if they did it, they're not monopolies in laptops/tablets, so they could just as well did it, and it wouldn't be the same legally as what MS did.
Anti-trust law is long standing with lots of precedent to work off of, so it had a natural application to the Microsoft case.
This is totally incorrect. There are a large number of alternatives.
I still use an 8 year old iPad every day, and have an updated version of iCab Mobile running on it, which has given me no problems whatsoever. I’ve certainly never experienced a website that won’t load, despite the age of the hardware.
It is completely false, as noted in replies all over, could you please chill with the spam?
They could argue it, but they would be factually wrong. Apple doesn't even sell half the tablets sold every year...
Edit: looks like there's now an effort to separate them, as the readme says. see [1].
0: https://chromium.googlesource.com/chromium/src/+/refs/heads/...
1: https://chromium.googlesource.com/chromium/src.git/+/refs/he...
But in the case of Chrome OS this is likely to be fixed soon because Chrome is getting unbundled from Chrome OS, meaning it can be updated separately. This is codenamed Lacros and is in testing now. Devices currently receiving updates are likely to get it. https://www.androidpolice.com/2020/09/12/google-is-separatin...
Also, Chrome OS devices explicitly support unlocking and installing alternative OSes. If you don't like what Google does with Chrome OS you can install Linux or Windows instead and keep using your hardware as long as you like.
It is absolutely a disgrace. Not even specifically to create software. Not allowing root, the ways of the app stores, the entire UX. It all focuses on consumption and weak workflow. A 13 inch iPad could very easily be a dedicated developer device (and some do get by this way), but it’s such a pain.
I get that Apple can't be expected to keep developing software for these forever, but I'd be a lot happier if they would transition them to some kind of minimal support where they publish routine OS and security updates for them rather than just abandoning them. They also have this habit of ratcheting up the OS targeting requirements of the SDKs so app builders end up unwittingly building new versions of their apps that exclude old devices unnecessarily. I'm not sure my oldest ipad could install any of its apps again if I uninstalled them, even the ones from Apple.
It's a disgrace that while hardware is starting to vastly outlast software, somehow we have managed to normalize 2-3 years of software support for hardware gizmos and consider 5 years to be generous. And consumers accept this! 5 years is nothing. I have a PC next to me that I bought 20 years ago, and it still works excellently and runs a relatively recent version of Linux. I last updated my phone only because I had to: It was so "old" that it was dangerous to even connect to the Internet. Still worked wonderfully, made calls, but the manufacturer abandoned it (and me) and stopped supplying security updates. So a perfectly functional phone goes into a landfill. This should be totally unacceptable.
Just simply not true. Plenty of browsers are still updated for iOS12 and 8-year old hardware like the 2013 iPad Air (which I still use every day)
Edit: getting downvoted - while writing this post on iCab Mobile browser which was updated less than a month ago...
Follow-up: Well I tested the language ‘feature’ in this browser - and though it didn’t crash, it didn’t run the function either. I’d forgotten what a sh*tshow of crappy and unnecessary garbage modern front end JavaScript development was.
You are getting downvoted because Webkit Engine is not updated with the browser. In this case iCab Mobile Browser. As noted in other reply it is merely a shell or skin on top of the OS Webkit Engine. Hence you are objectively wrong.
"I’d forgotten what a shtshow of crappy and unnecessary garbage modern front end JavaScript development was.*"
while essentially true, has nothing to do with the question at hand.
Not anymore they don't. I recently bought a chromebook hoping to nuke it and install Linux but the bootloader is locked and I can't install any random OS. There's even dedicated linux distros like Gallium OS targeting chromebook devices specifically but if you look at the compatibility chart it's support is very limited for anything newer than 2018. Even crouton compatibility wasn't satisfactory and I gave up and just went full google approved with Crostini.
Every ChromeOS device I know of supports developer mode, and I was fairly sure google mandated it. Which device do you have which does not support developer mode?
That one supports CCD, so you can still "root" it, but instead of just enabling developer mode, you also have to connect a cable and go through a slightly more involved process.
Fortunately, it's quite well documented: https://chromium.googlesource.com/chromiumos/platform/ec/+/c...
It's still not fully locked since following the above doc should let you flash your own firmware
https://9to5google.com/2020/09/14/google-chrome-os-separate-...
> Update 9/14: After nearly five months, LaCrOS has surfaced in a working state on Chrome OS Canary, as spotted by Chrome Unboxed. By enabling the above-mentioned flag in chrome://flags, a new “LaCrOS” app will appear in your app list, first in grey, then in the usual yellow of Chrome Canary.
Chrome support for Windows 7 has been extended into 2023, which is an OS released in 2009.
"Due to global electronic components shortage , Pinebook Pro currently out of stock until further notice."
Just bullshit. There are plenty of browsers being updated and fully compatible with iOS 12.
I don't see why it needs to go that far. They could have just not used the optional chaining operator, or used a pre-processor if they really wanted to use it.
Very few people are browsing with no JS at all, and they are doing it deliberately. They probably disagree with me, but I don't think anyone should do extra work for them.
The cost to make a website accessible to everyone is so high that it really only makes sense for critical websites.
They are literally the 3 client “languages” of the web.
Everything your abstractions/frameworks do is produce html, css, and js.
> browsing with no JS at all,
It's about building a reliable product. I've witnessed tons of cases of websites broken due to Javascript. Sometimes they were broken in Firefox, other times they were broken only in some locales...
Often they were not broken forever, a bad release got pushed, and it took some times for the problems to be identified and addressed... but in the meanwhile, a specific part of their website was broken 100% of the time.
If you're building the new Google Maps, sure... knock yourself out with the fanciest Javascript you can find (but even then, I'd set a restrictive CSP, to avoid other script from interfering, and I'd pick something like Elm to make sure that runtime errors are minimized). But if you're building anything else, you should really try to keep it simple (even Gmail still has its plain HTML version)
Progressive enhancement isn't about building sites completely without JS. It's about building resilient sites that work on edge cases like this.
Every business has to make the choice, but unless I was running a pretty large operation, I'd be willing to ignore 1.3% to put my budget into other things.
Here[0] is a little documentation about it, but if you want to use the decoupled browser, it looks like you can enable it via chrome://flags if you are on a recent version (which OP's mom isn't, and since her device isn't going to get patched I doubt she'll benefit from this).
0: https://chromium.googlesource.com/chromium/src.git/+/refs/he...
Fast forward to 2022, and the ASUS C201 support for Android is still "planned" and unsupported. https://www.chromium.org/chromium-os/chrome-os-systems-suppo...
Feels like a big con just to get people to buy chromebooks in 2016 at this point.
Also, a reminder to not trust Google if they "plan" something like the upcoming Chrome "Lacros" decoupling
i dont think the fault is entirely with google here, asus shouldn't have marketed it as that, considering your chromebook had an arm processor - great for battery life, but google really only implemented the docker/shell and android support for intel cpus.
really unfortunate though
It's been quiet long since I've last I checked it out, but at least at that time the locale was different inside the android apps vs chromeos (including keyboard layout etc) and there was a separate settings app like on any Android devices with dummy values in hardware etc.
It was funny because it let me install Firefox on the Chromebook but it felt more like gimmick then an actually useful feature as a lot of apps just outright didn't work
https://www.slashgear.com/chrome-os-to-replace-chrome-with-l...
In the case of ChromeOS they do allow you to install Linux which satisfies this on paper (and to me, but perhaps not everyone?), however the iPad does not allow this in any way (the App Store, as pointed out by the author, explicitly disallows browsers), and I think there needs to be regulations on makers of devices that are classed as "general purpose computing devices".
Or you can use one of the plentiful choices of browser that are distributed on the App Store and still updated for iOS 12.
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?
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.
(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?)
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)
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.
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...
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.
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. )
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.
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.
Chrome wasn't updating because their out-of-dated hardware and I had to tell them switch to Firefox "the red fox on globe icon" to use the internet.
This lasted until the day I finally convinced them to buy a new PC.
The device does not get a new version of iOS, so I tried Safari to see if the web client works. Spotify's web client does not work on that version of Safari.
So I tried downloading Firefox and Chrome, but I can't because they no longer support my version of iOS.
So I looked for a way to download older versions of apps (Spotify, or an older version of Firefox or Chrome on which Spotify would still work). As it turns out, there's a way: you first need to "purchase" the app you're interested in on a newer device that supports the latest version. Then, you can log into your older device and download an older version of the same app.
That means there's a way for me to run an older version of an app that works on my iPad, but nah, I need to first get a newer device and "purchase" it there.
My conclusion: the onus is on the device manufacturers to not arbitrarily restrict their users. Jim Nielsen's mom's iPad is perfectly capable of opening that website, but its manufacturers are limiting it artificially.
No, it's not. Firefox and Chrome on iOS both use the operating system's Safari engine. (I mean, yeah, the hardware would support running a more recent browser engine, so your point still holds.)
Same question for ChromeOS devices.
For various reasons but mainly because I so rarely use laptops, I have a crappy laptop from ca. 2010. It's slow, with a spinning-rust hard disk and an Intel Celeron from its day; it's a miracle it even allowed up to a 4GB RAM upgrade. With a GPU that can barely manage to process a 1366x768 framebuffer needed for the built-in screen, it's an unpleasant experience all around. By all means it's the definition of crappy laptop and that held even when the thing was new.
All the same, it has no problem running Debian 11, and both the newest Chromium and Firefox can at least launch on it. It does take half a minute for the browser windows to actually appear, but it works, more or less. The per-site experience after this depends heavily on how much "cool tech" web site developers have opted to use. YouTube is practically unusable even in the tiny video window it displays and 360p videos. Hacker News is perfectly fine.
Perhaps bias on my own part, but I would argue that this case is the crappy laptop that's reasonable to optimize for. It may not be pleasant, but for large classes of web sites, it should be bearable to some extent. I'm pretty sure both the Chromebook and iPad mentioned in the article have better hardware specs than my thing, but they're both made by companies that are far too willing to drop support after a short period, leaving users in an insecure status and many of them just don't know why web sites stop working.
If not, then it is a de-facto locked-down device. It shouldn't take technical expertise to keep consumer electronics usable.
I'm not criticising your point; just nitpicking your use of “grandma” as a signifier for the kind of person who can't deal with how garbage modern computers are. It's stereotypical, and only makes sense if you know those stereotypes; that's perpetuating stereotypes, and it also makes your writing inaccessible for people not familiar with the way your culture sees old women.
Pretty much every technology invented by humanity gets better with knowledge and training. That doesn't make those technologies "locked down".
A more useful definition would be that a device is locked down when the manufacturer has taken measure to halt users from loading their own software, including their own OS.
There might be reason to claim Chromebooks aren't locked down, go flip developer mode on and off you go. As for the iPad case, Apple most definitely does not want you to run your own OS. Older iOS devices often have cracks and ports of Android to them, but that takes considerable effort to defeat Apple's locking down of the device.
The comment I replied to suggests "my grandma can't figure out how to install Firefox on a Chromebook, so that means the device is locked down". I disagree with that.
There is no magic world in which complicated technology remains forever usable by the unskilled.
Youtube crawls on anything older than Haswell due to a lack of H.264 hardware acceleration. Youtube has made a business decision to not waste bandwidth and disk space on older codecs.
Personally, I’d rather buy my grandma an iPad every 5 years for the rest of her life than try to teach her how to use a general-purpose computer, but that’s not a reasonable solution for everyone.
So I totally agree
Contrast that support with Google Chrome, its latest browser works on OS X El Capitan 10.11 from 2015: https://support.google.com/chrome/a/answer/7100626?hl=en - which is much more reasonable.
EDIT: I was wrong. mrpippy pointed out in a reply below that Mojave is still supported by the latest FF release. I was using the FF ESR release which only goes up to FF version 91. Sorry for the noise, and thanks for correcting me.
The hardware itself is supported just fine; install Linux on your 2011 Macbook and you can download the latest and greatest Firefox release. Mozilla just doesn't spend much time on operating systems that have fallen out of support. I don't expect them to keep their Windows 7 builds going for long once Microsoft ends their paid support programme.
If Apple doesn't bother publishing regular security and maintenance updates, then why should Mozilla? Users shouldn't be running operating systems that receive no or only some security patches anyway.
I appreciate that Mozilla has fewer resources than Google, but having the latest version of FireFox working only on macOS versions released within the past two years is unnecessarily restrictive in my opinion. I'm an independent software developer far more financially constrained than Mozilla who supports macOS releases going back 10 years. It's just a matter of not using the new API calls shipped with each new OS release and optionally dynamically loading the API calls that are not present on all OS versions.
EDIT: My original post was wrong. Mozilla still supports Mojave. See details above.
https://support.mozilla.org/en-US/kb/where-find-release-note...
https://www.mozilla.org/en-US/firefox/91.5.0/releasenotes/
I just assumed I downloaded the regular Firefox release, but evidently not.
During the in-situ upgrade process, I probably got hit with this installation bug (https://en.wikipedia.org/wiki/MacOS_Big_Sur#Criticism) where the installer never finishes if you have more than 20,000 folders in an obscure folder. I'll never know because I was forced to wipe the disk and perform a clean install. But before you wipe your disk, do a search for "Macintosh HD - Data" and "Macintosh HD - Data - Data", because the Big Sur installer is apparently not idempotent, so you need to delete the "Macintosh HD - Data" volume if the installer breaks halfway through the process.
You should create the USB installer before all this because the clean install may download the Big Sur image, then throw it away, and proceed to download and install Snow Leopard instead. At least that's what happened to me. But Snow Leopard not have the certificates necessary to connect the App Store. So the machine can't download the Big Sur image anymore. The only way around that is to own a second Mac to download the image and create the bootable USB drive for Big Sur, and do another clean install.
For example, the Nexus 5 phone released about 8 years ago is still selling for over $100 on eBay because it's easy to install hacking software on it that was featured in Mr. Robot.
If you have an iPhone that old that no longer receives iOS updates, there's no way to get security updates on it or install some other OS.
I think there's more desire and utility the other way around-- old general purpose laptops make pretty good Chromebooks (by using Neverware's Cloudready, no also owned by Google), but there's not much demand for turning eight old Chromebooks into general purpose computers.
I have such an old Chromebook. I bought it for about $130. It has a mediocre keyboard and an 11" lower-quality TN display. Now it doesn't get OS updates.
Current eBay price is $20.
It's a hopeful sign that OP's parents are at least catching on to the planned obsolescence pattern. That makes it easier to explain the importance of right-to-repair type regulations to a non-technical audience.
The iPad, while a great machine, can’t really be considered “general-purpose” since I can’t compile and run arbitrary code on it. For most iPad users this is a feature: it makes the thing much safer to use.
Going back to your original comment above, a general purpose computer definitely helps. But as the chromebook side of things shows, it's not sufficient.
I don't follow the reasoning here. Why does the onus lie on the web developer and not on Google or Apple?
Regressions are regressions. You don't get to make excuses if you unilaterally changed something for someone.
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.
Don't you think the customer experience is strictly more important than the developer experience?
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.
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.
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.
Optional chaining however is missing for something like 8% of users 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.
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.
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.
Because you can easily support newer JS features in older browsers with Babel? 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.
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.
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.
I reckon whenever I run roll-up on my Vue apps it creates many versions of my app which I beleive are only to automatically take care of such issues.
If I scaffold a new React App using Create React App it comes with browserslist[1] which handles setting the target browsers versions that babel will transpile to. If you never change the defaults then the production targets are: ">0.2%", "not dead", and "not op_mini all".
I was wondering if these defaults would have prevented this problem in the story from happening.
If we run this:
npx browserslist ">0.2%, not dead, not op_mini all"
and_chr 96
and_ff 95
and_uc 12.12
android 4.4.3-4.4.4
chrome 96
chrome 95
chrome 94
chrome 93
chrome 92
edge 96
firefox 95
firefox 94
ie 11
ios_saf 15.2
ios_saf 15.0-15.1
ios_saf 14.5-14.8
ios_saf 14.0-14.4
ios_saf 13.4-13.7
ios_saf 12.2-12.5
opera 82
opera 81
safari 15.1
safari 15
safari 14.1
safari 14
safari 13.1
samsung 15.0
In the post, the versions the mom was stuck with were:
- Chrome 76 (released July 30, 2019[2])
- iOS Safari 12.?? (originally released 2018, last update 2019[3])
So this brings up the question of how far back should we support? Chrome 76 and iOS 12 are only a few years old (2018-2019). According to caniuse[4], Both Chrome 76 and Safari 12.1 have a usage of 0.07% so in order to support it you would need to change the ">0.2%" to ">0.06%". If your build process is already setup to use Babel+BrowsersList then it should be an easy fix of just changing values in the array and it should come at no cost to your development experience.
1. https://github.com/browserslist/browserslist
2. https://en.wikipedia.org/wiki/Google_Chrome_version_history
One solution is to only buy hardware that's capable of running a generic Linux distro after the manufacturer abandons it.
Use boring tech, people.
You can't download updates since Apple no longer host them and there's no option (at least official) to sideload them even if you had the files.
This is an utter disrespect for the customers no one should tolerate.
If there's an iota more work involved, the analysts have no reason not to defer to analytics. Anything less than ~1% gets dropped. So there goes your ES5 build.
"Accessibility" in the screen reader sense is additional work done to support a low-usage audience, but because it has legal implications it has much more weight.
I guess it would take someone using older tech winning in court for this to be given greater consideration. But that seems unlikely because people who use older tech are not a protected class.
The article frames it as if the parents are naive here, but it seems like this is 100% right. Mom's chromebook and iPad not receiving updates is a perfect example of planned obsolescence.
To me this does not feel like planned obsolescence and feels more like a general case of "technology marches on".
The ?. operator was included in Edge, Safari, Chrome and Firefox early 2020. According to caniuse.com, only 90% of users have browsers that support it... but depending on who your audience is, it might be much less (e.g. if you target schools, or government, there might be computers locked in older OSs or browser versions... at least that's the case in my country).
If the hardware is actually, physically incapable of running later versions (AKA your Chromebook would crash and burn on boot), sure.
Any other case it's corporate greed and/or laziness.
Li-ion battery arrangements inside those devices seem to hold about 80% of their usable capacity and voltage for about six months, with average usage patterns. A year after that this drops to 50% of original capacity, or below. This is known, if a bit too generalized.
Yet those are not easily swapped out. And your CPU throttles, your WiFi throttles down with the battery, reducing usability. There is no "please change out the battery" alert for the user at any point.
The marketing for these devices makes no mention like "you've got about a year of usage for this device before it becomes slow".
In any of this there aren't any external factors to anticipate, unlike with the Javascript landscape example above. As a manufacturer you know your device usage patterns, you do collect some telemetry and some repairs data. You can make a projection.
My point is, those are being sold in full knowledge of the facts of their limited lifetime. With no mitigation strategies, with no concessions for user-serviceable battery replacement or how to buy those batteries. There is no battery shelf at the Apple store.
It isn't discussed much. There is no customer blowback to this product strategy. It could be, in bad faith argued that people are fine with buying something to replace it a year later.
My question is, to you, are you arguing this in good faith? Do you really think this is fine to have something called a "product" where it is actually a service, with a limited term and no end-user serviceability?
Is it OK to call something a "question" where I am asking you to ask yourself, and don't care to hear what the answer is, because I have already arrived at an opinion long time ago and see no reason to change it hence?
Please don't be offended by this, it isn't intended to rile you in any way.
I am only after some clarity, as I perceive your language to be confusing terms mightily and so making things seem more complicated than they end up being.
What? Taking the example of Apple (since they make their battery ratings easily accessible, but other manufacturers are similar), iphone batteries are rated to hit 80% at 500 charge cycles, and ipad/macbook batteries are rated to 1000 cycles [1]. Assuming you discharge your battery from 100% to 0% every day (which is at the upper end of average usage), iphone batteries should last ~1.5 years, and macbook batteries around 3 years.
Apple also has a pretty good battery replacement service, at least in comparison to other manufacturers. When my iphone battery wore out after ~3 years, I shipped it to Apple and paid $60, and they sent it back a few days later with a new battery. My macbook battery lasted ~4 years of heavy usage, and they did the same thing for ~$200. A user-swappable battery would definitely be easier (and cheaper), but the service they offer is good enough that it's still feasible to get a replacement and keep the device past the battery lifespan.
The example here is stupid because the laptop is perfectly capable of executing a .? operator - there is no insufficient hardware or similar things. The only reason it can't is because of artificial limitations put up by Google, likely on the risk that some other, unrelated features might fail otherwise.
I don't think it's planned obsolescence in the sense that they specifically set out to brick the device - but they are certainly accepting that such devices becoming obsolete quickly in their planning.
You cannot predict all the possible future requirements of a product, the best you can do is make a reasonable effort. In this case the vendors likely could do some kind of patch/update to support .?, but surely there are a large number of other little things that have changed or been added over the years, not just .?. So, where does that slippery slope end? How many new features, and related regression testing should be put into older devices? Does the hardware vendor have a kind of ethical responsibility to continue to update it until it just absolutely cannot be carried along any longer?
In hardware designs there are always a lot of hard trade offs made to keep the bill of materials as low as reasonably possible. As new components become available new capabilities for the devices become possible, and at some point you need to focus your primary R&D efforts on the newer stuff just for efficiency sake.
My personal experience is that very few mainstream devices are really built with some kind of planned obsolescence. Instead, devices that become unsupported and unable to get current software updates are usually just victims of the basic drivers of modern business (profit, growth, etc.). Sure there are cases where the hardware vendor WANTS devices to expire early and force users to buy new ones, but when you look at the app store revenues of Apple or Google, I don't think they're sweating hardware revenue to the point they are implementing some form of planned obsolescence. They might even prefer that older devices were more cost effective to support in order to reduce the potential for churn to the alternate platform/ecosystem.
Yes, they should, because these are the same people doing both
It is not a coincidence that "technology evolving" results in obsolescence. It is true that it is additional effort to support old devices, but it is a finite and feasible amount of effort.
Plus, old devices are hard to support in part because of decisions made in the creation of those old devices that make them hard to support. Like many other engineering things, if companies decided to get better at supporting old devices, it might be hard at first but it would get easier and easier as they got practiced and built solutions around it.
1) Chromebook is a "secure platform" => including drivers, firmware, etc. etc.
2) Supporting "security" across the browser is the first point, but additionally, there's security required across the whole hardware footprint
3) "when it's too expensive to keep track of / backport security fixes" or "the latest kernel won't build anymore" => "Sorry, your device is obsolete."
4) The rise of evergreen browsers (specifically chrome-monopoly) is pushing the definition of what is worth updating / monkey-patching / transpiling.
There's "ways" to update "stuff" but at that point you're basically using it as a linux device (subject to _linux's_ security and update stance) instead of a chromeos device.
If ChromeOS moved to Fuchsia I don't think we'd see stuck stale installs like this very much.
The first gen iPad Air mentioned in the article was released over 8 years ago and was receiving security updates through most of last year.
My mom was using a plastic MacBook from 2010 without major issues up until late 2020.
That said, I do think Apple should give you the option to completely unlock unsupported devices so that you could install Linux or something.
I think it is for OS updates, but not for something that should clearly be user-updatable like a browser.
It's not like you can even install Firefox to get around it.
There are plenty of browser alternatives still compatible with iOS12 and 8-year old iPad hardware.
I have no idea how this myth has become so entrenched on HN.
There's a setting to make it default in "Settings > Default display settings" but I agree it should be the default automatically. I wonder why it isn't?
+90% of users can use it, which is probably not high enough IMO.
My rule of thumb has been that if it's an app core to someone's job or life management, it needs to be functional for hardware/software going back 5-7 years, less if it's just entertainment or something.
Anything older than 2020 doesn't support optional chaining. Which makes sense, given it's apparently an ES2020 feature.
This is not to say that the stats should be disregarded; just that like any other data source, it should be treated as one view of (some of) the data, with its own shortcomings.
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?
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 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.
And building with the right HTML foundation, means you have a fallback for any breaking javascript, that will cover even more edge cases.
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 don't need to use every js feature on every website.
I would go so far as to say it's irresponsible.
I would also like to display a friendly error message to the user if I resource fails to load because of a 404 or because of network issues. This is the only solution I found: https://stackoverflow.com/a/64243346/247696
Of course, I don't think this is the whole solution. But it's something we can do without waiting for browsers to get updated.
1. the error message will not be helpful or actionable, instead of the website not working it'll be telling the user to get lost
2. google can break it at any moment with no notice (others as well, but google seems much more aggressive in their "deprecation"), they already removed (then reverted because of just how much it broke) cross-origin alerts
Love this. I have an iPhone SE 2020, and if I had my druthers I would downgrade to an even older, smaller phone, but a lot of modern apps are just clearly meant for larger screens, and even its 4.7" screen -- SotA in 2017 -- struggles to display content properly.
I'd switch to a dumb phone entirely, but alas, I'm dependent on google maps, guthooks (a hiking app), and especially ride sharing and bike sharing apps. It's a bind.
What is their incentive to do so? Because their incentive to not do so (by taking advantage of new features) is easier-to-write and easier-to-maintain sites. Losing X% of users (where those users are using old browsers) may be worth avoiding the risk of having your site crash badly when a dependency doesn't materialize (because without optional chaining you're exhaustively checking all those could-be-undefineds by hand).
... all of that having been said: for my money, the best solution is to support both by avoiding "bare-metal JavaScript" like the plague. Use TypeScript and set your compilation target to an old ecmascript version. Of course, then your site is larger because of polyfill for features a modern browser would understand natively... Everything is trade-offs.
The issues are probably rare enough though that there is little motivation to actually do this.
No! This is 100% Google/Apple's fault for planned obsolescence. They should have an option to allow the browsers to update to the latest even if the device is unsupported. You can't expect every website on the internet to test on every old version of every browser that any old device might be stuck on. Where would it stop? Meanwhile, your mom's old browsers are missing important security updates!
No, you don't have to. All you have to do is not use modern features without transpilation and expect them to work for everyone. babel + browserlist with sane defaults would have prevented the issue described in the post.
You could also install extensions like stylish on Chrome and fix it therein. You could try blocking the CSS file from loading. [0]
Sure, we can prioritize shitting on the people who made the site, or Apple, or Google, but then your mom continues to have this issue. Shouldn't fixing that be the first priority, even if it involves some hacks?
iOS devices limit browsers to only using the Safari engine so any installed browsers will have the same limitation.
> You could also install extensions like stylish on Chrome and fix it therein. You could try blocking the CSS file from loading. [0]
The chaining operator is a JavaScript enhancement. Sure, you could block the JavaScript but considering the site doesn't work when the JavaScript fails I don't think blocking JavaScript will fix the site.
An extension, like https://chrome.google.com/webstore/detail/resource-override/..., that is similar to the dev tools local overrides might let you fork the site's JS files. But that isn't a maintainable approach.
I code because I enjoy coding. I'm going to code in whatever way makes me happiest. I don't see any obligation to change what I'm doing in order to make things I write more accessible. The default assumption is that nobody ever sees my software at all. If I publish then it's all upside.
If you don't like microtonal jazz don't listen to microtonal jazz, if I'm classically trained that doesn't mean I have to play stuff that's accessible to you.
This is of course not what happened. Stories like this make me think that this is what should have happend, tho.
This is clearly something google should fix by unbundling chrome from the hardware (and it looks like they are going to do so). I agree that this is also just a sloppy job by the website maintainer but I don't expect much from them and I expect a great deal more from apple / google, if only because I give apple / google a great deal more money.
Turns out I'd forgotten to test the site on pre-Edge / IE browsers, which apparently come with very old versions on gov't computers. Maybe that's not a problem anymore, because of the Edge update? Honestly don't know... haven't gotten those emails in a while.
I'm barely starting to use CSS vars now.
Is there a solution tho, instead of sticking to absolute no new browser features when it's not 100%? What if the browser pulls always compatible bytecode from server instead of pulling javascript text code?
Such old browsers probably have known security vulnerabilities.
Maybe find a new OS? Seems sad that old devices can't keep working.
The "distribution" assets of many packages target ES5 or ES6, but every now and then I run into issues introduced by packages that skip transpiling completely.
This often results in problems when using popular "zero config" build packages, as they commonly skip transpiling dependencies in the node-modules directory by default.
If you can’t bother to write the if statement that guarantees backward compatibility and follows a defined standard in use for almost 20 years, you are a horrid engineer IMO.
This is why there’s a general trend toward all things becoming complicated, brittle, and shitty.
If you're not using a compiler, you should definitely not use the latest and greatest features, unless you are well aware that you will not be supporting older browsers.
And in this case you can simply do an if statement with (first && first.second && first.second.third)
My point being, writing one long line is how the language inherently works. Use that instead of the new feature that only ships in new browsers. I’d still be upset if one of my teammates added an entire bundling system so they can simply write fewer lines for such simple menial aspects of the code. Forest for the trees.
> But what about the iPad? I discovered that my Mom’s iPad was a 1st generation iPad Air.
> “But what was the culprit in the website,” you ask? After opening the developer tools on the Chromebook and looking at the console, I discovered the website authors were shipping JavaScript that used the optional chaining operator (?.), an unsupported syntax in older browsers that caused the entire website to fail.
[...]
> This only reconfirmed my parents’ belief that device makers deliberately make things go out of date so that you have to go buy new hardware every couple of years.
> I wanted to try and explain to my Mom that, while true for many native applications, browsers shouldn’t go out of date so easily because of hardware. “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. 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 mean, it's been supported since 2020 in both Firefox and Chrome.
I can see a good argument for ensuring that websites will run with no javascript whatsoever as an accessibility feature. I mean, I think at least that plain text is easier to handle for screen readers most of the time. But I don't see any obligation to support 2 year old browsers, what other updates is a 2 year old browser missing? Seems insecure.
Should the 9 year old iPad air still be supported with new browser versions? Maybe. 9 years seems beyond the norm. It would be nice if devices were required to be opened up after they lapsed into an unsupported status.
> Turns out, you can’t. From what I could gather, the version of Chrome was tied to ChromeOS which couldn’t be updated because of the hardware. No new ChromeOS meant no new Chrome which meant stuck at version 76.
There might be a business rationale to bend to reality, but no obligation. In this case it appears to be a volunteering organization, so I guess they might not be as motivated to solve niche problems.
There are 2 issues
1 some hardware is locked, you can run what you want on it, it must be approved. In the TFA is is cearly shown that it was impossible to run a new browser version.
2 since is just software as you said, I assume the developers could install some software and have the JS transpiled to a more compatible version or popup a message if the user does not use latest Chrome or Safari and send them away.
Maybe search engine should check this websites in an older browser engine and remove SEO points, also try the website with JS off and if you get nothing, no text that you need JS also remove points.
My comment was about "is just software" so should the software guys do the transpilation step rather then forcing users to throw their devices? (since again "IS JUST SFOFTWARE)
What I am saying is if you put a webpage that targets everyone (not a limited subset like say our internal team that all run latest Apple shit) then since "is is just software" it is easier to transpile the code then ask the world to throw away their devices and buy new stuff.
I am sure you are not OK if all websites will use a new JS feature in the exact day it is released and the updates did not had time to propagate to all users, so the question is how many percent of an users should is small enough so a average webdev can stop using the transpiler and break stuff?
Especially in 'enterprisey' networks there are devices that /still/ require SSL, Java applets, Flash (urghh!), SSH v1 support, or features of (X)HTML, CSS, and Javascript that have been removed or modified. Most of that hardware would be expensive and disruptive to replace.
I still maintain a version of 32-bit Netscape Navigator for accessing some key infra-structure devices that continue to work perfectly and are on isolated private networks.
Some examples: Cabinet Distribution Units (CDUs - network-controlled power switches), network KVM (Keyboard-Video-Mouse over Ethernet), Ethernet switches
When I think Motorola I think enterprise, so, another data point.
Why shouldn't it? It's a perfectly usable device. Why should it have to go to landfill?
A decade seems like a long time for first-party support but as I said in the sentence immediately after the one you quoted, a device should be required to be opened up when it is no longer supported.
[0] https://packages.debian.org/search?keywords=firefox-esr&sear...
[1] de.m.wikipedia.org/wiki/Versionsgeschichte_von_Mozilla_Firefox (the English page is useless for historical release information)