https://github.com/DioxusLabs/dioxus
Fullstack GUI library for web, desktop, mobile, and more. - DioxusLabs/dioxus
Fullstack GUI library for web, desktop, mobile, and more. In Rust using a HTML + CSS renderer built on top of Servo.
I wish we went the other way around: build for native and compile to HTML/CSS/WASM.
For me the disadvantage of Electron is well, it doesn't have any advantage or performance improvement over the browser version for 99% of use cases, and when you shove that on a mobile phone it performs as horribly as the web version.
People already use higher level components that ends up shitting out HTML and CSS anyway, why not skip the middleman and just render the box optimally from the start? Web browsers have become good, but if you can skip parsing HTML and CSS entirely and also skip maintaining their state, that's even better.
I had the misfortune of developing a React Native app, and I'd say thinking in terms of rows and columns and boxes was nice. Most of RN's problems are because they still run JS and so you have to bundle node and have the native messaging bridge, and of course that it's tied to the turd that is React. But zero complains about the UI part when it doesn't involve the bridge: very smooth and snappy, much more than the browser. And the browser version was no different than standard React in performance.
I like that it's not yet another Chromium one at least.
There are several issues with native development without a browser layer.
First of all, native UI toolkits are very different and making a robust cross platform app is pretty much impossible. So, the traditional approach is to use one toolkit, which will be native to one platform, and then let your other users deal with it. For example, GTK apps on Windows and Mac look and feel like shit.
Another approach is to use a custom cross platform toolkit, which doesn't use anything native at all. If enough work and thought is put in such application, it can be a very pleasant experience. But often it's shit for all users.
The second issue is that it can be quite hard to manage fluid window sizes and to build a proper responsive UI with native toolkits. Some are better at it, some are worse. Native toolkits also tend to punish developers for deep nesting of components making UI development even more painful.
HTML + CSS solves all that. It's responsive by design, everyone is used to web apps already, nesting is not a problem at all, etc.
I'm not saying to use native toolkits like Qt or GTK, those indeed have problems. What React Native does is somewhere in-between: it's an abstraction that produces decent results between platforms including the web.
It uses slightly higher level abstractions that work a lot like the web for rendering, you still get your boxes and a subset of CSS properties. But on web it'll compile to flexbox or grids, on Android it'll compile to something like a LinearLayout or some other kind of layout the OS understands. On web a <Text> will compile to a <span>, on Android it'll compile to a native text element. On mobile where you need the performance the most, you otherwise end up rendering a web page that will then eventually end up doing the same thing back to display it natively, but with all the downsides of a web view.
This performs way better with basically no downside for the web version, has the majority of the flexibility one needs for responsive layouts but it's way more lightweight when you do target native. On native you can just render it all yourself for really cheap, like any native toolkit would. You're your own toolkit.
They will never look native, but at least all the rendering will be native. Most companies have their custom UI theme anyway, native widgets rarely gets used anyway.
We're talking Electron replacement after all, it's not like apps made with it look anything native. But if at least they performed like native apps by skipping the web views and all the baggage it brings with it, that'd be great.
I know how React Native works and it doesn't fix anything. For example, if the underlying toolkit punishes you for deep nesting - you're still fucked. Google recommends to have 10 or less levels of nesting, which is bonkers to any web developer. There is similar advice for iOS, Mac and Windows (not sure about GTK and Qt, haven't used them for over a decade). Each platform has its own solution, so you end up with custom code for each and at that point or doesn't matter if you're coding in C or JS.
For the end user, its main weakness is that complex pages can be pretty slow to render if not coded well. It's not that bad either. You wouldn't be like "oh this is a React site, yuck", they're all like that these days for the reasons you'd expect.
As for React Native, its main issue is the communication between the JavaScript browser-ish environment and the Java/Kotlin native environment that can be costly because every has to be serialized (meaning, converted to some type of data structure both sides can understand) and deserialized, so complex screen updates don't scale too well.
It's easy for developers to accidentally trigger much bigger and much more expensive rerenders than expected. If you see whole second long page hangs on some websites as new content loads in that's usually what happened.
For developers, it's complicated, you kind of need to experience it to understand the footguns.
React was born to solve one particular problem at Facebook: how can we make it so any developer can jump on any part of the UI code and add features without breaking everything. One of the most complicated aspects of a website is state management, in other words, making sure every part of the page are updated when something changes. For example, if you read a message in your inbox, the unread count needs to update a couple places on the page. That's hard because you need to make sure everything that can change that count is in agreement with everything that displays that count.
React solves that problem by hiding it away from you. Its model is simple: given a set of inputs, you have a function that outputs how to display that. Every time the value changes, React re-renders every component that used that value, compares it with the previous result, and then modifies the page with the updated data. That's why it's called React, it reacts to changes and actions.
The downside of that is if you're not very careful, you can place something in a non-ideal spot that can cascade into re-rendering the entire page every time that thing updates. At scale, it usually works out relatively okay, and it's not like rendering the whole page is that expensive. There's an upper cap on how bad it can be, it won't let you do re-render loops, but it can be slow.
I regularly see startups with 25MB of JavaScript caused by React abuse and favoring new features over tracking down excessive renders. Loads the same data 5 times because "this should only render once" and that turned out to be false, but it displays correctly. I commonly see entire forms being re-rendered every character you type because the data is stored in the form's state, so it has to re-render that entire tree.
But it's not that bad. It's entirely possible to make great and snappy sites with React. Arguably its problem isn't React itself but how much it is associated with horrible websites because of how tolerant to bad code it is. It's maybe a little bit too easy to learn, it gives bad developers an undeserved sense of confidence.
E: And we have better solutions to this such as signals which SolidJS, Vue and Svelte make heavy use of. Most of the advantages with less problems.
Anyway, that part wasn't relevant at all why I don't like React. The point is, skip the web, you don't really need the web. React Native skipped the whole HTML part, it's still JSX but for native app styled components for UI building. The web backend worked very well, your boxes became divs with some styles. It pretty much just worked. Do that but entirely in Rust since Rust can run natively on all platforms. Rust gets to skip all the compromises RN needed, and skip the embedded browser entirely. Make it desktop first then make the web version, it'll run just as well and might even generate better code than if a human wrote it. Making the web look native sucks but making native fit web is a lot easier than it looks. Letting go of HTML and CSS was a good call from React Native.
https://egui.rs/ promises to be able to do this, although I'm not positive it's ready for primetime
egui is cool but it's an immediate UI kind of thing, that's usually used in video games as you're constantly re-rendering the whole thing anyway.
A more fitting UI library would be Iced, which is also what System76 is building their COSMIC desktop environment on.
It does claim to support the web too, although not via HTML which brings some accessibility concerns. I'd expect performance to be very good otherwise.
IMO, I'd say Dioxus is more of a portable front end framework. If you're looking for an electron alternative i.e, something to run web applications like they are native apps, I'd recommend Tauri.
Also, this might be a bit out of date, but I believe Dioxus is using Tauri's stuff under the hood. Although I heard this before the dev went full time on Dioxus, it could've changed, I know they have done a lot of work on it.
I seriously doubt that a dual-language platform is ever going to supplant Electron. Electron has the major advantage that the entire app is written in one language. And according to Stack Overflow's 2023 developer survey, 66% of devs use JavaScript, 45% use Python, 43% use TypeScript, and 12% use Rust. More devs use Java, C#, C++, PHP, and C than Rust. So 2/3 of developers wouldn't have to learn a new language to use Electron, and only a small fraction of the remainder knows Rust.
I think this is a bit of a backwards way to look at it. If there is a good reason to learn a language then people will.
Not that this platform is necessarily that reason.
It's not just about learning a language. Given two equivalent languages, writing a project using one or the other is always going to be less work and less of a maintenance burden than writing it using both. A competent manager will take that into account when deciding what tools to use. On top of that, learning a new language has a cost. Of course Rust and JavaScript are not equivalent, but which one is 'better' is highly subjective and dependent on how you measure 'better'. So a manager needs to take that into account. But my fundamental point is that using two languages for a project adds overhead, and learning a language adds overhead, so unless cost (including time) is irrelevant, there must be a compelling reason to choose a dual-language solution* over a single-language solution, and to chose a solution that requires your devs to learn a new language over one that does not. Not to mention switching platforms has a massive cost if your project is already mature. Even if you're creating a new project, if your team already knows JavaScript and doesn't have any particular objection to Electron, there's no compelling reason.
If there is a good reason to learn a language then people will.
Sure. Except in my experience interviewing candidates and from what I've seen online, there are a lot of developers out there who aren't very good. I am not optimistic that the average developer will have an easy time learning a new language. If the "we" in "Is this the electron alternative we've been waiting for" is you and I, that's not a problem. But if OP meant to suggest there will be a large-scale shift away from Electron, then the average developer is quite relevant.
*As someone else pointed out, Dioxus is designed with the intent that you'll right the frontend in Rust, so it's not exactly dual-language like I thought.
It's not a dual-language platform, though. You write the backend and the frontend in Rust. The frontend code is compiled to WASM to serve it to the browser.
The folks who only know JavaScript and refuse to learn more deserve to be blamed for electron's (and similar) continued existence, and therefore for excessive resource usage.
Since people keep bringing up tauri, here's the comparison made in the README:
Tauri is a framework for building desktop (and soon, mobile) apps where your frontend is written in a web-based framework like React, Vue, Svelte, etc. Whenever you need to do native work, you can write Rust functions and call them from your frontend.
Natively Rust: Tauri's architecture limits your UI to either JavaScript or WebAssembly. With Dioxus, your Rust code is running natively on the user's machine, letting you do things like spawning threads, accessing the filesystem, without any IPC bridge. This drastically simplifies your app's architecture and makes it easier to build. You can build a Tauri app with Dioxus-Web as a frontend if you'd like.
Different scopes: Tauri needs to support JavaScript and its complex build tooling, limiting the scope of what you can do with it. Since Dioxus is exclusively focused on Rust, we're able to provide extra utilities like Server Functions, advanced bundling, and a native renderer.
Shared DNA: While Tauri and Dioxus are separate projects, they do share libraries like Tao and Wry: windowing and webview libraries maintained by the Tauri team.
We've been using Leptos at work, which is a similar framework (and probably shares half the stack with Dioxus).
And yeah, it's really good. My favorite thing about using Rust for the UI is algebraic data types.
So, in Rust when you call a function which can fail, there isn't an exception being thrown, but rather you get a Result-type as return value.
This Result can either contain an Ok with the actual return value inside. Or it can contain an Err with an error message inside.
So, in your UI code, you just hand this Result all the way to your display code and there you either display the value or you display the error.
No more uninitialized variables, no more separate booleans to indicate that the variable is uninitialized, no more unreadable multi-line ternaries.
It just becomes so much simpler to load something from the backend and display it, which is kind of important in frontend code.
Tauri is the electron alternative we already have. This does look like a good framework, just not the same as electron.
Probably not. Electron is popular not just for its cross-platform support, but also that its skills are highly transferable from existing web dev.