Just a little heads up: Google is still trying to convince everyone that web apps don't suck If insanity is doing the same thing over and over again and expecting different results, Google's Chrome team might be a candidate for involuntary commitment. The ad biz's browser boffins are presiding over yet another Chrome Dev Summit in the hope of putting web applications on equal footing with native applications. "We …
You assume we have a network connection. Never assume: it makes an ass out of you. Some tasks can be presumed to have a connection, email & web surfing primarily, but others like a spreadsheet, document editing, calculator, solitare, or just looking at family vacation pics are not among them. Sure we MIGHT do those things through a web interface, but what's the point?
I've got work to do, I need it to work just as fast as the desktop running the program, not to have to wait for a site to load, refresh between each action, & eventually cough up the results. If I'm editing video & have to wait for a web based interface to react to the task at hand, it's going to take FAR too long to be of any real benefit to the user. If I'm dealing with a locally stored, locally generated, & locally maintained database file, relying on a web interface to interact with it seems rather counterproductive.
A SmartPhone may need a web based application in order to Get Shit Done, but then I can't imagine writing a PhD dissertation on your SmartPhone...
PWAs are a mess
You seem to be conflating two things: PWAs and Electron/Node.Js based desktop apps.
PWAs are great additions to websites and easy to implement for mobile devices. Electron isn't required as they just need a browser runtime. Lots of apps can be implemented as PWAs and distributed without having to use an app store.
Bridging the gap from mobile to desktop is part of the ChromeOS everywhere strategy which is less interesting and more of a challenge. Some desktop/mobile apps work well – Telegram seems well done to me – others less so.
I'm not confusing it, JavaScript just does not do convincing desktop apps no matter how the app got there. This is what AC wrote:
Offline capability exists and in many cases would run just as fast as a traditional app.
This is just not true. If you think it is, lay off the kool aid.
"Given that a lot of apps are just a webview that talks REST to an http server I think it is a reasonable claim."
No it's not. REST has nothing to do with rendering, ps scheduling or even simple things like FS access or user perms. REST is a glorified, text based transmission for web APIs that are _NOT_ built on web apps. As the article describes, the new ones will still C/C++ and in Chrome only, as most other browsers reject most of Chrome's new API "standards".
All that said, yes you can put apps on the web, but once you cross the boundaries of application from a simple calendar to a spreadsheet editor, you notice the creep (good luck with WebGL, it just isn't happening). The only exception would be serving static frames in a web app for something like video chat, just don't make that chat interactive like a game.
"..."make the web a first class platform "
The question is: first class for whom?
Google and their data grabbing pals?
People with FTTP or those living in areas where the ISP and telecoms companies have decided that it is profitable to deliver gigabit connections?
If you are not in one of these groups, and I am not, then I reckon that you will be out of luck.
And anyway, who wants to put their critical applications and data onto the internet? As far as I can see that's just asking for trouble.
No it's not. REST has nothing to do with rendering, ps scheduling or even simple things like FS access or user perms
I never suggested it was I specifically referred to the huge number of apps that do depend on REST. Of course, it doesn't work for everything but for all those travel & search apps, it's great idea.
"I never suggested it was I specifically referred to the huge number of apps that do depend on REST. Of course, it doesn't work for everything but for all those travel & search apps, it's great idea."
So, calendars? The "apps" you're talking about are probably already webapps run in a sandbox. What Google is talking about here, is to pull you aboard their "Chrome as your desktop" strategy so they can get you off of KDE, Gnome, etc... and possibly off your OS onto ChromeOS. This is a lock in play, but I don't think that even Google thinks they can fool you (it's probably just a few dudes that just can't give up hope on Google dictatorship).
I strongly disagree with this assertion. PWAs threaten to make the web an even more dangerous and hostile medium than it already is.
How exactly? Service workers have no access to the DOM and all code is tied to the origin. I'm no fan of Javascript everywhere, and particularly dislike SPAs ("Single Page Apps"), but baseless scaremongering helps no one.
How can I secure a WPA so that it cannot communicate over the internet? I haven't really figured that out, and unless I can do that, they are too risky to use.
Any code that executes in your browser without you specifically asking it to is a security risk. Doubly so because it's inside the browser, where it effectively masquerades as your browser and therefore can dodge external security mechanisms. The more capabilities that are made available to that code, the more dangerous the situation becomes.
What I see WPAs as doing is unnecessarily escalating the already furiously heated battle between attackers and defenders. That's really why I object to the notion. Why do we want to do this? In the end, it only makes the web less usable to the masses.
If you want to make an application, make a real application. Don't tie it to web engines.
"Offline capability exists and in many cases would run just as fast as a traditional app."
Yes, and those cases are when you're comparing them to poorly written traditional apps. Regardless of that, the ability of PWAs to run offline is not a selling point for me. Just the opposite. I don't want the risk of mistaking a PWA for a real application.
As has been commented, you wouldn't do high end video editing on a PWA, that's ridiculous and offline use is available and pretty seamless.
Think of about 25 years ago when companies used to create PC applications to download to view their product catalogue or even early purchase of goods etc. You would never download an application from a company onto your PC nowadays - just to see marketing information or a function specific to that company. Even most general applications are now served over the web - for some of our users all the applications they use are web based.
So imagine a situation for a company that has a good web presence, an ecommerce site, useful tools and functions a backend that has api links into third party products. Your marketing department now want 'an app'. Marketing: "we need an APP", You: "Why?", Marketing "Everyone has an app it's embarrising we don't have an app".
You now have a choice, go to an agency to build an app in two different flavours that duplicates 80% of what your website does only you need to create separate version of it for each mobile platform and get it accepted by an app store and risk that any fees on it have to be paid to the respective app store owners. If ever your third party links get changed significantly you have to update all versions at the same time and disable all the old versions that people may have. All information and data needs to be update the same on every platform - web/apps. Your marketing department when they change web information using their CMS now need to add requests into the app agency to make changes as well and publish a new version.. etc...etc
Or you can wrap the website in an app skin, or read in the CMS information from the database directly and remember to test all changes to the information on every platform...or...
Yo ucreate a responsive website for your web that works perfectly on all platforms and utilise PWA on the mobile side to add app like functionality such as an app button, offline use, GPS, notifications etc with one code base to maintain, one web development team, one CMS, write once run anywhere etc etc.
The PWA part just means you don't have to go native for when the marketing department says "But we have to have an app as we want to use xyz functionality of the phone".
You would never download an application from a company onto your PC nowadays
I agree, a native application for things like ordering products is just a duplication of effort if you have a web based version, but aside from the 'have to have an app' internal pushes you have users perfectly willing to install any and all sorts of rubbish on their phones..
Native apps are fine for applications that need the efficiency and speed, but cause phone platform lock-in where user is locked out if their device can't run Android or IOS apps.
"Think of about 25 years ago when companies used to create PC applications to download to view their product catalogue or even early purchase of goods etc. You would never download an application from a company onto your PC nowadays - just to see marketing information or a function specific to that company."
True. I wasn't willing to do that 25 years ago, and I'm not willing to now. But I see no reason why PWAs would be needed to accomplish this. A normal web site does the job nicely.
Leaving aside the issues of throughput, downtime etc. The main problem with web apps is that they tend to assume some form of cloud storage and push towards subscriptions. Surrendering your data to some organization that may or may not support your data/workflow in a few years time is suicidal.
The web is ephemeral and so are its apps. How many web based systems have gone? How many change their fundamental agreement between the user and app? There is no guarantee that any web app will be there next week, or won't have changed such that it no longer supports your workflow
You are far better long term relying on an app that you can download, that runs on your own hardware, and where you retain control of your data. Use the web for communication, and offsite storage.
At John Lilburne, re: the cloud.
By all the Elder Gods & their noodly appendages, THANK YOU! Someone finally states the fekkin' bleedin' obvious. The moment you put your business eggs in someone elses basket you can kiss your business goodbye.
"$X as a service" is a marketing euphamism for "we'll fuck you over when you cease being a cash cow." If they decide to change something that breaks a function you require, you have no fall back except to claw all your data back & try to start from scratch with someone elses product. If you download a program & an update breaks it, you can always uninstall the update, restore the function you need, & get back to work. Even if you have to completely uninstall, scrub the system of every last trace, & reinstall the program from the original download, you've still got the ability to go back to a point where you could Get Shit Done. You can't do that with a web app (unless you are the one writing it).
MS has proven what a SNAFUBAR "software as a service" can be, just look at all the UI changes & subsystem breakages to start the migraine, and relying on such a basket is a quick way to lose all your eggs.
A web app is code (js/html/css) loaded from an internet endpoint.
A native app is code loaded from disk.
After that, both can make the same mistake and assume that a network is available when its not.
The advantage to a native app is the app can load even without a network. A web app *could* load without a network if it had loaded at least once with a network, but that's really up to the browser and the developers of the code.
The advantage to a native app is the app can load even without a network.
If the native app is delivering internet content there's no advantage whatsoever.
And as an awful lot of applications merely exist to harvest user data and stream it back to HQ there's little incentive to build something that does run sans network connection.
The only reason native is usually chosen over webapp is market research tells them it'll be better recieved, and other positive metrics.
"The advantage to a native app is the app can load even without a network."
There are far more advantages than that. A native app is also faster and more efficient, can make use of special abilities of the platform it's built for, won't change unexpectedly because the developer decided to change something, can be more easily managed from a security point of view, and so forth.
I actually had a use for this for a prototype eye exam device that never went past the clinical trial phase (unfortunately), but that's the world of new product development...
In short, there was an android fondleslab that became a remote controlling device for the equipment, which also had some live video feed and charts and command buttons and whatnot. It was quite literally a web site on the LAN, but it looked like you were running "an app".
The web server [written b me] was also a device control application, running as a daemon under Linux. The slab and the linux box were connected via a wifi access point. The serial output from the Linux box went to a microcontroller, which did things on the equipment, involving various blinky lights and stuff. The camera was a regular USB web cam, re-purposed to take continuous video of a patient's eyeball.
To prevent the web page from having unnecessary "decorations" around it, I embedded it into a 5 line (or so) "web application" wrapper app thingy that basically invoked the web server on its hard coded IP address and let you navi-guess it via the slab, without any of those Chromium decorations etc..
So I guess in a "light client heavy server" application like that, it made sense and free'd up some screen real estate.
We know it frustrates you when people run apps on iOS or applications on Windows, and you can't see what the users are doing like you can with Chrome for web activity and Android for Play Store apps. Sorry, you don't need to see what every computer user on the planet is doing all the time. No one wants that dystopian future, go away!
PWAs are an open standard and are utilised by every major mobile browser to some degree - admittedly Safari is slow to the party but it is always generally a few years behind the curve on the latest standards.
In reality it is far easier for Google to make money by having apps in the Play Store than it is using a PWA. In the Play Store they get a nice chunk of the initial sale and any ongoing in-app purchases, it is also far easier to incorporate Google's advertising system. On the web they get no money, can't dictate your browser and it is a lot easier to insert advertising engine of your choice.
I'm going to have to disagree with you there. I'll grant that installing a binary that is untrusted is a security nightmare, because it has a great deal of access to the disk. The other side of that coin is that granting a web app access to the disk also lets them have similar levels of access. It may be sandboxed, but there are infinitely many security problems allowing things to exit their sandbox or run stuff inside their sandbox that affect things outside it, E.G. putting some malware in there and using the scheduler to run it. So don't allow anything untrustworthy to have access to your disk.
On this front, binaries have an advantage in that they can quite easily be loaded into virtual machines, taken apart, run through malware scanners, blocked by security policies, run inside custom sandbox products, and the like. Most of these things can't be done easily or at all with a web app. You can run it in a VM, but the code still knows where you are because it can require a network connection to start. Most other things in the list are completely impossible. What's more, a binary doesn't change itself, or if it does, you can find out. A web app runs the latest code that was pushed to you. That new code could be an update from the authors, the result of someone getting into the server, a result of someone changing the source for a nodejs component, or someone deciding the application doesn't need to exist anymore. This leaves a large landscape for injection of malware, and I don't want it.
In addition, there eventually comes a time where you need programs with disk access. When dealing with data, sometimes you want more than one program to be able to modify it. You use program 1 for some functionality, save the file, and use program 2 to do something different. Web apps are going to make that a disaster. For example, I give you the app mentioned in the article that compresses images. We already have a bunch of tools that compress images, and they can be quite fast. Does the web interface add anything to this process, even assuming it does the job as well as something using the GPU for the math? Somehow, I doubt it. A graphical program with access to the disk can make it really easy to do batch compressions. A command line program can allow scripting of the compression process. A web app can... it can compress images. What is the benefit?
Mobile OSes shown you can sandbox native applications as well - it's not really that difficult, it's just what the OS APIs let them do. Java and .NET promised to sandbox applications as well, even if many ways to evade the sandbox were later discovered. WinRT and UWP applications are another example of native sandboxed applications.
The problem of sandboxed applications is their little interoperability with other ones. If the applications are wholly self-contained, say a streaming player, or a game, that's not an issue. But for applications than need to interoperate with others - say an email client that needs to receive or pass data to other applications, or the OS itself (i.e. to attach a log file...), that becomes a far bigger issue.
But you say "untrusted" - that's why digital signatures of executables are not a bad thing, of course if the trust chain is reliable.
"Mobile OSes shown you can sandbox native applications as well"
They have? I can only speak to Android, but I don't think that's been shown at all. While it is possible to distribute and run native apps on Android, there are very few in existence. Almost every Android app you've ever run has been implemented in Java or a Java derivative, and Java applications are not native applications -- they're running in a VM.
At least with a locally installed application I can decide not to install the latest and supposedly greatest version, in which functionality has been removed, broken or changed so it no longer works the way I want it to. With web apps the provider has free range to change whatever they want.
However, that problem fades into insignificance compared to the lack of privacy with your data being examined on their server. No thanks, Google, not a chance.
Damn effective in reducing the file size of an image, I must admit.
Then, to see if there was any phoning home during the process, I quit it, relaunched it, and cut my WiFi. It worked a charm. Of course, I still need the WiFi to call the page, but it does not seem to do anything network-wise once it's launched.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
