WebKit Blog

> Who outside of Apple is using WebKit at this point?

Gnome/GTK, at least. The one bundled with Gnome (previously called Epiphany) still uses it. I was going to say Midori, but apparently it's recently-ish switched to Electron, which is understandable, but a little disappointing.

There are other niche browsers using WebKitGTK, but with the loss of Midori (?) and Qt's WebKit interface its definitely got a really small presence now.

> And how often do the tarballs drop?

Unlike most open source projects inside Apple, WebKit is developed basically in the open, with a dedicated website at https://webkit.org/ and an SVN repo at https://svn.webkit.org/repository/webkit/. They also link directly to the WebKitGTK project, and provide instructions for building for/on Linux (and Windows).

It's kind of a shame it's not more widely used -- I understand why most people so inclined would prefer Gecko/Firefox, but there may come a time when the only valid choices are a rendering engine backed by Google's dollars, or one by Apple's dollars. And unlike Mozilla, which is still mostly relying on Google's dollars, Apple has a vested financial interest in keeping a separate and at least adequate web stack.

Edit: Worth mentioning one problem with WebKitGTK adoption in linux has been API deprecation. I haven't done any dev work with it, but I know a lot of projects just gave up after the WebKit -> WebKit2 port, and GTK itself can be a PITA. The tooling outside Darwin/OS X is more cumbersome,…

I'm still shocked that they went the Chromium route here. This would have been their chance to really, well, for lack of a better way of putting it:

stick it to Google [0]

I think it would have been far, far more impressive to use Quantum (https://wiki.mozilla.org/Quantum) or WebKit (https://webkit.org), with the added benefit that nw.js is already up and going for the Webkit engine (and likely would have sufficed as an Electron replacement that they could drive forward, but I suppose they own Electron now with Github acquired)

For its not Apple anymore and certainly not Mozilla that is the prime competitor nowadays to Microsoft, its Google (With Chromebooks in the schools, and their small business and cloud offerings) and Amazon's Web Services division that are their main competitors now.

While I don't know how all the business logic went into this and ultimately came up with this being the best calculation at hand, I think this would have played better in the media too (especially if they leaned on Mozilla)

[0] I know Chromium != Google, but its pretty hard not to see that most of Chromium's development is downstream from Google and Google employs and/or otherwise has had some direct influence over the core team

I highly recommend you take a look at https://webkit.org/blog/6161/locking-in-webkit/ then. It’s been known for a long time that pthread mutexes are very expensive and terrible. Unfortunately you can’t fix it AND maintain back compat (and you might lose technical compliance with POSIX). But that doesn’t mean that there aren’t drastically better locking primitives and it’s the epitomy of hubirus to think glibc is a great codebase. It’s just widely used and most people really don’t want to dive into writing their own libc. Literally every high performance application I’ve seen uses their own locking primitives, DNS alternatives etc. The only exception is when the locking isn’t a critical bottleneck.

Examples of the same concept in different contexts:
WTF lock
Folly locks
ABSEIL locks
Rust mutexes

I have more interesting projects to work on than glibc maintenance.

Apple essentially invented color matching on personal computers back in the classic Mac OS days; it's hard to believe after all this time, they're not dealing with color correctly.

The WebKit blog from 2016:

WebKit color-matches all images on both iOS and macOS. This means that if the image has a color profile, we will make sure the colors in the image are accurately represented on the display, whether it is normal or wide gamut. This is useful since many digital cameras don’t use sRGB in their raw format, so simply interpreting the red, green and blue values as such is unlikely to produce the correct color. Typically, you won’t have to do anything to get this color-matching. Nearly all image processing software allows you to tag an image with a color profile, and many do it by default.

[1]: https://webkit.org/blog/6682/improving-color-on-the-web/

But putting capabilities behind permission isn't what Apple or Moz considered.

> Finally, if we find that features and web APIs increase fingerprintability and offer no safe way to protect our users, we will not implement them

https://webkit.org/tracking-prevention/
https://www.infoq.com/news/2020/07/apple-fingerprinting-privacy/

Strangling the web platform to keep users safe, forcing them onto much less secure much more invasive apps is not justified nor reasonable. Watching Mozilla adopt the same condescending paternalistic platform murdering "protect the children" absolutist authoritarianism with no possible consideration or affordances was a sad sad sad week. It's extremely reckless & hostile behavior, at deep deep deep injury to making so many great futures possible.

You're saying each tool solves a problem. That's true. But is it a problem that you have? And is the pain of that problem larger than the pain of introducing another tool that you need to debug when things go wrong?

Also, browsers have really stepped up their game. Now there is native CSS nesting[0], cross-document view transitions[1] and much more. So the above calculus is continuously shifting. So much that I think it's best to start with a really simple stack nowadays.[2]

[0]: https://developer.mozilla.org/en-US/docs/Web/CSS/CSS_nesting/Using_CSS_nesting

[1]: https://webkit.org/blog/16967/two-lines-of-cross-document-view-transitions-code-you-can-use-on-every-website-today/

[2]: https://mastrojs.github.io/