igrunert
Joined 10 years ago
Karma
297
Submissions
25
Member since
Mar 21
https://iangrunert.com/
View on Hacker NewsRecent submissions
Comment · 9 months ago
If you're in Denver, Colorado you can see one in-person at The Forney Museum of Transportation.
Comment · 11 months ago
WebKit on Windows has progressed since ~5 years ago. The gap between the Windows port and the Linux WPE/GTK ports is shrinking over time.
Every JIT tier has been enabled for JSC on Windows[1], and libpas (the custom memory allocator) has been enabled.
The Windows port has moved from Cairo to Skia, though it's currently using the CPU renderer AFAIK. There's some work to enable the COORDINATED_GRAPHICS flag which would enable Windows to benefit from Igalia's ongoing work on improving the render pipeline for the Linux ports. I go into more detail on my latest update [2], though the intended audience is really other WebKit contributors.
Webkit's CI (EWS) is running the layout tests on Windows, and running more tests on Windows is mostly a matter of test pruning, bug fixes and funding additional hardware.
There's a few things still disabled on the Windows port, some rough edges, and not a lot of production use (Bun and Playwright are the main users I'm aware of). The Windows port really needs more people (and companies) pushing it forward. Hopefully Kagi will be contributing improvements to the Windows port upstream as they work on Orion for Windows.
[1] https://iangrunert.com/2024/10/07/every-jit-tier-enabled-jsc... [2] https://iangrunert.com/2025/11/06/webkit-windows-port-update...
Comment · 1 year ago
The layout tests on Windows are failing at the moment due to a regression introduced a few days ago (likely https://commits.webkit.org/301043@main).
The easiest way to run WebKit on Windows is via Playwright.
Comment · 1 year ago
A CMPXCHG16B instruction is going to be faster than a function call; and if the function is inlined there's still binary size cost.
The last processor without the CMPXCHG16B instruction was released in 2006 so far as I can tell. Windows 8.1 64-bit had a hard requirement on the CMPXCHG16B instruction, and that was released in 2013 (and is no longer supported as of 2023). At minimum Firefox should be building with -mcx16 for the Windows builds - it's a hard requirement for the underlying operating system anyway.
Comment · 1 year ago
The "Chrome Commit Tracker" linked is a pretty interesting set of visualizations that I hadn't come across before. Makes it a lot easier to get a feel for the sizes of the various teams, and how they change over time.
https://chrome-commit-tracker.arthursonzogni.com/organizatio...
Comment · 1 year ago
WebKit runs on Windows, the Windows port just needs work to bring it up to the level of the Linux port. I got every JIT tier enabled in JavaScriptCore [1] and enabled libpas (the memory allocator). The Windows port is moving to Skia in line with the Linux port.
Really just needs more people (and companies) pushing it forward. Hopefully Kagi will be contributing improvements to the Windows port upstream.
[1] https://iangrunert.com/2024/10/07/every-jit-tier-enabled-jsc...
Comment · 1 year ago
Ah yeah, I see Firefox ran into that and added retries:
https://hacks.mozilla.org/2022/11/improving-firefox-stabilit...
Seems like a worthwhile change, though I'm not sure when I'll get around to it.
Comment · 1 year ago
I recently ported WebKit's libpas memory allocator[1] to Windows, which used pthreads on the Linux and Darwin ports. Depending on what pthreads features you're using it's not that much code to shim to Windows APIs. It's around ~200 LOC[2] for WebKit's usage, which a lot smaller than pthread-win32.
[1] https://github.com/WebKit/WebKit/pull/41945 [2] https://github.com/WebKit/WebKit/blob/main/Source/bmalloc/li...
Comment · 1 year ago
I think the author was happy to be employed by a megacorp, along with a team to push jemalloc forward.
He and the other previous contributors are free to find new employers to continue such an arrangement, if any are willing to make that investment. Alternatively they could cobble together funding from a variety of smaller vendors. I think the author is happy to move on to other projects, after spending a long time in this problem space.
I don’t think that “don’t let one megacorp hire a team of contributors for your FOSS project” is the lesson here. I’d say it’s a lesson in working upstream - the contributions made during their Facebook / Meta investment are available for the community to build upon. They could’ve just as easily been made in a closed source fork inside Facebook, without violating the terms of the license.
Also Mozilla were unable to switch from their fork to the upstream version, and didn’t easily benefit from the Facebook / Meta investment as a result.
Comment · 1 year ago
The gap between the Windows and GTK ports is shrinking. Every JIT tier has been enabled for JSC on Windows[1], and libpas (the custom memory allocator) should get enabled soon.
The Windows port is moving from Cairo to Skia soon as well, matching the GTK port (though I think the focus is enabling the CPU renderer to start).
Webkit's CI (EWS) is running the layout tests on Windows, and running more tests on Windows is mostly a matter of funding the hardware.
There's a few things still disabled on the Windows port, some rough edges, and not a lot of production use (Bun and Playwright are the main users). It'd definitely be more work than Linux, but it's not as bad as you'd think.
[1] https://iangrunert.com/2024/10/07/every-jit-tier-enabled-jsc...
Comment · 1 year ago
While the modern web is complicated, there's a few things working in Ladybird's favor.
Web Platform Tests (1) make it significantly easier to test your compliance with W3C standards. You don't have to reverse engineer what other engines are doing all the time.
The standards documents themselves have improved over time, and are relatively comprehensive at this point. Again, you don't have to reverse engineer what other engines are doing, the spec is relatively comprehensive.
Ladybird has chosen to not add a JIT compiler for JS and Wasm, reducing complexity on the JS engine. They're already reached (or exceeded) other JS engines on the ECMAScript Test Suite Test262 (2).
There's a big differential between the level of investment in Chromium and the other engines - in part because Chrome / Chromium are often doing R&D to build out new specifications, which is more work than implementing a completed specification. There's also a large amount of work that goes into security for all three major engines - which (for now) is less of a concern for Ladybird.
I'm confident that the Ladybird team will hit their goal of Summer 2026 for a first Alpha version on Linux and macOS. They'll cut a release with whatever they have at that point - it's already able to render a large swathe of the modern web, and continues to improve month-on-month.
(1) https://web-platform-tests.org/ (2) https://test262.fyi/
Comment · 1 year ago
Ladybird does have another slight advantage in that it only has an interpreter for JS and wasm, instead of maintaining multiple tiers of JIT compilation for both. That choice materially reduces the surface area for exploits.
Comment · 1 year ago
For Ladybird - Andreas Kling called out that the vast majority of "easy tests" are passing and each additional test is going to be more difficult to come by going forward.
https://www.youtube.com/watch?v=-l8epGysffQ (1 minute - 4 minute)
Comment · 1 year ago
There are a handful of git features which work significantly better with a clean history on main. If `git blame` points at a well crafted commit, it can help bring additional context to the line in question. In addition `git log -S<string>` can be used to find when code was introduced.
Both of these features aren't very useful when they point at a "wip" or similar commit message.
By all means push lots of little commits to your branch while you're figuring stuff out, but squash and rewrite history into logical commits (usually just one) before landing the change on main.