Turns out doing a PWA is just basically about using the "Service Workers" API  and the practices around that.
This nice article does a lengthy trace on the origins of the "PWA" term . The same guy that started the "Service Workers" spec in Github  created the PWA marketing campaign, apparently. Makes me wonder why he thought it was more marketable to sell this PWA idea more than the simpler and more direct message: "use Service Workers".
The PWA campaign also reminds me of the less successful "Offline First" campaign from a couple of years ago .
> When I first heard someone talking about "Progressive Web Apps" I thought they were talking about "Progressive Enhancement"
Progressive enhancement is indeed where the P in PWA comes from. The core idea is to ship great sites for all users, and progressively upgrade with the latest web capabilities (service workers for offline, manifest for adding to homescreen and full-screen displays, and so on) when a user's device supports it. If the user's device doesn't support it, they should still get a good, traditional web experience: fast, secure, usable.
> Turns out doing a PWA is just basically about using the "Service Workers" API  and the practices around that.
Your first impression about progressive enhancement was closer to the mark. The PWA Checklist  is the canonical document about what constitutes a PWA. We created that doc in November 2016  to try to clear up the massive confusion about the definition of a PWA, but apparently to no avail.
Under the "Baseline PWA" checklist you'll notice that there's mention of service workers and manifest files, but there's also mention of loading fast on 3G, having mobile-friendly design, being secure, supporting all browsers, and so on. Again, the core idea is to ship good experiences for all users, and progressively enhance the UX when possible.
It'd be an interesting postmortem to study why the "PWA" term has been so notoriously confusing. IMO part of the problem was that we as a team weren't 100% crystal-clear on the definition at the start. But to be fair, I think we did straighten out our messaging pretty early on. The PWA Checklist that I linked to which has been out since November 2016 is evidence of this. But by that time it was already too late. PWA became a buzzword, and the blogging community seemed to conflate "PWA" with "promising new web platform capabilities" (service workers and manifests). I don't mean to shift blame. We (Web DevRel) most likely caused that conflation. I think the takeaway is that this is a lesson on what can happen when you're not 100% clear on messaging right from the start.
1. Lack of support on iOS. I presume it’ll stay this way for a while (years!). Mobile Safari finally has service workers, but really, that’s about it. No support for “Add to Home Screen” (technically it’s there, but doesn’t work the way it does in other browsers), and a lot of other APIs.
2. The Web is missing some APIs that would really let it compete with native apps. I know there was WebNFC at some point, but it was dropped. No standard/widely implemented API for reading contacts, sending texts, etc. Features like that would really push PWA over the edge and make it awesome.
It turns out iOS 12.2 will be "one heck of a release for Progressive Web Apps…"
absolutely this. i have no idea why the Contact api  work has been discontinued. my current conspiracy theory is that it would have allowed many communication apps to no longer require native apps and cloud-stored address books.
like selecting a file to upload, i dont see why i can't select a contact to use/upload from a locally available address book. So many web apps could use this.
Entire classes of PWAs are essentially impossible to build right now because of the lack of ability to work with files directly, think offline editors, offline music players, etc.
See PWAs on Windows 10, or the recent TWA support on Android.
Default should be for example some icon indicating that the website wants more permission ... and then if I feel like it, I grant more permission. Til the point of fully trusting and giving all access.
But a website is a website I just read and will never get more permissions from me.
But a pwa ... like a game, I would grant more permissions. This is something that should be made easy from the browser to choose, whithout getting annoyed by permission popups all the time.
But this would be up to the websites then. They could do this now, but they aggressively push for all the permissions they can get in the hope at least some click (accidently) yes.
I do not want popups to click away all the time. I want to decide that I like notifications from site x if they offer that.
And the speedometer is great but what about the other info? Fuel gauge? Mileage? Battery Charge? Engine faults?? Geolocation won't help with any of those.
That said I do love the PWA approach to things and I think more people should embrace it. Just... not for this.
My car's battery gauge has never worked, not in the 20+ years that my father and I have owned it. (I don't know if it worked for the one person that owned it before him, or if it never ever worked.) The only time it would have been helpful is the one time the alternator died. OP has an electric hybrid, so it's a bit more useful to them, but still not critical.
The "check engine light" is helpful to people who know little about their vehicle, telling them "please take me to a mechanic!" Otherwise, they seem to be more annoying than helpful -- the family minivan that said "I need an oil change!" because changing the oil yourself didn't reset the counter, or the endless O2 sensor replacements the SUV wanted. You could learn much more, and with less annoyance, by sticking an inexpensive ODB2 reader into your car once in a while.
I just do what I've done with every bike, reset the trip when I fill.
The fuel gauge in my dads pickup is also really whacked. Once it hits about 50% fuel left, it rapidly goes down to 0. Cars don't burn though higher rates of fuel just because of how much is in the tank.
Aside from the calibration issue, GPS has poor or no coverage in tunnels, underpasses, mountainous areas and between dense urban high rises. Prone to EM interference too. Not a good thing for safety critical device.
So perhaps if you drive early model Ford T no speedometer is fine, but otherwise seriously doubt it.
> There are no vehicle inspections, ever. As long as I continue to drive without causing incidents, my vehicle's condition is of little significance to anyone except me.
You don't have DEQ? While it doesn't cover the dashboard, it certainly covers other equipment on the car to know if you're polluting more than the set threshold.
Edit: just saw the reply below mine as it wasn't there when I was typing. I didn't realize that DEQ (Dept. of Environmental Quality) wasn't a national thing. Every 2 years I have to take it in and they hook into the cars OBD2 port to read the cars computer to get the sensor readings. Before computers were in cars, they stuck a sensor up your tailpipe and you had to rev the car up to 6,000 RPM for a few minutes (something like that, it's been a long time). You'll probably remember the big volkswagon scandal over this for falsifying the data.
I know where I live, it's common to see vehicles that would be unsafe driving at highway speeds, but no one cares as long as they work well enough for local driving.
How do I find your ad-free hobby project in the sea of search results for "speedometer" PWAs on the open web?
What makes sure you will keep paying the, admittedly modest, hosting costs for the app?
I think it's great you can make "tiny PWAs" but I think the article is glossing over the incentives and discovery problem that leads to 30MB ad-infested utility apps on the play store.
Last I saw things launched from the home screen or in a webview from another app use the "Android System Webview" as it's rendering engine.
IIRC there was some work done to make that runtime swappable, but I'm not sure how far that went.
I think PWA is about tooling, like Google's chrome dev tools or Workbox, and frameworks. The good side of it is sharing the codebase/API between app and website. The bad side is you may bet on the stillborn/transient tech and will have to rewrite or monkey-patch everything.
And ads were never the only business model, it's developer's choice. There are apps for Android w/ decent prices and w/o annoying banners. PWA is no different.
The convergent evolution leaves nothing untouched. I think if proliferate rate of web frameworks continues to grow exponentially, we'll have to deploy docker images right into the browser. I mean, it was a joke. Was it?
<script async="" src="https://www.google-analytics.com/analytics.js"></script>
<script>window.ga = window.ga || ((...args) => (ga.q = ga.q || ).push(args));ga('create', 'UA-130560367-1', 'auto');ga('set', 'transport', 'beacon');ga('set', 'anonymizeIp', true);ga('send', 'pageview');</script>
I thought the point of a PWA is that it is installed on the phone. So it doesn't need any hosting.
For the initial distribution, IPFS would be a good fit. It ensures a.) That even if the original developer is compromised you still don't get a malicious app, and b.) That even if the original developer stops hosting it, it's still available as long as anyone in the world is hosting it.
Google doesn’t have the best track record in the forever department :)
I’m finally groking what rms has been banging on about for so long. It is completely unacceptable that we are running software that does this to the user. Users need to be empowered and able to run code that they can control.
<script>let on true;</script>
<body onclick="on = !on; this.style.background = on ? 'white' : 'black'">
i.e. QR-coded dataURI document
data:text/html;charset=utf-8,<!DOCTYPE html><title>Screen light</title><html onclick=on=!on;this.style.background=on%3F'white':'black'><body onload=on=true>
data:text/html,<title>Screen Light</title><html onclick=o=!o;style.background=o%3F0:'black';style.color=o%3F0:'white'><body onload=o=1><h1>Screen Light</h1><p>Turn your screen into a light source<br>Tap to toggle<p><a href=https:/news.ycombinator.com/item?id=19069487>Source
 Check out for example this HTML / SVG sketchbook: https://gist.github.com/myfonj/c8ce74bf549e19600026ce9022388...
 http://tinyurl.com/selcoditor (see network log)
Other applications work much better for that, though they may or may not recognise non-http URIs e.g. here scanbot just displays the textual content and you're on the hook for copy/pasting it wherever you need.
Sadly, copypasting resulting URI as plaintext is most probably the only option for modern browsers, because any other way of top level frame navigation to dataURI document is blocked. (Besides existing bookmark, that is.) I keep forgetting this, sorry for hurried "in theory it must work great" shout out.
Case study: people copy-pasting random code into their Myspace profiles
I suspect you can get a better coding experience by connecting your Glitch account to Github and then using an editor that works well on your device.
The PWA part of Glitch is completely under your control.
But I'm curious how much download weight matters, outside of as a proxy for "how much bloated ad bullshit is hiding inside the app bundle"?
I'd wager the difference between a 2KB PWA and a 5MB or 30MB native app download is relatively insignificant — in storage space, in cellular data use, in initial download time — to your average user when compared to streaming a film on Netflix or downloading a F2P game with 100MBs to GBs of assets.
(where "average user" is assuming most of these apps are only localized in English and only available in largely-western countries — totally get how the story is very different in emerging markets)
2kB will feel instant. 5MB will feel mostly quick. 30MB will feel like it had to earn it.
When things are instant then it feels like magic. It's sad that having all those super fast machines everywhere we have to deal with so much bullshit. Your computer can push through gigabytes of memory on a second. Does it feel this way? That's why people still use CLI, at least there, many things feel instant and when not it's usually reasonable.
It's not only download speed, it's also verification time, compilation/optimization and whatever else happens during install. All of those will take longer the bigger the app is.
But at the same time for me the proxy effect of "how much bloat and bullshit did they cram into it" is as important and can't be dismissed.
While bundle size might sometimes correlate with cold start times for PWAs (depending on whether it's JS code that's bloating the bundle, or other media assets that won't trigger an initial parsing + evaluation hit), that's less likely to be the case with native apps.
And that's just one usage, by one user. Multitply by thousands of usages and billions of users. It's inexcusable from a craftsmanship viewpoint.
On Android, iOS, Firefox extensions, and many websites, you can't give permission for one thing without giving permission for everything. Or those "I accept cookies popups" -- until recently, you couldn't choose which cookies you wanted to accept, so either you accept tracking cookies in order to use basic functionality, or you head elsewhere. The application developer could be a good citizen and request on the permissions needed -- but it's just easier to request that they be able to read and modify any and all data, regardless of their need or desire to do so.
On Windows, Unix, and other "system-level" permission systems, you have a different problem. There, there is no real ability to verify what an application is trying to do with its elevated permissions -- it just wants to be given God power, even if it only needs permission to do one or two very specific things in one or two very specific locations.
An OS-level analogy would be the ability to block specific syscalls made by specific processes, optionally only when spawned by a specific parent process.
The most relevant result I could find for "linux on the web" was https://linuxontheweb.appspot.com/ which doesn't seem to be relevant at all.
He also posted a comment in the thread with some more details:
> It makes heavy use of the HTML5 Filesytem for local storage, as well as Native Client for vim, python, and plugin codecs to enable highly configurable realtime a/v streaming via WebRTC peer connections. Windowed HTML5/JS applications can be developed live within the site itself. There is a feature to stream terminal sessions to each other, in order to show how to efficiently use vim to develop applications, for example.
I try to stay away from the above kinds of sweeping generalizations about the whole thing nowadays. It is best to let it speak for itself and evolve in its own good time.
Also, link number 5, at https://linuxontheweb.appspot.com/shell.os is for people who just want to poke around the deep system internals via a command line. For that, you need to use the "import" command in order to pull in libraries of commands. For instance, running a command like:
$ import fs && vim
should open up my custom-made vim clone.
There are plenty of high-quality mobile apps on F-Droid, even with downloadable source. This is purely a PEBKAC issue.
I don’t see why this means PWAs are better than apps. There’s nothing stopping you from writing an app instead of a PWA in this case.
Lower barrier means it's easier to just publish something small you made for yourself, since it can be free without consideration to loosing money from it.
Rose tinted glasses.
There was a time not too long ago where IE6 was virtually required because of activex, vbscript, ie specific markup, etc.
Apparently it is still unknown to most HNers that PWAs can also use native APIs, depending on how they are distributed.
> Both the above cases would lead one to say “surely there is a app for that!”
I note from his 'about' page that the author is a proud and admirably public-spirited citizen of Oakdale, which proclaims itself "Cowboy Capital of the World". Seems about right.
I'll say it again for the people in the back.
Introduce acronyms before you use them.
PWA is not an acronym. It's an initialism.
In many countries a car without a functional speedometer is not allowed on the road, for safety reasons.
Besides, GPS can only update once a second. And given the signal jitter you can't get a good speed reading from the last two fixes - when you are going in a straight line. When you are not going straight, the GPS based estimate must underestimate the distance you travelled and thus your speed.
Using this toy speedometer thingy for driving is just dangerous and insane and illegal in so many ways that I wish the article could just be pulled from the web.
this is well known in the prius chat boards.
Toyota also knew about it, but instead of making it a safety recall, they put out a service bulletin: T-SB-0172-09 Combination Meter - Intermittent Display
If you search the web for that you will find a ton of hits.
The solution is to replace the entire instrument cluster circuit board. If you have a replacement board, It's relatively easy, maybe an hour of work if you are handy, and there is no soldering unless you have no replacement and want to replace the bad capacitor yourself, and maybe a transistor. You will probably break your A/C vents in the process because they are made of a type of plastic that becomes extremely brittle with age.
There is a guy in Texas, Texas Hybrid Batteries, who will sell you a refurbished dash circuit board for $150 if you mail him yours. Buying a new one is a bit spendy and may require going through a dealer depending on laws, since the odometer is part of the assembly and has to be 'flashed' to what your vehicle was before the swap. However on cars of this age the odometer is often up to about 200,000 miles and exempt from a lot of the odometer laws.
Drivers who want to go fast will go fast - for them the gauge is only useful so they can slow down for speed traps.
Not having a speedometer shouldn't make a sensible driver suddenly very dangerous at all.
of course. Any sensible driver will not drive the car without a speedometer.
I think you missed the point of my comment entirely.
Knowing your speed is not required to be safe while driving - being observant, correctly signaling, and driving at a speed appropriate for the conditions are.
Yes, they really do. Just ignoring the fact that people tend to drive faster when they don't have a speedometer, people already travel too fast for road conditions as a matter of course. Let alone the fact that at residential road speeds, the difference in life expectancy of someone hit by a vehicle drastically changes with even a slight increase in speed.
Safety checks exist because vehicles are roving machines of death driven by easily distracted people, who have a long track history of ignoring what they can't see.
Your life shouldn't be put in danger because some other arsehole decided that it's perfectly fine to drive a rust bucket with nothing more than a sheet of paper left by way of brakes, or with lights that are so badly adjusted anyone else gets blinded, or with windows in a state that someone sneezing will shatter them, or any other number of things.
But yeah, authoritarian government overreach. Sure.
I always come back to a paper some Netflix guys mentioned in a presentation I saw at a conference to make us appreciate how extremely hard integrating separate systems is : "Hundred Impossibility Proofs for Distributed Computing" (https://groups.csail.mit.edu/tds/papers/Lynch/podc89.pdf). The paper basically says there are at least a hundred walls that are mathematically proven to be insurmountable that you are going to potentially hit when trying to keep your data corruption free across systems.
This makes systems that keep data within the bounds of a non distributed, transactionally sound database like Postgresql comparably much more agile and powerful as you don't hit these hundred plus walls.
After some high profile failures of integration like Oracle/IBM's "Phoenix Pay" here in Canada, after people tried to counteract the problems with sophisticated and costly CQRS layers to manage the connections, they are now noticing what was mathematically proven in that paper, that you can't make a maintainable and reliable system when data is spread across too many different companies' servers. I think, at least for tech companies that know how to build stuff, that the trend is now to minimize holding data in a web of connected SAAS services, regrouping key data to their own transactional databases.
This trend has been helped by the fact that, it is now incredibly easy to build frontend and backend services tied to your own database. This "Tiny PWAs" article is a good example. This guy quickly built apps so that he didn't have to deal with ad laden ones in the app stores. As a testament to their simplicity, these apps ended up being only 1.7KB and 800B. This would have been impossible just a few years ago.
See https://docs.microsoft.com/microsoft-edge/windows-runtime. There are examples of what these APIs allow you to do on https://www.pwabuilder.com/windows.
BTW, you can use https://pwa2uwp.fragara.com/ to publish a PWA to the Microsoft Store, without needing Visual Studio or even a Windows machine.
Interesting, there is one speedometer there, created 2-3 years ago. The source code is even available in GitHub. It seems that it isn't easy to find PWAs? https://pwa-directory.appspot.com/pwas/5079866537934848
Speedometer app for example, I bought Ulysses Speedometer a long time ago. The price is almost nothing but over the years they maintained it well and added useful features. To me that is the most time and money efficient solution.
Edit: to be slightly less snarky, that was my experience of the linked site - just one long scrolling blank page. This could be a really simple HTML / CSS page. Why do it as a PWA and add more points of failure?
The footer says it's based on Polymer and Hugo, perhaps they don't play along well with Safari?
Strange how Safari still has trouble with PWAs, web applications were one of the main selling points of the original iPhone...
I thought that only happened after a PWA site had been visited a few times, not on first visit.
Hugo is a static site generator so that has no bearing on the page's behavior in the browser. I don't know if it's a PWA but they used Polymer in such a way that there's no content in the HTML, which is stupid. I don't think PWAs are antithetical to PWE, Progressive Web Enhancement.
Presumably, so that it can be available in his car, when there’s no network access.