So you end up with stuff like the image crate (a straight up disaster of a crate—lots of fancy Rust bells and whistles, doesn’t support a bunch of stuff you want to do with images, reading the GitHub bug reports make me feel no hope that the issues will be addressed, ever) and R (a straight up disaster of a language, just a nightmare to write, but full of useful statistics packages, always has the package you need, but the language was made by Satan).
I’ll say the same thing about R+statistics as I will for Python+machine learning, for C++&game development / OpenCV, or Fortran and scientific computing. Having domain experts actually use your language to solve problems is such a massive advantage that you can almost ignore the benefits and drawbacks of the language itself. Almost.
And guess what? Browser does not have a fuck ton of well supported widgets. All it does it some button with outdated UI, few inputs nobody really uses and dropdown select suitable only for the most basic uses.
Anything other built on divs with CSS and JS.
And it works.
So my opinion is that it's definitely solid foundations what matters. Rest will come with time from third party libraries.
Adobe Flash anyone? Silverlight? Before WebAssembly/WebGL/WebGPU unity (yes that game engine) even required a browser plugin. Web browsers were often severely incompatible with each other and web standards were a suggestion at best. Now, it's bad form to slander dead people so I will just say that the nice kind folks at apple under the orders of their dear leader did their best to destroy as much of the pre-2012 web as possible by gatekeeping the iPhone browser and using their market power to strong arm web technology.
The problem is we’re in 2011 again, except chrome is the new flash and safari is the ie6.
I beg to differ. When the economics of doing UIs shifted away from APIs like Windows Forms, Carbon, JavaFX towards the current trend of doing everything in a browser, it brought with it some serious regression in how powerful and user friendly those GUIs are.
With Microsoft-level resources, you can take on a mammoth engineering task like implementing Office or Visual Studio in the browser. But if you are resource-constrained in the way that most developers are, you cut corners and drop functionality, and that's where we are today with browser GUIs ...not that any of that matters if all you're doing is CRUD, like most people are. But one shouldn't judge technology by its easiest, most boring, and degenerate use cases.
Consider, for example, the evolution of a CRUD app that was first written in, say, the late 80s for OS/400, using an interaction style where it's all full screen forms rendered as text that you fill out with your keyboard, then submit. Say, you rewrote that app in the 00s in Windows Forms but using the same interaction design, and then again in the 20s as a browser-based app. If you look at the evolution of what happened to UI technology through the lens of that app, you won't feel like anything is amiss in 2023, but you're also kind of missing the point of having a GUI in the first place, as opposed to, say, a text terminal.
Whenever I hear "all I need is a textedit and a button" from a web developer, I kind of assume that this is what informs their viewpoint.
If you instead look at the evolution of UI technology through the lens of an app like Photoshop, it will immediately be obvious to you what it is that GUIs uniquely have to offer that, for example, text terminals can't, and why rewriting such a UI in a browser is anything but trivial.
The GUI part was started by bootstrap and similar tools and shifted to React, Vue etc.
What are you talking about ? HTML and CSS is full of widget libraries, it's the best cross platform widget library out there.
Ease of deployment + reach is the driving force behind improving the platform, but at the present nothing in Rust can even compare to something like Material UI. And let's not even go into stuff like date range picker components and shit where companies probably spent millions in engineering effort to get them right (eg. AirBnB) .
That's... entirely wrong and not necessary to paint swathes of developers like.
Rust has numerous solutions for native GUIs. People ship apps with those stacks. Rust also has things like Tauri for when you don't want to deal with differences across platforms.
Just because there's not one blessed solution doesn't mean it's not possible to write UIs in Rust today. ;P
Egui is mostly bindings. And those can suffer from impedance mismatch (e.g. using OOP UI in Rust)
I'm excluding games because they tend to have trivial GUIs. I'm excluding tauri because the majority of the GUI code in a tauri app isn't Rust.
This is a serious question. I'd love be shown I'm missing something. I read this article hoping to find out that a serious rust GUI library was ready for real use and was quite disappointed.
For any app more complex than a demo "todolist", handling "business logic" is - by far - the most important. Hundreds of widgets that don't do anything, or do it wrong and buggy, are worthless.
"handling business logic" is difficult and, ironically, perpendicular to many frameworks (as in: frameworks make dev/testing/evolving/refactoring of business-logic harder, not easier). A perfect example was (is? IDK) Visual Basic: tons of widgets, a neat builder, but terrible in managing even simple state and handling business-logic. Or React, which is a perfect framework (and paradigm/architecture) for small, or flat apps, but terrible for complex or convoluted apps.
What I see in Rust, is a focus on the stuff beyond mere "providing lots of stuff that can be drawn to screen": how to manage state, react to changes, manage events etc. Which is, the way I see it, why there also are so many frameworks emerging: what architecture and paradigms work best, very much depends on your use-case.
1. There are unprincipled Rust GUIs, e.g. Egui. It works great.
2. Making a GUI framework is just bloody hard and a ton of work. I think only a small handful of languages have native GUI toolkits. Most just wrap C or HTML.
GTK is 25 years old and Qt is 27 years old. I don't think 5 years is long enough to develop a mature GUI toolkit (unless you have an enormous company backing you maybe).
Finally, modern GUIs are way more complex than they were back then - especially when it comes to graphics APIs and text handling.
So I still think it's too early to say Rust has failed when it comes to GUIs.
That said, it feels like it's starting to change. Lower-level components are getting stabilized, SlintUI and iced are picking up speed, etc.
Just to say.
But I agree with you: if your work balance is more oriented towards productivity then rust will not help much. For example, I design lots of stuff in python/jupyter/ecosystem first and then port that to rust for the speed and correctness.
You might only want 8 colours, but if you don't know exactly which 8, you'd better have a large palette available.
In the very rare cases it's not it is better to build a custom widget that matches your customers requirements exactly. Nothing is worse than a half-baked GUI element idea, badly implemented and sloppily maintained that matches like 85% of your customers requirements - and that's what most non-standard widgets are.
Quality and consistency trump quantity in my opinion.