HackerReposA FIELD GUIDE TO OPEN SOURCE
ProSponsor the shelf♧ 0
← Back to top all-time
Elanis
web-to-desktop-framework-comparison
JavaScript2022–2026
Elanis / web-to-desktop-framework-comparison

web-to-desktop-framework-comparison

An objective comparison of multiple frameworks that allow us to "transform" our web apps to desktop applications.

11Distinct people
13Mentions
0Explicit recommenders
2KGitHub stars
REPOSITORY AT A GLANCE

What to know before exploring

What it is

An objective comparison of multiple frameworks that allow us to "transform" our web apps to desktop applications.

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

No other repository is repeatedly linked in the same discussions.

This week on Hacker News

Nov 8–Nov 15 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/15/2026, 3:30:57 AM 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 year13 dated mentions

Observed mentions: 2022-02-07 10:46:53 UTC to 2026-02-22 09:34:32 UTC.

0123452022-01-01 00:00:00 UTC to 2023-01-01 00:00:00 UTC (exclusive): 2 mentions; 0 submissions, 2 comments20222023-01-01 00:00:00 UTC to 2024-01-01 00:00:00 UTC (exclusive): 5 mentions; 1 submissions, 4 comments2024-01-01 00:00:00 UTC to 2025-01-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments20242025-01-01 00:00:00 UTC to 2026-01-01 00:00:00 UTC (exclusive): 5 mentions; 0 submissions, 5 comments2026-01-01 00:00:00 UTC to 2027-01-01 00:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 comments. Incomplete calendar period.2026*

* An incomplete calendar period is marked with an outlined bar. Its count is not directly comparable with a full period.

Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.

View mention counts and date ranges
UTC ranges include their start and exclude their end. Select a period to filter the source evidence.
PeriodStart (UTC)End (exclusive, UTC)MentionsSubmissionsComments
20222022-01-01 00:00:00 UTC2023-01-01 00:00:00 UTC202
20232023-01-01 00:00:00 UTC2024-01-01 00:00:00 UTC514
20242024-01-01 00:00:00 UTC2025-01-01 00:00:00 UTC000
20252025-01-01 00:00:00 UTC2026-01-01 00:00:00 UTC505
2026 (partial)2026-01-01 00:00:00 UTC2027-01-01 00:00:00 UTC101

What Hacker News says

5 sources
Here's a great comparison, updated two weeks ago. https://github.com/Elanis/web-to-desktop-framework-compariso... Electron comes out looking competitive at runtime! IMO people over-fixate on disc space instead of runtime memory usage. Memory Usage with a single window open (Release builds) Windows (x64): 1. Electron: ≈93MB 2. NodeGui: ≈116MB 3. NW.JS: ≈131MB 4. Tauri: ≈154MB 5. Wails: ≈163MB 6. Neutralino: ≈282MB MacOS (arm64): 1. NodeGui: ≈84MB 2. Wails: ≈85MB 3. Tauri: ≈86MB 4. Neutralino: ≈109MB 5. Electron: ≈121MB 6. NW.JS: ≈189MB Linux (x64): 1. Tauri: ≈16MB 2. Electron: ≈70MB 3. Wails: ≈86MB 4. NodeGui: ≈109MB 5. NW.JS: ≈166MB 6. Neutralino: ≈402MB
In Show HN: I rewrote my Mac Electron app in Rust
> it's still a far cry from your ~200 Mb Electron hello world. I think that projects that ship packaged web apps but attempt to use the system native web views where available are really nice, like Wails: https://wails.io/ (so for example, on Windows it would use Webview2, so you don't have to package an entire Chromium install yourself) Here's a comparison of how the distribution sizes change, Wails in particular also has way faster builds than something like Tauri: https://github.com/Elanis/web-to-desktop-framework-compariso... That said, I wish we got more native software, or even something like LCL that can target Win32, GTK, Qt or whatever else is available. Sure, writing components that are available on a lot of platforms and work similarly everywhere is a pain for the developers, but I applaud the effort regardless, since the above
Read the rest
solutions like Wails don't actually do anything for the memory usage and CPU cycles, whereas native GUI software is better for most apps that don't try to be very interactive. I could even see myself using Lazarus/Pascal more if it seemed to have a more active ecosystem, right now I couldn't tell you what are the equivalents of something like Spring Boot for webapps, or even consuming Web APIs in client software, handling OAuth2/OIDC/JWT, seems like mORMot 2 would fit the bill the closest?
In Lazarus Release 4.0
I mean, most OSes already ship with a WebView component that you can use instead of shipping an entire browser runtime. Wails does that: https://wails.io/ Tauri also does that: https://tauri.app/ That does help with the app sizes quite a bit: https://github.com/Elanis/web-to-desktop-framework-compariso... Sadly it doesn’t change the memory usage much so the technology is still inherently wasteful, but on a certain level it feels like a lost battle - because web technologies often feel like the choice of least resistance when you want GUI software that will run on a bunch of platforms while not being annoying to develop (from the perspective of your run of the mill dev).
In Servo's progress in 2024

MAKE YOURSELF AT HOME

A few shortcuts

/
Search the collection
?
Open this guide
Esc
Close dialogs and navigation

Your saved repositories and interests stay in this browser.