So is it a yet another webview-based framework like NeutralinoJS (https://neutralino.js.org), Electrino (https://github.com/pojala/electrino) or DeskGap (https://deskgap.com)? What's their advantage apart from using Bun instead of Node?
For relly lightweight cross-platform desktop apps better use a non-webview-based native framework like Qt, GTK, wxWidgets or even recently released FLTK 1.4.
In Electrobun: Cross-platform desktop applications written in TypeScriptpojala
electrino
C#2017–2024
pojala / electrino
electrino
Desktop runtime for apps built on web technologies, using the system's own web browser engine
18Distinct people
22Mentions
0Explicit recommenders
4.4KGitHub stars
What to know before exploring
What it is
Desktop runtime for apps built on web technologies, using the system's own web browser engine
GitHub
Where it is used
No documented product use was verified in the last source check.
What people are saying
No recommendation phrase was found in the indexed comments.
No classified warning is attached to this page. Read the discussions before treating silence as approval.
Also in these discussions
- jscherer92/quark · linked in 5 of the same discussions
Mentioned in the same Hacker News threads. That is not proof they are substitutes.
This week on Hacker News
Nov 7–Nov 14 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/14/2026, 5:04:57 PM UTC.
No direct repository links were found in the indexed HN discussions over the past seven days. Older discussions are available below.
Mentions over time
HN mentions by year22 dated mentions
Observed mentions: 2017-05-02 15:08:16 UTC to 2024-11-21 14:32:34 UTC.
Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.
View mention counts and date ranges
| Period | Start (UTC) | End (exclusive, UTC) | Mentions | Submissions | Comments |
|---|---|---|---|---|---|
| 2017 | 2017-01-01 00:00:00 UTC | 2018-01-01 00:00:00 UTC | 7 | 1 | 6 |
| 2018 | 2018-01-01 00:00:00 UTC | 2019-01-01 00:00:00 UTC | 6 | 1 | 5 |
| 2019 | 2019-01-01 00:00:00 UTC | 2020-01-01 00:00:00 UTC | 3 | 0 | 3 |
| 2020 | 2020-01-01 00:00:00 UTC | 2021-01-01 00:00:00 UTC | 3 | 0 | 3 |
| 2021 | 2021-01-01 00:00:00 UTC | 2022-01-01 00:00:00 UTC | 2 | 0 | 2 |
| 2022 | 2022-01-01 00:00:00 UTC | 2023-01-01 00:00:00 UTC | 0 | 0 | 0 |
| 2023 | 2023-01-01 00:00:00 UTC | 2024-01-01 00:00:00 UTC | 0 | 0 | 0 |
| 2024 | 2024-01-01 00:00:00 UTC | 2025-01-01 00:00:00 UTC | 1 | 0 | 1 |
From the project README
An excerpt from the repository, fetched Nov 13, 2026.
Read the project’s introduction
electrino
An experimental desktop runtime for apps built on web technologies, using the system's own web browser engine. The project is still young and accepting contributions.
Electrino aims to be a featherweight alternative to the popular and powerful Electron. It implements a minuscule portion of the APIs available in Electron, but the output app size is much smaller.
A "Hello World" app takes 115 MB using Electron, but only 167 kB using Electrino:
Read more about Electrino in this post on DailyJS
Comparison
Feature
Electron
Electrino
Comprehensive API
Yes
No
Small output size
No
Yes
Cross-platform support
Yes
Limited to macOS and Windows 10 at this time
Contribute
Integrate WebView
Support require() calls
Add Node.js backend
API
Electrino currently supports the following API implementations:
app
BrowserWindow
ipcMain
Tray
nativeImage
Roadmap
The plan is to examine API usage of real-world apps that use Electron but don't really need the full capabilities. Good candidates are desktop utilities, menu bar apps and other small apps that users typically leave open. (For large productivity-style apps, Electron is a better choice.)
Jan Hovancik offered his Stretchly app as a candidate, so I'm going to start by mapping out the APIs used by Stretchly and see what it would take to implement it with Electrino.
If you have a small Electron-based Mac app and you'd like to try putting it on an Electrino diet, let's give it a try! My contact info is below.
Contact
Pauli Olavi Ojala / @pauliooj / pauli @ lacquer.fi
Amila Welihinda / @amilajack / amilajack @ gmail.com
Read the full README on GitHubWhat Hacker News says
22 sourcesElectrino, but looks abandoned:
https://github.com/pojala/electrino
In Tauri: An Electron alternative written in Rust> I kind of wonder why it took this long for someone to try this approach. It just makes a whole lot more sense on the surface.
Like other replies have mentioned, it's not a new idea
DeskGap uses the native OS Webviews. https://github.com/patr0nus/DeskGap/
Electrino (4 years old) was an experiment where they forked Electron and removed Chromium to replace it with the native OS Web views. https://github.com/pojala/electrino
Quark is a fork of Electrino: https://github.com/jscherer92/Quark
There's also a way of building desktop GUIs using Deno, which uses Deno Webview, which is a binding for the same webview library that Tauri uses.
https://denotutorials.net/making-desktop-gui-applications-us...
https://github.com/webview/webview
In Tauri: An Electron alternative written in RustCheck out: nodegui (https://github.com/nodegui/nodegui), electrino (https://github.com/pojala/electrino) or muban (https://github.com/yue/muban).
In C++ Lightweight, cross-platform, HTML rendering engine for desktop appsI don't think that the web is fundamentally slow! I do think Chromium in particular has become a major resource hog. Firefox, which doesn't have Safari's platform advantage, opens more quickly and takes up much less memory than Chrome (even as it still uses up battery quickly). Gnome Web, a Linux webkit-based browser for Linux, also performs quite admirably, so I'm not convinced Safari's success is simply due to its macOS integration.
There've been a couple attempts to build electron-like frameworks that use the OS's native webview, but they don't seem to have gained that much traction. Deskgap is probably the most mature of them, relatively speaking.
https://deskgap.com/
https://github.com/pojala/electrino
https://github.com/jscherer92/Quark
In The iOS and Mac markets are almost the same size?Sharing this as another alternative, unfortunately unmaintained:
https://github.com/pojala/electrino
In NeutralinoJS: Lightweight Electron alternative using native browser controlsThere was Electrino a couple of years ago but it looks dead.
https://github.com/pojala/electrino
In WebWindow, a cross-platform webview library for .NET CoreI _believe_ they are doing this because they are heavily investing in Electron (Skype, Visual Studio Code, Teams, more). Having both Chromium and V8 be part of Edge (and the OS) means they can remove them as bundled dependencies from Electron on Windows and lighten the payload of those apps. I wouldn't be surprised if we see future Windows builds of Electron becoming smaller because of this.
There is not proof of this, this is just a hunch I have.
Eletrino[1] and Quark[2] tried tackling this idea of using native OS engines but they seem to just be side projects and/or experiments.
[1] https://github.com/pojala/electrino
[2] https://github.com/jscherer92/Quark
In Chromium-based Edge preview buildsHi HN,
DeskGap is another try to build an lightweight alternative to Electron. Compared to the existing attempts [0, 1], I choose not to go that far and bundle a real Node.js with it[2].
And to battle test the framework, I wrapped squoosh[3] into a desktop app[4] with DeskGap, and successfully submitted it to the app stores.
[0] https://github.com/pojala/electrino
[1] https://github.com/jscherer92/Quark
[2] https://deskgap.com/#faq
[3] https://squoosh.app
[4] https://github.com/patr0nus/Pym/
In Show HN: DeskGap – Like Electron, but uses the system webviewAsk HN: How to optimize Electron apps?
There has been a lot of discussion on performance issues with Electron apps the last few weeks [1-5]. I'm curious what is something that an individual developer could do to optimize their Electron app. Electrino [6,7] is a nice proof of concept that it is possible to greatly reduce the app size. Others have said to share Chromium between apps, but that isn't something that an individual has power over.
So how could Chromium be stripped down to only include the features needed for a given Electron app? Are there other potential optimizations?
[1] https://news.ycombinator.com/item?id=18733837
[2] https://news.ycombinator.com/item?id=18631738
[3] https://news.ycombinator.com/item?id=18578261
[4] https://news.ycombinator.com/item?id=18765482
[5] https://news.ycombinator.com/item?id=18761840
[6] https://news.ycombinator.com/item?id=14260755
[7
Read the rest
This is something Electron itself can probably do and I can see why some people might be interested in shipping their Electron apps without Chromium.
There is also Quark[1] and and Electrino[2] that do this with branding APIs.
[1] https://github.com/jscherer92/Quark
[2] https://github.com/pojala/electrino
In Carlo – Web rendering surface for Node applicationshttps://github.com/pojala/electrino is electron alternative that uses the system's own web browser engine.
In ReactXP – A library for building cross-platform appsThere was an attempt with electrino [0] that has ultimately been abandoned (I'm sure the author has posted their story here before). It aimed to provide an electron compatible API over the native browser controls, which is definitely ideal but not so much for those who just want to write for Chrome and nothing else.
I think native app development might have a fair chance if it could adapt to some of the decisions the web dev community (and communities using server-side languages) have made over the years.
- There was a fairly universal rejection of WYSIWYG editors after the Frontpage/Dreamweaver era, once CSS2 and XHTML started to become a thing; yet your default option for building a Mac or Windows app is to download around 6GB worth of IDE, interface builders, and other toolkits you'll never even know you'll need before you can properly
Read the rest
get started.
- While you might consider a webpack or babel setup to have appropriated the position, you don't require the solution or project file those editors build to get a hello world up and running by hand. An index.html and an app.js is enough to deploy an entire application.
- hot code reloading and debugging in the UI is a breeze (react native and flutter have been great for this too); no need to manually rebuild on each change.
This comes at the cost of dealing with the usual web-dev bugbears, ones that don't exist when you're working in C# or Obj-C or Swift or whatever, but the browser has almost accidentally become this amazing environment for experimental app development, that I imagine in some ways takes what Smalltalk had to offer in a totally different direction.
It would be interesting to see what OS vendors could do to level the playing field there. I enjoy doing native app development a lot but I do miss some of what you get from working with JS and React.
[0] https://github.com/pojala/electrino
It's very early and certainly not production ready, but this is the idea behind Electrino (https://github.com/pojala/electrino)
In Show HN: Chromely – Lightweight Alternative to Electron for .NET and .NET CoreA project with that idea is Electrino: https://github.com/pojala/electrino It provides an electron-like API but uses the OS version of safari. It doesn't seem to be actively developed anymore though.
In Electron 2.0.0 betaShowing the 15 most recent of 22 sources. Enable JavaScript to search and browse every indexed mention.