With appcache / service workers and indexeddb you could probably build a tiny auditable offline loader, and then have it “install” payloads of which you can first verify signatures or audit the code. The main question remains why though.
Unfortunately it relied on the HPKP Suicide technique, since otherwise a compromised server could send a malicious update to the service worker code. Now that HPKP has been abandoned by browsers, WebSign is no longer viable (and it always required you to trust that the server really was throwing away its private keys).
As for the question of "why", it seems like you are asking either "Why would someone choose to write/use a webapp when they could just write/use a native app instead?" or "Why would a webapp developer/user care about the threat model of a web host being compromised?". Both of those questions have reasonable answers for at least some non-zero number of webapps.
Actually WebSign is still in production at Cyph, and never strictly depended on HPKP, with the caveats that:
1. Rather than simply prevent an attack, it shows a scary warning that compromised code will be run on the next reload, and
2. It relies on things that aren't intended as security features, and so is inherently more fragile than it was originally. In particular, if an attacker could fill up enough of a user's disk space, some browsers may just evict the WebSign instance.
We recommend that regular users of Cyph install the desktop and mobile apps, but it's at least a reasonably safe solution that significantly improves usability.
With appcache and a long lived expiration header on the manifest it would be possible to guarantee that no updates to the original loader are ever downloaded, hence no risk of server compromise. Regrettably appcache is deprecated.
