Progressive Apps: Escaping Tabs Without Losing Our Soul | Hacker News Reader

Progressive Apps: Escaping Tabs Without Losing Our Soul

infrequently.org

51 pointscpeterso9 comments

[apple-]mobile-web-app-capable yes [1][2] is a non-standard meta-tag that some browsers detect in order to identify webpages who, when launched from the homescreen, want to be treated app-like. (they want you to ditch the navigation capabilities (back, urlfield) of the Browser as they provide their own, for instance)

Add to Homescreen is something that is available as a bookmark-alike feature in most/all mobile browsers. It is user-initiated, so if the user doesn't look for it, there is no prompt (unless the webapp provides it).

The other app-y bits (App Manifest for prefetching and caching the rest of the app for offline use, localstorage webfs and assorted others for persistence, responsive design using the picture element and flexbox) are all provided for webpages as much as app-like sites.

[1] https://developer.apple.com/library/safari/documentation/App... [2] https://developer.chrome.com/multidevice/android/installtoho...

This is something I have been thinking about too and I would love to see standardised. I would see it as an html flag that indicates to the browser the user has the option to run the page in an Atom style shell. The main things I would want when running in privileged "app mode" include:

1. full access to keyboard short-cuts without browser mediation. Web-based tools like spreadsheets really suffer from inability to assign short-cuts for basic features like "add row".

2. no browser chrome e.g. url bar, toolbars, bookmarks etc. taking up screen real estate. Really important when running on mobile but also nice on the desktop too.

3. no addons by default (perhaps a different addon profile) to reduce performance overheads and behaviour conflicts on already performance constrained web-apps. The assumption is that these are tools like IDEs, word processors and spreadsheets.

4. aggressive caching of js/fonts/images for faster load. Even Google Docs suffers from "flashes of unstyled content"

5. cross-platform access to OS features for file-system access. One reason users have lost control of their data into the could is because browser-filesystem interaction is so painfully hobbled. If we used the file-system more then users could choose the dropbox style sync service of their choice rather than be locked in to the web-app developer's hosting. Users becoming responsible for their data again simplifies the web-app developer's architecture and hosting costs.

6. isolated process \ memory space from the user's other browsing activities. As a user, I don't want my office web-apps compromised by a broken video player in another tab of my browser. It would give a middle ground between Chrome's 100s of processes taking GBs of RAM versus Firefox vulnerable single process.

The main issue is that any unsandboxed behaviour would be abused. I wonder if browser vendors could support some type of app-developer certificate system. A nominal fee from a registered company would help track identity and certificates for malware developers can be banned.

unsandboxed behaviour being abused... you mean like all other apps written natively for any platform since the dawn of time? There's no vetting process for Windows utilities or bash scripts you find online. The closest you can get is that it's hosted on a store, but that's a mobile paradigm and is a problem as much as it is a solution.

I know what you mean but if a web page just has to to request "run me as an app" to get unsandboxed access then you know every popup from every shady site is going to have a go. It will kill the feature as dead as ActiveX plugins. I want to have the cake and eat it.

Is there any example code on how to do that? I could not find it in the article.

This is the way Firefox OS wants (wanted? since it's criticised in the article) applications to be.

There's a reason all of these examples show Android. While it's possible to do with Apple, there is no "ask-when-you-need-it permission model" for homescreen - you have to rely on users choosing the buried "Add To Homescreen" option, which they very rarely do.

It's a shame, because you can do a lot with those little homescreen webapps - if it could also allow notifications and/or be opened via URL a lot of apps could be made that way

Chrome for Android had the same buried "add to homescreen" thing for a long time: https://developer.chrome.com/multidevice/android/installtoho...

Chrome for Windows has had "Create Application Shortcut" for roughly forever: https://support.google.com/chrome/answer/95710?hl=en

Neither indicated that a site would work well in that mode. That's a big part of the change: detection that a site meets the quality criteria + prompting.

Oh absolutely. I think this is a huge step forward - I'm mostly just moaning at a lack of cross-platform compatibility in a situation where it would be a huge deal.

What was the rationale for not having a document.addToHomescreen() function? I can see it being open to abuse, but not any more or less than pop-up windows (especially when limited to only being called within touch events and so on)

The abuse considerations were what led us to implement the engagement check. An API for this would absolutely be spammy.

If everyone is going to be calling it on every page-load, and if the browser is (predictably) not going to allow that to show every time (see window.open()), then why provide an API when we could just treat meeting the criteria we'd look for anyway as the same thing as calling such an API?

That's what the Chrome system does: you've implicitly called "addToHomescreen()" on every page load where your app meets the criteria. When we allow it to show is still mediated by the browser.

Chrome 44 is going to allow a measure of control: http://updates.html5rocks.com/2015/03/increasing-engagement-...

The event is cancelable, meaning that if you don't want it to show on a particular page, it'll trigger again on the next. We'll also be adding a way for you to delay the load; cancel and re-trigger inside the same page. The way to think about it is that you sometimes get a golden ticket. We'll give you the ability to spend it when you want in the near future, but making you do an API call when the intent is already clear just seemed like bad design.

Reply on news.ycombinator.com