8 ms·
With both Firefox and Chromium using jxl-rs (Rust-based), I wonder what Apple will do about the libjxl (C++) they already shipped. I know they're doing some mem
by concinds 22d ago
With both Firefox and Chromium using jxl-rs (Rust-based), I wonder what Apple will do about the libjxl (C++) they already shipped. I know they're doing some memory-safety with Swift, but are they shipping any Rust in their platforms so far? I also wonder if anyone's done benchmark comparisons between both libs.
--
Also, I was under the impression that after backtracking, Chromium was relying on Mozilla to come up with a Rust port, but it seems it was the reverse. Good on Google Research.
https://hacks.mozilla.org/2026/08/intent-to-ship-jpeg-xl/ https://hacks.mozilla.org/2026/08/intent-to-ship-jpeg-xl/
> So, we laid down a challenge to the JPEG XL team at Google Research: Build a safe, performant, compact, and compatible JPEG XL decoder in Rust, and we’ll ship it. That challenge was met; Google Research built jxl-rs, and it’s the core of our JPEG XL support in Firefox.
- deadbunny 22d agoApple is gonna do what apple wants.
- cute_boi 22d ago[flagged]
- arkon_hn 22d agoNot to mention how updates are tied to OS updates...
- tengwar2 22d agoHasn't been the case for some time.
- spartanatreyu 22d agoNot true. MacOS releases a new version each year, the current MacOS landscape looks like: - MacOS Sequoia (previous version, everything works as expected) - MacOS Tahoe (current version, broken experience, basically Apple's "Windows Vista/8 moment") - MacOS Golden Gate (next version, fixes what was broken in Tahoe, comes out in a month) I'm on MacOS Sequoia because I have things that can't be broken by updating to Tahoe. I also cannot test how my websites/webapps will work in a month, because Safari's beta (called Safari Technology Preview) only works on Tahoe and Golden Gate. I cannot wait a month to update to Golden Gate because Golden Gate drops support for my iMac. And I can't test the new version of Safari on my Windows or Linux devices because Safari isn't available for them. I can test the Webkit browser, but that doesn't include the Safari specific changes that apple makes which I need to be able to test. --- So, I can't test Safari until I wait a month and purchase a new apple machine. (Oh by the way, apple keeps cancelling orders for new machines)
- alwillis 22d ago> And I can't test the new version of Safari on my Windows or Linux devices because Safari isn't available for them. You can download three Linux-compatible WebKit-based browsers from Apple's WebKit page: Epiphany Technology Preview: https://webkitgtk.org/epiphany-tech-preview https://webkitgtk.org/epiphany-tech-preview WPE: http://wpewebkit.org/download http://wpewebkit.org/download WebKitGTK: http://webkitgtk.org/download http://webkitgtk.org/download
- tosti 22d agoThere are subtle differences. From the top of my head, differences with osx include the font rendering and the tab order (which is broken for everything except form elements).
- alwillis 21d agoI get it; when Safari was available for Windows, the font rendering was different from the Mac version.
- dlahoda 22d agoWhat Updates tied? App Store updates use same networking and storage as OS? Why it is bad?
- deleted 22d ago[deleted]
- flyingjoe 21d agobecause updating a single app via the app store is faster than updating the whole OS. Having a security vulnerability in a browser could be fixed immediately, but having to ship out a whole new OS leaves it open for a while. Especially with users generally being against/too lazy to do OS updates
- arkon_hn 21d agoExactly this. We so often see people still using iOS versions from ~4 years ago despite having options to update. Apple holds the ecosystem back.
- kekdkrjfjjwfj 21d agoExcept that they can and have pushed security updates that are not necessarily OS updates. Granted the process is still through the settings app, but the point still stands. They have a channel for pushing yellow and red alert updates. Anything else can easily wait a couple of months.
- Unai 22d agoA non-evergreen browser in 2026 should be publicly ridiculed any time its name is brought up.
- account42 21d agoWeb developers who think you need the latest and greatest features to build a hypertext document are the ones who should be ridiculed.
- Unai 21d agoThankfully, people with ridiculous opinions ridicule themselves. Like pretending the web is just documents, as if we were living three decades ago. Or pretending that "latest and greatest features" is the only reason to keep a browser updated. Or pretending that new features are somehow bad or not useful. Or defending poor Apple for wanting people to spend a grand on new hardware to update be able to update their browser.
- nchmy 22d ago[flagged]
- chuckadams 22d agoMaybe because they don't want to see this thread dragged down into an open-ended gripe-fest against Apple, especially when it's concerning a feature Apple did ship before everyone else.
- dlahoda 22d agoMy wife, son and me not using Safari. Do not see how Safari relates to App Store. We use App Store.
- SR2Z 22d agoThe point of a PWA is that instead of downloading an actual binary app, you essentially get a webpage that runs like it was an app. They can be installed from anywhere and are safe by nature because they're really just webpages. That was the original conception of iPhone apps, until Steve Jobs realized just how much money could be made from the app store. Now you get to pay Apple a 30% cut for the privilege of installing software on your own device!
- kekdkrjfjjwfj 21d ago> Now you get to pay Apple a 30% cut for the privilege of installing software on your own device! Kneejerk reactions everywhere! Wow. And to think HN commenters like to think themselves superior to other reddit/instagram/linkedin/social media users.
- SR2Z 20d agoAm I wrong? Was Apple's cut not 30%? Did it not generate a quarter of their revenue last year, over a hundred billion dollars? I have an iPad. I don't need nannying from a trillion-dollar corporation to use my device and yet that's what I get - every excuse Apple makes (security, consistency, whatever) are obviously possible without the level of locked-down their devices are.
- llm_nerd 22d agoWhat a funny tangent to go off on. JXL was dead. Apple is who brought it back to life[1], and the only reason Chrome resurrected JXL, and now Firefox followed their path, is because Apple pushed JXL support to a billion plus devices. I know people like complaining about Apple, but there's a "read the room" kind of moment where people just seem to either not know the context or are just knee jerking. [1] Worth noting that Apple used the reference implementation, libjxl, and that project still remains the reference implementation with the Rust port being experimental (and of course Apple deployed JXL support over a year before the Rust port even existed). Maybe they'll switch to it at some point, but it's a bit premature to complain about.
- deadbunny 22d ago[flagged]
- concinds 22d agoI don't see what this has to do with the topic, sorry.
- wongarsu 22d agoTheir point is that Apple is the Nintendo of computing. They don't care what others do, they just do their own thing. Which produces some great things and some stupid things. They also don't care whether you think what they are doing is great or stupid, they just continue doing their thing Which then tracks back to the beginning of the thread: the correct answer to whether apple will adopt jxl-rs or keep libjxl is "who knows, no point trying to predict them". Which is not a value judgement How you square all of that with the iPhone regularly copying features Android had for years is your decision. Might be a symptom of the same, might be that this all was an entirely inaccurate description of Apple
- _joel 22d agoThat useless strip could play lemmings and doom, it wasn't all bad
- 22d ago
- Snafuh 22d agoLuca Versari, one of the devs between both libraries, has a performance dashboard to compare performance between the two https://jxl-rs-perf.lucaversari.it/ https://jxl-rs-perf.lucaversari.it/ jxl-rs started to outperform the C++ library 2 months ago.
- rfgplk 22d agoIf he is one of the devs between both libraries, why is there a performance gap? Why not port the optimizations from one lib to the other? You can even create a pinned agent workflow that automatically translates optimizations between repos. Fairly trivial to implement actually.
- NewJazz 22d agoBecause developers of security critical code don't flippantly merge LLM changes for marginal performance gain, and their time is incredibly valuable.
- AlotOfReading 22d agoJust because you can theoretically write equivalent code in both languages doesn't mean two idiomatic implementations in each language will be 1:1 with each other. I haven't looked at the code in question, but some examples of common differences: A C++ program might do template metaprogramming at compile time and the same thing at runtime in Rust, or vice versa. The C++ version might use virtual functions that rust wouldn't use. The Rust version might simply give more optimization information to the backend. The C++ version might use fairly awful parts of the stdlib like iostreams or shared_ptr that rust simply implements better. Etc. Or maybe they're just focused on the rust implementation as they should be.
- josephg 22d agoYep. Also: The rust borrow checker makes it difficult to implement tree like structures with pointers like you would in C or C++. Safe rust trees are (imo) best written using vecs. Rust makes function arguments noalias. Rust adds runtime array bound checks. Rust and C++ do iteration quite differently. Rust encourages map/filter/reduce. I suspect this results in different assembly. Doing a “unity build” in rust is really easy (codegen-units=1). In C++, you need to make heavy modifications to your build system and sometimes your source too. But with some time you could probably port the optimisations across. If anyone has some spare tokens, Claude can be quite good at doing this sort of work. Show it both repositories and tell it to make the C++ code just as fast as rust.
- saagarjha 22d agoShipping unsafe C++ is easier on Apple platforms than Rust. This seems unlikely to change anytime soon.
- dlahoda 22d agoI do not feel so. Not only Rust does C API, but Objective-C the way it allows to call Apple platform and call Apple compatible functions back. Also well integrated Rust programs(with platform calls and low level hardware access) are well compiled without Apple SDK. 3-4 kicking Rust solutions are easy findable in this area.
- saagarjha 22d agoJust because it is possible or even easy does not mean it will happen.
- josephg 22d agoIs it? I wrote a pure rust iOS app recently. It uses native controls, and looks and feels great. iOS and iOS-sim are both very well supported targets by the rust compiler.
- saagarjha 22d agoYou’re not shipping code as part of Safari
- josephg 22d agoYou're moving the goalposts. You said: > Shipping unsafe C++ is easier on Apple platforms than Rust. ... Which seems false. I can easily believe that apple might not have rust tooling in their Safari build system. But that doesn't mean rust has poor support for apple platforms.
- saagarjha 21d agoNo, you're reading what you want out of my comment. The context of this thread was very clearly browser support of JPEG XL, not your apps.