You could not watch Netflix on Linux until Chrome came along.

You also didn't have very good security from browser exploits until Chrome.

Chrome also made the web significantly faster to use.

Chrome was critical in unblocking the use of Linux on desktop.

I've been using exclusively Linux on the desktop for almost 10 years now. If there was an unblocker, it was wine/Proton, or for laptops, NetworkManager (I remember having a bit of difficulty configuring wpa_supplicant for my university in 2008). I don't even have Chrome/Chromium. Linux on the desktop is enough of a niche/bubble still that it wouldn't surprise me if a large number of other users don't have Chrome either (e.g. I don't use or care about services with DRM, and have it disabled in my browser). Honestly besides flexbox and TLS updates I'm not sure I know of anything useful that's been added to browsers in the last 20 years.

+1 for Wine, I didn’t bother with Linux until Wine showed up.

Uh, Wine showed up in June of 1993[1], a full month before the first official release of Windows NT. Not necessarily in a usable form, mind you, but even now the usability is heavily dependent on what specific software you are trying to emulate.

[1] https://gitlab.winehq.org/wine/wine/-/commit/2c25c3e9442c69b...

"Honestly besides flexbox and TLS updates I'm not sure I know of anything useful that's been added to browsers in the last 20 years."

Wasm and webgl/webGPU are really useful for anything performance related.

Easily over 99% of what I use a browser for are essentially static pages, so wasm and especially webgpu strike me as extremely niche. Like it's cute that you can run quake in a browser, but I can also just open my start menu and launch quake. For actual web usage (looking up information, shopping, paying my bills, bank transfers, stock trades, etc.), simple, static html is the high performance approach.

Google maps or other map applications are a pretty mainstream feature.

In a browser/on the desktop? I would think everyone would use a dedicated application, probably on their phone. For Linux users in particular, I would be unsurprised if they use OsmAnd. Maps also shouldn't require webgpu or wasm. e.g. XForms made something like a scrollable map application trivial to develop years before wasm was a thing[0]. That shows what could have been a browser improvement if W3C standards were still relevant. Google maps of course predates those things by over a decade.

[0] https://www.youtube.com/watch?v=2yYY7GJAbOo

If I want to use google maps, or find a new home - I am not browsing maps with my phone. I use a big screen.

With the browser.

And most real estate sites also do have a map for example.

That still sounds relatively niche/doesn't really disagree with my statement that easily over 99% of web usage is not something like that. How often are you finding a new home? Map widgets also shouldn't really be a performance concern; they were doable 15-20 years ago (i.e. with much weaker hardware and no webasm/webgpu).

"How often are you finding a new home?"

Too often.

" Map widgets also shouldn't really be a performance concern"

Have you ever build one?

I hate those stuttering ones build by suckers and enjoy those that just run smooth GPU accelerated.

Also I frequently encounter maps on various sites.

The tracking service for my package. The shop showing me the nearest stores. A map with points of niche interest ..

I haven't built a map app and basically never touch frontend stuff, so I vibe-coded one in 20 minutes here[0] following the approach of the video I linked earlier. It's done inside of an SVG to make it so you could add map markers as another layer (and I added a dot to demo). The map marker here doesn't stay in the correct spot after a zoom change, and I didn't bother to do touch events, but that's not really the point and I don't see much purpose in spending more time. The point is smooth panning works just fine with 150 lines of simple javascript. Probably could be done with less if I were more familiar with browsers.

You can sometimes see a flash if you pan quickly and a new tile is loading in, but the embedded Google Maps on Zillow has a (much more obvious/longer) visible delay for new tiles loading in too. And actually the full, real google maps has tons of stuttering/tearing on my computer when panning, so mine seems to perform better on my computer (though to be fair theirs takes more of the screen. Mine seems to do fine when upping the page zoom level to make it bigger though). The big difference though is my (frontend portion of the) widget can be built during a lunch break, and it's easy enough to see what's going on that a high school student could figure it out with view-source.

Note that for real world use cases, it'd probably also make sense to restrict the range that the user is allowed to zoom and pan around anyway (e.g. Zillow or your delivery tracker don't need to let you scroll a world map to look at a neighborhood/get context). For something like a delivery tracker, you might not be allowed to move the map at all, in which case you're pretty much dealing with a static image where you maybe reposition a marker every minute or so. This does not require wasm or webgpu, and it's a poor use of engineering resources to add that kind of complexity.

[0] https://ndriscoll.github.io/map.html

SVG indeed also has come a long way and also with just using images in the browser you can solve it quite performant, that is right. I have done both (no map service, but having lots of images on the screen). But WebGL is still leagues ahead. And that shows on old smartphones for example. And I regret not having made the switch earlier as more performance gives much more possibilities, than being restricted to what the DOM offers.

And they've been working quite well with not all that much in ways of improvement for years, if not decades. What's the last huge improvement in maps thats been noticeable to users in the last 5 years?

My google maps experience rather degrades with enshittification, but I do remember the great improvement with webgl (5+ years ago).

Yeah - I think the big problems are solved, and then you start moving into more and more niche cases. I really love being able to flash firmware on ESP32 devices with webserial!

The use of USB authentication devices (FIDO2) is also interesting.

"Chrome was critical in unblocking the use of Linux on desktop."

Sure, but it was about more people using the internet in general.

The very small minority using linux desktop (hello, I am among them) could and did use the internet before chrome.

And from a technical point of view, I do love chrome dev tools. But that is besides the point.

Isn't Android Linux based? The development of chrome on desktop Linux have any benefits for mobile Linux?

The other way around.

"development of chrome on desktop Linux have any benefits for mobile Linux?"

Android is the big market, that gets prime support.

Otherwise android and linux desktop just share the kernel (and not even the same one).

So the developement of chrome on android probably makes it a bit easier to target linux desktop, but not much.

(I still don't have WebGPU on my linux desktop but since quite a while on my old android phone)

Dolphin Browser was the go-to in the late 2000s for Android.

Al Capone did a lot of good on his neighborhood...

Chrome didn’t murder anyone

Neither did Al Capone

Now that’s a mic drop moment

This is the first time I've heard a dedicated Linux desktop user complaining about the inability to watch paid streaming content. What is the world coming to! \o/

There are alternate histories where the web stagnated as an app development platform in favor of other ecosystems.

MS development slowed around IE6 after winning browser war against Netscape.

Apple's mobile ecosystem competes successfully with web, but could have gone further.

Chrome and Android have helped keep the web more relevant.

At its core, the ideals of the Web as an interoperable, nearly universal platform are extremely promising. I highly doubt people would prefer completely split ecosystems where programs could only be accessed on specific platforms.