Electron Headless Alternatives

electron.org hero image

It’s not the first time I talk about electron alternatives, but it’s only recently that we have a FinalizationRegistry in JS, which combined to a Proxy, can produce memory-leak safe remotely driven results, either on the client, or, recently, on the server side too.

Before talking more about my latest solution, let’s quickly sum up what’s already out there.

workway

This project was also previously discussed in here, but it was born in times where not every browser was Proxy capable, and it’s full of tiny limitations that could be a show-stopper for any project “bigger than a hello world”.

The idea behind this project, on the server side, is the following:

• you specify which folder, with .js files, should be allowed as possible namespace to drive via any browser
• you import the module and define a single namespace through it, and its file name

There’s a lot of code around this concept, and it works pretty well, I suggest everyone to move away from it ASAP, as its whole stack, and logic, is simply outdated, so it’s not a real “electron replacement”.

electroff

Exposed to the client through a fancy, pretending to be, CommonJS virtual namespace, this module creates a dedicated virtual NodeJS machine per each connected client.

I know the classic Web Kiosk, Electron driven use case, is actually one browser instance with privileges, and not many browsers at once, but for Internet of Things projects, what we miss is an Electron like ability to drive NodeJS on the backend, without even needing a browser, but having any remote client able to interact with the backend/connected devices, logic, and so on.

The need for a dedicated VM per client has the following goals:

• no global leaks between different clients
• the ability to destroy each client once lost (via Web sockets) to avoid memory leaks in general
• the ability to use the same underlying shared server, without any ability to actually interact between clients

This module works perfectly on Raspberry Pi or any other board, but it’s still not the fastest, easier to deploy or work with, module to have NodeJS powers through a browser.

It doesn’t use FinalizationRegistry, but it does use Proxy, and it might be the go-to solution for most IoT projects … but …

proxied-node

Here we are, my latest state-of-the-art solution to a problem with the following advantages, compared to my previous attempts:

• no VM needed per each client … it’s literally one, or more, namespaces exported as module, for any client out there
• because of the different stack/goal, it’s possible to create channels among multiple clients too (i.e. one client notify all others through pub/sub logic or any similar alternative)
• because of its implementation, it’s the fastest, lightest, safest, way to expose any shared among clients namespace, only if there is the will to do so (i.e. if the logic is around localhost or 127.0.0.1 host, no external clients can reach the server, so it’s safe as electron alternative too

I’ve also provided both the same Oled demo for the Raspberry Pi, and a basic SQlite demo that demonstrate applications based on this module can have a real-world database out of the box, and PosgreSQL, MySQL, or literally anything else is easily possible too, for either one single client, or multiple clients across the same network.

Conclusions

Once again I try not to break older ideas, and create new projects around new ideas, even if the problem to solve is very similar, but as long as the solution is completely different, I think it makes sense to keep all experiments/modules around, and give developers the freedom to pick any of these:

• targeting down to IE10
• confining each client in its own NodeJS VM, over shared dependencies and namespaces
• providing the simplest, fastest, easiest way, to drive any NodeJS namespace through modern browser clients

Pick your solution, and don’t hesitate to ask me more about these projects, either here or through my projects’ community 👋