> 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.
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.
This has become enough of a problem that Google is working on decoupling the "system" version of Chrome (used for login window, settings, etc) from the browser that users interact with directly on Chrome OS, making it so you can keep using the device safely after its EOL date (which is 6 or 8 years now I think).
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).
Reminds me of how we bought a Chromebook in 2016, and specifically got a version that was "planned" to be allowed to run Android apps (which was a new thing at the time).
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.
I think the Chromebooks Android support is more like the virtual devices that Android studio creates then actual native installs.
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
Most android apps are java. They should be built for jvms. The fact that we have java jars that fail because of hardware architecture invalidates java as an idea to me.
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?
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.
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?)
> 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)
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.
> 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.
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>.
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.
Is someone using a three-year-old Android OS... using a three-year-old version of chrome? Or can an old version of Android still be using a more recent Chrome? I don't actually know how it works!
Many Androids stop receiving updates after just two years. I don't know if it affects the browser :)
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. )
It is a trade off.
How much did they really gain by using ?.
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.
We can stop transpiling to ES5 when a long enough time-window (one you're comfortable with) has elapsed since the last ES5-only browser was released and hopefully your users have upgraded. Additionally, you can check the User-agents in your access logs (or analytics) to see what fraction of your users are still on ES5 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.
We can stop transpiling to ES5 when a (window youre comfortable with) has elapsed since the last ES5-only browser was released and hopefully your users have upgraded. Additionally, you can check the User agents in your access logs (or analytics) to see what fraction od your users are still on ES5 browsers I think once you've correctly configured your CI transpiler, you wont even have to think about it, so it's a small cost, IMO.
iOS also doesn't allow the browser to be updated after the hardware has reached end-of-support. In general, Chrome OS devices have 6-8 years of support, while iOS seems to have ~7.
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.
Phones are a bit more of a commodity than laptops/desktops are, I think primarily because of the strong evolution you see in comparison over the same timeframe. A laptop from 7-8 years ago largely still is capable of running the latest software (and most of the time Operating Systems), while an 8 year old phone hardly has the performance to do either with the advancements that have been made.
You only think that because that's what we've let transpire. It's a disgrace that I can not use my iPhone or Android phone to easily create new software, only consume. They're more than powerful enough to fully replace most computer usage including software development. But no, we've let them normalize locking the OS, and hiding the file system. Its an absolute disgrace.
Hah I so strongly disagree with your Phil Xbox take. But am nodding along agreeing with a lot of your recent comments. This one especially.
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.
Locking the filesystem doesn't necessarily mean developing with them is impossible. What is preventing IDEs from working is the inability to execute unsigned binaries combined with the absence of signing binaries locally. And I agree, I too see this as an invitation to fornicate myself, a personal invitiation signed by google and Apple no less.
iPads and phones are different beasts, though. I personally have much lower expectations of my ipad, and one of those fairly low expectations is that the browser should continue working (with the implied, "and be safe to use" that requires security updates) for as long as the device doesn't physically break.
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.
As someone who still has (and uses, offline) his original iPad, I can tell you the App Store is now a barren wasteland on that device. Nobody's app runs on it anymore! So don't delete anything.
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.
I also bought a new phone for my mom just because, the latest android update was 2017 and some apps did not work any longer, so we bought a new phone. The phone was still in a pretty good shape and the battery too. She just used here phone very rarely.
> Also, Chrome OS devices explicitly support unlocking and installing alternative OSes.
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.
> Not anymore they don't. I recently bought a chromebook .. but the bootloader is locked
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?
Acer 311 but any chromebook with an Intel Gemini Lake processor has a locked bootloader and bios. Developer Mode can be enabled but the most that gets is installing crouton which is still beholden to booting Chrome OS and using it's kernel.
Oh, huh, indeed that seems to be more involved than just 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.
> iOS also doesn't allow the browser to be updated after the hardware has reached end-of-support.
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.
Apple has fooled you. Those aren't complete browsers. Those are simply UI shells around the system version of WebKit which cannot be updated or bypassed or replaced. No new web platform features will be added, no bugs fixed, and security holes are not guaranteed to be addressed.
While what you said is true, iOS 12 still received some security fixes, so the total support for the iphone 5s is 9 years and 8 for the 6. Critical bugs shouldn’t be that big of a threat (considering that even up to date phones are colanders.
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.
What happened in this article reinforces my belief that devices marketed as "general purpose" devices _must_ allow users to, in some way, run their own software on them "unrestricted" (standard sandboxing of course, mostly the same rules as App Store apps, just none of the application class rules or arbitrary API access restrictions).
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".
Not really, you can only do that for 7 days at a time, unless each device owner pays $99 yearly, and even then there's no simple and obvious way to do it.
> you can install one of the numerous alternative browsers that are available and updated for iOS 12
Those "browsers" are more like skins, they can't actually modify how websites are rendered or how JavaScript is executed. So no, the article is correct, you can't install actual browsers from the App Store.
Fun fact: Because of this fact, for a brief moment in history Google actually purposefully caused Google Chrome on iOS to crash when they detected that JavaScript on a site was attempting to perform a uXSS attack[1], because they couldn't actually stop the attack since that would require modifying WebKit.
All of which run WebKit under the hood and can not implement support for optional-chaining on their own as that is a JavaScript engine thing which they can't touch.
This is generally because ChromeOS isn't just an OS based on Chrome - Chrome itself is the OS, supported by how the OS portion is just a folder in the chromium/src tree[0].
Edit: looks like there's now an effort to separate them, as the readme says. see [1].
The irony here is that the best way to buy a device for Chrome is to buy a Windows laptop and install Chrome on it... Google will support it far longer than they'll support their own products.
Chrome support for Windows 7 has been extended into 2023, which is an OS released in 2009.
> 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.
It’s odd that today Google (in this case) but others as well, can get away with more than Microsoft did in the late ‘90s but the DoJ doesn’t make a peep.
Well, in this case they don't get away with anything of the same nature.
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.
It's a fairly meaningful distinction in the context of grandparent comment which talks about DOJ not pursuing Google/Apple for this specific fault, since the Microsoft case was one about abusing their monopoly position.
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.
Much of the case rested on how tightly the browser was woven into Windows —that MS was preventing competition in the browser space (via the strong arming tactics) but the “bad thing” they did was the tight browser integration.
> the “bad thing” they did was the tight browser integration.
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.
That was only an issue because it was used as a deliberate tactic to prevent Netscape Navigator from competing with Internet Explorer. Which was challenged because of Microsoft's monopoly position.
Tight browser integration was not illegal in and of itself.
ChromeOS also appears heavily at school where kids are now growing up being forced to use it. (Not going for a "think of the children" thing, more like imprinting)
A similar thing happened with the Let's Encrypt root certificate expiration a couple months back. Because trusted certificates can't be updated on EOL devices, otherwise perfectly functional websites and apps just stopped working overnight. What a waste.
ChromeOS is addressing this with LaCros - a separately installable version of Chrome that runs on top of ChromeOS. The goal being exactly to be able to update Chrome when the underlying ChromeOS can't be updated.
Same thing with Android - while you can certainly still upgrade your apps, your OS won't, as most manufacturers want you to buy a new phone after a certain period of time (2 years, usually). I really hope to see an EU regulation to put an end to this consumer-hostile behavior some day.
To me, that depends on the length of support for ChromeOS on a piece of hardware. If it’s say 10 years in total and 7 years from date of last sale-as-new, I’m okay with it.
The really important part imo: We need labelling of products that way. Nowadays "everything" is connected to the internet and I as a consumer have no chance to predict how long I will be able to use a product. The vendor has to give a guarantee and put it in a box (and probably get an insurance so they can't simply close one company and continue under a new name every other week ...)
While I’d like ten, eight is probably good enough for me. I just bought a new Chromebook for $92 all-in (low-end, obviously). At around $1/mo for the length of OS support, that seems fair enough to me. Even $4-5/mo for a nice one would be OK for most people.
Thanks for the pointer to that, which prompted me to go look in Settings:About Chrome OS:Additional Details where retail Chromebooks list their end of automatic updates date. For my device, it's June 2026, so a little under $2/mo for the utility is still well worth it and hard to complain about on a value-for-money basis, but half as much as I thought I was buying, so I agree with a sibling post that that information should be much more readily available to consumers prior to purchase.
The dev made a mistake by having a Javascript error totally break the site. Websites should still be functional (even if a bit inconvenient) without Javascript.
> Websites should still be functional (even if a bit inconvenient) without Javascript.
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.
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)
It's not extra work. The site in question was for making a reservation. A basic HTML for would have satisfied that requirement and worked completely without javascript. Any additional features could have been built with javascript and the site would be no different to users on modern browsers as the current build, but it would still work on the author's mom's browser.
Progressive enhancement isn't about building sites completely without JS. It's about building resilient sites that work on edge cases like this.
It is absolutely extra work. You have to test every mode of operation. So to support those with JS disabled (about 1.3% of users according to some quick searches) you have to test with JS disabled. Then you have to test again to make sure your JS workflow is stable.
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.
No. Stop defending bad practice. its conceivable there are new functions that are not backwards compatible. At some point you need to be able to update your browser. its the fact she is locked out from doing that is what puts her in the pickle. Google and Apple made sure she can't get a new browser so that she would purchase a new device. period.
Arguing that websites should support the least common denominator of functionality and then progressively enhance for modern functionality is not simultaneously defending corporations' planned obsolescence. Both problems can be solved independently.
A friend lent me a 2017 iPad that she's no longer using. I wanted to download Spotify, but couldn't, because I needed a newer version of iOS.
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.
It gets worse. Even if you could download an old version of Firefox and Chrome to your iOS device, they'd have the same problem as Safari, because Apple bans third party browser engines. Firefox and Chrome for iOS are essentially wrappers on a Safari core.
Yes, I forgot about this. It does make it worse! I've commented this elsewhere, too: the incompatibility problem is still anti-user, it affected me when trying to download other types of apps that have nothing to do with browsers.
> 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.)
You're right: I forgot that ultimately it's Safari anyway. But this happened to me with several other apps, too, such as Garage Band, some synthesizer apps, even a guitar tuner wouldn't work on a completely capable device that's now basically useless!
It's a 2nd generation iPad Pro. The Internet says I should be able to upgrade to iPadOS 15.2, but the device won't give me any updates and it's running iOS 10.
Maybe the update function in iOS 10 has stopped working for some reason? You could try updating it with iTunes (or via Finder on newer macOS versions).
This seems like a pretty poor implementation on Apple's app store's handling of out of date app installation. I believe there is a workaround where you can use an online version of the app store to first trigger an app download to your iphone, which would then transition it into that "re-download from cloud" state which lets you get an older version.
I've successfully installed an ancient version of iTunes for Windows to associate apps to my account and that method worked for a while, until Youtube pulled support for the version of the Youtube app that the old iPad I got used last. The web player is dog slow, so the iPad is pretty much a fancy glass eBook reader now.
There's actually another (terribly convoluted) way to "purchase" apps, with another computer and an old version of iTunes[0]. This version of iTunes supports searching for and purchasing apps, so it can be used to get the license for apps. I used it to get Spotify working on my 2012 iPad, installing iTunes on Linux with WINE.
Which reminds me to ask - is anyone making a custom OS for iDevices yet? Something like Graphene for iOS? I know about Asahi Linux, but that's for M1 laptops, AFAIK. (Because the "right" solution here is clearly to ditch the OS and install something Linux-y, and then whatever software you need, including recent Chrome).
The first line of the article is misleading. It's not just about a "crappy laptop", it's about locked-down devices (ChromeOS, iPad) that have had their support terms expire. I suppose that is crappy, but it's not quite the image I'd conjure myself.
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.
I have a late 2006 Core 2 Duo Macbook pro with 4GB ram and a 128GB SATA SSD running Mint 20. Same deal, everything but video runs fine.
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.
Chrome OS devices are not locked down in the slightest. You can run any browser you want in Chrome OS via the Play Store or as a Linux app. Furthermore, every Chrome OS device can be unlocked to run any OS you want. You can install Chromium OS, Linux, or even Windows if you like. They are not at all like iPads.
Sure she could, given appropriate instructions and a reason to care about it. Why not? She's a capable person. Also, she could buy a secondhand one that's already been unlocked, or sell hers to someone who can still make use of it by unlocking it, or whatever. The point is, the end of support does not render the hardware useless and/or a security disaster waiting to happen.
Capable, sure, but would she actually give a shit? I know none of my family does. I'd lose them after I uttered the first sentence of the technical explanation.
"Easy to use" and "not locked down" are two different and potentially competing goals. "Locked down" makes it impossible for even the most technical person to do something without knowledge of some sort of secret key. Chromebooks are not that; someone with the technical knowledge can do almost anything with them. They even go out of their way to choose peripherals that are well-supported by mainline Linux. "Easy to use", on the other hand, is usually implemented by removing the surface of possibilities. Having a command prompt pointed at an apt repository that lets you install the browser of your choosing is quite hard to use compared to just popping up a preselected browser when you press the power switch.
Pretty much every technology invented by humanity gets better with knowledge and training. That doesn't make those technologies "locked down".
That's a definition of "locked down" I can't get behind. _Impossible_ for even the most technical person? That would mean basically no device in all of history could be considered 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.
I think we're talking past each other. You have quoted half of a sentence I wrote without reading the other half, for example.
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.
Mine could. (I know the point you're trying to make, but “grandma” and “person who wants to see computers as tools, rather than puzzles” are not synonymous.)
Being able to use a tool isn't the same as being able to transform a tool into a totally different type of tool. Someone shouldn't have to learn how to install and use linux just to use their 2014 laptop to browse the internet.
I understand that; I know many other people who wouldn't be able to deal with this. Just… my grandmother isn't one of them. (Sure, she isn't a “computer person” and doesn't really like the things, so she'd have trouble working it out on her own, but she's able to follow instructions and deal with the computer deviating slightly from how the instructions say it will react.)
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.
Of course it should take technical expertise to keep devices usable. I don't know why people expect manufacturers to support devices for any and all use cases. No manufacturer is going to do that because that's expensive and unprofitable. Sure the community can continue to support devices but that just pushes the expertise onto you.
There is no magic world in which complicated technology remains forever usable by the unskilled.
Not sure about the chromebook, but that iPad is probably ~8 years old. I have a laptop that’s older than that, and I’d be pretty annoyed if the internet was irrevocably broken on it. This is an interesting argument for general-purpose computers over specialized, user-friendly ones (iOS, chromeOS).
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.
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.
There's a scary warning that you are doing something unsupported and if you press the wrong key, whatever is installed will be wiped and the default OS restored.
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.
But they won't because it's much more profitable if the user buys new hardware instead, nevermind whether the existing device is fundamentally capable of serving their needs, and nevermind the accumulating e-waste.
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.
This reminds me of a story from 2013. We were developing a web app and kept hearing about a friend of our boss who was having trouble with it in Australia. We assumed it was ping to our small server in Europe. Turns out he was using a very old version of Firefox, but that was the latest one available on his MacBook. Yes, his PowerPC MacBook.
Mozilla cuts off support for macOS releases much too early in my opinion. I'm running macOS 10.14 Mojave which was released in 2018 and it only supports FireFox 91. The latest version of FireFox is 96. I can't find a definitive statement what minimum version of macOS is needed by the latest Firefox, but what they list on https://www.mozilla.org/en-US/firefox/96.0/system-requiremen... is incorrect and/or out of date: macOS 10.12.
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.
Just a quick digression: If you decide to upgrade from Mojave to Big Sur, make sure you create a bootable USB installer first, and back up anything that you don't want to lose. I decided to upgrade because Mojave is no longer getting security updates, but ran into some issues took 2 entire days to resolve.
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.
On the other hand, Mozilla has fewer resources to spend on maintaining backwards compatibility. Mojave is pretty old as far as continuously updated operating systems are concerned, and the devices that didn't get the Mojave update are all over 10 years old at this point.
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.
Upgrading or switching the OS is a major undertaking.
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.
I’m also running Mojave, and am still getting Firefox updates. Not sure why you aren’t, and I think their stated support back to 10.12 is still accurate.
I don't understand why you consider the iPad to not be a general-purpose computer. Do you mean an iPad without a web browser? Is iOS really good at keeping ancient apps working on ancient devices?
By “general-purpose computer” I mean something that is programmable/configurable down to a low level. If I have a Linux or macOS laptop it would be pretty hard for the manufacturer to stop me from installing an up-to-date browser; worst-case I can compile Firefox from source. I bet it would work even on a 20-year-old computer.
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.
I would put an iPad or smartphone somewhere between a general purpose computer and a fixed-function device. I think that has actually been the core of their success. They have the features of general purpose devices that most people care about without the hassle of having to maintain a device (which I enjoy, but my parents certainly do not)
I suppose. If I buy a new Macbook I can immediately compile and run whatever software I like on it. I don't usually think of it as "rooted": in my mind, root access is the norm when you buy a general-purpose computer.
This was kinda what I was trying to suss out. I've gradually started thinking of Macbooks as "not general-purpose." For example, I can no longer get gdb working on them. At least it's imposed enough barriers that I haven't been incentivized to spend a lot of effort getting over.
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 think Chromebooks are general-purpose devices either. You certainly can't install arbitrary code on them. A Chromebook is closer to an iPad-with-a-keyboard than it is to a general-purpose laptop running Linux (or even Windows).
I don't particularly like Chromebooks, but this doesn't seem like a fair characterization. You can put Chromebooks in Developer Mode without needing anyone's permission. You can install Linux on them. You can run Linux programs on them. (Though I don't know for sure that you can run gdb on them.)
> 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?
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.
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.
> 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. 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.
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?
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.
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.
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.
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.
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.
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 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.
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.
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.
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.
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.
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.
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.
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.
For all the hate Webpack and Babeljs gets, couldn't this have been prevented if the website was using a transpiler to create a vendor version that would work with old browsers?
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"
From that list it looks like the oldest Chrome supported is 92 and oldest supported Safari is 12.2-12.5
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 using Create React app this probably should have at least worked in iOS Safari.
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.
That list includes IE 11, which doesn't support (basically any) ES6+. So Chrome 76 would have worked because it would be being served JavaScript that IE 11 could understand.
While subjectively more simple, you don't need to rely on browserlist to get optional chaining transpilation in babeljs. You also don't need something as complicated as create-react-app to use babeljs.
Yeah the recent "omg webpack is so lame, just use es modules", etc puts us back to having to worry about browser differences, complaining about them not updating, etc.
I am old enough to remember the manta of "backwards compatibility" from the 1980's. It was the advent of the web that eventually led to "release early / release often" and damn any concern about breaking old stuff. If it was not for Linus enforcing "user space" backwards compatibility in the kernel, Linux systems would have (un)planned obsolescence at the kernel level.
Then why should Javascript evolve, if no one is going to use those features because of backwards compatibility?" Also take note that even Linux dropped support for i386 around 2012.
There is probably some happy medium between backwards compatibility and deprecating old behavior. JS programmers are a little too ADHD for me and create a lot of broken crap. Linux dropping support for an old machine is not the same as changing the kernel API -- my old programs that ran on an i386 will still run on a more modern machine (perhaps recompiled).
There's a reason I keep my websh-t translated by Babel so that it can be used by people with iOS 9. Those people exist, and iPad 4s are built so well that they are damn hard to kill. I'd reconsider if there was a month with no visits from Safari 9 at all.
We developers are responsible for preventing that kind of obsolescence, and ultimately have the power to have a sizeable impact on bigger issues like climate change, pollution or even people dying in mines.
> They should be making their website’s code more accessible to legacy devices.
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.
> 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.
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.
Is it specifically planned obsolescence, or just case of technology evolving? Do you think Apple or Google, when making the decisions on browser upgrade-ability, anticipated javascript changes that would break common sites and force users to buy new hardware?
To me this does not feel like planned obsolescence and feels more like a general case of "technology marches on".
"Technology marches on" would be if at some point, 4K became the dominant video resolution on the web and therefore, the laptop wouldn't be powerful enough to use most of YouTube.
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.
Having been involved in the design and specifications of a number of hardware products over the years, my experience has been different.
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.
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.
> 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.
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.
Not even. JS developers should know to transpile their code to support users that for whatever reasons (from a long list) cannot run the latest JS version... or stick to truly standard things.
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).
It is lazy, indeed, but the whole ecosystem enables it. You install some yarn based framework installer, create a project, and before you know it, it sets something like "browser-support" at 95%. That number is estimated from dubious sources, and quickly eliminates older versions, and every update discards more versions.
what I do it's generé a bundle for modern browsers, and another for IE11 (and by extension ancient versions of Firefox and Chrome) with the necessary polyfills
> Do you think Apple or Google, when making the decisions on browser upgrade-ability, anticipated javascript changes that would break common sites and force users to buy new hardware
Yes, they should, because these are the same people doing both
"Is it specifically planned obsolescence, or just case of technology evolving? "
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.
Unless you’re going to continue supporting updated software on existing devices until the end of time, there will always be a place on the time and feasibility curve where you’ll have to draw the line. So while that is indeed a plan, or becomes a plan as a device ages and practical realities begin to assert themselves, attributing it to a sort of corporate greed or malice seems reductive.
In the case of software updates it _is_ planned obsolescence. However, whether it is planned out of malice or out of cost (I imagine it costs some amount of money to continue to support old hardware) is up in the air.
Having predefined end-of-life date on a device is absolutely planned obsolescence in a literal sense; it is both planned and it makes the device obsolete and they definitely knew it would make the device obsolete when making the decision, doubly so in ipads case where user has no options to do anything about it (on chromebooks at least you could in theory install different OS afaik?).
I got bit by this obsolescence. My understanding of the gist of 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.
At the scale of a large company, nothing is specifically anything. There is continual random noise generation, that is then filtered through incentives for what sticks. In fact, one of the core mechanics of a corporation is diffusing explicit motivations such that no individual can be specifically blamed. However when talking about the overall emergent behavior, it still makes sense to talk in terms of explicit motivations.
While unavoidable for some web programs (but if your program is so complex, why aren't you compiling for the native OS ?), this sounds like the failure of the website to gracefully downgrade to work without JavaScript ?
All iOS "browsers" are mere re-skins of the native Webkit browser control. When you install "Firefox" or "Chrome" on an old iPad, you're just getting the built-in Webkit with a different UI. That's fine if you care about bookmark synchronization or where the tabs are located on the screen, but it won't help with this problem.
This is one reason I'm very excited by Fuchsia - it should enable far longer usable lifetimes for devices with the kernel and drivers being updatable separately.
If ChromeOS moved to Fuchsia I don't think we'd see stuck stale installs like this very much.
Also keep in mind the limitations and biases of the CanIUse stats themselves - last I checked, their data was from StatCounter, and so based on people who visit websites that use the StatCounter service. The country-wise sample sizes [1] make the geographic biases clear - China is pretty underrepresented for example, presumably because Chinese websites don't use StatCounter as much. There may also be other kinds of biases in the data that are not so easily visible.
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.
For end user/consumer software, 90% is nowhere near high enough. In b2b/enterprise settings you have levers to help you push that number higher through IT policy, but end users will absolutely attempt to visit your cutting edge 2022 website on the iPad 3 they've used lightly.
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.
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?
Probably to boost awareness and adoption of new technologies, with the downside of effectively boosting awareness and adoption of new technologies over other considerations, like the web backward compatibility.
> 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?
> 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)
This blog post prompted to look for ways to display a friendly error message to the user, explaining the issue and that upgrading the browser may help. This is what I found: https://stackoverflow.com/a/70671657
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
> The internet is for end users: any change made to the web platform has the potential to affect vast numbers of people, and may have a profound impact on any person’s life.
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.
> 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
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.
Do polyfill/transpiling proxy servers exist? I'm thinking along the lines of an addon for squid or similar that would leverage babel to add polyfills and js transpiling. Might require per-site rules but shouldn't something like this be possible?
I'd imagine someone could build a Chrome extension to do this as a fully client-side solution... i.e. Grab all the scripts on a site, recompile for something like an ES5 target, and then replace them with the locally compiled scripts.
The issues are probably rare enough though that there is little motivation to actually do this.
> 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.
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!
> 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.
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.
Or at least if they're going to end support for a device, give us one last update to open up the bootloader so we can make some use for the thing other than as a paperweight.
But that would just increase the number of issues reported over time. It can't scale. When should they stop supporting these devices? If their telemetry shows 1 user on an iPad from 5 years ago, does that mean they need to support it? What about 1 user on an iPad from 50 years ago? Again, where does it end? You shouldn't be running an out of date browser at all, that's a major security risk.
Support doesn't need to be perfect. An out-of-date browser should be security-OK for things that don't involve money. Maybe JS needs to get switched off. So sites should work without JS.
This seems like "IT-style" troubleshooting and fixing, and even then it seems half-hearted. Can't you install other browsers on iPad?
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?
> This seems like "IT-style" troubleshooting and fixing, and even then it seems half-hearted. Can't you install other browsers on iPad?
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.
I think in the context give this is a fair point, but a counterpoint:
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.
When CoffeeScript came out, i thought the course of action was obvious: Never update the JavaScript language again, and update CoffeeScript and similar languages. Just for the sake that javascript will have to be backward-compatible for ever it seems such a bad idea to change it at all, except maybe for thing that make it a better compiler target.
This is of course not what happened. Stories like this make me think that this is what should have happend, tho.
I wonder if the Chromebook has enough hdd space to make installing debian and chrome latest viable?
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.
I think one of the solutions to this is for JavaScript frameworks to evolve and be able to support both JS and no-JS. This way any user can run a website whether they're using an old browser or a modern browser where they choose to disable JavaScript
I have a first gen iPad. Due to lack of software updates or the option to run another OS, I am using it as a clock. It’s a real shame. I’d love to be able to use it for something else.
Would installing chrome, firefox or some other browser through google play work here? It'd be a hack, having a special mobile browser for just that site, but still
ha, this reminds me of building a site that was used by gov't types (FDA, NIH, CDC) and I kept getting questions about why the site didn't work.
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.
Could you install a different browser on the ipad, like firefox? Is there anything preventing the latest version of firefox from installing on an old ipad?
> my Mom had trouble volunteering and participating in her local community because somebody shipped the optional chaining operator in their production JavaScript.
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?
I see this issue happen from time to time when including dependencies that are not transpiled.
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.
I’ve seen the transition occur in my company where DX is trumping backwards compatibility, “simplicity”, and inter team cohesion.
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.
Hopefully nobody is writing if statements in code to handle backwards compatibility. That would be terribly unmaintainable. This should be handled at the compiler level. In javascript world, it is fairly simple to use Webpack or the like to target whatever browser versions you wish to support.
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.
That’s literally how all polyfills work. They first check if the thing is there, and if not then implement it.
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.
> No new ChromeOS meant no new Chrome which meant stuck at version 76.
> 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.
> So I looked at the version of Chrome on my parent’s computer. Version 76! I knew we were at ninety-something in 2022, so I figured that was the culprit. “I’ll just update Chrome,” I thought.
> 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.
It falls on Google and the website developers. It's up to Google to allow people to update their software. It's up to the website developers to recognize that the reality doesn't always match the ideal and to develop for the reality.
I disagree, Google and Apple are the ones that have locked these devices down. They have the keys and the technical abilities -- they have an obligation to keep them up to date or unlock them.
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.
How about when the updated browser removes functionality that servers require?
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
>it is software. It can be updated over the internet. People should run up to date browsers.
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.
Not Google, all search engine.
And let's not forget that others too lock their devices so you can't install a different browser (Apple too), you should be able to read Wikpedia even if your device is 10 years old,
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)
There's no obligation for websites to support old browsers. NB: this appears to be some volunteering platform. It is probably maintained by volunteers. These volunteers should not have to step up and fill in for incompetence on the part of two of the most profitable companies in human history.
I understand, I am not obligated that my blog work on Safari, I could make it Firefox and Linux only. I also understand that Google and Apple are rich and are always chasing more profits and I don't defend this evil giants. I also understand that are exceptions like you are not building a simple webpage but a very complex image/video/code/graph editor or video game and you need a very specific feature.
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?
I mostly object to the article which seems to be pretty explicitly pointing the finger at the web developer, for using 2 year old, standard features of their language. There's a problem between the user and the device manufacturer here.
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.
It doesn't need to. The website developer chose to use new language features that older devices aren't likely to support. If your website needs users to upgrade their OS or browser to use it, then you should be comfortable with some people not being able to use it.
That's not quite correct. That is the version in the most recent point release of Bullseye (11.2). But the version currently in bullseye-security, uploaded on Dec 19th, is ESR 91.4.0. (stable-sec: 91.4.1esr-1~deb11u1) That's from the upstream release dated Dec 7th(/16th?) which is the current upstream ESR release.
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.