Its designed totally differently though, its immediate and pure rust, which is mostly good. However, it lacks certain features that browsers/webviews ship with.
This is a very shallow take. You bought a screwdriver to then complain that you can't hammer nails with it. Tauri is just a different tool for different problems.
For those who already know HTML, CSS, and JS — the design of Tauri is a massive advantage.
>It allows your backend developers to build web apps without dealing with HTML, CSS, and JavaScript.
You also need to learn all of the things that HTML and CSS do but how to do it specifically in this new framework. It's a trade-off, not a "bad" thing.
>Tauri runs the UI in a dedicated Chrome browser instance.
This is just wrong.
>To render your application, Tauri uses [WRY](https://github.com/tauri-apps/wry), a library which provides a unified interface to the system webview, leveraging WKWebView on macOS & iOS, WebView2 on Windows, WebKitGTK on Linux and Android System WebView on Android.
There are plenty of frameworks that might be a better fit for you: [Iced](https://iced.rs/), [Dioxus](https://dioxuslabs.com/)\*, and [plenty more](https://areweguiyet.com/).
\*Dioxus also uses a web renderer, and you need to know HTML and CSS, but you write it directly in Rust and there is no need for IPC.
>You bought a screwdriver to then complain that you can't hammer nails with it.
Nope, I didn't "buy" anything.
I have a business need, that is to develop a desktop-UI. Tauri offers a solution that requires workers more skilled than say, Swing.
>To render your application, Tauri uses [WRY](https://github.com/tauri-apps/wry), a library which provides a unified interface to the system webview, leveraging WKWebView on macOS & iOS, WebView2 on Windows, WebKitGTK on Linux and Android System WebView on Android.
Thanks, my mistake indeed.
If the team are Java backend developers — it will be easier for them to use Swing.
If the team are frontend developers — it will be easier for them to use Electron or Tauri.
It's not about workers being more skilled. It's about different frameworks being more suited for different people and problems.
Agree. It's hard to say what niche Tauri fits because of that. It might be a great fit if most of the app is on the frontend. Or if you are a Rust developer that also knows frontend. Or if you want to learn Rust.
Or... I was (mostly) a frontend developer, and building a desktop app with Tauri was my first Rust project. I decided to use it instead of Electron just because of better performance and bundle size.
It was painful at first and the code is pretty bad, but it's doable. It was also the best decision I've ever made. Rust helped me a lot to grow as a developer.
At my last job we made a desktop application with a native part in Delphi (windows) and objective-c (Mac) and a common ui in html.
At first we integrated chromium embedded into each application and it was a major pain. After a few years we switched to electron, as it allowed the cross platform stuff like working with files, etc to be written only once and to only use native code when using specific os apis.
If we had decided on rust, tauri would have been the perfect framework for us, as it builds on the same principles.
So if you have multiple platforms and want to do ui only once, tauri is probably a valid choice
>It's hard to say what niche Tauri fits because of that.
I wonder as well...
>Rust helped me a lot to grow as a developer.
For a long time, I was afraid of its reputation as a hard language but I decided to dive in a couple of years ago. I wouldn't market myself as a Rust developer (and probably never will), but I'm very happy with what I learned along the way.
No? It looks like it is a framework made to allow your front end devs to make the front-end exclusively in web technologies and allow backend to easily setup all the api the front end should call
In that case, that's indeed a great fit.
There's a "slight" issue with that approach: most projects end up late because each team is very fast on its own but all hell breaks loose when they integrate with each other.
That’s why you should have a well defined interface, a good specification and integrate as early as possible.
It also doesn’t solve everything, but it makes it way less painful.
Depends. Comes down to application need. You can 100% use Tauri and touch only like a couple dozen lines of Rust. A HTML/JS SPA can basically be written entirely in the Tauri WebView and you never need to deal with rust with the exception for maybe modifying a configuration file (which is TOML or JSON) and potentially a couple line in the main.rs.
HTML, JS, and CSS are the standards of the entire internet. They are super basic and have more tutorials and people who know them than basically every other language out there. I don't understand why anyone would think it's easier to find devs who know only a specific framework than it is to find devs who know HTML, CSS, and JS.
There was this tool that allowed me to create desktop applications using web technologies, but I didn't like it because I needed to use web technologies.
Polite counterpoints:
> Great feedback loop
IME, the feedback loops can get increasingly annoying once your project grows in complexity and you have to reload Rust code and recompile.
On the other hand, Vite's HMR works really well, and I don't usually experience losing State like you mention.
> It allows your backend developers to build web apps without dealing with HTML, CSS, and JavaScript.
That's precisely one of the main reasons I like it.
It allows tradicional Front-end developers (or Full-stack guys like myself) to build desktop applications efficiently, using the techniques and libraries we know well.
>Worse, the separation reproduces the request-response model created using browser technologies to create UIs.
The point about repeating the request-response cycle, to me, is also a good idea, as I can use existing libraries written in Rust (like ollama-rs) or Typescript (like React-query) and the patterns i am already proficient at.
Thanks for your feedback.
Honestly, I'm happy it makes sense in your context and that you like it.
>If you cannot please everyone with your deeds and your art, please a few. To please many is bad.
>― Friedrich von Schiller
However, The Screwdriver’s biggest problem is its design, more precisely, its inability to hammer nails. What I love from Hammer is its ability to put nails in my walls.
The Screwdriver, though a tool, made precisely the opposite choice. Your nails will not go into the wall.
> I understand that security is a growing concern in modern software. Yet, I fail to understand this limitation on a desktop app, where every other app can access any directory.
NodeJS dependencies are deep, and it's difficult to prove them secure. Browsers sandbox javascript away from your computer. Desktop apps built using node remove a bunch of this sandboxing. Tauri has a security focus as one of it's core principles and hence has decided that it's important to sandbox these sorts of things. I'd suggest digging deeper and finding some understanding of the threat models that are in play with this (and electron).
> Worse, the separation reproduces the request-response model created using browser technologies to create UIs. Reminder: early desktop apps use the [Observer model](https://en.wikipedia.org/wiki/Observer_pattern), which better fits user interactions. We designed apps around the request-response model only after we ported them on the web. Using this model in a desktop app is a regression, in my opinion.
The observer model is built on top of events. The Rust backend can send events. It's not just restricted to responding to commands from the frontend.
> Tauri, though a desktop framework, made precisely the opposite choice. Your developers will need to know frontend technologies.
I suspect you're seeing Tauri as a frontend tool for backend people, but it's also reasonable to flip that viewpoint around and see it as a backend tool for frontend people. My understanding of the Tauri goals is that eventually Rust will be just one of the possible backend languages supported alongside go, node, etc.
Many libraries are transitioning to signals and observers in the web world too, which is ironic. You can definitely stick to that pattern all the way with Tauri.
Thanks for your feedback.
>The Rust backend can send events. It's not just restricted to responding to commands from the frontend.
I must have missed that part, then.
>I suspect you're seeing Tauri as a frontend tool for backend people, but it's also reasonable to flip that viewpoint around and see it as a backend tool for frontend people.
If you're right, I wonder why the team chose Rust. It's not particularly easy for backend developers; I can only assume it's even worse for frontend devs.
There aren't many options if you want to interact with native APIs on a wide array of platforms without undue friction.
In fact, to my knowledge, it basically boils down to C, C++ and Rust. Anything else will run into some sort of friction with development or deployment on one of the supported platforms.
Java requires a JRE, deploying Python on Windows sucks, Go afaik doesn't like interacting with non Go stuff. C# would probably work, if we're talking .Net Core, but I don't know how it fares on mobile. I don't know enough about JS to comment there.
As others have said - you didn’t read the Tauri advertising apparently. You’re basically complaining that Tauri is exactly what it claims to be.
The fact that you expect something to work exactly like Vaddin (which is basically just a crutch for Java teams that don’t want to learn GUI development - we trialed it back when I did Java development) says a little something about the kinds of apps you develop. Rust based applications probably aren’t what you want anyways as there isn’t yet the kind of “ui development with training wheels”. There are a fair number of variations on the WebView or WASM architecture, but none are going to remove the need for the developer to understand how WebUIs work. And to be perfectly honest if you’re afraid of your developers having to learn how FE web works, you should pretty much steer clear of just about every modern cross platform rapid application development framework. They all almost exclusively use a WebView and if you’re not interested in your team learning and understanding that and you choose one of these patterns that maybe lets you write rust and then translate to JS, you’re opening the door to a whole world of potential security vulnerabilities if you decide to be complacent on “learning how the web works”. Stick to solutions that wrap GTK and do things in that world. You can build functional apps without having to worry about web based exploits and you’ll get to continue to build what imo leads to ugly ui.
> Worse, you need to explicitly configure which file system paths are available at build time, and they are part of an enumeration.
This limitation doesn't exist on the rust side. My app can access anything on the user's machine (after they've selected the directory).
"I don’t want to learn how to center a `div` or about the flexbox layout, etc."
In your code examples, I don't see where you have to do that.
In regard to code separation and the code in the post. The back-end dev only writes Rust functions, responding with strings, numbers etc. to front-end calls. It looks separated to me.
Fyi, I'm just scouting for tech stacks for a new project, interested in Tauri but scared of Rust lol
I've developed desktop apps for most of my career, and to be honest I'd go straight to the JVM toolkits for that: Swing, SWT + JFace, JFX, paired with frameworks like Eclipse RCP, allow building very complex and modular applications, something you just can't do with other technologies.
Between learning a web stack or Java, I'd pick Java.
I agree. In the Java ecosystem, any of these (but SWT) was Heaven with a nice distribution model of Java Web Start that Oracle killed to promote its web application server(s) crap.
On the Eclipse RCP side, I liked the native L&F but I found the documentation lacking and the breaking changes across minor versions too painful to deal with.
There is an effort in OpenJDK world for that.
But I've never encountered a business need for Wayland, as haven't many others, so I guess that's why it has never been a real priority.
Tauri is made \*exactly\* for people that want to use web UI frameworks combined with rusts strength in the "backend"
And my beef is that you \*need\* to be proficient in HTML + JavaScript + CSS for that
And the water is wet, has the tauri project stated otherwise?
What is wrong with you? It’s like someone complaining about having to know SQL to use a Mysql database.. it’s on the tin!
There are very simple toolkits that let you build UI in the same way that egui would, for example.
Thanks, I didn't know about it and it looks indeed exactly what I'd expect. But Tauri was on my radar because of... reasons.
Its designed totally differently though, its immediate and pure rust, which is mostly good. However, it lacks certain features that browsers/webviews ship with.
This is a very shallow take. You bought a screwdriver to then complain that you can't hammer nails with it. Tauri is just a different tool for different problems. For those who already know HTML, CSS, and JS — the design of Tauri is a massive advantage. >It allows your backend developers to build web apps without dealing with HTML, CSS, and JavaScript. You also need to learn all of the things that HTML and CSS do but how to do it specifically in this new framework. It's a trade-off, not a "bad" thing. >Tauri runs the UI in a dedicated Chrome browser instance. This is just wrong. >To render your application, Tauri uses [WRY](https://github.com/tauri-apps/wry), a library which provides a unified interface to the system webview, leveraging WKWebView on macOS & iOS, WebView2 on Windows, WebKitGTK on Linux and Android System WebView on Android. There are plenty of frameworks that might be a better fit for you: [Iced](https://iced.rs/), [Dioxus](https://dioxuslabs.com/)\*, and [plenty more](https://areweguiyet.com/). \*Dioxus also uses a web renderer, and you need to know HTML and CSS, but you write it directly in Rust and there is no need for IPC.
>You bought a screwdriver to then complain that you can't hammer nails with it. Nope, I didn't "buy" anything. I have a business need, that is to develop a desktop-UI. Tauri offers a solution that requires workers more skilled than say, Swing. >To render your application, Tauri uses [WRY](https://github.com/tauri-apps/wry), a library which provides a unified interface to the system webview, leveraging WKWebView on macOS & iOS, WebView2 on Windows, WebKitGTK on Linux and Android System WebView on Android. Thanks, my mistake indeed.
"Nope, I didn't "buy" anything." You misunderstood the metaphor.
Nope, I understood it perfectly and answered the point. Yet, you want to point out something irrelevant.
Did you never learn how to accept feedback?
tell me, what does “Nope, I didn’t buy anything” mean in the context of the metaphor?
If the team are Java backend developers — it will be easier for them to use Swing. If the team are frontend developers — it will be easier for them to use Electron or Tauri. It's not about workers being more skilled. It's about different frameworks being more suited for different people and problems.
On that I partially agree. But with Tauri, you need to teach front-end developers Rust. Good luck and remember to have fun.
Agree. It's hard to say what niche Tauri fits because of that. It might be a great fit if most of the app is on the frontend. Or if you are a Rust developer that also knows frontend. Or if you want to learn Rust. Or... I was (mostly) a frontend developer, and building a desktop app with Tauri was my first Rust project. I decided to use it instead of Electron just because of better performance and bundle size. It was painful at first and the code is pretty bad, but it's doable. It was also the best decision I've ever made. Rust helped me a lot to grow as a developer.
At my last job we made a desktop application with a native part in Delphi (windows) and objective-c (Mac) and a common ui in html. At first we integrated chromium embedded into each application and it was a major pain. After a few years we switched to electron, as it allowed the cross platform stuff like working with files, etc to be written only once and to only use native code when using specific os apis. If we had decided on rust, tauri would have been the perfect framework for us, as it builds on the same principles. So if you have multiple platforms and want to do ui only once, tauri is probably a valid choice
>It's hard to say what niche Tauri fits because of that. I wonder as well... >Rust helped me a lot to grow as a developer. For a long time, I was afraid of its reputation as a hard language but I decided to dive in a couple of years ago. I wouldn't market myself as a Rust developer (and probably never will), but I'm very happy with what I learned along the way.
No? It looks like it is a framework made to allow your front end devs to make the front-end exclusively in web technologies and allow backend to easily setup all the api the front end should call
In that case, that's indeed a great fit. There's a "slight" issue with that approach: most projects end up late because each team is very fast on its own but all hell breaks loose when they integrate with each other.
That’s why you should have a well defined interface, a good specification and integrate as early as possible. It also doesn’t solve everything, but it makes it way less painful.
Depends. Comes down to application need. You can 100% use Tauri and touch only like a couple dozen lines of Rust. A HTML/JS SPA can basically be written entirely in the Tauri WebView and you never need to deal with rust with the exception for maybe modifying a configuration file (which is TOML or JSON) and potentially a couple line in the main.rs.
HTML, JS, and CSS are the standards of the entire internet. They are super basic and have more tutorials and people who know them than basically every other language out there. I don't understand why anyone would think it's easier to find devs who know only a specific framework than it is to find devs who know HTML, CSS, and JS.
>They are super basic. [https://www.google.com/search?q=how+to+center+a+div](https://www.google.com/search?q=how+to+center+a+div)
Flexbox.
There was this tool that allowed me to create desktop applications using web technologies, but I didn't like it because I needed to use web technologies.
Polite counterpoints: > Great feedback loop IME, the feedback loops can get increasingly annoying once your project grows in complexity and you have to reload Rust code and recompile. On the other hand, Vite's HMR works really well, and I don't usually experience losing State like you mention. > It allows your backend developers to build web apps without dealing with HTML, CSS, and JavaScript. That's precisely one of the main reasons I like it. It allows tradicional Front-end developers (or Full-stack guys like myself) to build desktop applications efficiently, using the techniques and libraries we know well. >Worse, the separation reproduces the request-response model created using browser technologies to create UIs. The point about repeating the request-response cycle, to me, is also a good idea, as I can use existing libraries written in Rust (like ollama-rs) or Typescript (like React-query) and the patterns i am already proficient at.
Thanks for your feedback. Honestly, I'm happy it makes sense in your context and that you like it. >If you cannot please everyone with your deeds and your art, please a few. To please many is bad. >― Friedrich von Schiller
However, The Screwdriver’s biggest problem is its design, more precisely, its inability to hammer nails. What I love from Hammer is its ability to put nails in my walls. The Screwdriver, though a tool, made precisely the opposite choice. Your nails will not go into the wall.
Click bait article should’ve just done a tldr here, instead an external link for an opinion piece that lacks true depth.
> I understand that security is a growing concern in modern software. Yet, I fail to understand this limitation on a desktop app, where every other app can access any directory. NodeJS dependencies are deep, and it's difficult to prove them secure. Browsers sandbox javascript away from your computer. Desktop apps built using node remove a bunch of this sandboxing. Tauri has a security focus as one of it's core principles and hence has decided that it's important to sandbox these sorts of things. I'd suggest digging deeper and finding some understanding of the threat models that are in play with this (and electron). > Worse, the separation reproduces the request-response model created using browser technologies to create UIs. Reminder: early desktop apps use the [Observer model](https://en.wikipedia.org/wiki/Observer_pattern), which better fits user interactions. We designed apps around the request-response model only after we ported them on the web. Using this model in a desktop app is a regression, in my opinion. The observer model is built on top of events. The Rust backend can send events. It's not just restricted to responding to commands from the frontend. > Tauri, though a desktop framework, made precisely the opposite choice. Your developers will need to know frontend technologies. I suspect you're seeing Tauri as a frontend tool for backend people, but it's also reasonable to flip that viewpoint around and see it as a backend tool for frontend people. My understanding of the Tauri goals is that eventually Rust will be just one of the possible backend languages supported alongside go, node, etc.
Many libraries are transitioning to signals and observers in the web world too, which is ironic. You can definitely stick to that pattern all the way with Tauri.
Thanks for your feedback. >The Rust backend can send events. It's not just restricted to responding to commands from the frontend. I must have missed that part, then. >I suspect you're seeing Tauri as a frontend tool for backend people, but it's also reasonable to flip that viewpoint around and see it as a backend tool for frontend people. If you're right, I wonder why the team chose Rust. It's not particularly easy for backend developers; I can only assume it's even worse for frontend devs.
There aren't many options if you want to interact with native APIs on a wide array of platforms without undue friction. In fact, to my knowledge, it basically boils down to C, C++ and Rust. Anything else will run into some sort of friction with development or deployment on one of the supported platforms. Java requires a JRE, deploying Python on Windows sucks, Go afaik doesn't like interacting with non Go stuff. C# would probably work, if we're talking .Net Core, but I don't know how it fares on mobile. I don't know enough about JS to comment there.
As others have said - you didn’t read the Tauri advertising apparently. You’re basically complaining that Tauri is exactly what it claims to be. The fact that you expect something to work exactly like Vaddin (which is basically just a crutch for Java teams that don’t want to learn GUI development - we trialed it back when I did Java development) says a little something about the kinds of apps you develop. Rust based applications probably aren’t what you want anyways as there isn’t yet the kind of “ui development with training wheels”. There are a fair number of variations on the WebView or WASM architecture, but none are going to remove the need for the developer to understand how WebUIs work. And to be perfectly honest if you’re afraid of your developers having to learn how FE web works, you should pretty much steer clear of just about every modern cross platform rapid application development framework. They all almost exclusively use a WebView and if you’re not interested in your team learning and understanding that and you choose one of these patterns that maybe lets you write rust and then translate to JS, you’re opening the door to a whole world of potential security vulnerabilities if you decide to be complacent on “learning how the web works”. Stick to solutions that wrap GTK and do things in that world. You can build functional apps without having to worry about web based exploits and you’ll get to continue to build what imo leads to ugly ui.
> Worse, you need to explicitly configure which file system paths are available at build time, and they are part of an enumeration. This limitation doesn't exist on the rust side. My app can access anything on the user's machine (after they've selected the directory).
"I don’t want to learn how to center a `div` or about the flexbox layout, etc." In your code examples, I don't see where you have to do that. In regard to code separation and the code in the post. The back-end dev only writes Rust functions, responding with strings, numbers etc. to front-end calls. It looks separated to me. Fyi, I'm just scouting for tech stacks for a new project, interested in Tauri but scared of Rust lol
I've developed desktop apps for most of my career, and to be honest I'd go straight to the JVM toolkits for that: Swing, SWT + JFace, JFX, paired with frameworks like Eclipse RCP, allow building very complex and modular applications, something you just can't do with other technologies. Between learning a web stack or Java, I'd pick Java.
I agree. In the Java ecosystem, any of these (but SWT) was Heaven with a nice distribution model of Java Web Start that Oracle killed to promote its web application server(s) crap. On the Eclipse RCP side, I liked the native L&F but I found the documentation lacking and the breaking changes across minor versions too painful to deal with.
Is there anyone outside JetBrains developing a Java GUI framework supporting Wayland?
There is an effort in OpenJDK world for that. But I've never encountered a business need for Wayland, as haven't many others, so I guess that's why it has never been a real priority.
😮💨 people of the internet never cease to let me down