7 ms·

Announcing Masonry 0.1, and my vision for Rust UI

154 points by bpierre 4y ago

OJFord 4y ago
This sounds great, and yes is exactly the sort of GUI framework I'd want to use; I've also had the displeasure of using Qt/QML (though not at such scale/for as long)). ... But I can pretty much do this today with Tauri? The missing bit here IMO is why we need to rebuild webdev-like tooling in a Rust-only framework rather than just use it.
- brundolf 4y ago
  Everything has tradeoffs; web-based UIs have a performance cost (not a prohibitive one for most things, but a cost is a cost). So it's not a bad thing to have native options But you're definitely right that devex is one of the web's main strengths. It's really hard to replicate that without a massive community like the one the web has; that's going to be a sticking point for any native framework (which if we're honest, are going to remain a niche going forward) Even with cross-platform frameworks, there's a big fragmentation problem right now. And even if there weren't, native development as a whole is simply a smaller community these days
  - PaulDavisThe1st 4y ago
    > It's really hard to replicate that without a massive community It's not the size of the community. It's the use of interpreted languages and strong introspection and a (relatively) consistent platform called "the browser". That's what make devex so different to native. Sure, the endless stream of new frameworks etc. also contributes to the difference, but it's not as fundamental IMO.
- mattgreenrocks 4y ago
  The web will not last forever. Better to build a foundation that is capable of bridging to the web if necessary than staking yet another UI layout engine atop a document markup syntax.
  - adastra22 4y ago
    That is a very interesting viewpoint. I’m not a webaholic like a lot of the JS devs out there. It’s a shit platform. But I have no illusions about its lasting power. Why do you think the web stack is going to go away?
    - mattgreenrocks 4y ago
      It's not that it is going away anytime soon, it is more that it is a poor choice for 'conceptual bedrock.'
  - sethaurus 4y ago
    Sure, the web will one day die — and it will certainly change a lot before that day! But even so, would you stake a current native UI toolkit to last longer, and provide more value, before that day? There are good reasons to write truly native UI. Performance is very persuasive. Longevity, perhaps less so.
    - adastra22 4y ago
      I'll wager the Win32 gui api will outlast your choice of web stack.
      - rat9988 4y ago
        Do the other native frameworks in the other OS have the same longetivity story?
        adastra22 4y ago
        X11 does.
    - mattgreenrocks 4y ago
      The conceptual foundations of something like this are extremely important. If you stake the basic ideas of the framework on the DOM, then DOM details will become implementation details which will become details that clients will depend on. And you'll have just re-written React but with even more layers. It needs to be thought about in terms of first principles, ala SICP. There are basic primitives to be defined that are the "ground," and then it is built up from there.
- PoignardAzur 4y ago
  Building things in Rust is its own reward! More seriously though, that's a fair question. Anything that isn't the web has a lot of catching up to do before it can compare to the web. (Though browsers are increasingly relying on rust frameworks for low-level work, so there's some potential for code reuse.) My gut feeling answer would be "because things built for the web have a tendency to fail for no reason, and things built in Rust have a tendency to work on the first try". I'd have a hard time backing up that gut feeling with hard numbers, but I think it's a shared one. Web techs tend to have all sort of legacy cruft and small papercuts and stuff. Mature Rust crates are easy to install, work immediately and have an intuitive API. My hope is to get to a point where developing Rust GUI is just easy, no papercuts. (But again, lots of catching up to do first.)
  - interactivecode 4y ago
    how do things on the web fail for no reason? My experience is the exact opposite. The web's html is very lenient and if you html makes somewhat sense it will render your document. If you're comparing legacy web code to new and modern rust crates of course it's not a fair comparison. just wait until the until the second wave of rust gui libs, it will be a similar pain of legacy code when the web industry went from Angular v1 to React. Legacy projects, outdated packages and brittle build processes, now with rust there will also be the added "benefit" of a more complicated programming language.
    - scns 4y ago
      Did you never see that infamous "undefined is not a function" error message?
      - interactivecode 4y ago
        Of course I've seen it. have you ever seen the `Syntax Error: expected SEMICOLON` error message while trying to do something completely unrelated?
  - aliqot 4y ago
    > Building things in Rust is its own reward! Stop saying stuff like this. It's not true and it pushes people away bc you look fanatic
detaro 4y ago
Side note, but the "browser dev tools but for Qt" exists, it is called Gammaray.
- LorenDB 4y ago
  Indeed, as I read the part about wanting a devtools thing, I thought "How has this person never used Gammaray?" Gammaray is super useful.
- kelnos 4y ago
  Same for GTK; settting `GTK_DEBUG=interactive` in the environment before running the app (I think you have to set a gsettings key somewhere first as well) brings up a separate window with your application that lets you inspect the UI. I wonder how common these things are, though, in other toolkits.
- simplotek 4y ago
  > Side note, but the "browser dev tools but for Qt" exists, it is called Gammaray. Also, accessibility tools like Microsoft's inspect[1] already allow people to see an app's widget tree. With Qt it's also trivial to put together a tree view that renders your app's widget tree. Qt also provides infrastructure to unit test widgets.[2] Qt also uses UI form files to allow WYSIWYG access to their UI components. From reading the article, I was left with the impression that the author's struggles with a Qt codebase was that he had little to no experience with desktop development in general and Qt in particular, and experienced issues trying to get his bearings. [1] https://learn.microsoft.com/en-us/windows/win32/winauto/inspect-objects https://learn.microsoft.com/en-us/windows/win32/winauto/insp... [2] https://doc.qt.io/qt-6/qttestlib-tutorial3-example.html https://doc.qt.io/qt-6/qttestlib-tutorial3-example.html
  - PoignardAzur 4y ago
    > Qt also provides infrastructure to unit test widgets. ... Holy crap, how did I never hear of this? I did search for Qt testing infrastructure before writing this article too.
- pjmlp 4y ago
Already__Taken 4y ago
given ff safari(?) chrome and old edge all have Dev tools and node can attach to Chrome, is that specified well enough to use one of those with the framework?
- vlovich123 4y ago
  Yeah I was thinking the same thing. Especially since many of these frameworks try to target the web via WASM, if you made that piece smooth you might not need a 1p solution for a simple and just leverage browsers for that piece (+ profiling and even maybe hot reloading).
leeoniya 4y ago
i was gonna bring up https://github.com/redox-os/orbtk https://github.com/redox-os/orbtk only to discover it's no longer under active development.
- throwme_123 4y ago
  Suggests two alternatives: 1. https://iced.rs https://iced.rs (MIT) 2. https://slint-ui.com https://slint-ui.com (GPL) For slint, there is an online editor: https://slint-ui.com/releases/0.3.4/editor/?load_demo=examples/todo/ui/todo.slint https://slint-ui.com/releases/0.3.4/editor/?load_demo=exampl...
KRAKRISMOTT 4y ago
I want a proper, visual studio style, drag and drop GUI builder.
- splix 4y ago
  Or maybe some Figma plugin/client that generates the code from a UI designed there.
  - pas 4y ago
    uh there are a bunch of those, locofy, teleportHQ, etc. They are okay-ish, if you know the rules of the target code system/platform. (Ie. if you know React, and so you already create components in the UI builder.) So basically my big problem is that these UI builders don't force/encourage the conventions that result in nice code. The potential is there, of course, maybe even throwing a chatGPT-like AI in the loop can help with recognizing what the user wants and emitting and maintaining the resulting code base.
- capableweb 4y ago
  Not at all overkill: Unreal Engine. On a more serious note, would be interesting to see an app builder inspired by the UI and Blueprint editors of UE but tailored for apps rather than games.
  - cyber_kinetist 4y ago
    I've heard people using the Godot Engine to make complex UI applications. So I've tried myself writing a simple app (it required multiple windows support which was added in Godot 4 beta), and the experience was really solid. It has its own slot/signal system like Qt but because it's much more well integrated into the language/editor. The node system in Godot is similar to the DOM, and editing layout was much easier than expected. (Compared to Unity's UI system which was built on top of a component system and is more finicky to use because of this. And no and I don't want to talk about UIElements, it's unfinished and unusable in its current state). And most important you don't need to wait for C++/MOC compiler to build, because of the scripting langauge (GDScript) changes can be tested instantaneously. Unreal Engine might be a bit overkill since it has too many dependencies built in (you don't need a state-of-the-art 3D renderer and physics engine for UI). Godot is much more lightweight than that (about 40~50 MB from my tests, at least better than Electron), but some might still think that's too much though.
CGamesPlay 4y ago
I feel like this is one of the under-appreciated reasons why the web is taking over desktop apps. It's so much easier to build a web app that runs with native extensions than it is to build a native app with almost any toolkit. Even if you only target a single platform (say, macOS, and excluding Windows/iOS/Android development), is there a single platform's GUI toolkit that can stack up to what you get in 10 minutes of setting up an electron app?
- deleted 4y ago
  [deleted]
- dcow 4y ago
  xcode and swiftui is getting close. You can hover over visual elements and see the code, and vice versa. You can render the UI and modify layout and styles without compiling and launching a new instance of the app.
- p-e-w 4y ago
  That's certainly true, but consider how many tens (hundreds?) of billions of dollars were spent until web development reached the state it is in today. And how many dead ends had to be explored before we had things like browser dev tools with integrated support for React. Think of all the frameworks that no one uses anymore, the abandoned bundlers, templates, entire languages like CoffeeScript, the list goes on and on. The amount of brainpower invested in the web platform dwarfs what any native toolkit has been given. No wonder it's so good; it would have been a crazy waste of resources otherwise. I'm sure native toolkits would be just as user-friendly, or even better, if they had such lavish resources dedicated to improving them.
  - deafpolygon 4y ago
    You also want to mention an additional reason: native toolkits have to be tested multiple times; once for windows, once for macos, once again for Linux and whatever else you want to support. Even if you get QT deployed for a Mac version, there's still no guarantee they look the same on Windows. Each platform has its own quirk. With fewer developers working with these toolkits, we see less adoption, more issues, etc.
VanTodi 4y ago
So it's the vision of a single person and another UI library is being born. I'm being sceptical at this, cause it looks like the same problem with JS and all the frameworks: I can't find anything that has all the features I want, so I start a new one, which potentially never becomes stable. I'm not a Rust developer (yet) and have a background in PHP and JS, so I'm glad if some vets can elaborate on the GUI problem with other programming languages.
- darthrupert 4y ago
  This happens on every moderately successful language platform. The difference is that mentioning Rust makes this front-page material somehow.
  - mlindner 4y ago
    Rust doesn't have a good GUI story yet. It makes it to the front-page because people are looking for a good one. https://www.areweguiyet.com/ https://www.areweguiyet.com/
- CGamesPlay 4y ago
  I've recently been having some success with a fail-fast version of this. Quick example: I wanted a utility component library for React, and none of the ones I looked at seemed promising. So I built my own, focusing exclusively on the consumer API and seeing what was possible. I pretty quickly ruled that my dream API wasn't possible, but I figured out why and what trade offs were going into it. Then I want back to the available libraries with a much better understanding of the underlying problems, and identified one that most closely resembled what I thought was precisely what I wanted. This approach has worked for several of the dependencies I've adopted lately and I have found that I now spend a lot less time fighting with my dependencies because I'm trying to pigeonhole them into a place where they can't fit.
- ebiester 4y ago
  I think what's interesting here is that the author is trying to build a foundational component upon which other developers can leverage. The author is trying to build something that other GUIs will want to integrate (e.g. Druid and Xilem). And I think it's fair for someone to put together a proof of concept as a research proposal. They may not make it far in and of itself, but it may become an inspiration for someone else.

154 points by bpierre 4y ago

This sounds great, and yes is exactly the sort of GUI framework I'd want to use; I've also had the displeasure of using Qt/QML (though not at such scale/for as long)). ... But I can pretty much do this today with Tauri? The missing bit here IMO is why we need to rebuild webdev-like tooling in a Rust-only framework rather than just use it.

brundolf 4y ago
Everything has tradeoffs; web-based UIs have a performance cost (not a prohibitive one for most things, but a cost is a cost). So it's not a bad thing to have native options But you're definitely right that devex is one of the web's main strengths. It's really hard to replicate that without a massive community like the one the web has; that's going to be a sticking point for any native framework (which if we're honest, are going to remain a niche going forward) Even with cross-platform frameworks, there's a big fragmentation problem right now. And even if there weren't, native development as a whole is simply a smaller community these days
- PaulDavisThe1st 4y ago
  > It's really hard to replicate that without a massive community It's not the size of the community. It's the use of interpreted languages and strong introspection and a (relatively) consistent platform called "the browser". That's what make devex so different to native. Sure, the endless stream of new frameworks etc. also contributes to the difference, but it's not as fundamental IMO.
mattgreenrocks 4y ago
The web will not last forever. Better to build a foundation that is capable of bridging to the web if necessary than staking yet another UI layout engine atop a document markup syntax.
- adastra22 4y ago
  That is a very interesting viewpoint. I’m not a webaholic like a lot of the JS devs out there. It’s a shit platform. But I have no illusions about its lasting power. Why do you think the web stack is going to go away?
  - mattgreenrocks 4y ago
    It's not that it is going away anytime soon, it is more that it is a poor choice for 'conceptual bedrock.'
- sethaurus 4y ago
  Sure, the web will one day die — and it will certainly change a lot before that day! But even so, would you stake a current native UI toolkit to last longer, and provide more value, before that day? There are good reasons to write truly native UI. Performance is very persuasive. Longevity, perhaps less so.
  - adastra22 4y ago
    I'll wager the Win32 gui api will outlast your choice of web stack.
    - rat9988 4y ago
      Do the other native frameworks in the other OS have the same longetivity story?
      - adastra22 4y ago
        X11 does.
  - mattgreenrocks 4y ago
    The conceptual foundations of something like this are extremely important. If you stake the basic ideas of the framework on the DOM, then DOM details will become implementation details which will become details that clients will depend on. And you'll have just re-written React but with even more layers. It needs to be thought about in terms of first principles, ala SICP. There are basic primitives to be defined that are the "ground," and then it is built up from there.
PoignardAzur 4y ago
Building things in Rust is its own reward! More seriously though, that's a fair question. Anything that isn't the web has a lot of catching up to do before it can compare to the web. (Though browsers are increasingly relying on rust frameworks for low-level work, so there's some potential for code reuse.) My gut feeling answer would be "because things built for the web have a tendency to fail for no reason, and things built in Rust have a tendency to work on the first try". I'd have a hard time backing up that gut feeling with hard numbers, but I think it's a shared one. Web techs tend to have all sort of legacy cruft and small papercuts and stuff. Mature Rust crates are easy to install, work immediately and have an intuitive API. My hope is to get to a point where developing Rust GUI is just easy, no papercuts. (But again, lots of catching up to do first.)
- interactivecode 4y ago
  how do things on the web fail for no reason? My experience is the exact opposite. The web's html is very lenient and if you html makes somewhat sense it will render your document. If you're comparing legacy web code to new and modern rust crates of course it's not a fair comparison. just wait until the until the second wave of rust gui libs, it will be a similar pain of legacy code when the web industry went from Angular v1 to React. Legacy projects, outdated packages and brittle build processes, now with rust there will also be the added "benefit" of a more complicated programming language.
  - scns 4y ago
    Did you never see that infamous "undefined is not a function" error message?
    - interactivecode 4y ago
      Of course I've seen it. have you ever seen the `Syntax Error: expected SEMICOLON` error message while trying to do something completely unrelated?
- aliqot 4y ago
  > Building things in Rust is its own reward! Stop saying stuff like this. It's not true and it pushes people away bc you look fanatic

detaro 4y ago

Side note, but the "browser dev tools but for Qt" exists, it is called Gammaray.

LorenDB 4y ago
Indeed, as I read the part about wanting a devtools thing, I thought "How has this person never used Gammaray?" Gammaray is super useful.
kelnos 4y ago
Same for GTK; settting `GTK_DEBUG=interactive` in the environment before running the app (I think you have to set a gsettings key somewhere first as well) brings up a separate window with your application that lets you inspect the UI. I wonder how common these things are, though, in other toolkits.
simplotek 4y ago
> Side note, but the "browser dev tools but for Qt" exists, it is called Gammaray. Also, accessibility tools like Microsoft's inspect[1] already allow people to see an app's widget tree. With Qt it's also trivial to put together a tree view that renders your app's widget tree. Qt also provides infrastructure to unit test widgets.[2] Qt also uses UI form files to allow WYSIWYG access to their UI components. From reading the article, I was left with the impression that the author's struggles with a Qt codebase was that he had little to no experience with desktop development in general and Qt in particular, and experienced issues trying to get his bearings. [1] https://learn.microsoft.com/en-us/windows/win32/winauto/inspect-objects https://learn.microsoft.com/en-us/windows/win32/winauto/insp... [2] https://doc.qt.io/qt-6/qttestlib-tutorial3-example.html https://doc.qt.io/qt-6/qttestlib-tutorial3-example.html
- PoignardAzur 4y ago
  > Qt also provides infrastructure to unit test widgets. ... Holy crap, how did I never hear of this? I did search for Qt testing infrastructure before writing this article too.
pjmlp 4y ago

Already__Taken 4y ago

given ff safari(?) chrome and old edge all have Dev tools and node can attach to Chrome, is that specified well enough to use one of those with the framework?

vlovich123 4y ago
Yeah I was thinking the same thing. Especially since many of these frameworks try to target the web via WASM, if you made that piece smooth you might not need a 1p solution for a simple and just leverage browsers for that piece (+ profiling and even maybe hot reloading).

leeoniya 4y ago

i was gonna bring up https://github.com/redox-os/orbtk https://github.com/redox-os/orbtk only to discover it's no longer under active development.

throwme_123 4y ago
Suggests two alternatives: 1. https://iced.rs https://iced.rs (MIT) 2. https://slint-ui.com https://slint-ui.com (GPL) For slint, there is an online editor: https://slint-ui.com/releases/0.3.4/editor/?load_demo=examples/todo/ui/todo.slint https://slint-ui.com/releases/0.3.4/editor/?load_demo=exampl...

KRAKRISMOTT 4y ago

I want a proper, visual studio style, drag and drop GUI builder.

splix 4y ago
Or maybe some Figma plugin/client that generates the code from a UI designed there.
- pas 4y ago
  uh there are a bunch of those, locofy, teleportHQ, etc. They are okay-ish, if you know the rules of the target code system/platform. (Ie. if you know React, and so you already create components in the UI builder.) So basically my big problem is that these UI builders don't force/encourage the conventions that result in nice code. The potential is there, of course, maybe even throwing a chatGPT-like AI in the loop can help with recognizing what the user wants and emitting and maintaining the resulting code base.
capableweb 4y ago
Not at all overkill: Unreal Engine. On a more serious note, would be interesting to see an app builder inspired by the UI and Blueprint editors of UE but tailored for apps rather than games.
- cyber_kinetist 4y ago
  I've heard people using the Godot Engine to make complex UI applications. So I've tried myself writing a simple app (it required multiple windows support which was added in Godot 4 beta), and the experience was really solid. It has its own slot/signal system like Qt but because it's much more well integrated into the language/editor. The node system in Godot is similar to the DOM, and editing layout was much easier than expected. (Compared to Unity's UI system which was built on top of a component system and is more finicky to use because of this. And no and I don't want to talk about UIElements, it's unfinished and unusable in its current state). And most important you don't need to wait for C++/MOC compiler to build, because of the scripting langauge (GDScript) changes can be tested instantaneously. Unreal Engine might be a bit overkill since it has too many dependencies built in (you don't need a state-of-the-art 3D renderer and physics engine for UI). Godot is much more lightweight than that (about 40~50 MB from my tests, at least better than Electron), but some might still think that's too much though.

CGamesPlay 4y ago

I feel like this is one of the under-appreciated reasons why the web is taking over desktop apps. It's so much easier to build a web app that runs with native extensions than it is to build a native app with almost any toolkit. Even if you only target a single platform (say, macOS, and excluding Windows/iOS/Android development), is there a single platform's GUI toolkit that can stack up to what you get in 10 minutes of setting up an electron app?

deleted 4y ago
[deleted]
dcow 4y ago
xcode and swiftui is getting close. You can hover over visual elements and see the code, and vice versa. You can render the UI and modify layout and styles without compiling and launching a new instance of the app.
p-e-w 4y ago
That's certainly true, but consider how many tens (hundreds?) of billions of dollars were spent until web development reached the state it is in today. And how many dead ends had to be explored before we had things like browser dev tools with integrated support for React. Think of all the frameworks that no one uses anymore, the abandoned bundlers, templates, entire languages like CoffeeScript, the list goes on and on. The amount of brainpower invested in the web platform dwarfs what any native toolkit has been given. No wonder it's so good; it would have been a crazy waste of resources otherwise. I'm sure native toolkits would be just as user-friendly, or even better, if they had such lavish resources dedicated to improving them.
- deafpolygon 4y ago
  You also want to mention an additional reason: native toolkits have to be tested multiple times; once for windows, once for macos, once again for Linux and whatever else you want to support. Even if you get QT deployed for a Mac version, there's still no guarantee they look the same on Windows. Each platform has its own quirk. With fewer developers working with these toolkits, we see less adoption, more issues, etc.

VanTodi 4y ago

So it's the vision of a single person and another UI library is being born. I'm being sceptical at this, cause it looks like the same problem with JS and all the frameworks: I can't find anything that has all the features I want, so I start a new one, which potentially never becomes stable. I'm not a Rust developer (yet) and have a background in PHP and JS, so I'm glad if some vets can elaborate on the GUI problem with other programming languages.

darthrupert 4y ago
This happens on every moderately successful language platform. The difference is that mentioning Rust makes this front-page material somehow.
- mlindner 4y ago
  Rust doesn't have a good GUI story yet. It makes it to the front-page because people are looking for a good one. https://www.areweguiyet.com/ https://www.areweguiyet.com/
CGamesPlay 4y ago
I've recently been having some success with a fail-fast version of this. Quick example: I wanted a utility component library for React, and none of the ones I looked at seemed promising. So I built my own, focusing exclusively on the consumer API and seeing what was possible. I pretty quickly ruled that my dream API wasn't possible, but I figured out why and what trade offs were going into it. Then I want back to the available libraries with a much better understanding of the underlying problems, and identified one that most closely resembled what I thought was precisely what I wanted. This approach has worked for several of the dependencies I've adopted lately and I have found that I now spend a lot less time fighting with my dependencies because I'm trying to pigeonhole them into a place where they can't fit.
ebiester 4y ago
I think what's interesting here is that the author is trying to build a foundational component upon which other developers can leverage. The author is trying to build something that other GUIs will want to integrate (e.g. Druid and Xilem). And I think it's fair for someone to put together a proof of concept as a research proposal. They may not make it far in and of itself, but it may become an inspiration for someone else.