[email protected] <mailto:[email protected]>
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
_______________________________________________
dev-webapps mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-webapps
