Advice for the next dozen Rust GUIs

https://raphlinus.github.io/rust/gui/2022/07/15/next-dozen-guis.html

by raphlinus • 4 years ago

345 270 4 years ago

raphlinus.github.io

mwcampbell8• 4 years ago

I'm the main developer of the AccessKit [1] project mentioned in this post. AMA. To preemptively answer one expected question, I know the project has been inactive for a while; I'm back to work on it in earnest starting this month.

[1] https://github.com/AccessKit/accesskit

favorited7• 4 years ago

This is a really interesting project. Accessibility support is near and dear to my heart.

The readme mentions a macOS adapter prototype, but I don't see that directory. Does it exist in a different branch? I'd love to check it out – I'm pretty experienced with the Mac's AX implementation, but have basically no experience with AX on Windows...

mwcampbell8• 4 years ago

Oh wow, the readme is even more out of date than I realized. I yanked the Mac adapter prototype from the main branch last year. You can find it if you dig through history. I'll bring it back and continue working on it later this year; it's already on my schedule of work to do this year.

password4321• 4 years ago

Do you have a Patreon/whatever setup, since "this is the way" per baby Yoda?

mwcampbell8• 4 years ago

Not yet. But Google is funding my work on AccessKit again this year. I'll write a blog post about that work later.

billconan4• 4 years ago

I attempted to implement my own windowing library after studying winit and SDL2.

The missing feature I need is supporting detachable tabs (like what chrome and sublime text have).

I think for productivity apps, this is very important. But implementing a windowing lib from scratch is not easy.

zachrip• 4 years ago

What are some of the difficulties?

billconan4• 4 years ago

you mean what are some of the difficulties of implementing detachable tabs using existing libraries?

For example, they don't give you the correct mouse coordinates once your mouse cursor is outside a window. I heard this is impossible to do if the underlining system is wayland.

billconan4• 4 years ago

Also, do you think if multi-channel signed distance field is a good approach for GUI text rendering?

I understand, for games, it can support extreme zooming with small textures. But for GUI (for example a text editor), we only occasionally resize fonts.

I looked at some of the open source projects (mostly terminal emulators), they simply rasterize fonts onto a texture map using CPU. I wonder if signed distance field is really necessary.

raphlinus10• 4 years ago

I'm not a fan of distance fields for GUI text rendering. Their main advantage in games is super-easy integration into the rendering pipeline (they're basically just a texture and a simple shader), but the quality is not quite as good as standard font rendering. There are other issues, including fairly large texture RAM requirements for CJK fonts, and no easy way to do do variable fonts. My main work these days is piet-gpu, which is intended to do 2D graphics (including font rendering) "the right way." In the meantime, using existing platform glyph rendering capabilities makes sense and will certainly give the best visual match to platform text.

modeless3• 4 years ago

The best GPU accelerated text rendering I know of is https://sluglibrary.com/. Not based on distance fields. Unfortunately not open source, though it is a one-man project. Maybe someday one of the big tech companies will pay him a whole ton of money to open source it.

modeless3• 4 years ago

Dear Imgui has an impressive implementation of detachable tabs. https://github.com/ocornut/imgui/wiki/Multi-Viewports

billconan4• 4 years ago

That was the reason I studied SDL2 in the first place.

It's working on linux (with x11), but buggy on Mac.

dmitriid• 4 years ago

This advice is applicable to anyone building cross-platform UI toolkits, not just to Rust.

stephc_int135• 4 years ago

I have no business related to Rust, but after reading a few articles from this author, I tend to think that his approach to GUI toolkit design is deeply flawed.

He is undoubtedly highly knowledgeable about the subject, but this knowledge may be a curse in his case.

A mix of second system syndrome and Architecture Astronaut, trying to satisfy too many constraints can be a deadlock.

I think the sensible approach is starting with a Minimum Viable Product, cutting some corners and consciously making tradeoffs. And if success comes, then try to organically grow from there.

zem• 4 years ago

i am just interested enough in new gui toolkits that i have read through a bunch of blogposts, articles, and github repo docs for a ton of emerging ones. my overall impression is that if a lot of these "architecture astronaut" concerns are not at least planned for up front, they will never be implemented, so i welcome the OP's thoroughness in documenting the various issues to be taken into account.

stephc_int135• 4 years ago

I don't think that GUI toolkits that are in use today were born in their final form, or that everything was planned from the start.

I think that unfortunate early design decisions can lead to dead-ends, or extremely painful evolution, of course, and knowledge can help, but paralysis is in my opinion an ever bigger issue.

Making the perfect GUI Toolkit starts by making one that is Good Enough for some use cases.

game-of-throws3• 4 years ago

Maybe you know this, but he already released an MVP for a GUI library: https://github.com/linebender/druid

stephc_int135• 4 years ago

Not an MVP but an early demo, from my point of view.

tayistay2• 4 years ago

A more scrappy approach is what I'm trying to do with my library, rui [1]. Just get something out there. Also, it's really in service of my (already released) app, as opposed to trying to be a successful open source project. If others happen to like it, great!

That said, I think Druid is a good Minimum Viable Product. I just needed GPU acceleration for my app, and wanted something closer to SwiftUI, which I'm used to.

[1] https://github.com/audulus/rui

Diggsey• 4 years ago

This approach doesn't work for GUI frameworks IMO. When building an application, you're looking for a GUI library that meets a set of requirements. If it doesn't meet those requirements you're not going to use it: as an application developer you're not going to want to rewrite the fundamentals of the GUI library, so there's no opportunity for that library to improve.

Maybe it would work if there was no other choice, but in the end you can always use bindings to GTK or some other mature non-Rust UI framework, or use web-view based option.

In order for a pure Rust solution to succeed in the general case, it needs to meet all of these constraints from the get-go, but of course that's an insurmountable task.

For that reason, I think the best approach is to not try to "solve" GUI yet, but instead focus on the pre-requisutes:

- Window creation. - Text rendering. - Compositing. - Accessibility. - etc.

ie. all of the things mentioned in the article can be separated out and tackled one at a time. For that reason I think the author has taken exactly the right approach.

raphlinus10• 4 years ago

“If you want to build a ship, don’t drum up the men to gather wood, divide the work, and give orders. Instead, teach them to yearn for the vast and endless sea.” — Antoine de Saint-Exupéry

I will one hundred percent agree with you that my approach is not a good one if you want a pretty good GUI in a reasonable amount of time. For that, an incremental approach, especially adapting some existing successful design, would be better. But that is not in fact my goal, it is to yearn for the sea.

I am, quite deliberately, spending a lot of risk points. In addition to using a language which may (see elsethread) not be a good fit for expressing UI at all, I'm building a GPU 2D renderer from scratch, also using compute shader techniques which have not been proven, and I am designing a reactive architecture that is not just a simple adaptation of React. Any of these could fail, as have some of my previous attempts. But I think they will be interesting failures, in that we'll learn something, and if all the pieces do come together, it will be a UI toolkit capable of performance completely untouchable by the existing state of the art. In turn, I'm interested in how that could open up new creative possibilities constrained by current implementations.

So I'm pretty comfortable with my approach. And hey, next time you're in the Bay Area (or perhaps when I'm in your neck of the woods), lemme buy you beer and we can talk about why it gives you satisfaction to dump on other people's work.

mwcampbell8• 4 years ago

I think another great counterpoint to dogmatic incrementalism is Gary Bernhardt's classic talk "A Whole New World": https://www.destroyallsoftware.com/talks/a-whole-new-world

joshka• 4 years ago

So I'm pretty comfortable with my approach. And hey, next time you're in the Bay Area (or perhaps when I'm in your neck of the woods), lemme buy you beer and we can talk about why it gives you satisfaction to dump on other people's work.

I love this response - stealing it :)

stephc_int135• 4 years ago

To be frank, I think that the kind of work you are doing is necessary.

In my opinion GUI is not yet something I would consider to be a "solved problem". Both from the API perspective and the rendering side, and compute shaders are indeed extremely promising and could be something close to an end-game in this space.

This is why I read your articles.

And I have absolutely zero interest in dumping on your work, but I have the feeling that a large part of this work is going to waste because of what I consider to be flaws in the ways you are approaching the problems, or maybe the way you advertise your approach, I can sense how discouraging it can be for other devs.

jakear3• 4 years ago

it will be a UI toolkit capable of performance completely untouchable by the existing state of the art

Could you give an example of an application where the bottleneck is UI code? In my experience the bottleneck is always either disk or network. Not trying to bash you, genuinely curious.

runnerup• 4 years ago

Last part might be worth an edit. I saw his comment as constructive well meant criticism rather than callous, thoughtless, or mean spirited.

Also love the work you do and enjoy following it. Your treatises on Oklab are the #1 place I send programmers of all skill levels to understand color.

aaaaaaaaaaab4• 4 years ago

it will be a UI toolkit capable of performance completely untouchable by the existing state of the art

Why exactly? What are the current state of the art UI toolkits leaving on the table performance-wise?

game-of-throws3• 4 years ago

Small comment: It's possible to stitch together UI/video/3D without dealing with the compositor, if you use child windows instead (or in wayland terms, a subsurface). On win32 at least, it's a much simpler approach.

layer8• 4 years ago

The article mentioned scrolling. Do you get smooth scrolling with that approach, when the child window is conceptually embedded into a scrollable view? I guess you should, because the traditional Windows controls are technically all windows (HWND), but I wonder.

raphlinus10• 4 years ago

I could probably have written this in a clearer way. Child windows like a proto-compositor in a way, just with more limitations. You can put video/3D/etc content in a child window, but there are serious tradeoffs. When it's in a scrolling container, either your scrolling implementation is built from child windows, or you're going to deal with less than perfect synchronization as you overlay a changing clip/translate for the embedded content with draws of the rest of your UI (this used to be a common problem in browsers). Modern compositor APIs have explicit transactions[1, 2] causing the various view changes to be applied at the same time. It's not that the problem can't be solved, it's that it's trickier than people imagine.

And of course a Wayland subsurface is using the compositor.

[1] https://docs.microsoft.com/en-us/windows/win32/directcomp/ba... [2]: https://developer.apple.com/documentation/quartzcore/catrans...

c-smile3• 4 years ago

I am participating now in such project - 3D CAD alike application: it renders 3D scene in Vulkan with Sciter rendering auxiliary UI on the same Vulkan surface. Sciter manages dockable widgets, property editors, scene tree logical representation, menus, etc. on top of 3D scene.

Approach is explained here: https://sciter.com/sciter-and-directx/ You see there exactly 3D, video and GUI around.

pornel3• 4 years ago

The background for this is that most existing UI toolkits are a poor fit for Rust.

Rust doesn't like having shared mutable state, but event-based UIs have a global event loop and can mutate anything at any time.

Rust works best with strictly tree-shaped data structures, but event handlers turn trees of widgets into arbitrary webs with possibility of circular references.

Rust prefers everything thread-safe, but many UI toolkits can't even be touched from a "non-main" thread.

Rust's object-oriented programming features are pretty shallow, and Rust doesn't have inheritance. That makes it awkward to model most toolkits that have deep hierarchies with a base View type and a dozen of Button subclasses.

So instead of retrofitting mutable single-threaded OOP to a functional multi-threaded language, there's a quest to find another approach for UIs. This change of approach has worked for games. Rust wasn't nice for "class Player extends Entity" design, but turned out to be a great fit the ECS pattern.

kelseyfrog• 4 years ago

Is there an ECS-compatible ontology for UI components?

bowsamic• 4 years ago

In the post the author says the first architecture for Druid was ECS but they gave it up

jchw3• 4 years ago

The thing is, there do exist UI frameworks that prefer composition over inheritance and strictly tree shaped components where data only flows one way: they're all the rage on the web.

And that's great, because they give plenty of useful insight into things that work and don't work when designing UI frameworks this way.

To be fair, it's not exactly like nobody realized this. More than one Rust desktop UI framework is explicitly React inspired, and it's not like FRP-based UI was non-existent prior to being popularized in web frameworks. Still, all the same... I suspect the best answers for how to do good UI in Rust are not far away from this paradigm.

jollybean7• 4 years ago

So the question is, why are we wrangling our UI approach to match the strict nature of software languages?

Isn't that kind of upside down?

Wouldn't the obvious lack of fit hint at perhaps some kind of fundamental impedance mismatch?

While most other techs are not a perfect fit, Rust is a 'worse fit' for the kinds of things we want to do in UI. The 'design objectives' of UI for the most part just do not apply at all.

Even the 'Stateless / Unidirectional' tree patterns seem to be a bit inverted as I think the slight advantage of thinking just a bit about hierarchy in a different way is abnegated by the hurdles imposed when it does happen.

Dart is a good language for UI, I suggest better than Rust in almost every way. The 'advantages' of Rust may present themselves in at lower layers.

And both the unidirectional and even 'stateless' (i.e. Flutter) are mostly unnecessary. We'd be better served by some fairly basic conventions.

I will admit I 'learned' something by using the fairly strict hierarchy in Flutter - and am better for it - but I still want my 'statefulness' tree back.

nyanpasu648• 4 years ago

I don't like React: https://news.ycombinator.com/item?id=31981947

In Cocoa, scroll position is part of the view's state, a mere property of the view. This is simple because the UI itself is stateful.
In React, scroll position is typically not part of the state from which we project the view. Instead this state is attached to the projection itself (e.g. a HTML node) and we are dependent on the "Memoization Map" to preserve it. So this memoization is now required for the correct functioning of the app. The "pure function" abstraction is leaking.

kaba011• 4 years ago

The DOM still propagates events upwards, resulting in backwards tree-traversal.

pohl3• 4 years ago

Swift is different from Rust, but it's more towards Rust's end of the spectrum. Sure, it has classes, but it's almost as if they're mostly there to aid in compatibility with Objective-C APIs like UIKit. SwiftUI builds UIs with value types and protocols like View.

I wonder if something like SwiftUI would work well for Rust.

raphlinus10• 4 years ago

I think the answer is yes. See rui in particular (linked by its author in another comment), which inspired my Xilem exploration.

pjmlp17• 4 years ago

Visual designers and GUI components don't play well with borrow checker.

pornel3• 4 years ago

Swift<>Rust similarity is only superficial in syntax. Swift has full OOP with inheritance, allows shared mutable state, and doesn't have compile-time thread safety. It has been built for Cocoa interoperability from the start.

The clunky `Rc<RefCell<Object>>` that Rust tries to get rid of from UI toolkits in Swift is just `Object`. Rust's undesirable case is the Swift's built-in default (that's not a criticism of Swift, ARC works great there, but these two languages have chosen very different trade-offs).

worik5• 4 years ago

What about Flutter?

armchairhacker3• 4 years ago

I believe the solution for this is to have a shared context, batch changes and then run through all of them at once.

So when you e.g. mutate a variable, it doesn’t actually change until the next frame. which you can get by calling some sort of poll function. The poll function has mutable access to your entire widget tree, applies the updates, then you can have more UI with shared access

Rust is fast enough that i think performance won’t be an issue.

jollybean7• 4 years ago

Most UI frameworks enforce a 'single thread' rule, i.e. one thread at a time touches the tree. Would this solve the problem?

epage• 4 years ago

I'm glad Rust* is forcing us out of a rut in UI toolkit design. All of these spell hard-to-debug problems.

* Yes, I know elm-derive UIs are also a thing and have laid a lot of ground work in this area.

btw I've had great experience 10 or so years ago doing composition-based UI design in GTK with Python. When Maemo switched from GTK to Qt, the requirements on inheritance were one of my points of frustration and I got away with creating a couple adapter classes to avoid most of it.

stu2b50• 4 years ago

I wouldn't give Rust or Elm the credit for that, though. Although it was not first, React is really what put the declarative method for UI programming on the map. Today, there's a solid argument that by usage numbers React is the most used UI framework today, and it's children like Vue are high up there too.

Swift also has a similar problem and unlike Rust has a powerful backer, so SwiftUI is in many ways already a vision of what a Rust native UI framework would look like.

nine_k• 4 years ago

There's one "UI toolkit" that builds in top of immutable data structures, trees, and unidirectional data flow. It has also taken web UI development by storm. It's called React.

I wonder if React-like approaches are going to work for Rust UI toolkits. They could even wrap some native controls, much like React does with DOM controls, or React Native with Android controls.

deterministic• 4 years ago

Yep I agree that is the right approach. Elm is amother example of this architecture in action.

amelius3• 4 years ago

React is nice for high-level work. However, if you're writing e.g. a rich text editor from scratch it is probably not a good fit from an efficiency viewpoint.

hnjst• 4 years ago

I recently tried https://github.com/yewstack/yews that looks very much like "React in Rust". It is web oriented through WASM compilation and integration with web technologies, Tauri can be used to bridge the gap and use it for desktop apps but it is probably an excessively complex and impure assembly for that goal.

JediLuke• 4 years ago

The ‘Scenic’ GUI library written in Elixir handles all these problems very elegantly, and Elixir is completely functional (no traditional OO, classes or objects)* and immutable.

*of course Elixir/erlang is actually OO done right (actor model) but that’s another story

cjohansson• 4 years ago

Thank you for the context, this also explains why most UIs gets broken / stuck at times. Like spinners that never stops or buttons that stay disabled even though they should be enabled. Those kinds of issues happens every day even in Apple, Google and Meta products (a lot of economical power) so there must be a deeper structural cause for this and I think it boils down to that the UI frameworks used are inherently fragile and has built-in edge case issues because of this

kaba011• 4 years ago

I wouldn’t say it is inherent, I think it has more to do with state management - some state is inherent to the component itself, but the separation is problematic. All too often business logic gets stored in the component and vice versa.

amelius3• 4 years ago

Rust works best with strictly tree-shaped data structures, but event handlers turn trees of widgets into arbitrary webs with possibility of circular references.

This is also the problem with closures. And why you can't do Haskell/Ocaml style functional programming in Rust.

Rust has the reputation of being fast, but if you force everything into a tree, you are making big compromises from the start.

tjoff12• 4 years ago

I'd argue a GC is an order of magnitude bigger compromise though.

And that even before considering performance.

dataangel4• 4 years ago

Rust has no problem expressing things that aren't thread safe. If the UI framework is single threaded all it takes is making its objects neither Send nor Sync, which will likely be taken care of automatically by them having fields that are not.

seanalltogether• 4 years ago

I haven't looked closely at the latest rust gui projects, but from what I remember most of them seem to be focused on code driven ui layouts, which I think is going to be a non-starter for anyone doing serious application work. View hierarchies and layout rules are too big and too complex to be maintainable via hand coding. Even a moderately sized app can have hundreds of custom views or components that need constant refactoring. You really need something like xml or json or whatever to build out that tree structure and easily visualize it.

favorited7• 4 years ago

I think the industry at large is moving in the opposite direction, towards declarative layouts written in code. As an example, for decades, Apple's UI design tooling (Interface Builder) was serialized to XML, but SwiftUI uses a DSL so your interfaces are written in code. I haven't been a web developer professionally for a while, but I've dabbled in React, where you build UI components in JSX, which is an extension of JavaScript.

I don't see why Rust couldn't be successful with a similar approach.

favorited7• 4 years ago

On macOS ... going forward, it’s likely that new capabilities and evolutions of the design language will be provided for the latter [SwiftUI] but not the former [AppKit].

I think this is vastly over-stating the technical churn of UI development on macOS.

While we're definitely seeing new UI toolkits introduced that are Swift-only (like the new Charts.framework[0]), nearly every Mac app Apple ships is written using AppKit. For example, I just verified (`otool -l PATH_TO_APP_BINARY`) that Mail, App Store, Notes, Music, Xcode[1], and Photos all link against AppKit, and none link against SwiftUI (on macOS 12.4 21F79, which I'm running).

There is, in my opinion, approximately zero chance that Apple either:

(A) rewrites all of the UI in all of their apps, replacing AppKit with SwiftUI, in even the medium-term, or

(B) starts treating AppKit apps as second-class citizens by introducing a new design language only available from SwiftUI.

Yes, we're going to keep seeing cool new widgets and features which are only available from Swift. No, the platform's design language is not going change in a way that makes AppKit apps obsolete.

[0]https://developer.apple.com/documentation/Charts

[1]I bet Xcode links SwiftUI somewhere for IDE integration, but I'm specifically referring to the UI implementation, parts of which have been in development since, like, NeXTSTEP and are certainly built using Objective-C & AppKit.

jolux3• 4 years ago

Aren't App Store and Photos Mac Catalyst apps?

favorited7• 4 years ago

Nope! Both are fully native macOS apps, at least on the version of Monterey that I'm running.

You can examine which frameworks a binary links by running `otool -l /System/Applications/Photos.app/Contents/MacOS/Photos`. Traditional macOS Cocoa apps will link AppKit, while Catalyst apps will link UIKit.

For example, if you run that command with a Catalyst app (e.g., Messages or Maps), you'll see that those apps link against `/System/iOSSupport/System/Library/Frameworks/UIKit.framework/Versions/A/UIKit`, and AppKit is nowhere to be found.

tacotacotaco• 4 years ago

I would remind you that Microsoft disowned MFC and aggressively pushed all developers off of win32api once .net was released. Then they went about rewriting visual studio in .net and possibly the office suite as well. I hope Apple doesn’t attempt this because, in my opinion, I don’t think Microsoft’s products benefited from that churn.

xyzzy_plugh• 4 years ago

This is an extreme exaggeration. The shit you can do with MFC is still frightening, even today.

pjmlp17• 4 years ago

And yet a couple of devs sabotaged C++/CX efforts to the point that C++/WinRT with WinUI 3.0 isn't a match to MFC in tooling.

jreese• 4 years ago

On the flip-side, it's worth keeping in mind where the puck is heading. Every "new" macOS app from Apple (eg, Shortcuts, System Settings, and even recent refreshes of old apps) has been written in either SwiftUI or Catalyst. A bunch of these still link to AppKit here and there, but it seems pretty clear that no new developement is breaking ground with AppKit.

Similar to the Carbon/Cocoa split, I'm sure we'll see AppKit supported well into the future, especially since we just passed the latest major architecture transition. But that doesn't mean AppKit isn't a dead end.

favorited7• 4 years ago

That's totally fair, but I think the point that "every 'new' macOS app from Apple ... has been written in either SwiftUI or Catalyst" isn't really surprising. New features are probably going to rely more on newer technologies – especially in places like Shortcuts & System Settings, where the legacy approaches had non-trivial security implications. And, at least so far, we've only seen Catalyst apps from Apple when either:

(A) an app was being ported from iOS because it didn't already have a native Mac counterpart (e.g., TV, News, Podcasts), or

(B) the Mac version was significantly behind its iOS counterpart from a feature perspective (e.g., Messages).

I had written a diatribe earlier about how I don't see this as equivalent to the Cocoa/Carbon situation, but deleted it because I'm being long-winded enough already. It boiled down to the fact that Carbon existed specifically to help port apps from a legacy OS to what Apple was loudly declaring to be the future: OS X. Carbon was a way for apps to get off the sinking ship that was the "classic" MacOS. I mean, they had a funeral for it! https://i.imgur.com/KjFh63u.jpg

20 years from now, will Apple's macOS apps contain more Swift+SwiftUI than Objective-C+AppKit, probably! But I'm not worried about AppKit being a "dead end" until they rewrite Mail, Keynote, and Xcode – because they have significantly more invested in those apps than I have in my AppKit apps.

(For the record, I love SwiftUI, and use it whenever I can! I just have no expectations that AppKit is going away any time soon.)

Klonoar• 4 years ago

The Music.app rewrite is AppKit-based, so it's not unheard of for Apple to still reach for AppKit internally.

ketralnis• 4 years ago

Apple themselves aren't particularly quick at adopting the guidance that they give to developers. iTunes was carbon well after Apple was telling developers to stop using it

pjmlp17• 4 years ago

Apple clearly stated at WWDC 2022, that the best days of Objective-C and AppKit/UIKit are behind them, they even had a slide for it in case there were any doubts.

sandyarmstrong• 4 years ago

Yup. Even the "What's new in AppKit?" talk pushed using SwiftUI for things like Settings due to controls only available in SwiftUI.

rustqt6• 4 years ago

Fwiw, I've head a great time with rust qmetaobject for some (basic) GUIs. Qt is more polished than any non-concerted (or even concerted) effort is going to be in at least half a decade

riquito• 4 years ago

Raphlinus, great post as usual, thanks for sharing your knowledge, is always an interesting read.

I'm loosely following the progress of slint ui (formerly SixtyFPS), anything interesting in their approach or does it strictly matches one of your examples?

raphlinus10• 4 years ago

I don't follow slint as closely as maybe I should. I'm definitely happy there's a real product out there, and would be happy to work with them on common infrastructure, but we haven't had much interaction (yet).

hardwaresofton2• 4 years ago

Bit of a hot take, but I basically expect that most new Rust GUI projects will be written in Tauri before long.

It works on multiple platforms, and is flexible, and it's easier to find off the shelf pieces due to the web technology involved, and it's lighter than Electron. It's a no-brainer for me (and others, I think) if I'm starting a new GUI desktop project.

tmpfs• 4 years ago

I think you are right about this with the one huge problem from my point of view being the text rendering on Windows.

This is of course a problem with the Webview implementation on Windows but it is so awful it makes me want to use something else instead.

Note this is not a reflection on Tauri which I think is awesome but Microsoft really should fix it.

favorited7• 4 years ago

Is there something blocking Tauri from switching to WebView2 on Windows? It's based on Chromium, so I assume most of the legacy web view issues would be irrelevant.

IIRC, WebView2 is supported going back to Windows 7...

oldmanhorton• 4 years ago

Tauri uses WebView2 on windows, I believe, which should have the same text rendering as the Windows 11 start menu and Edge itself. You may be thinking of older IE-based webviews, which were used even well after "old edge" webviews were introduced because "old edge" webviews weren't supported on windows 7 or 8.

xvilka• 4 years ago

Hopefully, not. From my personal experience, Electron and alike applications are slower, larger, and in general have less advanced UI than many Qt or GTK-based (or Windows UI) applications. Nothing can beat good old native GUI frameworks.

hardwaresofton2• 4 years ago

Note that I did not make performance claims relative to native!

The “use Qt/GTK/etc” is quite a common refrain on hn, and while I agree all these projects just have not achieved the DevEx that anyone is looking for.

Electron/Tauri and even flutter are easier, and that’s why I think they will win.

AFAIK the real problem is accessibility features which are lacking. The wasteful resource use will be essentially fixed as computers get faster/hold more data, and more devs put even minimal effort into resource usage.

asiachick• 4 years ago

Instead of trying to decide whether a GUI toolkit is native or not, I recommend asking a set of more precise questions: > * Does text look like the platform native text? > * To what extent does the app support preferences set at the system level? > * What subset of expected text control functionality is provided? > * Complex text rendering including BiDi > * Support for keyboard layouts including “dead key” for alphabetic scripts > * Keyboard shortcuts according to platform human interface guidelines > * Input Method Editor > * Color emoji rendering and use of platform emoji picker > * Copy-paste (clipboard) > * Drag and drop > * Spelling and grammar correction > * Accessibility (including reading the text aloud) > If a toolkit does well on all these axes, then I don’t think it much matters it’s built with “native” technology; that’s basically internal details. That said, it’s also very hard to hit all these points if there is a huge stack of non-native abstractions in the way.

This is it! Browsers handle all of this. It's a ton of work. Many many gui kits start with just ASCII and really don't realize how deep the rabbit hole is for making all of this work.

And as always, if you haven't read them

https://gankra.github.io/blah/text-hates-you/

https://lord.io/text-editing-hates-you-too/

overgard• 4 years ago

I think the web really killed the idea of "native" widgets. I think the rise of web apps just got everyone used to the idea that controls are just going to look different everywhere. Even on macOS, practically every app I use has a very distinct look and set of widgets (vscode, photoshop, blender, spotify -- two of those are electron, but even the non-electron stuff doesn't look very much like a "mac" app anymore). And in windows, microsoft really killed it themselves by constantly updating their own apps with non-standard widgets that everyone else wanted to clone (I remember the longest time it seemed like the only new things of note in every new version of ms office was how the toolbars looked). I suppose it's not a terrible thing, but I do kinda miss the days of windows 2000 and classic macos where the platform had a (somewhat) uniform look and feel.

wmf• 4 years ago

I think it's more a desire for branded UI rather than Web apps. Adobe wants their UIs to be instantly identifiable as Adobe, Slack wants to be instantly identifiable as Slack, MS Office as you said, etc. Personally, I doubt this benefits users (do you really need to market to people who already bought your product?) but I'm sure the logic is compelling to decision makers and it's cheaper to "design once, run everywhere". It also makes sense to developers that their app should look the same across OSes even though that "consistency" doesn't affect the 99% of users who only use one OS.

Nadya• 4 years ago

What's funny is that it pisses off a large number of those 1% of users who swap OSs frequently as well. So it isn't even for the benefit of that 1% either.

When operating a Mac I expect Mac-specific behaviors. When operating a Windows PC I expect Windows-specific behaviors. I LOATHE programs that decide to do away with OS-isms that I am accustomed to and require me to learn how to "do things their way" because they wanted cross-OS consistency. Sometimes this means conforming everything to a single platform which is partially evil but just as often it means conforming to _none of them_ which is pure evil.

But I understand this - as a web developer I've experienced pressure from Project Managers and the "decision makers" to make things consistent across browsers/devices even if doing so goes against how the users of said browsers/devices would expect things to operate - breaking user expectations and creating a worse UX for many users. I fight against it when I can but I'm not always successful.

int_19h2• 4 years ago

But this kind of branding wasn't as prevalent before web apps invaded the desktop. Now the users are pretty much conditioned to expect every app to do its own thing.

edflsafoiewq• 4 years ago

Consistency across OSes if for the benefit of devs, not users. The more you can reduce platform differences, the easier it is to maintain multiplat code, you don't need a specific platform to repro issues, etc. It's the same logic as the trend toward static linking.

CrimsonVoid3• 4 years ago

I know this is going to be a controversial opinion considering how much everyone seems to love Rust, but does anyone else find Rust incredibly painful to work with, even for simple tasks? Like I'm no stranger to unmanaged languages, and to some extent I cut my teeth on C, but doing anything with Rust always feels like the most aggravating exercise in needless verbosity and the "Lombok problem" doesn't help either. (Funnily enough, both these reasons are why I don't like Java either). I don't want to sound too negative, Rust is a very promising language, but even seven(!) years later it still feels like a pre-alpha language.

cturtle• 4 years ago

Yes I do find it painful. Because rust’s memory safety restricts the number of valid programs, it is (to me) more difficult to write code. That’s not a bad thing though! It’s just not a trade off I’m willing to make most of the time.

If my project requires the memory safety that rust offers, I’ll choose rust. But most of the time I’ll pick something else to lower my mental load when coding.

__david__2• 4 years ago

I don't find that. I was quite familiar with C and C++ before learning Rust and I find the places where Rust requires explicitness are the places where C lets you glide by and inject hidden bugs into your code. When my Rust code finally compiles it has an extremely high percentage chance to _just work_, where when C compiles you still have another whole pass of "find all the segfaults lurking around".

josephg• 4 years ago

I learned rust a few years ago, and almost all the code I’ve written in the last 18 months has been rust. Rust makes you deal with all the pain of learning it up front. Does that pain ever go away?

In my experience, it mostly does. I’m now significantly more productive in rust than C, and I feel much more pleased with the end result.

I still find it takes a lot more effort to write rust than javascript though. Both more thinking per line, and it often takes more lines of code. The resulting software is faster and more correct, but it’s not a uniform win. I still reach for javascript for “code as content” - like UI code.

Rust’s async story is awful. Pin is confusing. Async doesn’t play nice with other rust features (like traits). There’s no async streams and it’s extremely difficult to code your own. Solutions to these problems (like GAT and TAIT) have been proposed, coded and discussed for 6 years or something but they still haven’t shipped. I’m quite frustrated with how slowly the language is moving to fix obvious problems. And it seems to be getting slower as more people try to “help” (by chiming in on GitHub).

But I really like rust-sans-async as a language for infrastructure code. The stuff I’ve built with it is bonkers fast, safe and correct. The crates ecosystem is fantastic. (Much higher quality than npm). And the community is smart and lovely. It’s not the most productive language but it fits the “better C” niche really well.

Starlevel001• 4 years ago

Rust is a clever language, which wrecks havoc on people's programming ego by making them very inclined to try and write clever code.

But if you avoid trying to be really annoying with the type system like the majority of the ecosystem is, and slap Arc/RefCell/heap allocations everywhere, the language turns back into a high-level language again.

Unfortunately, stepping outside the realm of ``core`` and ``alloc`` and ``std`` means having to repeatedly step on overly clever landmines everywhere you go.

melony• 4 years ago

The problem is that you can't even build data structures from introductory algos in Rust without pulling your hair out. No linked lists, no graphs.

filleokus• 4 years ago

I remember reading (on HN I think) that coding in Rust is like playing some kind of intricate puzzle game. Tricking the compiler into accepting your code. You feel smart when it works and challenged when it complains. I personally like that aspect, at least for now.

On the other end of the spectrum I would say Go is, with its lack of "advanced" or functional language features and sans-syntactic-sugar straight forward approach. I always feel like I have oncoming RSI when I write Go, its just so verbose and un-dense and frankly boring. No room for (too much) cleverness.

At the same time I would guess real development teams using Go are more productive (in problem spaces where Go can be used instead of Rust of course). Especially if you factor in mentoring of junior colleges new to the language etc.

the_duke2• 4 years ago

coding in Rust is like playing some kind of intricate puzzle game. Tricking the compiler into accepting your code

That is mostly only true for very early beginners.

There are certain patterns you have to learn and understand, especially for developers not accustomed to thinking about lifetimes ( which applies to most developers that only have experience with GC languages).

And sometimes you do have to battle the compiler, even with experience.

But most of that goes away pretty quickly once the language clicks for you.

After that Rust can still feel restrictive, but that's because there are very few languages that enforce as much correctness at compile time.

That very well can mean that Rust just isn't a good fit for certain domains - which is perfectly fine!

baby2• 4 years ago

Completely agree with Golang, it is such a nice language as it remains pretty basic/simple and thus extremely readable and easy to use. Sure it's not expressive enough for some applications, but for a lot of applications it really shines. I'm mostly doing Rust nowadays, but if I want to use a beautiful and enjoyable garbage collected language there's Golang.

game-of-throws3• 4 years ago

When I hear you say "Lombok problem", it makes me think you're writing getters and setters and generally treating the language as if it's Java. You might get along better if you try to unlearn some of those habits. There's nothing wrong with public fields or free functions; in fact I'd say most of the time the straightforward approach is preferred.

CrimsonVoid3• 4 years ago

It's less about getters and setters specifically and more about how much Java's ecosystem relies on code generation through libraries like Lombok instead of just trying to fix the language. Likewise, Rust's answer to everything seems to be "just make a (proc) macro" instead of trying to extend the language. Proc macros do have their place, serde being a great example, but then there are crates like thiserror and bitflags which exist because Rust provides nothing in the language grammar to actually talk about errors and error handling patterns, or bitmasks (which is an incredibly common thing for a systems programming language). Sure you could write out the From<Error> impls instead of using thiserror, but most people aren't going to because Rust makes something that should be mundane incredibly annoying to write by hand.

Side note, Rust best practice seems to be in favor of getters and setters like Java and several popular libraries I've seen don't expose struct fields directly instead opting for set_x() and x() methods. Give it a few years and I'm sure Rust will have its own Lombok crate generating getters, setters, and constructors too.

wokwokwok• 4 years ago

Not everyone loves rust.

I don’t love rust. I think rust has some fair critiques to be made of it.

It’s not, and never has, or (probably) will be the answer to all problems.

Don’t use it just because it’s popular; why are you trying to use it, and what are you using instead?

I’ll eat my hat if you can convince me that rust is more of a pain in the ass than c++. I think cpp is a stupid broken ecosystem, and the fact that rust went all in with a single unified package manager makes the comparison a non-event.

So… compare apples to apples right?

“pre-alpha” language? I don’t even know what you mean by this; but, it’s ok not to love it.

There are things I dislike about it too.

It is verbose.

I still use it though; it’s better than the alternatives for what I’m doing.

rvz• 4 years ago

It is good for some use cases, but the hard fact of the matter is, it is not useful as a way for creating cross-platform scalable GUI apps.

I have heard all the arguments for using Rust in GUI apps, but realistically they seem to be very weak to convince a serious team of developers to choose between the alternatives.

baby2• 4 years ago

I really really hate Java, in parts due to the verbosity, and find Rust very pleasant to write. I'm not sure I would call Rust verbose at all, although you can look at code that gets verbose due to the expressiveness of the language and the desire for people to over engineer things (versus a language like Golang that remains very readable at all time). But when I write my own code, I tend to avoid the complexity and write pretty clear (I would like to think) Rust code.

There's definitely a learning curve (I think everyone agrees with that one), which might be what you're feeling now, but that quickly goes away once you pick up some speed. I would say keep on learning Rust and the language will grow on you.

lakecresva• 4 years ago

but even seven(!) years later it still feels like a pre-alpha language.

Can you give any concrete examples of things that give you this impression?

CrimsonVoid3• 4 years ago

Sure, I kind of hint at it in another comment in this thread but a few more pain points for me:

* Rust has no way to talk about heap allocations succinctly other than Box; an actual type I had Option<Box<[Box<[&'a str]>]>>. It's more than just Box and Option being poor abstractions for the heap and nullability respectively, but the fact that Rust is a systems programming language and provides nothing to actually help with even mundane problems that arise in systems programming

* there has been almost no iteration in the design space of lifetimes despite being a cornerstone feature of the language

* prolific do_x and do_x_mut methods; there has to be a better way than countless *_mut methods for a language where mutability is so important

My general impression of Rust is that it ships a MVP version of a feature and never really tries to iterate on it, or iteration happens incredibly slowly (const generics being the only notable exception I can think of where almost every release seems to have something to say about const generics). And I get it, things like GATs are important for the language long term, but the "ivory tower" approach has left the rest of the language feeling neglected IMO.

nu11ptr4• 4 years ago

To be honest, usually the exact opposite. There are some things where I start writing in Rust and it turns out to be a bit of a pain, but this is unusual for the types of stuff I write. Typically this just means I need a crate to do the heavy lifting as I'm trying to do too much. I would say most things are solidly better and easier to write, and given the safety guarantees, often work even without tests (exception being complicated algorithms that I usually get wrong the first time). In summary, yes, I'm a bit of a fanboy, but there is a reason I am - Rust is pragmatic and helps me get things done in a way I have not found in other languages.

shrimp_emoji• 4 years ago

It was painful for me at first. Many struggles with the borrow checker. I dropped it for a year or two and came back, and, weirdly, my return met smooth sailing -- the borrow checker and I were a well-oiled cybernetic machine. It was like the lessons of my first time burrowed into my subconscious or something.

At this point, I kind of feel like, if you're writing safe C or C++, being mindful of where the data goes and why, you're pretty much writing Rust that compiles.

anon2913• 4 years ago

At this point, I kind of feel like, if you're writing safe C or C++, being mindful of where the data goes and why, you're pretty much writing Rust that compiles.

Exactly. If you're using modern c++ and you actually know what's undefined behavior and what's not, you're doing rust. The only difference is c++ compilers don't error out on the undefined behavior. Actually it wouldn't be that hard to write a c++ compiler that errored out in this way. unfortunately, it'd break all c++ programs today.

WiSaGaN• 4 years ago

It depends very much on what type of software you are writing. Whether you are writing an exploratory software that will get tossed a few days after, or a piece of hardware that will be used and modified continuously in order of several years. Whether it is a GUI like mentioned in this article with changing requirements or architecture trends once in a while, or fundamental building blocks with very slow-changing requirements but with high stakes regarding correctness and performance like kernels or cryptotography/security. There is no single tool that can handle all the problems, but rust can be especially productive to use in those latter case, considering the time spent in entire software life-cycle like maintaining and debugging. After some time, it is even possible to be more productive just in writing code itself than Python (for me this is true for command-line client tools)! At the end of day, if you are a C++ programmer that gets constantly bitten by bug either written by youself or by someone else in your team. Bugs like using `foo.to_string().c_str()` after the line that defines it, bugs caused by trying to erase element of an iterator in a `for` loop. Starting to write code in Rust, it will soon be less painful than writing in C++. Especially you are into idiomatic ways to write good software in C++!

avgcorrection• 4 years ago

Why would people be annoyed? Plenty of people have done the same thing in this thread. Except they stayed on the GUI topic. So maybe that’s why you included the sheepish intro sentence.

the_duke2• 4 years ago

Isn't all the discussion about the top level UX a bit of a red herring?

Iced, slint, sycamore, Dioxus , yew ... they all have quite different but very workable API surfaces. Yes, three of those target the browser, but there's nothing stopping them from building on a lower level Rust widget system instead. Even gtk-rs found a solid way to map a class structure to Rust extension traits.

Isn't the real problem in the weak fundamentals? Solid window and input handling, text rendering, layouting and 2d drawing libraries, ...

I see all the UI attempts struggling with those, and either implementing their own solutions or battling the existing ones (like winit).

I feel like if all those pieces were in place decent solutions could emerge.

__david__2• 4 years ago

I just happened to build a little project using Slint (https://slint-ui.com/) last week and found it fairly pleasant, even though it's got some rough edges still. I liked it because I was able to cross-compile to Windows from my Mac and from my Linux based CI with extreme ease ("cargo build --release --target x86_64-pc-windows-gnu"). It supposedly has some sort of native widgets available if you have Qt installed, but I haven't pursued that yet.

It has a little meta language for describing the UI that gets compiled when you compile the code and that was nice because it catches type and syntax errors at compile time.

I almost went with Tauri, but the cross-compile story didn't seem quite as good compared to Slint. Tauri does look nice though—web UIs are more flexible than Slint at this point. But for my simple little tool, Slint really hit the spot.

c-smile3• 4 years ago

The background for this is that most existing UI toolkits are a poor fit for Rust.

Being in GUI business for almost 30+ years I shall admit that this above is true. And not just Rust but C/C++ are there too.

Real (a.k.a. practical) GUIs are multi-paradigm entities. Same GUI implementation may have React'ive alike widgets immersed into purely declarative DOM/widget tree with elements of immediate mode graphics on top or inside that.

It is just that GUI reflects complexity of real life - you cannot say that sickle and hammer are best tools for everything...

Back to Rust... As a language behind UI Rust is the worst language imaginable. That's primarily due to its strictness.

Object ownership graph in GUI is usually quite complex. yet it is dynamic and frequently contain loops. This situation is best handled by GCable languages. On-click-here-highlight-the-thing-there-and-remove-that-one.

Also each part of UI declaration needs it's own DSL: for UI structure definition, style system and logic behind the UI.

Before arriving with Sciter [1] I've tried [2] many things for UI: C++, D, Java, etc.

Conclusion: HTML/CSS/JS is the best (most flexible and multi-paradigm) solution that we've got so far. Not perfect of course but good enough. And considering existence of Sciter it can be fast and lightweight.

Practical example: RustDesk (https://github.com/rustdesk/ - remote desktop access) is using Sciter for UI layer and Rust for app logic layer. So it is using proper tool for each task.

[1] https://sciter.com [2] https://terrainformatica.com/2014/07/17/10-years-road-to-sci...

gpm• 4 years ago

Also each part of UI declaration needs it's own DSL: for UI structure definition, style system and logic behind the UI.

This is actually one thing I think rust has going for it, the procedural macro system makes it possible to embed reasonably arbitrary DSLs in rust.

c-smile3• 4 years ago

Rust can be good for implementation of UI system but as a language-behind-UI it is bad - its advantages (e.g. strictness) directly translate to disadvantages in that area.

At the end, main idea of initial Rust design is to be the language with what browser is implemented.

JavaScript (in ES2020 specification) is really good enough as UI automation language. If not JS then TS.

Just in case in Sciter I've added native JSX to JS. JSX is an ergonomic way of defining tree alike literals that used for UI DOM population and patching.

ec109685• 4 years ago

The comparison of React Native to toolkits like Java’s AWT is incorrect given react native orchestrates the platform native UI toolkit, so the platform’s widgets will work similarly to other applications.

akagusu• 4 years ago

while Electron continues to gain momentum

Electron is not gaining momentum, it already is the standard.

No matter what people try to invent, it needs to do all Electron does but ways better.

nu11ptr4• 4 years ago

No matter what people try to invent, it needs to do all Electron does but ways better.

Tauri strikes me as a good step up from Electron, and likely a better fit for Rust users (as you can code everything except for view in Rust), but I have just started playing with it.

nextaccountic• 4 years ago

as you can code everything except for view in Rust

You can do the whole stack in Rust,

https://dev.to/stevepryde/create-a-desktop-app-in-rust-using...

https://github.com/jetli/rust-yew-axum-tauri-desktop

Const-me5• 4 years ago

On Windows, the graphics story is more or less OK. The OS includes Direct2D and DirectWrite user-facing APIs.

It’s now possible to implement an equivalent on all modern platforms which have a 3D GPU. An open-source example in C# https://github.com/Const-me/Vrmac#vector-graphics-engine That particular one requires GLES 3.1, but I’m sure (did it before) it’s also possible to implement comparable stuff on top of GLES2.

Waiting for target devices to have TFlops of FP32 performance, and good support for compute shaders, is less than ideal. Many currently sold phones, tablets, laptops, and even some desktop PCs, have limited GPGPU capabilities and/or performance. These currently sold devices gonna stay in use for at least couple years in the future.

Rendering things on CPU is less than ideal, because many devices have high-rez displays yet relatively slow CPU and especially RAM.

Am I missing something? What’s the reason there’re no cross-platform GPU-first 2D graphics libraries, despite GLES2 (or better equivalents) is now universally available, and have been for years?

stefan_• 4 years ago

Huh? That library exists, it is called Skia, it is the most premier 2D GPU (among other targets) rendering library in the world and it powers the Android UI, Chrome, Firefox and a ton of other things. See also: https://skia.org/

Const-me5• 4 years ago

Skia is not GPU first. It was initially designed for CPU-only rendering, 3D GPU support was an afterthought. For that reason, the quality of that support ain’t great. AFAIK it only uses 3D GPU to compose layers.

mwcampbell8• 4 years ago

Waiting for target devices to have TFlops of FP32 performance, and good support for compute shaders, is less than ideal. Many currently sold phones, tablets, laptops, and even some desktop PCs, have limited GPGPU capabilities and/or performance. These currently sold devices gonna stay in use for at least couple years in the future.

I'm reminded of how Windows Presentation Foundation relied on a level of GPU-based 3D acceleration that wasn't yet universally available on non-gamer PCs when Vista came out. This affected my brother when he was in seminary and tried to run the WPF-based Logos 4 Bible software on a budget laptop bought around 2007 (edit: actually 2008 IIRC). By 2011 it got bad enough that I just bought him a new laptop. And he wasn't the only one affected by this; there were others talking about it on the forum for that application [1]. This anecdote has stuck with me as a cautionary tale about us developers failing to put our users first in our technology choices (though I admit it hasn't actually stopped me from using Electron when the pressure to ship is on).

[1] https://community.logos.com/forums/t/6200.aspx

pbsurf• 4 years ago

Getting sufficient antialiasing quality for 2D graphics is difficult on GPUs. https://github.com/memononen/nanovg accomplishes this with GL2/GLES2 level hardware for most of the stuff one would want to render as part of a GUI. My project https://github.com/styluslabs/nanovgXC supports rendering arbitrary paths with exact coverage antialiasing, but requires GLES3.1 or GL4 level hardware for reasonable performance.

Const-me5• 4 years ago

Here's how I did that https://github.com/Const-me/Vrmac/blob/master/Vrmac/Draw/VAA...

Inexact but IMO pretty good still. With some modifications, the approach can be used in GLES2.

Animats• 4 years ago

I've been using egui->rend3->winit->wgpu->vulkan recently, with the goal of a program that will run on Windows, Mac, and Linux. It all mostly works. There's some dirty laundry revolving around full screen modes and window depth order, but it's not too bad.

egui, an immediate mode GUI on top of winit, is interesting. It works OK, but only does part of the job. It displays the GUI widgets, but doing something with them is your problem. Usually, you need each widget to have some persistent state. Managing that state is the user's problem. So is generating, queuing, and distributing events to and from the GUI elements. There's also something strange which causes some scrolled windows to vibrate between two states.

egui's default widgets are not very good looking. Light grey text on a dark grey background, super-thin scroll bars, that kind of thing. The aesthetics need work.

Overall, though, not bad. This stuff just needs to be used more. It has not had enough attention and polishing.

It's impressive that most of this works cross-platform, even cross-compiled. You don't even need a Windows machine to develop for a Windows target.

OJFord2• 4 years ago

This seems to implicitly mean low-level GUIs, or GUI frameworks? The only mention of Tauri is 'tao the fork of winit used by'.

The article opens:

A few times a week, someone asks on the #gui-and-ui channel on the Rust Discord, “what is the best UI toolkit for my application?” Unfortunately there is still no clear answer to this question.

I would say if by 'UI toolkit for my application' you just want a way to make a GUI app, not a game or some kind of highly native or specific interaction needs thing, just use Tauri. No idea why it's not a 'top contender', it has an order of magnitude more GH stars than Druid, for whatever that counts; I can only assume they mean lower-level toolkits. (No affiliation.)

I just think someone new or unexposed to rust's going to see this and think it's way harder than it needs to be or is just to do something basic.

raphlinus10• 4 years ago

That's fair. The main reason Tauri isn't higher on my radar is that if you're going to make an app based on the web technology stack, why not just use Electron? The tooling is mature, there's lots of knowledge, and you can use Rust modules (through wasm) easily enough. I suppose it depends on the actual use case, I'm sure there is a niche for Tauri, but it doesn't intersect use cases I'm interested in particularly.

OJFord2• 4 years ago

If someone into or getting into rust asked me 'how can I make a cross-platform app like with Electron', I would definitely say 'Tauri'; not 'actually you can use Electron with rust modules (through wasm) easily enough'.

Unless perhaps they're also big into the JS ecosystem anyway. That 'mature tooling' you mention is npm/yarn/etc. stuff; Tauri's is cargo.

curun1r• 4 years ago

AIUI, the major difference between the two is that Tauri uses the system’s WebView while Electron bundles a specific version of Chromium. That means Tauri will have a number of performance advantages at the cost of not being able to target a specific browser.

Still, the “why not use Electron?” answer is that Electron is much more hostile to the user…much larger download size, slower startup and increased memory usage. With Rust valuing zero-cost abstractions, Tauri comes a lot closer to that ethos than Electron.

veidr• 4 years ago

I find this omission weird, too.

It seems to me that, maybe because of the situation described in this article, Tauri already has become, or at least is quickly becoming, the clear answer to this question.

This article seems to be implicitly excluding Tauri from consideration, because the UI portion in Tauri is not "native" or even Rust-based. With Tauri, you write the whole app in Rust except the UI.

(Technically, you could use some Rust UI frontend tech, but I think 99% of devs using Tauri are using some web UI technology, such as one of the several excellent built-in vite-powered starting points (Svelte, Vue, Solid, React, Angular...) or something similar.)

This seems to me to be a pretty good solution for the next several years, at least, because implementing a good cross-platform native UI toolkit is very very hard — so hard that, arguably, nobody has ever done it.

magicalhippo2• 4 years ago

What subset of expected text control functionality is provided?

Missing from this otherwise great list, is basic system-standard text navigation and editing. I get so annoyed when basic stuff like ctrl+end or ctrl+v doesn't work like they should.

raphlinus10• 4 years ago

Thanks! I might add that explicitly, but meant it to be included under "keyboard shortcuts according to platform human interface guidelines".

magicalhippo2• 4 years ago

I think explicit might be better, because it goes beyond that. For example, pressing ctrl+v while having text highlighted should replace the text on Windows, but doesn't always with non-native editors.

edit: btw, great article. I've worked on a cross-platform application (Windows, Linux, OSX) which went from using wxWidgets to Qt. Quite painful either way, and while Qt was a fair bit better on OSX at the time we still had to use tons of ifdefs and per-platform configuration.

And while I've been a win32 GUI programmer for decades, I totally get why people reach for Electron or embedded web servers. It's a really hard problem space with lots of trade-offs to be made.

hsbauauvhabzb• 4 years ago

What’s actually wrong with electron, or makes electron slow? I feel like every ‘UI frameworks suck’ posts glosses over this, but no real indication of why.

boberoni• 4 years ago

Most complaints about Electron that I see are about memory usage. If you’re running on an old laptop with little RAM, running 3+ Electron apps can start to slow your entire system down.

There’s also a breed of users who are extremely sensitive to the “native feel” of a desktop app. For them, it’s a jarring experience to downgrade to something that is less snappy, but they expect a certain standard of snappiness.

josephcsible• 4 years ago

Because every Electron app is basically its own Web browser with all of the app's code being JavaScript, rather than the app just being native code. Try running Chrome, Edge, and Safari all at the same time and look what that does to your computer's resource usage. Electron apps basically do the exact same thing.

lewisjoe• 4 years ago

I like how the ecosystem around Kotlin has approached the problem.

1. The language itself has a way of introducing compiler plugins that lets you express your own tree structures in a succint syntax (comparable to macros in Rust I guess)

2. Then they figured out most UIs are trees and came up with a Flutter-like UI tree declaration API with react-like re-renders. Thus Android Compose was born! This went mainstream because most android devs fell in love with this new way of writing GUI

3. Like flutter, they are slowly exposing Skia (underlying rendering engine) APIs as kotlin wrappers - I guess the project's name is Skiko

4. Now with all these pieces they are building a full-fledged UI toolkit that renders over every platform (including web) - Jetpack Compose

pjmlp17• 4 years ago

Meaning Android team, no ecosystem to speak of.

There are even ADB episodes speaking about all those steps.

liquidnitrogen1• 4 years ago

Regarding Electron, i don't understand why anyone would want to go this route. I work in finance and desktop native apps (Winforms, WPF) have far more mature libraries, better performance and time to market compared to web GUIs. With Electron, we first write web apps and then wrap inside electron and then reinvent the wheel - this is so stupid.

1wd• 4 years ago

WPF is now open source (MIT licensed [1]), and its XAML control templates provide _as data_ a full declarative description of how a native Windows control is supposed to look like (in multiple Windows themes like Aero for Win7, Aero2 for Win10, Luna + Royale for WinXP, and Classic for Win95 look and feel [2]).

This includes everything like the exact colors and gradient stops and animation timing and vector shapes and accessibility behavior etc. of buttons and scrollbars and everything. Example: [3]

I wonder what one could learn / achieve trying to "port WPF to rust" / implement a XAML control template renderer in Rust. If you can "simply" parse and interpret those XAML files do you instantly get a native-like GUI that supports the exact look and feel of these different Windows themes? (on any OS!)

Somehow I think it is not realized how amazing that is!

[1] https://github.com/dotnet/wpf/blob/main/LICENSE.TXT [2] https://github.com/dotnet/wpf/tree/main/src/Microsoft.DotNet... [3] https://github.com/dotnet/wpf/blob/main/src/Microsoft.DotNet...

ComputerGuru• 4 years ago

I’ve had similar thoughts and starting writing my own rust XAML framework with exchangeable backends (backend implementations incomplete) but didn’t find much interest from the community despite how awesome XAML is at separating the UI from the toolkit.

speedgoose• 4 years ago

You only support windows, electron is multiplatform. About time to market it depends on your team. I don’t think there is a big difference between C#/WPF and TypeScript/React. But the second option works on more platforms and you will find competent developers a lot more easily.

malkia2• 4 years ago

The elephant in the room for big CAD/CAM apps is dockable widgets, where (for me personally), the "standard" is how Visaul Studio does it.

Even Qt, with it's built-in widgets is not enough (e.g. no multiple widgets/windows in non-main window), but there are some extensions/libraries/hacks to go around.

Recently, few years ago, imgui got proper support for these too. And flutter has one or more design docs around it - e.g. multi-window support, which might be the stepping stone to these.

Desktop apps are always going to be important in this space. Our game editor (Radiant) relies on this functionality when you use two, three or even more monitors.

PoignardAzur• 4 years ago

Can you develop?

I understand the term "dockable widgets", but I'm not sure I'm visualizing the same UI as you.

johnofthesea• 4 years ago

Something like Photoshop/Gimp panels I guess.

malkia2• 4 years ago

Something like this - https://github.com/nucleic/enaml#dock-item-alerts - this is a Python UI that has the capability (extended through Qt)

nyanpasu648• 4 years ago

Surprisingly enough, Qt's built-in docking system has not one but two actively-maintained open-source third-party alternatives, KDDockWidgets and Qt-Advanced-Docking-System. (QtitanDocking is a commercial third-party docking system.)

OtomotO• 4 years ago

I somehow have a hunch that actors could be a good fit for the graph vs tree problem.

Maybe it is time for some experiments

randyrand• 4 years ago

Why not copy the design of Flutter?

Why reinvent the wheel?

Advice for the next dozen Rust GUIs

Related Stories