Comment by 2OEH8eoCRo0
10 hours ago
Why do browsers need to support every media format? Why can't it be shipped as a shared library for the whole system to use?
10 hours ago
Why do browsers need to support every media format? Why can't it be shipped as a shared library for the whole system to use?
> Why can't it be shipped as a shared library for the whole system to use?
Flashbacks to DataTypes on the Amiga: https://wiki.amigaos.net/wiki/Datatypes_Library
My favourite tidbit about the Amiga is that it was the first platform that got PNG support in all its web browsers: you just had to install the png.datatype.
AmigaOS was the first to bring a lot of smart ideas to a consumer platform.
I got my A1000 in late '85 and only had prior exposure to 8-bit home computers (C64, Atari, etc), CP/M and DOS (no mainframes, minis or workstations). I didn't actually use Macs or early Windows until the early 90s and it was shocking how backward they still seemed in some ways. I'd sort of the assumed the other major platforms were making similar advancements throughout by the late 80s and shocked to find out how wrong I was. It wasn't until the mid-90s that PCs and Macs felt like they mostly caught up on QoL and OS features.
> Why can't it be shipped as a shared library for the whole system to use?
That's how it works on macOS; the bundled apps (Preview, Photos, etc.) gained support for JPEG XL.
This way browser vendors control what their app supports, and won't have something break because a user doesn't have a library.
Google seems to prefer reimplementing every portion of an OS possible in Chrome.
If you want things to work every single time on a billion different devices this is how you do it.
Yeah, and then 100 different apps can repackage the browser engine as an Electron app, each weigh 300+mb.
I saw this recently with Balena etcher. It's a firmware flashing app with about 10 buttons total. It's over 400mb because it's written in node and has an electron GUI.
Good jerb.
7 replies →
Indeed. The most goofy is their proprietary Print dialog. I think(?) they added it to gain a previewing pane, but Apple added that capability to the native print dialog about 10 years ago. Chrome still forces its old bespoke one though, and when you do the extra click to get the OS standard one, they apparently don't use the previewing API, so it's missing.
Given that there are more operating systems than browser engines these days, I'm not sure this would be an unequivocal win.
Eh. WebKit, Blink, Gecko being the big ones, supporting Windows, Linux (and alikes — maybe one would consider Android separate in this context) and Darwin (in this context iOS/macOS is the same). Mostly 1:1.
The thing is that it's still just a library, it just happened to be pre-installed. CGImage is just a helper in the Core Graphics library, not some magical "native"/"core" functionality in the OS that would be different than any other library with the same features.
An equivalent library for Linux (glycin for example), or per-format libraries like jxl-rs, are not "included in the OS", and tend to be the very same libraries one would use for Windows. If that does the trick on most platforms, then why have the maintenance burden of doing something different on macOS if all it does is save a few bytes on disk?
From Google's perspective, they would likely not want Chrome for macOS to gain support for jxl as the sole platform anyway, even if they are using CGImage and could decode it that way...
I'd definitely consider Android separate from Linux, yes. Their multimedia subsystems are completely different. The same applies to tons of embedded Linux platforms running an embedded Chromium or WebKit.
Browsers have also largely switched to handling most aspects of TLS and certificates themselves, despite there being OS libraries for those as well; the same applies to HTTP.
Because browsers want to provide a consistent platform and can’t rely on OS vendors to do it in the way they need and prioritize their interests.
But it is a shared library? It's used in both Chrome and Firefox.
Which both vendor it.
> Why can't it be shipped as a shared library
Shared libraries are a bad idea that is simply taking way too long to just die the horrible death it deserves.
Such an important piece of software does not want to subject itself to the packaging and support woes of shared libraries. There are security issues, maintainability issues, and much more headache by going with that approach.
Static linking is one and done, headache gone. People have large drives these days, so it's not a problem.
There are areas where the browser will dynamically link, but those are more OS-related than image and file format codecs.