web-to-desktop-framework-comparison VS typescript-go

https://github.com/Elanis/web-to-desktop-framework-compariso...

Electron comes out looking impressive at runtime!

Memory Usage - (Average of runs) Median of difference between system measured free memory before execution and during execution)

> 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 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 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 needed resources 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).

This comparison might be useful to you https://github.com/Elanis/web-to-desktop-framework-comparison

I looked into some alternatives a while back [1] and thought Neutralino looked promising except that it doesn't support node modules. I.e. you cannot use the existing ecosystem of node-stuff.

Still, glad there are many options for using web UI to create desktop apps these days.

[1]: Neutralino themselves link to this nice comparison table: https://github.com/Elanis/web-to-desktop-framework-compariso...

"Web to Desktop" framework comparison: This repository was made to create an objective comparison of multiple framework that grant us to "transform" our web app to desktop application formats.

Electron lets you make you simple desktop apps using html and javascript, but you might get memed for hogging up too much memory. There are other solutions that seem to be better, but I haven’t tried them. Here is a comparison I found online

As a fullstack dev, I did try electron. but I am not Microsoft and my app was not as optimized as vscode can be. If you wan to keep using html, you may want to look into tauri or neutralinojs (among others)

> but it uses your system's existing browser

According to (1) that is incorrect. It uses WebKitGTK+.

(1) https://github.com/Elanis/web-to-desktop-framework-compariso...

The big names around are biome, oxc and an announced Microsoft-developed tsgo.

You didn't read the article. It wasn't a rewrite, it was a port.

https://github.com/microsoft/typescript-go/discussions/410

Here's the FAQs, where they explain the decision to go with Go and not, say, rust.

https://github.com/microsoft/typescript-go/discussions/categ...

First of all, the original TypeScript compiler under the hood is moving in the new version 7 from JavaScript to Go. That is, there will be conditionally TypeScript 6 (JS) and TypeScript 7 (Go). This was done mainly because of the scaling problem when used in very large projects, but also, of course, because of the speed.

Since you wrote this it looks like [Anders replied](https://github.com/microsoft/typescript-go/discussions/411#d...) to one of the threads.

I have to agree with the sentiment that is a success story that the team is allowed to use the best tool for the job, even if it suffers from "not built here".

This is really healthy and encouraging to see in these large OSS corporate-sponsored projects, so kudos to you and the team for making the pragmatic choice.