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.
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
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.
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
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.
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...
Chrome support for Windows 7 has been extended into 2023, which is an OS released in 2009.
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.
Google'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...
https://www.slashgear.com/chrome-os-to-replace-chrome-with-l...
"Due to global electronic components shortage , Pinebook Pro currently out of stock until further notice."
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.
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%20lifespanJust 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.