How did you determine the weighting for your scores?

The most significant effect is that experimental and non-standard PWA capabilities aren't reflected in the primary score. You can see raw/unweighted scores by hovering over the primary score. Chrome wins handily if you count experimental/non-standard features.

For standards-based features I used a 4-tier model, described about halfway through the README (which I should also add to About):

    ┌────────┬──────────────┬───────────────────────────────────────────────┐
    │ Weight │ Tier         │ Rationale                                     │
    ├────────┼──────────────┼───────────────────────────────────────────────┤
    │ 3.0    │ Core PWA     │ Prerequisites for production PWAs (6 features │
    │        │              │ features: Web App Manifest, Service Workers,  │
    │        │              │ Caching, HTTPS, etc.)                         │
    ├────────┼──────────────┼───────────────────────────────────────────────┤
    │ 2.0    │ Important    │ Enhance PWA functionality (18 features: Push  │
    │        │              │ API, Add to Home Screen, Offline Support,     │
    │        │              │ Display Modes, etc.)                          │
    ├────────┼──────────────┼───────────────────────────────────────────────┤
    │ 1.0    │ Standard     │ Default weight (94 features)                  │
    ├────────┼──────────────┼───────────────────────────────────────────────┤
    │ 0.5    │ Experimental │ Nice-to-have capabilities (43 features:       │
    │        │              │ Sensor APIs, Bluetooth, NFC, AR/VR, etc.)     │
    └────────┴──────────────┴───────────────────────────────────────────────┘

This weighting turns out to be reasonably conservative. For example, if you hover over the score for Firefox (the largest benefactor), you'll see that it bumps Firefox's score by 5.

I'm very open to feedback. This is a sincere attempt to quantify vendors' PWA support.

If it's about security and privacy, why push more people away from the Web to native apps that they know is less secure [1][2]?

> WebKit’s sandbox profile on iOS is orders of magnitude more stringent than the sandbox for native iOS apps.

[1] https://assets.publishing.service.gov.uk/media/62277271d3bf7... [2] https://open-web-advocacy.org/apple-dma-review

The problem is that it has to use the WebKit rendering engine, and not that it happens to.

I think it's more insulting to browser vendors that they have to throw away their browser engines to appease the monopolistic tendencies of one company.

They don't need to implement it though. They just need to unban browser vendors from shipping their own engines.

I don't think it does benefit the open web. If consumers can't get value from the web, they'll go where they can find it. That is currently native apps, which is a closed and proprietary ecosystem. This causes the market itself to shrink, which means fewer and fewer people will invest in the web [1].

Here's a good podcast episode with people from the Open Web Advocacy: https://changelog.com/jsparty/316

> I do, frankly, think that mobile Safari couldn't compete that well in an open market, just like desktop Firefox can't.

Couldn't compete isn't a justification to exploit platform control and ban competition. If Apple's so worried that Safari usage will fall off in favor of Chrome, then they can invest in Safari to make it a level playing field to keep their user base.

[1] https://infrequently.org/2023/02/the-market-for-lemons/

I think malicious compliance is a fair interpretation of the situation: https://open-web-advocacy.org/blog/apples-browser-engine-ban...

It's hard to understand the privilege bubble you're in unless you actively try to live like your users. My read of the current trend [1] is that building for your marginal users isn't prioritized culturally in orgs or within engineering. Unseating those ways of working in my experience has been immensely challenging, even when everyone can agree on methodologies to put users first in theory [2].

[1] https://infrequently.org/2025/11/performance-inequality-gap-... [2] https://crukorg.github.io/engineering-guidebook/docs/fronten...

Thank you so much for the write up! I've been avoiding processes for some reason while I've been learning Elixir and this post pushed me to play with it today. And I started in Erlang and then managed to translate it to Elixir successfully!

I ran into this issue and I'm not sure if it's just a me thing.

When sending the message from the Pong REPL, the following didn't work for me:

```erl {ping, 'ping@localhost'} ! {pong, self()}. ```

When I checked, the PID of `self()` is different to the PID of the registered `pong` process. I needed to change it to the following:

```erl {ping, 'ping@localhost'} ! {pong, whereis(pong)}. ```

This sends the correct PID to the Ping process and we have an infinite loop counting up.

Maybe the versioning should be powers of 2

Use the Navigator API directly then? Why do _need_ a declarative version of it?