Hacker News Reader

Comment by rvz | Hacker News Reader

Another thing not mentioned is there's still no mature cross-platform production ready GUI libraries written in Rust yet. None of them come even close to Qt or countering Electron. Just mere unmaintained bindings to them. [0]

I guess it is either Electron (HTML/CSS/JS) + 200MB Chromium engine or Qt5 (C++) for now.

[0] https://www.areweguiyet.com/

View on HN

There are a bunch of tiny single person projects but they are young and have tons of missing features and bugs. Ideally, you'd have a team building and maintaining a solution but that requires either an insane amount of coordination (and there's tons of disagreement about which design pattern to use), or money.

"yet"

Most languages never get one, and content themselves with piggybacking off of WxWidgets or JavaScript (or whatever).

Indeed. There is certainly no mature GUI framework in Rust yet, simply because it is an extremely ambitious undertaking, but I believe that Rust is by far one of the most promising languages for developing such a thing. I see great vitality both in explorations (for example, figuring out the best patterns for expressing reactivity) as well as infrastructure.

I'll give an example of the latter which I find compelling. OpenType shaping (one of the subproblems of text layout) is a notoriously difficult problem, and almost nothing can compete with HarfBuzz, which is written in C++. Yet there is already one pure Rust alternative being used in production, Allsorts (used in Prince XML), and another promising one in development (rustybuzz, being developed by RazrFalcon, who has a track record of shipping ambitious 2D software).

I rather use the native engines from each platform.

I've come to the conclusion that it's simply impossible to develop many important applications using exclusively platform-provided GUI elements. I guess the evidence of this was always there; after all, Internet Explorer and Office have to implement their own controls, even though they're developed by the same company as Windows.

But by all means, if you can implement your applications using native widgets, please do so. You'll be able to make them accessible, internationalized, etc. with much less work.

The way is just to provide a thin wrapper good enough for the features that the application needs, not a full blown framework.

Which is why it is always a better bet to use use platform languages, they always get them.

> I guess it is either Electron [...]

The really crazy thing is that the group that eventually birthed Rust had an acceptably performant Electron alternative even before Electron existed—and it supported both HTML and native-ish looking widgets. But they completely underinvested in it and eventually killed it—insisting that they knew better and that no one really needed or wanted it. In the meantime, Electron came along and is now so ridiculously pervasive that it's regularly brought up in conversation—even where its of very little relevance—just as a consequence of people looking to complain about how popular it is. The only thing we hear from the former group who strangled their baby, though, is how dire the outlook is for them and their influence on the future of computing.

I’ve never heard about this Electron precursor. What was it called? Could you link to anything about it?

I'm assuming the reference is to XULRunner [1].

[1] https://en.wikipedia.org/wiki/XULRunner

Gecko, which is the rendering engine used by Firefox, has existed for longer than Blink/Webkit (powering Electron). It also supported a UI toolkit (described in XML and a wrapper on Gtk etc.) called XUL [1]. I think OP is talking about this. Mozilla never tried to make it easy to use Gecko (plus the Spidermonkey JS engine) as a re-usable library outside Firefox, making something like Electron really difficult to do. On the other hand, Blink is a lot easier to integrate, which is why Electron exists (as a thin wrapper over Blink+V8).

[1]: https://en.wikipedia.org/wiki/XUL

Reply on news.ycombinator.com