Re: alternatives to desktop/Android web runtimes

[Benjamin Francis]

Hi Myk,

Sorry for being late to this thread but I just wanted to speak in support
of "Progressive Web Apps" and to highlight the difference between web apps
and apps which are built using web technologies.

As I've said before I'm in full support of Web Manifest, Service Workers
and Push for Firefox with a standalone display mode for Firefox similar to
the web runtime, but using Firefox' instance of Gecko. I'm looking for ways
to help move this forward.

Solutions like Cordova and Electron are cool uses of web technologies, but
they are not web apps because they don't have a URL on the web. I'm
interested in a Graphene/Electron-like approach to create HTML-based chrome
from browser.html and Firefox OS (and possibly even Firefox), but separate
to web app support.

I'd like to hear more from anyone interested in working on these areas.

Thanks

Ben

On 27 January 2016 at 00:51, Myk Melez <m...@mykzilla.org> wrote:

> Over in this firefox-dev thread <
> https://groups.google.com/forum/#%21topic/firefox-dev/WV2XkVN3sWQ>, I
> decided to disable the desktop and Android web runtimes (WebRT) <
> https://wiki.mozilla.org/Apps/WebRT> for Open Web Apps <
> https://developer.mozilla.org/en-US/Apps>. After they're disabled, what
> are the best alternatives for running web apps with native capabilities on
> desktop and Android?
>
> There are a variety of promising options, and I'm not an expert in any of
> them, but I've listed them below along with my thoughts on which ones would
> work best for various use cases. Did I miss anything or get anything wrong?
> Please clarify and/or correct it!
>
> Progressive Web Apps
>
> Progressive Web Apps are web apps that use existing and emerging web
> capabilities to obtain a compelling and competitive set of characteristics,
> including network independence (i.e. they work offline), push
> notifications, and native affordances like high-quality homescreen icons
> and permanent fullscreen mode. Like Ajax <
> https://en.wikipedia.org/wiki/Ajax_%28programming%29>, responsive web
> design <https://en.wikipedia.org/wiki/Responsive_web_design>, and Offline
> First! <http://offlinefirst.org/>, Progressive Web Apps represent a way
> of developing apps rather than a specific product for doing so.
>
> Alex Russell's blog post Progressive Web Apps: Escaping Tabs Without
> Losing Our Soul <
> https://infrequently.org/2015/06/progressive-apps-escaping-tabs-without-losing-our-soul/>
> is a kind of manifesto for these apps, and this route is the most like
> traditional web app development and distribution, since it uses only
> standard (albeit non-universal) APIs and decentralized distribution from
> any web server to any web browser. It also has the benefit of being able to
> gracefully degrade on older browsers.
>
> Some "progressive" capabilities require an SSL-enabled server, however.
> And this route doesn't enable you to access privileged Web APIs <
> https://developer.mozilla.org/en-US/docs/WebAPI> available to Open Web
> Apps. The enabling technologies also aren't fully implemented in all major
> browsers, and some (particularly Safari) haven't implemented key
> technologies like Service Workers at all.
>
> It seems best for apps that don't require privileged APIs, such as hosted
> apps <https://developer.mozilla.org/en-US/Marketplace/Options/Hosted_apps>,
> plus unprivileged packaged apps <
> https://developer.mozilla.org/en-US/Marketplace/Options/Packaged_apps>
> (that use packaging for its ergonomics, to gain network independence, or
> for another reason unrelated to privileged API access).
>
> Apache Cordova
>
> Cordova <https://cordova.apache.org/docs/en/latest/guide/overview/> is a
> framework for developing mobile apps using web technologies for a variety
> of mobile platforms, including Android. It provides native API bindings, so
> you can access capabilities like the ones provided by privileged Web APIs.
> And it includes tools for packaging apps, which you then distribute via
> mobile app stores or other distribution channels.
>
> Cordova's Platform Support page <
> https://cordova.apache.org/docs/en/latest/guide/support/index.html> does
> claim support for Windows and Ubuntu, but it isn't clear how well supported
> the desktop variants of those OSes are. Cordova also renders web apps via
> platform-specific WebView components rather than the Gecko rendering engine
> in the web runtimes. (There's been some work to integrate GeckoView into
> Cordova, and bug CB-6246 <https://issues.apache.org/jira/browse/CB-3990>
> suggests that it was implemented, but it isn't clear how well-supported it
> is.)
>
> It seems best for apps that want to target Android (and other mobile OSes)
> and need access to native APIs.
>
> Electron and NW.js
>
> Electron <http://electron.atom.io/> and NW.js <http://nwjs.io/> are
> frameworks for developing desktop apps using web technologies. Like
> Cordova, they provide native API bindings and include tools for packaging
> apps, which you then distribute via desktop app stores or other
> distribution channels.
>
> Both of them embed Chromium, the web rendering engine in Chrome. And they
> both support the same desktop platforms as the runtime (Windows, Mac, and
> Linux). As with Cordova, Electron and NW.js seem best for apps that need
> access to native APIs.
>
>
> Finally, in the interest of being thorough, here are a few more options
> that don't seem particularly promising. But as I mentioned earlier, I'm not
> an expert on any of these, so I welcome corrections and clarifications!
>
> XULRunner
>
> XULRunner <
> https://developer.mozilla.org/en-US/docs/Mozilla/Projects/XULRunner> is a
> runtime for desktop apps that are written in XUL <
> https://developer.mozilla.org/en-US/docs/Mozilla/Tech/XUL> (plus web
> technologies like JavaScript and CSS), although it can also be used
> (perhaps with a XUL shim) to run apps written in HTML. XULRunner embeds
> Gecko, and Firefox includes a copy of XULRunner, so apps can reuse it from
> a Firefox installation instead of bundling their own instance (in fact the
> desktop web runtime does this).
>
> But XULRunner is not a priority of the Mozilla organization, as noted in
> this dev-platform thread <
> https://groups.google.com/forum/#%21searchin/mozilla.dev.platform/xulrunner/mozilla.dev.platform/_rFMunG2Bgw/C-4PcHj9IgAJ>.
> And I'm not aware of any other organization that is committed to
> maintaining and enhancing it, nor a significant community of active
> contributors. Thus it suffers from the same viability problem as the web
> runtimes.
>
> GeckoView
>
> GeckoView <https://wiki.mozilla.org/Mobile/Projects/GeckoView> is a
> component for Android that can be used to embed Gecko into your Android
> app. It's roughly equivalent to the Android WebView component, although
> doesn't try to maintain strict API compatibility with that component.
>
> But GeckoView is called a "side project" in various descriptions of it,
> like its introductory blog post <
> http://starkravingfinkle.org/blog/2013/10/geckoview-embedding-gecko-in-your-android-application/>
> and this post about embedding it into a Gradle-based application <
> http://www.ncalexander.net/blog/2014/07/10/build-your-own-browser-a-maven-repository-for-geckoview/>.
> And it isn't clear how useful it is for developing web apps specifically,
> as opposed to native Android apps that need to render some web content.
>
> Graphene
>
> Graphene, part of Browser.html <https://github.com/mozilla/browser.html>,
> is a version of Gecko (and Servo <https://servo.org/>) for developing
> desktop apps with web technologies. It's somewhat analogous to Electron,
> except that it isn't clear to what extent it provides native API bindings
> and tooling (versus just the rendering engine). It was developed to support
> Browser.html, and the new Brave browser <
> https://github.com/brave/browser-laptop> initially used it too (although
> now it uses Electron).
>
> But Browser.html (and by extension Graphene) is an experimental research
> project, not a supported product.
>
> -myk
>
> _______________________________________________
> dev-webapps mailing list
> dev-w...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-webapps
>

[Myk Melez]

> Benjamin Francis <mailto:bfra...@mozilla.com>
> 2016 February 23 at 07:24

> Sorry for being late to this thread but I just wanted to speak in
> support of "Progressive Web Apps" and to highlight the difference
> between web apps and apps which are built using web technologies.

No worries, I'm glad to hear it!

> As I've said before I'm in full support of Web Manifest, Service
> Workers and Push for Firefox with a standalone display mode for
> Firefox similar to the web runtime, but using Firefox' instance of
> Gecko. I'm looking for ways to help move this forward.

There's a tracking bug for the Web App Developer Initiative that
references a variety of issues in Firefox:

https://bugzilla.mozilla.org/show_bug.cgi?id=wadi

In general, Service Workers are the farthest along, implemented on both
desktop and Android (with active development of enhancements like
DevTools support); Push is on desktop, but not yet on Android (although
it's being actively developed); and Web Manifest is implemented in
Gecko, but it isn't yet being used to implement a standalone display
mode, neither on desktop nor on Android.

Nor has there been any movement to do this on desktop. (FWIW, Chrome
doesn't support this either, except as the experimental feature
chrome://flags/#enable-add-to-shelf for development/testing purposes).

On Android, however, there are a handful of bugs to track aspects of
both a standalone mode and "add to homescreen" generally:

*Bug 1126479* <https://bugzilla.mozilla.org/show_bug.cgi?id=1126479>
-"Add to Homescreen" from home screen does not open in fullscreen
*Bug 1208195* <https://bugzilla.mozilla.org/show_bug.cgi?id=1208195>
-Show sites opened from Android home screen bookmarks as separate
entries in the Android recent apps list
*Bug 1232706* <https://bugzilla.mozilla.org/show_bug.cgi?id=1232706>
-Promote "Add to home screen" if user visits website often
*Bug 1234558* <https://bugzilla.mozilla.org/show_bug.cgi?id=1234558>
-Use icon from app manifest for "Add to home screen"
*Bug 1237045* <https://bugzilla.mozilla.org/show_bug.cgi?id=1237045>
-Allow user to edit home screen shortcut name
*Bug 1240560* <https://bugzilla.mozilla.org/show_bug.cgi?id=1240560>
-When adding website to homes screen, no notification of success/failure
is presented

That's where I think we could have the most impact on Firefox support
for Progressive Web Apps!

-myk

[Adrian Aichner]

Hi Myk, All,

following the removal of DOM:Apps from desktop firefox I had some success converting by firefox os app, which I also installed as Desktop packaged app, to a progressive web app using a service worker.

It works fine when run from my self-hosts https site both in linux desktop nightly firefox and nightly firefox os browser.

I can go offline and online while in the browser in both environments and the app keeps functioning using cached file (following an immediate claim service worker pattern).

The use case I need to get working is when I need to restart the browser or the device while offline.

How do I get to my progressive web app while still offline?

It could function perfectly well, as in the case when I go offline with the app running, but there is just no way to get to it until I go online again.

Any thoughts on this use case?

Thanks,

Adrian

>
> -myk

[Myk Melez]

> Adrian Aichner <mailto:adrian....@gmail.com>
> 2016 March 2 at 12:13

> The use case I need to get working is when I need to restart the browser or the device while offline.
>
> How do I get to my progressive web app while still offline?
>
> It could function perfectly well, as in the case when I go offline with the app running, but there is just no way to get to it until I go online again.

Hmm, provided your service worker has cached your app's "start URL"
(a.k.a. home page), then navigating to that URL (via a bookmark, by
typing the URL into the location bar, or in any other way) should reload
the page from the service worker, so you should be able to get back to
your app without going online again. And that should work across browser
sessions, so you should be able to return to your app after restarting
the browser (or the OS/device).

I'd check to verify that the service worker is caching that page. And,
if so, that Firefox starts the service worker when you load the page,
and that the service worker is intercepting the load request and
returning the file from its cache.

-myk