A couple weeks ago, I blogged about Why Embedding Matters. A rendering engine can be put to a wide variety of uses. Here are a few of them. Which would you prioritize?
A headless browser is an app that renders a web page (and executes its script) without displaying the page to a user. Headless browsers themselves have multiple uses, including automated testing of websites, web crawling/scraping, and rendering engine comparisons.
Longstanding Mozilla bug 446591 tracks the implementation of headless rendering in Gecko, and SlimerJS is a prime example of a headless browser would benefit from it. It’s a “scriptable browser for Web developers” that integrates with CasperJS and is compatible with the WebKit-based PhantomJS headless browser. It currently uses Firefox to “embed” Gecko, which means it doesn’t run headlessly (SlimerJS issue #80 requests embedding Gecko as a headless browser).
Hybrid Desktop App
A Hybrid Desktop App is a desktop app that is implemented primarily with web technologies but packaged, distributed, and installed as a native app. It enables developers to leverage web development skills to write an app that runs on multiple desktop platforms (typically Windows, Mac, Linux) with minimal platform-specific development.
Generally, such apps are implemented using an application framework, and Electron is the one with momentum and mindshare; but there are others available. While frameworks can support deep integration with the native platform, the apps themselves are often shallower, limiting themselves to a small subset of platform APIs (window management, menus, etc.). Some are little more than a local web app loaded in a native window.
Hybrid Desktop Web Browser
A specialization of the Hybrid Desktop App, the Hybrid Desktop Web Browser is notable not only because Mozilla’s core product offering is a web browser but also because the category is seeing a wave of innovation, both within and outside of Mozilla.
Besides Mozilla’s Tofino and Browser.html projects, there are open source startups like Brave; open-source hobbyist projects like Min, Alloy, electron-browser, miserve, and elector; and proprietary browsers like Blisk and Vivaldi. Those products aren’t all Hybrid Apps, but many of them are (and they all need to embed a rendering engine, one way or another).
Hybrid Mobile App
A Hybrid Mobile App is like a Hybrid Desktop App, but for mobile platforms (primarily iOS and Android). As with their desktop counterparts, they’re usually implemented using an application framework (like Cordova). And some use the system’s web rendering component (WebView), while others ship their own via frameworks (like Crosswalk).
Basecamp notably implemented a hybrid mobile app, which they described in Hybrid sweet spot: Native navigation, web content.
(There’s also a category of apps that are implemented with some web technologies but “compile to native,” such that they render their interface using native components rather than a WebView. React Native is the most notable such framework, and James Long has some observations about it in Radical Statements about the Mobile Web and First Impressions using React Native.)
Mobile App With WebView
A Mobile App With WebView is a native app that incorporates web content using a WebView. In some cases, a significant portion of the app’s interface displays web content. But these apps are distinct from Hybrid Mobile Apps not only in degree but in kind, as the choice to develop a native app with web content (as opposed to packaging a web app in a native format using a hybrid app framework) entrains different skillsets and toolchains.
Facebook (which famously abandoned hybrid app development in 2012) is an example of such an app.
Site-Specific Browser (SSB)
A Site-Specific Browser (SSB) is a native desktop app (or simulation thereof) that loads a single web app in a discrete native window. SSBs typically install launcher icons in OS app launchers, remove or minimize browser chrome in app windows, and may include native menus and other features typical of desktop apps.
Chrome’s –app mode allows it to simulate an SSB, and recent Mozilla bug 1283670 requests a similar feature for Firefox.
SSBs differ from hybrid desktop apps because they wrap regular web apps (i.e. apps that are hosted on a web server and also available via a standard web browser). They’re also typically created by users using utilities, browser features, or browser extensions rather than by developers. Examples of such tools include Prism, Standalone, and Fluid. However, hybrid app frameworks like Electron can also be used (by both users and developers) to create SSBs.
Linux Embedded Device
A variety of embedded devices include a graphical user interface (GUI), including human-machine interface (HMI) devices and Point of Interest (POI) kiosks. Embedded devices with such interfaces often implement them using web technologies, for which they need to integrate a rendering engine.
The embedded device space is complex, with multiple solutions at every layer of the technology stack, from hardware chipset through OS (and OS distribution) to application framework. But Linux is a popular choice at the operating system layer, and projects like OpenEmbedded/Yocto Project and Buildroot specialize in embedded Linux distributions.
Embedded devices with GUIs also come in all shapes and sizes. However, it’s possible to identify a few broad categories. The ones for which an embedded rendering engine seems most useful include industrial and home automation (which use HMI screens to control machines), POI/POS kiosks, and smart TVs. There may also be some IoT devices with GUIs.
9 thoughts on “Embedding Use Cases”
Chrome recently announced that Chrome will support a headless mode by default (https://bugs.chromium.org/p/chromium/issues/detail?id=612904). Not matching their capability introduces additional friction for unit testing in Firefox that doesn’t exist in Chrome.
Indeed, I expect that new Chrome feature to gain significant uptake. Not only would it be advantageous to match the capability, it might also be beneficial to match the interface, to reduce the friction for implementers of unit testing frameworks that support (or would support) both browsers.
My company makes heavy use of SSBs – in this case created by developers, not by users. We previously used Prism, then moved to a XULRunner version of the same, and we’re now wrapping Firefox itself, passing it a -chrome flag to make it render our minimal UI rather than its own.
The main use-case is for corporate customers who don’t want to install another web browser, but are happy to install a “runtime environment” which is more locked down.
A well documented and supported way to achieve this, either via a specific SSB wrapper, or a hybrid desktop app, would allow us to more easily keep customers on recent Gecko builds without the hassle of having to change the wrapping code every couple of years.
Thanks for the tip, I was unaware of your company’s usage of Gecko! Are you also using Gecko-specific web APIs, or are there other Gecko features that you need or prefer? I’m curious why you’ve stuck with it for so long, especially since none of the solutions you’ve used (Prism, XULRunner, -chrome) have been particularly well supported.
We use Remote XUL & XBL. Yeah, I know. We’ve wanted to migrate to HTML for years, but we really need a client side component system. After a wasted effort to port to XBL2, we’ve been waiting for Web Components to settle down. However, e10s fundamentally breaks Remote XUL, so we’ve now been forced to start on a Web Components port anyway. An SSB helps with that, as we can target a known version without having to chase the constantly changing spec, polyfills and implementations.
As for Prism and XULRunner not being particularly well supported – they both started out quite well, with blog posts very similar to your own. They only look poorly supported in retrospect – I just hope your own efforts gain more traction.
Finally, even with a working Web Components port we’ll still want to have an SSB available. Our code runs on corporate intranets, where the option of a stable SSB can be appealing. For many smaller enterprises even the ESR releases are too frequent, and we still have some clients who refuse to run any browser other than IE(!) – but they will run an SSB, viewing it more as a runtime or platform than a browser.
Indeed, SSBs (and hybrid apps) benefit from being able to target a particular version of a specific runtime. Especially for Web Components, which have been pretty unstable, both in specification and in implementation. Positron itself uses parts of Web Components (particularly Custom Elements and Shadow DOM) that are expected to break.
About projects being well-supported: understood, and Mozilla did have good intentions with both Prism and XULRunner. Ultimately, the best guide to future support for a project is past and present activity. And even then, the future is always uncertain in tech.
I should also note, as I did in the previous blog post, that none of what I’m saying should be construed as a commitment by Mozilla to develop any particular project. I’m a Mozilla employee, but these are my personal thoughts unless and until Mozilla publicly adopts them.
Incidentally, I didn’t realize that ESR releases are still too frequent for some enterprises. That’s useful info, and I’ll pass it on to Asa Dotzler, who is one of the product managers for Firefox.
“Incidentally, I didn’t realize that ESR releases are still too frequent for some enterprises.”
It’s mainly smaller businesses, for whom the word “enterprise” seems a little grandiose: those with a handful of employees, up to a few hundred. The smaller ones often have no in-house IT expertise, and those that do tend to be overworked and underfunded.
With ever more intranet-based applications using HTML to provide a cross-platform UI, such companies are often loathe to upgrade until all their essential programs are tested with the new version. Doing that every 9 months can be onerous, especially if there are lots of applications to deal with. SSBs offer a way around this impasse, by at least allowing each application to be updated separately.
For a long time, I’ve been wanting to run a touch screen wall display that displays information and lets me control stuff around my home. But I want to hack my own, and given that I’m a big Mozilla aficionado, having that be a website running on a Mozilla engine (Gecko/Quantum/Servo) would be preferred. And nowadays, the hardware isn’t the issue, it could run on a Raspberry Pi (2 or 3) as a base.
I thought maybe FxOS would get me there but that obviously won’t. A pure Linux just running the web engine in full-screen would be even better.
I think stuff like that doesn’t only make a use case for hackers and makers, like in my case, but even for professional projects of various degrees – esp. as more and more devices around us get color displays, even touch displays, and web technology makes an easy-to-design-for “framework” for such displays.
I hope embedding efforts can help cases like that as well (I guess that falls into the “Linux Embedded Device” category you mention).
Indeed, there’s a wide range of potential users for an embeddable rendering engine, from individual tinkerers like you to large, commercial organizations (and everyone in between).
And even though the bigger projects may have more obvious impact, there’s a lot of value in enabling individuals to experiment and build small solutions, since those individuals are often employees of organizations (or become so) and can influence technology decisions with the expertise they develop on their own.
Anyway, thanks for providing your use case!