Re: Programs With Attitude?
No, they're exactly what they say they are; Web Apps made by Progressives (with the expected LACK of competency and quality expected from that group).
Microsoft and Google have been working together to help make Progressive Web Apps (PWAs) easier to publish, in the hope that web apps will one day compete with native apps on mobile devices. For the past few years, Google has tried to imbue PWAs with the technical means to match native apps on Android or iOS in terms of …
This post has been deleted by its author
Apparently I'm supposed to believe it's normal to thrash the CPU so much that even when the "app" is idling in the background the laptop runs at 60 degrees C.
Admittedly it's a laptop from 2012 but even so it has no problems running anything else.
PWAs are not Electron - that's rather the point. It avoids the bloat of having to bundle a whole browser with each application in favour of the already installed one.
FWIW I've pretty much abandoned native Outlook in favour of outlook.office.com installed as an app, seems generally faster, with some nice new features that are not present in the thick client. Memory usage seems to be very similar at about 280MB and CPU usage is negligible. YMMV of course.
There is no difference with a webpage or an app that will be constantly processing code.
"My thoughts were the opposite. PWA's don't have as much access to the hardware as native apps. Even when they eventually do, how is this different from native apps now?"
Let me count the ways. Um ... sorry, lost count somewhere around twenty three and I should keep working. Fine, here's the short version:
Current mobile operating systems have put a lot of work into sandboxing apps. They don't all do it right, but they mostly try. Users can generally block certain permissions and it isn't trivial for an app to circumvent a denial and get the data anyway. Similarly, it's usually difficult to have one app suddenly start reading the resources of another app. That's unlikely to be the same for a web app, if only because all the sandboxing would have to be started again. Of course there will be protection from accessing the location permission, but will the permission system be as granular? Will it be secure against circumvention attempts? Will it include any sneaky access methods because Google is building it?
In addition, a web app has a very different security profile to a native one. Web apps tend to use a lot of libraries. Those libraries come from really nobody knows where, or sometimes we do know and we might feel better if we didn't. Each of those places can get modified to introduce new code. Since these are progressive, update frequently, move fast and break things apps, our devices would be pulling this new code down and starting to execute it. At least with a native app, the library has to get tampered with, pulled down for the build, and released to the traditional channels. That might not be a reassuring shield but at least there's a shield.
Another issue is with privacy. Theoretically, analyzing network traffic from a web app isn't more complicated than with a native app. In practice, it's trickier. If you are able to intercept apps' traffic to block it, a web app can more easily disguise itself as a browser. Since the app needs to stay up to date, it must ping a server all the time, and because devs are lazy, there is a reasonable chance that it will require a server to function properly. While any app can require a server, it's more likely that a native app which cannot pull libraries from a server will function without one than one which requires a server pushing libraries for installation.
That's the short version. I should probably stop writing now.
I'm not convinced by your argument. They still feel similar.
"Similarly, it's usually difficult to have one app suddenly start reading the resources of another app. That's unlikely to be the same for a web app"
This is what the same origin policy is for.
"Web apps tend to use a lot of libraries. Those libraries come from really nobody knows where"
Native apps also depend on libraries.
"Another issue is with privacy. Theoretically, analyzing network traffic from a web app isn't more complicated than with a native app. In practice, it's trickier."
Security through obscurity.
But if you use websites or use apps at the moment you are more likely to have data mined.
PWAs can work cross browser, cross platform and don't require any tracking so it is up to the website whether they track and with whom and that is based on your browser settings.
Data tracking is an issue but PWAs don't make this any worse (for the end user), in fact in some cases they make it better.
What's more bloated, having to write a app for three different platforms (Android, iOS, Web) and have it hosted in multiple app stores (with different requirements and rules) to display similar content or wrap up a web page in an outer wrapper, or write a single web site that serves Desktop, tablet, mobile and now also pseudo installs as an app?
Single development team, single code base, easy to maintain and keep everything synchronised.
Apps remind me of the days when you'd visit a website and they'd make you download some software (or get it on CD) to view their catalogue, rather than just having a web searchable product catalogue with e-commerce site.
I've been playing too, and I'm not sure that you're right about the fees - no-one seems to be talking about removing the option to "add to home screen" in Chrome/Safari, which is the old way to install PWAs. As long as this mechanism remains, PWAs *can* remain free of embuggerance by the app stores.
AFAICS as long as this option remains the option to include PWAs in the stores just means wider visibility, coupled with access to the stores' payment gateways - as detailed in the article. I can see how this would be interesting for developers aiming at mass markets - while those of us developing PWAs which are not aimed at the mass market (mine are components in larger bespoke web services) can continue to make them available from our own websites for free.
But if the OS providers start to talk about removing the Add to Home Screen option, and allowing installation *only* via the stores, then you're right and all bets are off.
It would make zero sense to only allow PWAs via an app store.
However if you want to use their payment system then you might well have to pay a percentage.
I think Apple's reluctance in the PWA arena has been solely around the idea of losing income and control that the App Store gives them.
Apple are doing their best to spoil this particular advantage by dragging their feet on implementing newer browser features in Webkit while also prohibiting you from installing competing browsers on iOS (yes I know you can now set "Chrome", "Edge" and "Firefox" as the default browser but all are just wrappers around Webkit on iOS). Anyone would think they had a vested interest in forcing you to use the appstore.
Biting the hand that feeds IT © 1998–2020