Minimal files and config for a PWA(github.com)
github.com
Minimal files and config for a PWA
https://github.com/chr15m/minimal-pwa
23 comments
For me it's still just Share > Add to Home Screen, so 3 taps if you count the tap to reveal the menu.
Also interesting: "Now every site can be a web app on iOS and iPadOS." https://webkit.org/blog/17333/webkit-features-in-safari-26-0...
Also interesting: "Now every site can be a web app on iOS and iPadOS." https://webkit.org/blog/17333/webkit-features-in-safari-26-0...
> With iOS 26 they’ve put it yet another tap deep!
Yes. By default iOS 26 Safari has a new "Compact" tab menu which requires tapping the ellipsis menu button, then Share, then Add to Home Screen. Previously the Share button was located directly on the tab menu.
I've gone into Settings -> Apps -> Safari -> Tabs section and switched from "Compact" to "Bottom". This switches to a larger tab menu with single-tap access to the Share, Bookmark, and tab switcher buttons.
Yes. By default iOS 26 Safari has a new "Compact" tab menu which requires tapping the ellipsis menu button, then Share, then Add to Home Screen. Previously the Share button was located directly on the tab menu.
I've gone into Settings -> Apps -> Safari -> Tabs section and switched from "Compact" to "Bottom". This switches to a larger tab menu with single-tap access to the Share, Bookmark, and tab switcher buttons.
Interesting that it‘s possible to do it with a single HTML file, the icons and manifest being dynamically generated in JS and set as data URLs. I wonder if that works reliably.
It‘s in the same repo: https://github.com/chr15m/minimal-pwa/blob/main/single-file-...
It‘s in the same repo: https://github.com/chr15m/minimal-pwa/blob/main/single-file-...
I’ve been using this technique for years in this project: https://github.com/pseudosavant/player.html
A single HTML file with favicon, manifest, SVG icons, etc.
A single HTML file with favicon, manifest, SVG icons, etc.
Neat, thanks for sharing!
Having no build step and no dependencies is such a power move. ;)
Any gotchas with this approach that you‘re aware of?
Can this approach handle updates? I thought the way to do that was usually to check some hash in the manifest and prompt the user that an update is available if it has changed.
Having no build step and no dependencies is such a power move. ;)
Any gotchas with this approach that you‘re aware of?
Can this approach handle updates? I thought the way to do that was usually to check some hash in the manifest and prompt the user that an update is available if it has changed.
The biggest gotcha I've run into is that having everything in one file makes for a lot of tokens for LLMs to chew on or create when I code. The next iteration of that project will still have an equivalent `player.html` file that contains everything, but I am making a very basic build script so that it is easier for LLMs like GitHub Copilot to work on the project in parts.
This is awesome. Tried to search for other HTML only repos on Github using "language:HTML NOT language:JavaScript" but it doesn't return anything. Not even this repo. Was following https://docs.github.com/en/search-github/github-code-search/...
Favicon defined as SVG in the HTML then converted to PNG. That's a neat trick.
Fantastic minimal example. For those wondering what you can do with PWAs, check out https://whatpwacando.today/
That website is full of non-standard things. For instance Web NFC and Web Bluetooth are not standard web platform APIs, they are Blink APIs that have been rejected on privacy and security grounds by both Mozilla and Apple. Nothing apart from Blink has implemented them.
Mozilla on Web NFC:
> We believe Web NFC poses risks to users security and privacy because of the wide range of functionality of the existing NFC devices on which it would be supported, because there is no system for ensuring that private information is not accidentally exposed other than relying on user consent, and because of the difficulty of meaningfully asking the user for permission to share or write data when the browser cannot explain to the user what is being shared or written.
— https://mozilla.github.io/standards-positions/#web-nfc
Mozilla on Web Bluetooth:
> This API provides access to the Generic Attribute Profile (GATT) of Bluetooth, which is not the lowest level of access that the specifications allow, but its generic nature makes it impossible to clearly evaluate. Like WebUSB there is significant uncertainty regarding how well prepared devices are to receive requests from arbitrary sites. The generic nature of the API means that this risk is difficult to manage. The Web Bluetooth CG has opted to only rely on user consent, which we believe is not sufficient protection. This proposal also uses a blocklist, which will require constant and active maintenance so that vulnerable devices aren't exploited. This model is unsustainable and presents a significant risk to users and their devices.
— https://mozilla.github.io/standards-positions/#web-bluetooth
Mozilla on Web NFC:
> We believe Web NFC poses risks to users security and privacy because of the wide range of functionality of the existing NFC devices on which it would be supported, because there is no system for ensuring that private information is not accidentally exposed other than relying on user consent, and because of the difficulty of meaningfully asking the user for permission to share or write data when the browser cannot explain to the user what is being shared or written.
— https://mozilla.github.io/standards-positions/#web-nfc
Mozilla on Web Bluetooth:
> This API provides access to the Generic Attribute Profile (GATT) of Bluetooth, which is not the lowest level of access that the specifications allow, but its generic nature makes it impossible to clearly evaluate. Like WebUSB there is significant uncertainty regarding how well prepared devices are to receive requests from arbitrary sites. The generic nature of the API means that this risk is difficult to manage. The Web Bluetooth CG has opted to only rely on user consent, which we believe is not sufficient protection. This proposal also uses a blocklist, which will require constant and active maintenance so that vulnerable devices aren't exploited. This model is unsustainable and presents a significant risk to users and their devices.
— https://mozilla.github.io/standards-positions/#web-bluetooth
How is asking for user consent insufficient? I smell Apple propaganda.
Never really understood Mozilla's position on remote device access.
Yes, it's a risk, essentially by definition. It's no less so (and in particular absolutely not helping your browser product or the web platform!) if you just punt and force everyone to use a proprietary iOS/Android/Windows app instead.
Innovation happens on the physical side of the design wall too, you can't just put your head in the sand and figure someone else will solve it. That's how we got the walled app gardens in the first place.
And just to make this concrete: QMK keyboards configure magically by pulling up a web page ("use.via") on the device. Lots of gadget-space open source hardware uses similar tricks. This is not an obscure or useless feature. And it's deeply sad that Firefox[1], in its senescent obsolescence, doesn't even want to pretend to play for a piece of that action.
[1] The archetypical hacker's browser in its prime!
Yes, it's a risk, essentially by definition. It's no less so (and in particular absolutely not helping your browser product or the web platform!) if you just punt and force everyone to use a proprietary iOS/Android/Windows app instead.
Innovation happens on the physical side of the design wall too, you can't just put your head in the sand and figure someone else will solve it. That's how we got the walled app gardens in the first place.
And just to make this concrete: QMK keyboards configure magically by pulling up a web page ("use.via") on the device. Lots of gadget-space open source hardware uses similar tricks. This is not an obscure or useless feature. And it's deeply sad that Firefox[1], in its senescent obsolescence, doesn't even want to pretend to play for a piece of that action.
[1] The archetypical hacker's browser in its prime!
hey thanks for this.
do you know if we can also do this:
when signing up we send the confirmation link to the user's email. however, when the user clicks the link in the email it redirects to the website and not the pwa. is there a way to redirect to the pwa? thanks
Chrome has a flag for this but I haven't tested it personally. #enable-user-navigation-capturing-pwa
You can use something like https://developer.mozilla.org/en-US/docs/Web/Progressive_web... to handle the verification part inside Chrome.
For opening HTTP links in the PWA itself, you rely on the way the browser deals with links. I don't think you can reliably open any link in PWAs in a cross-platform manner today.
For opening HTTP links in the PWA itself, you rely on the way the browser deals with links. I don't think you can reliably open any link in PWAs in a cross-platform manner today.
I've done this before, its a lot of fun, you learn a lot about the browser. Especially caching. If you ever suspect caching issues for a bug / issue, open up Chrome Dev Tools, go to the "Application" tab, then "Storage" if you click the Clear site data button, it will wipe all cache, then right click on the refresh button, and "Empty cache and hard reset" if you do both of these (though one's probably enough) you will start over with nothing cached. Cache becomes very tricky when building a PWA.
I don't know if its been fixed since, but I really needed to tell if I was offline, only way was to make requests, if they failed assume offline, keep retrying till online to sync data to backend.
I don't know if its been fixed since, but I really needed to tell if I was offline, only way was to make requests, if they failed assume offline, keep retrying till online to sync data to backend.
How to do a minimal cache busting? That is what stops me from "minimal setups"
I wonder how long will PWAs will be viable option for sideloading own apps without notarization and developer account?
Ugh why would you put that out there?
The walled gardens go up around paid app stores because of the way court decisions landed in the US[1]. PWAs are an open standard, they aren't really part of the analysis.
But yes, if you want them to stick around maybe consider using platforms that best support them.
[1] Apple disallowed open access and so couldn't be a "monopoly" per the court and could charge whatever license fee they wanted; Google let people sideload their own apps and so was forced to allow entire third party app stores. Yes, this is just as insane as it sounds.
But yes, if you want them to stick around maybe consider using platforms that best support them.
[1] Apple disallowed open access and so couldn't be a "monopoly" per the court and could charge whatever license fee they wanted; Google let people sideload their own apps and so was forced to allow entire third party app stores. Yes, this is just as insane as it sounds.
It's often argued that Apple doesn't make PWA installs obvious because they want to preserve the sanctity of the web or something along those lines but I'd say that argument is invalidated by the “smart banners” for installing an App Store app that you can set via meta tag:
https://developer.apple.com/documentation/webkit/promoting-a...
In my experience they're far more intrusive than a PWA install banner!