Beep boop - this is a robot. A new show has been posted to TWiT…
What are your thoughts about today’s show? We’d love to hear from you!
1 Like
Seems like a simple hyphen or dot would do the trick for versioning: as in 20-04. It would cause people to say it the right way. Or 20.04. Or 202004, etc., etc. 20.20.04?
2 Likes
Seems as if Windows versioning and Cortana are something the hosts dread talking about however it ends up consuming half the show, almost every week. I guess if they eliminated those two subjects, it would be hard to fill a 2-hr show on a weekly basis. Windows Weekly is one of the regular shows I faithfully watch.
I was thinking that too.
Can someone explain exactly what bits get downloaded/installed on the local client machine when installing a PWA?
I’m thinking that for a “minimal” PWA, where you just add a manifest file to the web (server side) application/site, the PWA ends up being little more than a launcher of the web app that executes on the server.
But can a PWA download and execute some of the server side code and execute it on the local client?
1 Like
I think that some of the anticipated confusion over this arose when the release was going to be 2003 and someone (MJF, I think) said that it could be confused with “Windows Server 2003”. I think that most people thinking about Windows versions today won’t even know about Server 2003 and won’t confuse the two.
It is more likely for 2003, 2004, and later, 2009 or 2010 to be confused with a more recent year. But I think that most people are familiar enough with the current convention to deal with it.
Yes. And, maybe most importantly, PWAs can run offline. How useful that is depends on the app: Twitter not so much, email a little, word processing a lot.
Google explains it well here: Learn PWA | web.dev
Here’s a great summary from that article:
Progressive Web Apps are:
- Progressive - Work for every user, regardless of browser choice because they’re built with progressive enhancement as a core tenant.
- Responsive - Fit any form factor, desktop, mobile, tablet, or whatever is next.
- Connectivity independent - Enhanced with service workers to work offline or on low quality networks.
- App-like - Use the app shell model to provide app-style navigations and interactions.
- Fresh - Always up-to-date thanks to the service worker update process.
- Safe - Served via TLS to prevent snooping and ensure content hasn’t been tampered with.
- Discoverable - Are identifiable as “applications” thanks to W3C manifests and service worker registration scope allowing search engines to find them.
- Re-engageable - Make re-engagement easy through features like push notifications.
- Installable - Allow users to “keep” apps they find most useful on their home screen without the hassle of an app store.
- Linkable - Easily share via URL and not require complex installation.
2 Likes
I would think it’s slightly different for every application but I assume that instead of a big chunky application written in C++ or some other language the stuff that is actually “on” your machine is a progressive and reactive HTML/CSS+JS application, with the back end bits selectively installed depending on what you’d need to run offline.
Am I way off base with this? I have not actually written a PWA so I’m just guessing.
I think you’re on the right track, although I come from the “big chunky C++” camp and am not really sure how to map “progressive” and “reactive” into real bits.
I installed the twitter PWA via Chrome on Windows. I note that the desktop shortcut points to Program Files (x86)\Google\Chrome\Application\chrome_proxy.exe. I also see a lot of stuff getting installed in AppData\Local\Google\Chrome\User Data\Default\IndexedDB, which is where I think some of the stuff is going.
I’ll have to work through the material that Leo linked to if I want to figure out more of this.
I also suppose that if you uninstall the browser used to install PWAs, all those PWAs either go away or stop working? Maybe chrome_proxy.exe gets left behind and things still work?
From what I understand, you write a PWA to try and work online and if it’s not available, local storage is used for data and resynced when online. The PWA can also cache information locally for use should there be no connection. Similarly when you launch the PWA it will attempt to check for an update.
Microsoft tried some time ago, with ClickOnce applications, to distribute applications from the web and have them automatically update when you next launch. Never really took off widely, but we do use that to distribute a couple of apps on our intranet.
I mean “reactive” like Bootstrap. Code once, works everywhere. Regardless of the unit you are using to access the App, it’ll resize and fit your use case.
Progressive might be a little more ambiguous. Maybe some of it has to do with the backend controlling updates and changes quickly and efficiently without the user needing to do anything.
A PWA is Javascript, running in the browser. It is able to connect to the backend, which could be written in anything. It probably does so via an API over WebSockets using JSON or something like that. It could be the exact same Javascript that would otherwise run in your browser if it wasn’t a PWA. The big difference is that a PWA is designed to be able to use the local storage APIs to cache content for times when it is not connected to the server. It also uses the WebWorkers API to connect to the server in the background to have updates downloaded and chached so that the app is “always” up to date when you come back to it. It can also use other APIs to integrate into the OS like a regular app… things like notifications (for an email client.)