When I first heard someone talking about "Progressive Web Apps" I thought they were talking about "Progressive Enhancement" [1].
Turns out doing a PWA is just basically about using the "Service Workers" API [2] and the practices around that.
This nice article does a lengthy trace on the origins of the "PWA" term [3]. The same guy that started the "Service Workers" spec in Github [4] 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 [5].
I work on the same team (Web DevRel) as the "service worker guy" you mention (Jake Archibald). Alex Russell (who introduced the "PWA" and is now advocating for the "Never-Slow Mode" idea you may have heard about recently) works on Chrome but collaborates with us frequently.
> 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 [2] and the practices around that.
Your first impression about progressive enhancement was closer to the mark. The PWA Checklist [1] is the canonical document about what constitutes a PWA. We created that doc in November 2016 [2] 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.
I think the confusion comes from the fact that one of the key principles of "Progressive Enhancement" was making the site accessible to everyone by providing support for browsers that either don't support JavaScript or have it disabled. This version of the website often also supported much older browsers (e.g. IE6-8, but also lynx, etc) that weren't supported by the enhanced version of the website.
In contrast, the PWA checklist makes no mention of support for browsers without JavaScript or much older browsers (and in practice very few PWAs provide such a fallback, as they are almost all SPA JavaScript apps where implementing this kind of fallback is difficult). As such, it is many ways the antithesis of the original Progressive Enhancement concept.
There are only two real things limiting PWAs in my opinion:
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’s a shame they haven’t budged much on push notifications. I know they have a reputation because they are used so much for spammy purposes, but I see that as a UI problem rather than a problem with push notifications themselves. I think if iOS got push notifications we’d start to see non-spammy use cases, e.g. one-click waitlist notifications and no-install turn-based games. One fun use I've found (I have an Android so push is supported) is getting messages with the loss at each training epoch in Keras (see the side project in my profile.)
I think a reasonable solution on mobile is to only allow push notification requests to PWAs that you have added to your home screen (i.e. "installed"), and removing the app from your home screen should remove the notifications. This way it will function pretty much like native apps, and you won't have to worry as much about random requests for spammy notifications - if I've gone through the trouble to "install" the PWA, then it's more likely I have a higher degree of connection to that app than just some random news site asking if it wants to send me notifications.
> 2. The Web is missing some APIs that would really let it compete with native apps.
absolutely this. i have no idea why the Contact api [1] 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.
Regarding your conspiracy theory, it sounds like this could be a realistic worry, of a conflict of interest among those influencial in developing web standards. The "missing APIs" may be those which would provide more competition to various walled gardens.
I'm not really a fan of conspiracy theories, BUT when you consider that 2/3 of the biggest browser vendors also control mobile platforms, you can kinda start to rationalize it.
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.
FileWriter API existed in Chrome for a long time, but all attempts to push it mainstream failed due to Mozilla. I am curious if the latest attempt gets political backing from all members of W3C. Otherwise PWAs will stay pretty limited for toy apps; with WebAssembly and random local file access they could replace many desktop apps.
And if the standard on all this stuff is delayed, we're risking multiple incompatible APIs on all these features. Case in point: on Win10, PWAs get full access to the platform WinRT APIs (https://docs.microsoft.com/en-us/microsoft-edge/progressive-...). So they can do anything a native app can do - but that code isn't portable anywhere else.
Regarding 2, one point of distributing PAWs via the respective stores is that when their origin is validated, they are also native apps and have full access to all device APIs.
See PWAs on Windows 10, or the recent TWA support on Android.
I am very happy that the web has no more APIs. I'm already tired enough of telling my browser that I don't want any website to send me notifications, to access my location, to access my camera, my microphone. And God knows what goes behind my back. Enough is enough!
That is because of bad usability of the browsers, though.
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.
For comparison, there's old-school Flash, where the permission box for camera/microphone would be overlaid on the bit asking for said permission instead of modally blocking the page, and if you didn't give permission, it would still work fine, just with blank camera/microphone feeds.
Isn't this usability issue on part of the website developer/ux designer too? What you point out is right, but it can also be implemented in a way where you're not outright just calling the function to pop up that little notification asking for [insert api] permission. It might be a better solution where the ux designer/developer has some sort of button the website that then calls that function for a slightly better experience.
" It might be a better solution where the ux designer/developer has some sort of button the website that then calls that function for a slightly better experience"
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.
That was my first reaction. If I was pulled over in Ireland with no dash the car would be impounded.
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.
I'm comfortable with driving without any of those things -- my motorcycle, for example, only has a speedometer and a non-resettable odometer. (It's like that from the factory. Many street-legal motorcycles are similarly equipped.) You know how much fuel you have by knowing the capacity of you vehicle's tank, how many hours or miles you have driven, and your pre-existing (or found on the internet) knowledge of you vehicle's fuel consumption.
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.
That made me smirk. My motorcycle has a fuel gauge, but it's about as useful as a chocolate teapot. It manages a reasonable guess if on motorways. Normal riding and leaning and it may as well not be there. :)
I just do what I've done with every bike, reset the trip when I fill.
I think the tyre pressure warning light is rather useful. Sometimes there's just nothing noticeable until that light comes on and you examine your tyre to find its deformed (heavy load and very hot) to the point of nearly bursting on a motorway at 70mph.
Ok, but it's more accurate than the spedometer in my higher end car, which seems to be off by about 4.6mph lol. I was always wondering why those speed radar things on the side of the road that tell how fast you are going (usually in residential neighborhoods) were consistently showing me going about 5mpg slower than my car was indicating until I checked with my phone gps. So, I was consistently going about 5 mph under the posted speed limit because apparently BMW can't make a decent speedometer gauge!
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.
All speedometers are regulated into slight plus from the wheel speed. This ensures you are not speeding unaware of it.
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.
At least in some places, e.g. here in Germany, the speedometer is never allowed to show a slower speed than the car is actually going, so they err on showing too fast (up to 10% allowed I think) so that never happens, even if you put the fattest tires allowed for the model on etc.
I never had a car that actually had the same speed as I was driving. Always 5Km/H below it. You’re expected to drive 120Km/H where the limit says 120. If driving 121 would give you a fine that would be problematic.
Most places I know about require that all driving-related equipment your car is fitted with should work. E.g. it's fine if your car has no ESP or ABS, but if it does it has to work. If your car had no turn lights or seatbelts originally it passes the inspection, but of course not if they simply don't work.
So perhaps if you drive early model Ford T no speedometer is fine, but otherwise seriously doubt it.
It's not, but it would only show up in annual or bi annual safety inspections, if their area even had them. In the US it's on a per state basis, with emissions testing on a county level in some states.
Where I live (Indiana, USA) the authorities would only find out I had a dead dashboard if I got into an accident and they discovered it while investigating. 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.
Or if they pull you over for something, but then the first thing they ask is to turn your car off so they'd never see it anyway. Usually you pull over, turn your car off and put your hands on the steering wheel so when the police approach they know you don't have a weapon in your hands, or at least that was the etiquette I was taught.
> 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.
Depending on the state in question, there can be many exemptions for those tests - e.g. if a car is new enough, and certified to comply with some standard or another.
This is the case in most (AFAIK) of the US. Wikipedia has a map[1] summarizing required inspections state-by-state. Only ~1/3 have safety-related inspections. Emissions inspections are a bit more common, but nowhere near universal.
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.
What happens to your PWA page weight when you add tracking and ads to it?
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.
The other, largely unspoken, downside to PWAs are that the user cannot block the tracking and ads in them when launched natively. Even though they might run on your android where you have firefox mobile with all the adblocking extensions enabled, and run that PWA in the browser. I'm sure this might be another reason why PWAs are being supported by the advertising industry platform suppliers.
I've "installed" this PWA via Brave on Android. So it now runs upon the Brave engine when I launch it, I suppose. I hope Brave continues to block trackers when executing "installed" PWAs.
Speaking of Firefox, there was Firefox OS which appeared to be a stillborn child. It's app distribution model likely was close to PWA's. There's also Chrome OS which has lived longer than its foxy twin, and is going to be incorporated into Android according to wiki.
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?
I was completely distracted from your point when you mentioned the "foxy twin" of the "stillborn child". I know foxy had a double entendre here, but...uh...disturbing choice of words.
doesn't that live on as KaiOS. kai is heavily controlled by some indian company(to the point where you can't even publish apps on it's store without that company's approval) but atleast it's alive
Where do you see the google analytics code in the speedometer? It's true that the site his example is running on includes GA, but I can't see anything in the source other than a reference to an analytics build which uses a file that only exists if you choose to create it.
That's on the actual site, isn't it? I acknowledge it's there, but the person I originally replied to claimed it was in the source, which I don't think it is.
> What makes sure you will keep paying the, admittedly modest, hosting costs for the app?
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.
Hosting static content can be done for free. Looks like he's using Firebase, but I believe you could host it on Netlify/Github Pages for $0, since there's no server side work being done.
Good point. Looks like the Firebasee free tier hosting limit is 10 GB/month, so if his speedometer is 1.7 KB, and PWAs only need to be downloaded once by each user, that's ~5.8 million new users/month for free. So basically free forever.
> “surely there is a app for that!” A quick look leads to speedometer apps with ads and 30MB download weight, and simple screen light that also have ads that weight in at 5MB.
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.
Exactly. If more people's reaction, instead of searching an app store for a privacy respecting screen light, was to sit down and write:
<!DOCTYPE html>
<script>let on true;</script>
<body onclick="on = !on; this.style.background = on ? 'white' : 'black'">
and were able to easily upload it somewhere on a phone and run it locally from a shortcut on the screen. We'd have hacker culture encouraged right there.
Upload? Come on, just load it as dataURI, bookmark it and you have offline "application" at your disposal. And as a bonus, here, have this "distributed app store" you can even print on paper [1].
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
Yes, such "offline bookmarked dataURI applications" are great, underappreciated and ancient things. Sadly, current trend in modern browsers is to suppress them in sake of security, because in the past some crooks misused them them. Currently you cannot even link to them like you could in the past; anything other than direct navigation from bookmark or URLbar results in better case in blank screen, in worse is silently blocked. For example in the past you could redirect to them, or make datauri editor that encoded itself into another datauri, or both [1], but now you can not [2].
The built-in QR detector is very finnicky/odd, apparently it just assumes every payload is an HTTP URL, nothing else works even remotely.
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.
Yes, I had no luck even with QR reader integrated in Nightly Android [0].
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.
I'd love that but I don't think it'll encourage hacker culture. Instead we'll have the Can-Code making things for the Can't-Code like we do now, but with even fewer checks for nefarious activity.
Case study: people copy-pasting random code into their Myspace profiles
I wonder if https://glitch.com has a mobile-friendly IDE and will also let you set up a project to be a PWA? Seems like it'd be a great fit for what you're describing.
Hmm... When I pulled up one of my Glitch projects on my iPhone Xs the browser-based editor works but the editor view is either cut off on the right in portrait mode or almost offscreen when the keyboard displays in landscape mode.
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.
You can do that with mobile-web-app-capable and add to home screen on both ios and Android. No address bar and it looks like any other app. You need to host the site though.
Running it from file:/// of the phone's local filesystem could be more hassle-free. Not sure if it would be bookmarkable, but I don't see why not. I don't have access to a smartphone to try.
I agree the loss of control is unacceptable. I agree that only being able to get commercial apps like this that monetize through advertisements and selling opaquely-gathered tracking data is unacceptable.
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.
Similarly the problem with JavaScript on sites currently is not only download time and request count bloat. It's significant by itself, but it just takes time to even parse all this code and I did not start on execution.
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.
I think it's worth distinguishing install time from subsequent launch time. You seem to be describing the time it takes to go from seeing the app to using it for the first time. For an app you use regularly (or even just more than a few times ever), how long it takes an already-installed app to open from cold start seems like a much more important metric.
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.
I'm not sure of that. Plenty of my friends and family in the UK are using phones that are a few years old and only come with 8gb or 16gb of storage, such that they are regularly running out of storage space.
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.
In fact, the web browser is probably the most accessible place to roll out a whitelisting-based permission system. It has already been demonstrated successfully with uBlock Matrix and uBlock Origin -- you can block specific types of activity coming from specific subdomains. Some sites break completely when you block the few specific elements you don't want to see, but most work just fine, or at least close to fine. Being able to whitelist specific Javascript APIs (e.g. the battery API, the ambient light API, etc) is a logical next step in my opinion.
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.
I would argue that it failed to be successfully demonstrated with uBlock, as my premise was about regular users, not consumers with technical skills to go into browser settings.
I started building something I like to call "Linux on the Web" (LOTW) 6+ years ago in order to start working on this problem (it's live on the web right now). Just like with node.js applications, the smallest legal file size for an app running inside of LOTW is precisely 0 bytes. I've tried to shave that down even more, but I seem to be running into physical limits :)
Can you share a link? People reading your comment have no way to know how to learn more about your project, or even whether it is relevant to the topic at hand.
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.
I think that is the one actually because the looking at the post history [1] of the person you are responding to I find that the most recent post they made in the past was one titled “Linux on the Web” [2], which leads to that very URL that you found.
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.
Hi, yes, that stuff is from quite awhile ago, seeing that NaCl/PNaCl is quite dead, and WASM is now all the rage. I previously had actual vim running via NaCl, but the current (better IMO) version is just a fairly small JS clone (about 70kb). The whole system is rapidly stabilizing right now, what with the entire gui framework being fleshed out, both conceptually and technically.
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.
Did you try the "desk.os" link that is link number 3 on that page... https://linuxontheweb.appspot.com/desk.os ?
I can really only guarantee that things work on a relatively recent version of Chrome (like within the last few stable releases). The version that is live now is a couple weeks old. I'm working on some really cool features for the modular synth app right now. I'd love to start sharing this stuff with you guys!
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:
> 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.
There are plenty of high-quality mobile apps on F-Droid, even with downloadable source. This is purely a PEBKAC issue.
Less development setup required (you can make a PWA with literally just a text editor and a place to upload files), very easy to distribute, free to distribute, cross-platform (although here progress is still being made).
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.
I've argued both sides of this for a long time. The short argument for web apps are that you have real control over them, which means any platform, any time. An iOS app from five years ago is useless without recompilation with the current toolchain, and even then it only works on iOS. A web page from 1994 still renders unmodified today, on any platform, and will for the foreseeable future.
Yes, there are always ways to lock yourself in. If you only use features supported by multiple browsers and consider the https://en.wikipedia.org/wiki/Lindy_effect, you stand a decent chance of long term survival. What you sacrifice is efficiency and polish, which are important, so choose wisely.
Google/apple don’t provide tooling for users to control ios/android app, and most apps are compiled without source code available / verification of the binary. With a web browser you are actually executing interpreted code so it’s easy to read the source, block ads etc
Pls. God no.. Why this obsession with apps when a simple PWA does almost all you need. Apps are akin to what the windows app were a one and half decade back. Like web apps blew 99% of thick client app to oblivion the same is going to happen soon to the mobile apps. It isn't without reason, why Apple isn't too keen with this development (they were one of the last to implement web workers and PWA in their browsers). I hope they learn from MS' mistake and embrace PWA rather than try to impede
> You see my car, a 2005 Prius, has a terrible glitch in the dashboard where the dash simply doesn’t work. No speedometer, no gasoline gauge, nada.
> 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.
(It means web pages that use JavaScript to gain access to some “app” features, like offline-functionality and the device sensors as shown in the blog post.)
Progressive web app. They're kind of like JavaScript-driven websites that think they're native apps. They tend to be characterised by their use of modern web standards to do some useful things, like being available offline, and caching everything heavily to cut down load time. It's like a website you can install, basically.
Holy crap it's scary that he's building his own speedometer like that. GPS based speedos aren't all that accurate. Ballpark, sure, but not accurate. There are also many circumstances under which GPS won't work.
In many countries a car without a functional speedometer is not allowed on the road, for safety reasons.
How inaccurate is GPS? It seems like for his purposes a variance of even +/- 5 mph could be tolerated given one can generally sense approximately what speed they're traveling and can also compare themselves to other cars on the road.
GPS is susceptible to atmospheric conditions, obstructed views (4 satellites minimum required for positioning) and a number of other factors, most of which are undetectable at the device level. Car speedos are done with over-read deliberately as a safety measure. Better overestimating than under. As a driver you can make conscious decisions about what speed you're driving based on all evidence available, including an understanding of how over/under your speedometer returns results. With a GPS based speedometer you can't realistically do that, you can have no idea what the accuracy percentage is at any particular moment in time. It might be over, it might be under. No one can make good decisions based on junk data.
Soeedometers perform the most precise measurement you can get. When you fit a nonstandard tire you just introduce a constant scaling factor. That is not so bad. GPS on the other hand is atrocious. Don't even try to get an accurate position in places like downtown Seattle. I'm regularly getting misplaces by several blocks because of occlusion and reflections from the buildings. You just can't compute an accurate speed from such a signal.
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.
I might have this wrong, but I seem to recall reading somewhere that speedos in the EU have to overread by some random amount, with the aim of curbing speeding.
the second generation Prius 2004-2009 has a dashboard instrument cluster flaw where the capacitors go bad after a number of years and it stops working.
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.
If our drivers were smarter, we wouldn't need speedometers at all. Nobody thinks "I'm going too fast" then looks at the speedometer and decides "Oh, my speed is fine".
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.
Why not? Do you think any sensible driver would overshoot/undershoot their speed by any meaningful amount without noticing? Like without a speedometer everyone would just accidentally go 100mph everywhere or something?
> 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.
And many countries are authoritarian shitholes who care more about revenue generation than protecting people. People don't need a speedometer to drive safely.
> People don't need a speedometer to drive safely.
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.
Not sure if there is anything progressive about this but it's small, has a manifest so it will supposedly get cached, and is installable I think. Wrote it for similar reasons, sick of ads.
This made me think about building your own services vs integrating others and I can't help to think rolling your own makes more and more sense.
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.
This was cool and inspiring to read. I too enjoy making little apps to meet my needs and it was educational to see how someone else structures their tiny projects. Not just the projects themselves but also the lil domain they're hosted at.
It's a website built to a standard that Google created, and when a site is built that way Google and iOS treat it like an app. It can be "installed" on your phone and used like a normal app.
While such access is still hard on Android (see https://news.ycombinator.com/item?id=19057673) or impossible on iOS, you on the other hand can easily call all the WinRT APIs from JavaScript if you distribute a PWA on the Microsoft Store.
If you do like the programming challenge then fine. Speaking for myself, I spend too much time working with computers already. I just want a practical solution and spend time doing things I enjoy.
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.
Tiny PWAs and why they don't render until you force refresh on mobile Safari.
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?
Is it a PWA? I didn't get the normal "add to your homescreen" popup and manually adding it to my homescreen adds a bookmark instead of opening in a separate instance. I think this is just a regular old website with strange javascript libraries.
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 didn't get the normal "add to your homescreen" popup
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.
Looks like there are OS-specific oddities at play. I see an 'Add to home screen' prompt on android, it installs with a custom icon, and then opens in a chromeless browser.
Ah, right. I was confused because everything worked fine for me. Although, believe it or not, after reading this comment, I went back and saw the exact behaviour you describe! (Safari, iPad)
System on my old laptop had somewhat broken battery indicator in systray, so I ended up using simple HTML page polling / listening to navigator.battery changes [0] and displayed it, even in a "graph" form (in fact, just didn't redraw old values, so it was a side efffect). That worked pretty well, but then whole API became obsolete because of fingerprinting abuse. Ah, days of yore.
I think it would be easier to build an Android/IOS app if you already have the dev tools installed. Chrome APIs needed for web apps that interact with hardware are often unstable and not supported on all hardware or android patch from vendors. I built a simple app to submit links to HN, took maybe an hour, without much Android knowledge.
Turns out doing a PWA is just basically about using the "Service Workers" API [2] and the practices around that.
This nice article does a lengthy trace on the origins of the "PWA" term [3]. The same guy that started the "Service Workers" spec in Github [4] 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 [5].
1: https://alistapart.com/article/understandingprogressiveenhan...
2: https://jakearchibald.github.io/isserviceworkerready/
3: https://medium.com/@amberleyjohanna/seriously-though-what-is...
4: https://github.com/w3c/ServiceWorker/tree/c49c878cdcbaf7a81e...
5: http://offlinefirst.org/