alternatives to desktop/Android web runtimes

[Myk Melez]

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

[mrjoshu...@gmail.com]

Thanks for doing this research. As you know, I'm trying to find a replacement for Firefox OWA on the Windows/Mac/Linux desktop, and migrate my users to that before it stops working. I do not need any privileged API access for my apps.

Right now my desktop apps are available as Chrome Desktop Apps and as Firefox Open Web Apps. In both cases, I'm using a pretty small shim for the app itself, and hosting all the content in S3/Cloudfront buckets. I use appcache to ensure it works offline. An example app is here http://m.kaon.com/c/ka/ and you can get a feel for how enormous a problem this is for me if you look at this list of apps we are supporting right now http://m.kaon.com . We have 45 OWA apps spread over 1000 desktops at the moment.

Chrome Desktop Apps are a good solution, except:
0. I have to force the users to install Chrome, which is banned by some Enterprise customers.
1. Users have to have a google account to get the software from the chrome store. In Enterprises, this can be an issue. I loved that I could set up OWA installation without having to deal with a store.
2. Anything google has been a problem in China, although lately the GFW has been blocking our Firefox OWA apps and cloud connections, so this seems to be a nightmare either way now.
3. There is a bug in Chrome where appcache spontaneously forgets it has anything stored. Since our apps MUST be useable offline in some cases, that can be a deal breaker.
4. Chrome won't let any single file in the appcache be >32MB, which means we have to compress some video content more than our customers would like.

On your suggestion, I looked at Electron. I hate the idea of deploying a 100MB+ web browser when the user already has one (probably 3). Plus, that puts me in the position of keeping that browser component up to date. And although the documentation is pretty much non-existant, it appears that the general idea is you are going to wrap your HTML5 content inside the app, which means incremental updates are either going to be impossible, or will require a lot of very clever engineering on my end. Our content is often a couple GB, and the idea that a person in a remote location is going to have to download all of it because we updated one little thing...that would be bad.

The candidate solutions I'm looking at right now are:

A. Seeing if maybe I could switch from appcache to service workers in order to get better offline reliability in chrome desktop apps (the spontaneous eviction of IndexDB data when the user's disk space get's low scares the hell out of me, though; I wonder if this is actually the reason appcache is flaky in Chrome)

B. Making a XUL shim, and a small program that runs firefox -app <that shim>. I actually got that working, but there are a few details to work out. And I'm nervous that firefox -app will spontaneously disappear since XUL apparently isn't in fashion any more.

C. Electron as a worst-case-scenario fallback, I suppose.

-Joshua

[Myk Melez]

> mrjoshu...@gmail.com <mailto:mrjoshu...@gmail.com>
> 2016 January 27 at 07:00

> On your suggestion, I looked at Electron. I hate the idea of deploying
> a 100MB+ web browser when the user already has one (probably 3). Plus,
> that puts me in the position of keeping that browser component up to
> date. And although the documentation is pretty much non-existant, it
> appears that the general idea is you are going to wrap your HTML5
> content inside the app, which means incremental updates are either
> going to be impossible, or will require a lot of very clever
> engineering on my end. Our content is often a couple GB, and the idea
> that a person in a remote location is going to have to download all of
> it because we updated one little thing...that would be bad.

Hmm, indeed, Electron doesn't sound like a good solution for your use
case. Electron seems better suited to productivity apps—like code
editors and browsers—that need deep native integration, including access
to privileged APIs. And perhaps it's also better suited to apps with
infrequent updates, each of which contains significant changes. Another
way of looking at it is that Electron is another way to build "desktop
apps with web technologies" rather than "web apps with desktop integration."

> The candidate solutions I'm looking at right now are:
>
> A. Seeing if maybe I could switch from appcache to service workers in
> order to get better offline reliability in chrome desktop apps (the
> spontaneous eviction of IndexDB data when the user's disk space get's
> low scares the hell out of me, though; I wonder if this is actually
> the reason appcache is flaky in Chrome)

This should also give you similar offline reliability in Firefox, which
supports Service Workers. I'm not sure how the browsers differ in their
support for data persistence, however; nor how Service Workers differs
from AppCache in that regard.

I'd be curious to know which features of Open Web Apps (and Chrome
Desktop Apps) are critical to your use case, i.e. why running an app in
a browser tab is insufficient. An OWA provides a high-quality app icon
(f.e. on the desktop on Windows), and it runs the app in its own
process, in a dedicated (and mostly chromeless) window. It also supports
uninstallation via the native mechanism (f.e. the Programs and Features
control panel on Windows). Are all of these features essential, or is
there one in particular that is important?

FWIW, Web Manifest makes it possible for us to implement a subset of
these features in Firefox, albeit with shallower native integration
(f.e. no native uninstall, and perhaps the app would run in the same
process as Firefox, although it would run in a dedicated window). There
aren't yet firm plans to implement such features, but understanding your
use case better might help us along that process!

> B. Making a XUL shim, and a small program that runs firefox -app <that
> shim>. I actually got that working, but there are a few details to
> work out. And I'm nervous that firefox -app will spontaneously
> disappear since XUL apparently isn't in fashion any more.

Indeed. I don't know of any plans to remove `firefox -app`, but I've
never seen it described as a supported feature of Firefox, so I wouldn't
recommend it.

-myk

[Myk Melez]

> Joshua Smith <mailto:mrjoshu...@gmail.com>
> 2016 January 29 at 06:12
> Our customers want “an application”. It’s largely a perception thing,
> tbqh. It’s okay that it’s actually a browser under the covers, as long
> as you can’t tell there is a browser under the covers.
>
> The must-have features for us are:
>
> 1. Ability to install something on the desktop and/or start menu
> (windows) and to the dock (OS X). (It could be a shortcut if it had a
> customizable icon.)
> 2. No browser chrome, resizable window (with no file/edit menu on
> Windows!), full-screen capable (at the O/S layer, not the HTML layer)
These are features that we've talked about adding to Firefox for
Progressive Web Apps with a Web Manifest, although I don't know of any
plans to do so at the moment.

> 3. Support for mailto: links, and for opening the user’s default
> browser (OWA can’t do the latter)
FWIW, OWAs should actually be able to do that, per
https://bugzilla.mozilla.org/show_bug.cgi?id=847518.

> 4. Persistent local storage
>
> Nice-to-have features:
>
> 1. Exemption from any service worker cache eviction policies or size
> limits (this is more of a must-have, tbqh)
I suspect (more) persistence of local storage and exemption from service
worker cache eviction are two sides of the same coin. And the exemption
from size limits is something that I'd expect you'd want for local
storage too. They also seem doable for Progressive Web Apps, although
again I don't know of any plans.

> 2. Ability to install without having to put it in a “store” (chrome
> lacks this)
> 3. Ability in the browser to tell if it’s already installed (chrome
> lacks this)
> 4. Ability to launch the app from the browser
Distributed "installation" is inherent to Progressive Web Apps, which
can be accessed from any site, although they aren't installed the same
way as Chrome Desktop Apps and OWAs, since their installation/update
model is more web-like (automatic, incremental, and silent).
Nevertheless, Service Workers is intended to make it possible to
implement more package app-like models, and these are all features that
it would make sense to provide for such apps.

> Also, as Windows and OS X are adding support for custom URL schemes as
> a way to launch apps and pass them a relative URL, I’d love for that
> to be supported. We use this on iOS and Android, and it is incredibly
> powerful.
I'm not familiar with this work, but it sounds intriguing!

>> FWIW, Web Manifest makes it possible for us to implement a subset of
>> these features in Firefox, albeit with shallower native integration
>> (f.e. no native uninstall, and perhaps the app would run in the same
>> process as Firefox, although it would run in a dedicated window).
>> There aren't yet firm plans to implement such features, but
>> understanding your use case better might help us along that process!
>

> I’ll be perfectly honest with you: This sudden decision to pull
> support for OWA desktop apps because “nobody wants to work on it”
> makes me very hesitant to deploy anything using Firefox at this point.
> That’s not how a business should be run. You have millions of
> installed apps that are suddenly going to stop working in a future
> release, many of which I suspect people /paid for/ in your web
> storefront. If using Firefox implies that I have to dedicate a FTE to
> making sure the features we need in Firefox are maintained, that makes
> Firefox unaffordable. If Mozilla wants to be taken seriously in the
> enterprise, they need to fix this approach.
I hear you, and I do understand how this change impacts Mozilla's
credibility (even though it's the most responsible thing to do, given
the organization's decision not to prioritize the runtimes).

But note that the decision to disable the runtimes is my own (as the
module owner for the Desktop Runtime module, and the relevant peer for
Fennec), not Mozilla's. Although I'm a Mozilla employee, in this case
I'm acting in my capacity as a member of the Mozilla community, not an
employee of the organization.

-myk