
Show HN: Electrino, a featherweight API-compatible alternative to Electron - pavlov
https://github.com/pojala/electrino
======
pavlov
Yesterday there was a thread on HN about using Electron to build desktop apps:

[https://news.ycombinator.com/item?id=14245183](https://news.ycombinator.com/item?id=14245183)

I posted a comment lamenting that Electron apps are so big because each
contains a full set of the Node + Chromium runtimes, and proposed a
lightweight version of the same concept using the system-provided web browser
engine.

The idea seemed interesting, so I spent some time today putting together a
minimal proof of concept.

This initial version of Electrino can load the "Hello World" example from
Electron's quick start guide -- and that's pretty much it! With that enormous
caveat, the difference in file size is huge. The Electron version sizes up to
115.7 MB, while the Electrino version is 167 kB.

I'm curious if this could be turned into a real project. Anyone out there with
a small Electron-based Mac app that you'd like to put on an Electrino diet?
Ping me, and let's see if we can make it work!

~~~
giancarlostoro
I don't have an Electron project going, but I can tell you something like this
could add some value to some companies invested in Electron as-is. You just
have to get their attention. I would suggest maybe resubmitting this post
later if it doesn't catch the flare of intrigue. If I do end up building an
Electron Project I will definitely look into Electrino when the time comes.
You mention it doesn't feature all the features of Electron but is the typical
browser DOM still available?

~~~
pavlov
Thanks!

The full browser DOM is certainly there. The missing APIs are the Electron-
specific ones that apps can use to access desktop features.

Adding new APIs individually is pretty easy, but there's a lot of stuff in
Electron, so reaching full coverage is of course a lot of work... That's why
I'd like to try adding APIs based on usage in real-world apps, "filling in the
gaps" so to speak.

I wrote a blog post with some more details about the rationale behind
Electrino: [https://medium.com/@pauli/put-your-electron-app-on-a-diet-
wi...](https://medium.com/@pauli/put-your-electron-app-on-a-diet-with-
electrino-c7ffdf1d6297)

~~~
52-6F-62
This could be big. One of the most common complaints about Electron I've heard
is the file size and cpu load. In short, nice work!

I know it would add extra time to the build on the programmer end, but what
about component API's -- to keep build size at a minimum while allowing
access? I haven't looked at any of the code -- would this be possible?

Any thoughts?

------
Etheryte
Most of the time though, the real issue that people have with Electron-based
apps is memory and CPU usage. Electron is notorious for hogging RAM like
there's no tomorrow. While this project is a neat idea, it doesn't seem to
address the main problem of Electron.

~~~
pavlov
Using the system web runtime does reduce the app's memory usage too, not just
the on-disk size.

The system runtime is loaded just once (and is probably already in active
memory), whereas each Electron app loads its own copy of Chromium.

For large apps, it won't make a huge difference. I'm absolutely not saying
Atom or Spotify should switch away from Electron... The use case I had in mind
for Electrino is more about small utilities, desktop widgets, that kind of
thing.

~~~
ricardobeat
Have you tested that? In my experience using a system webview actually
consumes _more_ resources than Electron, and is noticeably slower, at least in
OSX/WebKit.

~~~
pavlov
I did do trivial tests. The Electrino "Hello World" launches faster and
consumes about 70% less memory than the Electron one.

For complex apps, I imagine the picture can be very different. The use case I
see for the Electrino approach is small apps that are constantly loaded. Big
productivity-style apps are better served by Electron.

------
scribe123
Nice work! I wrote a very similar engine back in 2014. Mine has a platform-
agnostic API:

[http://scribe-src.github.io/scribe-api/doc/](http://scribe-
src.github.io/scribe-api/doc/)

Support for OSX (with ObjC bindings exposed):

[https://github.com/scribe-src/scribe-platform-osx](https://github.com/scribe-
src/scribe-platform-osx)

And could work with just MachO binaries (not .app dirs) by shoving data into a
loader segment.

------
anilgulecha
the file size is too small to be an equivalent to (nodewebkit/electron) -
webkit/chromium.

What you'd need is node (without webkit) which translates to ~9MB, + launching
with the system browser.

9MB or so would still be a large step down from entire chromium runtime, but
desktop apps still will have access to things like fs module, which are needed
for desktop apps.

~~~
pavlov
The plan is to implement Node-compatible modules directly in Electrino.

I made stubs for "path", "url", "process" so that the Electron Hello World can
be loaded. Doing "fs" next seems like a good idea, but I'd like to have a
real-world app to test it against to see which APIs actually get hit (rather
than just reimplementing all of "fs").

~~~
dangoor
It seems like the trouble with this approach is that you have to not only
build up adequate Electron compatibility but you also need to build up Node
compatibility, which seems to me to be a bigger deal. One of the huge benefits
to Electron is the ability to use any of the modules from npm.

I can see how the architecture is greatly simplified, and I can still imagine
using something like this... but giving up npm is a lot.

~~~
pavlov
Yes, the backend provided by Node needs to be reimplemented using the native
JS bridge APIs. Whether this is realistic or not will depend on how much the
typical Electron app actually makes use of Node -- I just don't know,
honestly. If it's mostly "fs" and a bunch of the other OS-wrapper APIs, it's
not insurmountable.

Re: npm, you can of course still use an npm-based workflow for the browser-
side part of the app (Webpack, whatever). It's just the Node-side services
that are missing.

------
mingodad
Why not only use a small http server with something like luajit for
os/database access and javascript for presentation/navigation ?

------
derimagia
"It implements a minuscule portion of the APIs available in Electron" \- I
wouldn't really call that API-compatible.

For most apps I'm sure this is fine though.

------
ricardobeat
MacGap offered this before Electron/NW came to exist:
[https://github.com/MacGapProject/MacGap1](https://github.com/MacGapProject/MacGap1)
(and there was a way to bundle node too)

Unfortunately neither v1 nor 2 have been actively developed in the past few
years.

------
arenaninja
Ah so far it works only for macOS. I wanted to give it a test run but I'm on
Windows at the moment

------
tanerax
Wasn't one of the big benefits of using Electron the fact that you only have
to build everything for one browser, one technology and have it run on all
platforms?

------
bbcbasic
Why not use Java folks? Write once run anywhere and reasonable file sizes and
memory usage.

~~~
roryisok
Hard to argue with that. Why is it when you google "Build cross platform
desktop apps" there are no hits for Java in the first five pages? It's
Electron on every page, with a few passing mentions of Qt. Even Haxe gets a
look in, but no Java (as far as I can see)

~~~
bbcbasic
I never said it was sexy

