Tauri is a very interesting framework. On the one hand, it is a framework solving a huge problem in the world of desktop development. It enables cross-platform development without the disadvantages of shipping a separate Chrome browser each single time. This saves resources and reduces the bundle size. On the other hand, it is one of the rare frameworks which requires two totally different languages. In this case, the languages are Rust and JavaScript. Tauri requires JavaScript, CSS and HTML in the frontend, but also gives the possibility to outsource fragments to Rust. This idea is not totally new. A similar approach was actually intended with WebAssembly.
This makes sense. Through this approach, you can still use the UI technologies of the web while harnessing all the power of the computer with a much more optimized language. However, this feature of Tauri is very rarely seen in other frameworks. Also, WebAssembly is a great thing but has some sort of absence in the web. But why is this approach of two different languages so rare? To answer this question, we must first familiarize ourselves with the huge difference of these two languages.
Rust vs. JavaScript
We cannot avoid a technical comparison of these two languages if we want to approach this question. However, I want to keep it short.
JavaScript is a high-level, interpreted language. This means that it has a high degree of abstraction from the actual technical process. This allows the programmer to achieve things more easily and faster. Furthermore, the code is converted into machine-readable code only at the moment of execution. Thus, no separate build process is necessary. While such languages shine with their ability of fast development, they have the disadvantage of poor performance. A separate program which converts the code must run each time the program is executed.
Rust on the other hand is a compiled language for system programming. This means that Rust code is converted into machine code before it is being shipped. The resulting binary is therefore highly optimized. Also, the language gives more access to system resources like memory, increasing the complexity of the implementation. However, you have nearly total control over your program.
When speed and UX meet
Rust is loved for its great ability to build reliable and efficient software. You can argue that JavaScript has somewhat of an opposite reputation. However, it has the monopoly on the browser and is quite flexible.
But when is such a fast pace required? There was only one project in the recent past where I needed to use Rust.
Some time ago, I wanted to build a small Markdown editor with live preview using Tauri (similar to VS Code). For the parsing of the Markdown, the library „marked“ was used. So nice, so good.
But after some time I noticed a certain latency that comes up when working with larger texts. This has to do with the fact that with every keystroke, the whole text had to be regenerated in the preview. The larger the document, the more work for the parser. It surprised me a little bit how fast I got into this bottleneck. Now, there are many ways to help here.
First, I could debounce the two values in React to limit the latency to in the editing. This would only hide the latency away for the user. Also, I could try to split the text into multiple chunks and only regenerate the parts that are edited. But this approach needs careful implementation for not breaking the text. But why do you need to run this task in JavaScript? The task of parsing Markdown to HTML is a nearly perfect case for Rust. Without any of the optimization from above, the task of converting large documents into Markdown was 12 times faster in Rust. This was one large task that can easily be outsourced to Rust.
Reality
How often is this the case? From my perspective, this case is a little bit rare because most of the time JavaScript is fast enough. It gets the job done. Even when this is not the case, we can make more performance by relying less on JavaScript. This is the bases for the island architecture, which I have explained in this article. You still have a steeper learning curve when working with mid-level languages.
This problem and the idea that your current language will get the thing done too is enough to justify the decision for sticking to a specific language most of the time. However, this idea is not always the best approach – as can be seen in the JavaScript world, too. Creating website in JavaScript became great. But using JavaScript for anything far away from the browser falls out of place. Rust or any other mid-level language has this problem too. Creating a website with Rust is possible through WebAssembly, but not really efficient in terms of the developer experience.
Summary
To come back to the question from the beginning: I think desktop apps are a rare field where the requirement of great UX and awesome performance come together. IoT could have similar requirements in the future too. However, it may not share the need of great user experience. Maybe, we will see this dual language approach more often in the future.
Schreibe einen Kommentar