What HTML5 runtime environments (renderer shells) don't generate any background network I/O?

50 views Asked by At

I need to put together a nice interface/UX that will run fullscreen as the primary shell/UI on purpose-configured hardware.

HTML5/CSS/JS will be the absolute easiest design path; I don't have anything that requires rock-solid 60fps framerates or similar high-performance requirements, so the live-reloadable nature of HTML easily makes it a winner for rapid development. (Plus, I'm using Linux, so I know my next (real) alternative is Qt, perhaps with Python. That won't be as fast to iterate with.)

Since this is going to be an embedded/appliance type setup, I don't need the "one-click run" packaged nature of Electron; indeed, I will far prefer the more traditional approach of a local application-/web server running in the background.

So, all I need is a basic headless browser to appear fullscreen for the duration the machine is turned on.

That could be Chrome, but here's the thing. The general Internet will be accessible from the devices in question, but only my own backend processes will use it. I'd prefer the renderer(s) not access the network directly.

I understand Chrom{e,ium} contacts Google for telemetry and metrics tracking, as well as to fetch safebrowsing lists and so forth - and that this behavior cannot be turned off, to ensure that some majority of web users don't end up with what are (in the context of "the whole internet") arguably-insane security defaults.

But for my use case, this behavior is pointless, because I'll only ever be accessing 127.0.0.1. There's no point for me to waste my bandwidth on this I/O; the effort being made to update this data in the background is effectively wasted.

I'm currently wondering what renderer solution to deploy, and weighing up NW.js, QtWebEngine and Electron (in that order). I particularly like the following from http://wiki.qt.io/QtWebEngine:

Auxiliary services that talk to Google platforms are stripped out

If I knew NW.js did the same thing, it would be a shoo-in and my choice would be made, but I'm not sure where to look.

Is it a good idea to make the effort to build a simple QtWebEngine kiosk shell, is NW.js resource efficient, or is there another option I haven't thought of?

I've tried CEF in the past; it seems somewhat clunky, or at least the demo shell does (I'm not up to recompiling it). Perhaps it's exactly what I'm looking for and don't realize?

0

There are 0 answers