Hacker News Reader

Comment by jtxx | Hacker News Reader

The main cross platform open source offerings are GTK and QT.

There are lightweight electron alternatives - HTML/CSS engines with a scripting DSL. Sciter is a paid option but I know there are free options depending on your language of choice

I’ve been working on a cross platform music player and went with GTK over QT because I preferred the Rust bindings, QT seemed to have a lot of non UI code I didn’t need, and I was skeptical of dealing with QT licenses (but a lot of people seem to work with it just fine - I just didn’t put the research in to see if it was right for me).

Compiling linux / mac was very easy for me. Cross compiling linux -> windows via mingw64 was also pretty easy. I had some trouble compiling mingw64 on windows, but that was due to SQLite / MSys issues that I never really figured out.

View on HN

> The main cross platform open source offerings are GTK and Qt.

Not really. Gtk UX just isn't an acceptable standard outside Gnome and seems to have approximately ~nil cross-platform share apart from GIMP and perhaps one or two more apps. There are really only two cross-platform toolkits that enable an acceptable level of UX: Qt Widgets and wxWidgets. wx has a smaller and generally more limited selection of widgets and some quibbles (awkward APIs, poor rich text support, docs aren't that great), while Qt Widgets is more on the "does it all" side of things, but that means it's less simple. E.g. a model-backed list is pretty darn simple in wx, but wx is also quite limited. Meanwhile Qt requires you to understand a relatively large model API and more code for basic models, but on the flipside it's also much more powerful. For anti-bloaters, Qt has a larger binary size than wx. wx has a bunch of stuff that only works on one platform or the other and there are a number of behavioral differences as well, since it mostly wraps an underlying toolkit. Qt tends to have largely uniform behavior and features across all platforms.

FWIW all of these (Qt, wxWidgets, Gtk) are LGPL.

Yeah good point, I forgot about wxWidgets - wanted to use it but the rust bindings didn't look maintained.

I think you forgot Swing and JavaFX. Both are cross platform, stable, backwards compatible for years and open source.

Qt (and not QT) is licensed under LGPL3 and GTK is licensed under 2 and later. So if you are not compiling a proprietary application on embedded device, it doesn't make any difference.

> There are lightweight electron alternatives

Are there? I know of alternatives, but none that are particularly 'lightweight.'

I started a new project based on gtk-rs for exactly the same reasons as you.

I was thinking of sciter (5mb) and another similar crate that I can't remember the name for

That's about one order of magnitude smaller than Electron. Good to know.

My gtk-rs project is intended to replace a small, self contained win32 application. The application is 132KB. So although 5MB is small it's an oom larger than my benchmark.

However, my gtk-rs hello, world GUI application is 14.6MB in release mode and that does not include the GTK DLLs that are also needed. Yikes. That's crazy.

Perhaps 5MB is a reasonable price to pay for cross platform GUI. Not taking 7+ seconds to build a GUI hello, world would be nice as well.

There's also https://tauri.studio, which uses Chromium Edge on Windows and WebKit on Linux and macOS. You can get ~2MB binaries with it.

(that's a Rust-specific framework, but the underlying webview library is just a C library)

> There are lightweight electron alternatives

The very definition of an oxymoron... ;)

Why is that an oxymoron?

Because electron consumes CPU cycles and RAM like there's no tomorrow.

Which is the very reason alternatives to Electron, that are more lightweight exist, of course.

I suspect a parse error somewhere.

Indeed, the person you're replying may have experienced a parse error, but this isn't the same person as the one who claimed it's an oxymoron.

Maybe they made that claim because an alternative to Electron probably still uses HTML5 and JavaScript, and HTML5 and JavaScript are huge so it's hard to believe such a thing could be lightweight.

Anyone who says "JavaScript" is "huge" needs to be asked to both qualify and then substantiate the claim (along with the implicit suggestion that they have any idea what they're talking about, instead of just trying to participate in the pile-on with cheap remarks).

There's javascript runtimes for MCUs with <16MB of RAM (no, they are not the same as V8 in Chrome/Node/Electron, but that's the point: large range with many possible solution sizes)

Reply on news.ycombinator.com