Show HN: Electrino, a featherweight API-compatible alternative to Electron | Hacker News Reader

Show HN: Electrino, a featherweight API-compatible alternative to Electron

github.com

99 pointspavlov29 comments

Yesterday there was a thread on HN about using Electron to build desktop apps:

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!

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?

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...

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?

A lot of people have griped about the bloat of Electron, or wondered why package each app with Chromium over and over, but you went and did something about it! This is rad and I'll be following avidly.

I started a project call magnemite[0] that records the window and saves to disk. It's not done but it only makes a few API calls.

[0]: https://github.com/styfle/magnemite

This is super duper cool. Slack and discord could immediately become 1/20th the size.

A lot of electron apps don't need the full capabilities of electron - what would be dope is if you could selectively add packages for these things.

The other huge downside of electron is performance - particularly with complex apps. If you could make any headway into that, I'd be 110% on your side.

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.

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.

Imho, it will make a big difference for large apps too, especially on CPU usage. Chromium is what takes up the majority of CPU time, so by reducing it to a very small replacement, it should help.

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.

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.

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/

Support for OSX (with ObjC bindings exposed):

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.

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.

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").

As a starting point, would it not make more sense to remove the chromium dependency and still include Node?

I saw your comment yesterday and it really gave me something to think about. I swear if you don't go down this path I will as soon as I get a chance!

I think both paths are worth exploring!

Ideally developers would have a spectrum of choice: all native libraries (Electrino), native browser + Node (your suggestion), Chromium + Node (Electron). They could then pick what works best for the scale of the project.

Already cloned electron and working backwards from that :)

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.

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.

Admiring the optimism but having an untested reimplementation of node would make people a lot less confident in using the project

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

"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.

MacGap offered this before Electron/NW came to exist: 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.

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

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?

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

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)

I never said it was sexy

Reply on news.ycombinator.com