Tauri: Rust-based Electron alternative releases beta | Hacker News Reader

Tauri: Rust-based Electron alternative releases beta

tauri.studio

243 pointsadamnemecek168 comments

If you want to read more about what is new in the Beta release, we also published an article over at dev.to

https://dev.to/tauri/announcing-tauri-beta-more-efficient-cr...

Tauri: An Electron alternative written in Rust - https://news.ycombinator.com/item?id=26194990 - Feb 2021 (417 comments)

Hey - I am nothingismagick aka Denjell, one of the founders of Tauri, and will do my best to answer your questions about the project, rust, wasm, etc.

https://github.com/tauri-apps/tauri

Does the project contain C++ code?

v8 is c++ and by their own page, they use node whihch embeds c++ so I'd say yes

no, that is electron. not tauri

we do not embed node in the final binary, although you can use either the nodejs based cli or the rust cargo one.

no, not directly. all primary code is written in rust

They use whatever is the system WebView on the platform you run the code on. On Windows that's the Edge engine, on MacOS it's Safari's engine, etc. Those are all some combination of C and C++.

See https://github.com/tauri-apps/wry

Edit: s/IE or Edge/Edge

That seems to eliminate one of main advantages of electron, the consistent runtime environment.

If your html/css/is has to work correctly in EdgeHTML, Safari Webview, and Blink, you are limited to the lowest common denominator features.

Electron with Chromium has the largest feature set out of all of those.

I can’t speak for other developers but my app runs on electron and the web (because why not?), so I need to make sure my app works with those browsers as well.

A lot of the big electron apps I’m aware of are the same (slack, notion, discord, etc).

Slack used to use a similar approach but gave up in part because platform webviews are more outdated than browsers on average.

Electron has two "sides" to it — a renderer process, and a NodeJS process, that communicate over IPC (where as far as the renderer is concerned, the NodeJS process is kind of like a very intrusive browser extension.)

AFAIK, if you're writing a greenfield Electron app, it's best to do as little as possible in the renderer side, and as much as possible in the Node.js side, because the Node.js side has things like native threads and mmap(2), and everything running within the Node.js process can share that state, but things on the renderer side have to use it through RPC.

I would assume that this project is similar, but with arbitrary Rust code in place of Node.js (is that right?)

In that case, it doesn't matter how featureful the renderer is, as you're just using it as a GUI framework with a declarative view-model format. Just like a XAML or QML, but it's HTML+CSS.

As such, idiomatically, you won't be using fancy browser APIs like threads or WebRTC within the renderer; instead, you'll be using native code on the "app side" and then passing the renderer data. The features of Tauri itself are "whatever native libraries you want to bring into your Rust binary." (Plus whatever conveniences it already builds in, of course.)

This is actually untrue, you want to do as much as possible in the renderer process. The main NodeJS process is responsible for all user interaction, including mouse clicks and keyboard input. If you block the main process, the entire app will become unresponsive

But the main NodeJS process can spawn (regular POSIX) worker threads, just like any other GUI app’s main (event loop) process; and those worker threads can both 1. load native libraries and call into them, and 2. communicate just as directly with the renderer as the main thread can. The renderer, meanwhile, only gives you ServiceWorkers; and those can’t do anything natively. (Plus, they have all the same IPC overhead to the main renderer context that calling the renderer from Node does.)

Think of it like this: let’s say you’re creating an Electron equivalent to Mathematica. You have a big native blob of maths evaluation code. Where are you going to run it — in the renderer (as Emscripten WASM) or in a worker thread of the native app (as a native static library or DLL)?

Or let’s say you’re doing an Electron BitTorrent client. Where are you going to handle the network connections and do the file management and... basically everything the app does? Well, in this case, you have no real option: the renderer can’t open raw TCP sockets. You’ve got to do it native. (But it would have been the better choice anyway, for IOPS reasons—localStorage + virtualized attachment downloads don’t buy you very much disk concurrency.)

A less clear-cut case is a game engine. The answer there depends on whether you can get a handle to the renderer’s Canvas from your native code. If so, then the choice is obvious: native game engine, draw to renderer’s canvas. If not, it might still be more CPU efficient to go native: you might be able to approximate that over RPC if your game has a bandwidth-efficient wire protocol representation of its render command stream (as e.g. most 2D tile based games do.) Only if neither of these work would putting the game engine into the renderer be optimal.

For Windows it will actually install Webview2 if it's not there already so it's not running on deprecated IE.

https://github.com/tauri-apps/wry#windows

Good to know. Still awful on MacOS, and you'd presumably need to check distro by distro for Linux.

So basically on Windows it will use Edge. The idea is good, but this is not the first time someone try this. At the end it is all about testing, tools that needs to make 100% ( not 99% or 99.99% ) sure functions and rendering on all platform are intended as it is.

So you need to make sure your code works on 3 different platform eventhough you're using a tool that's supposed to fix that problem in the first place?

I don't know the extend of WebView in Electron is it something common?

Worse, it needs to run on every version on every os. Windows 10 has an evergreen webview, but on Mac for compatibility reasons the webview is only updated with a new OS release.

Edit: This is not something you run into with electron. It's the reason electron apps are so big, they bundle the whole browser engine.

A ton of time and resources have been put into making web apps work across multiple rendering engines. These days, it can be difficult to have something break on one platform if you are using a modern development stack. The webview engines that Tauri uses are all quite modern, see https://github.com/tauri-apps/wry/discussions/202 for more details.

Please add an example app with bundles for each platform – a calculator, todo list, or something similarly simple?

yeah, we just plain forgot to put that back on the landing page. mea culpa

https://github.com/tauri-apps/tauri/tree/dev/examples/api

Can I integrate Tauri into an existing Windows application?

Specifically:

1. Can I place it into a native window handle (e.g. HWND on Windows)?

2. Can I create a new window, but use the parent application's event loop without modification?

Thanks

Interesting that you guys list "No Rust Skills Required" as a Pro instead of a Con. As a Rust programmer I'd prefer "No JS Required"

Are you asking for them to make an entirely different product?

It's off-topic, but it would be nice for someone to make a really good GUI toolkit for Rust. Something that integrates with system APIs for copy-paste and stuff like that.

There's a few decent ones but like a lot of Rust stuff, they're young.

I hear you though. It's, IMO, a core tool missing from my Rust toolbelt.

The most promising one is makepad.dev IMO. It works on Mac/Windows/WebGL afaik

I see how the second part of my comment seemed like I'm asking for "Rust in the front-end", that was not my intention. My main point stands though, requiring Rust is not necessarily a "Con", it's in the "Pros" list for many people

I would also expect/like that: HTML/CSS + Rust (no JS/GC). And running out-of-process. Add XUL as a bonus.

I'm finishing this (no XUL tough), but the first impl(developer language) is in Swift. But the runtime the Swift access is pure C shims, so any other language can benefit from it.

If anyone is interested, it would be much easier to create those bindings to Rust. I'm super interested (and i would probably create a Rust SDK anyway) and there's a lot of other bonuses that neither Electron or Tauri can offer (as i target it not to be "just" a web-based app platform, but something that also had the soul of web browsers, by forming networks, addresses, etc).

If anyone is curious, there is more disclosure in another answer on this same thread.

i would love to give new all of those cool new languages that need a platform to thrive: Rust, Zig, Crystal, (and while not new) Python, a chance to have a 360 ecosystem, so we can stop being hostage of just Javascript being used.. and no, WebAssembly is definitely not it, as in the end it will give Javascript access to FFMPEG and the likes making it more prominent and ubiquitous

Why Node and not Dino?

Assuming you meant Deno, we used Node for the CLI because most web devs already have npm installed. We want the getting started process to be as simple as possible. Our Node CLI is just a wrapper really, as nearly all of the commands are actually implemented in Rust. You don't even need Node to build a Tauri app anymore. Node is not including in a shipped Tauri app, although we plan on supporting both Node and Deno as optional replacements for Rust in the future.

is it possible to include wasm in Tauri apps?

Yeah, you can use wasm on all platforms.

Does it try to achieve feature parity with Electron?

No question, just a small commendation. It pleases me that you acted appropriately to the criticism about Tauri not being native and removed this previously advertised claim.

I’ve seen this before, and I still have no idea what it does.

If it’s an electron alternative, is it too much to ask to show an image of a webapp running on a desktop (preverably a variation of every OS) front and center on the landing page?

I’d like to see it working immediately, without needing to watch any videos.

have some appreciation to his fashion and fireplace

That's a great idea! We do have a revamp of the landing page ahead of us, now that our roadmap is almost completed.

As far as I can tell, they have reimplemented the electron api in Rust to make use of native web views removing the chromium dependency.

I agree it’s confusing and not clear on the homepage or from the hacker news title. I was expecting something like an electron framework using servo.

I would be much more interested in a Gecko/Servo alternative to Electron than a native webview alternative.

Not that I don't also acknowledge the need for that, but my application is dramatically faster in Firefox than Chrome, yet we're stuck packaging a suboptimal experience in the desktop app because Chromium is our only option.

We are going to put our demo app (that showcases the API) front and center on the landing page. Thanks for the input

https://github.com/tauri-apps/tauri/tree/dev/examples/api

As a developer of an Electron app to me a competing framework that doesn't bundle its own rendering engine doesn't make sense, why would I want to trade control over how my app is rendered for ~100MB of disk space?

I might as well just ship a website at that point, almost everything that makes Electron appealing comes from shipping your own rendering engine.

you can't ship your own rendering engine on ios

> why would I want to trade control over how my app is render for ~100MB of disk space?

it depends how much you respect your users

100 MB on disk is less than 0.1% of a typical consumer SSD. Memory and processor usage is the concern.

> you can't ship your own rendering engine on ios

That's irrelevant, just because I can't do some things on iOS doesn't mean that I shouldn't do them under desktop OS' too.

Just one example: file system watching, if I need to do that with Electron I'll just use `chokidar` and have it working in no time, plus I can share whatever frontend code with the backend too, good luck doing the same with Tauri (given the current state of things anyway).

> it depends how much you respect your users

I don't know what kind of users you've got but mine care about me iterating quickly on the app, care about having new features, care about having a faster app. Most of them would consider trading any of that for ~100MB of disk space stupid.

As I said, if disk space is all you care about you might as well just ship a website.

Order of magnitude memory reduction, not disk space, was the selling point last time I heard. And given how often I hear users complaining about memory consumption in Electron apps, I think that is something pretty attractive, if it pans out.

> Order of magnitude memory reduction

That doesn't make sense to me, you are still using a browser at the end of the day. Sure you can save some memory by not bundling Node (at the cost of making even reading a file much more difficult), but that's not orders of magnitudes.

Now it's a browser that was probably already in memory for one reason or another, not necessarily a process per Tauri app.

That's a good point, that will save you some memory unless you happen to be in a scenario where for example you use Chrome under macOS and a single Tauri app, which would then use Safari under the hood, meaning still multiple browsers.

But I think that would save much less memory than people think. A bare-bones hello-world Electron app consumes about ~100MB of RAM (rough figure since it depends on many factors), maybe you can bring that down to ~20MB by sharing a common browser instance (I doubt it, a Chrome tab takes like ~50MB for me right now), but if your app uses 1GB+ of memory that has way more to do with how the app is coded than by having to spawn another instance of the browser. Basically you won't get a memory hungry app consuming 10x less memory by running it as a website.

Also electron require multiple node backend services which each eat memory like crazy (based on electron app I use).

Have one, real Multithreaded +, more efficient backend, will reduce memory and offer better performance.

Wails is also an alternative that does just that. Shared Web UI engine + Go compiled backend.

> Also electron require multiple node backend services which each eat memory like crazy (based on electron app I use).

AFAIK Electron requires 1 Node instance (you can disable it for renderer processes and you can have 0 WebWorkers or only WebWorkers with Node.js disabled) which consumes like ~50MB or something like that, which probably accounts for stuff other than Node.js too, if the app you are using require multiple Node processes that use huge amounts of memory they are just badly written.

> Have one, real Multithreaded +, more efficient backend, will reduce memory and offer better performance.

You can't just share Node.js across multiple apps, Tauri just doesn't bundle it at all, which is a whole different story with mostly downsides from my point of view.

> just badly written.

Ins't the easy answer. Each time a dev want to ignore valid comments.

I have the following electron app running: Spotify, Figma, VS Code, Discord, Slack. They all use more than 1 helper. Consuming between 600mb to 3.5gb.

Slack is much better than it was. But I wish they switch to something like Tauri or Wails in the future.

Of those apps I can only say that VS Code is well written and that Spotify is junk.

Is 600mb too much for VS Code? I guess it depends on what you are doing with it and which extensions you have installed etc., if you are running a pretty bare-bones installation and seeing 1GB+ memory usages in VS Code please open an issue in their issue tracker and tag me (same username as in HN).

> Slack is much better than it was.

And that didn't happen by switching to the website approach, I think you'll be disappointed if any of these apps end up switching to Tauri or Wails without significantly improving their code too. Which is why I'd predict no major player will jump ship.

for my work, vscode take between 1.5 to 2.5gb. Nothing has change since start using it 4 years ago, and my experience is consistent with my coworkers. I keep using it because it 'feels' the best overall. No magical issue will fix that, node is memory hungry as is java.

Calling an app junk to justify is argument is unconvincing. Its still a widely used app that works as good as the competition. In the case of slack, their optimisation endeavour seems to cost them quite a lot. But sure I don't have the number. If they would have start the project in Tauri or Wails at the beginning, would that saved them the refactoring? I don't now. But we will need more team using that kind of alternative to gain the knowledge and real benefit.

At this point I rewriting a toy project from electron to wails and its great. But well, it's only a toy project.

> for my work, vscode take between 1.5 to 2.5gb.

That sounds like a lot, you are probably running some heavy extensions or too many of them I guess, could you post a screenshot of the "process explorer" window for your instance of vscode?

> Calling an app junk to justify is argument is unconvincing.

I couldn't care less about what you think about Electron, that's just what I think.

Not if you take one of the biggest selling points of Electron.

Im working on something not quite the same thing but that deal with all this, and being able to ship with a web rendering engine and not using whatever its on the system is actually better giving all the power, bindings, compromise you can make that you are unable when you can only deal with a abstract wrapper to every web rendering engine out there.

Lower memory footprint but with much less features and a generic "no sir, cant do such a thing.." as a answer to users that will need important features to ship applications with this.

Of course it's less convenient for developers not to ship a rendering engine. But should developers' need always come before users' needs, especially for applications that live and run on their own PCs?

Its not also about user needs, given the final application will have access to more functionality, also guaranteeing things will work.

I agree that Electron is user hostile in the way it uses memory, but there's an answer in between the Electron and what Tauri is offering here.

Tauri could have a embedded engine and yet propose a better architecture and better use of memory in consequence. The best of both worlds.

In Chrome for instance, each tab is equivalent to a app, giving is a whole isolated process and yet it doesnt kill your machine even with many tabs open.

Apple's brand new iMacs with the M1 CPU only have 8 GB of RAM.

If every little desktop widget loads its own browser engine, most of that RAM will be spent on redundant copies of Chromium.

If your Electron app is something that you expect users to run almost exclusively, then no problem. If it's just another little client app for some service, please consider a solution that would reduce its memory footprint.

That's a fair point, but just ship a website then, much easier and pretty much same result.

It makes sense to use frameworks like Electron if they enable new capabilities for your app, and Electron is very good at that, bundling Node.js with it, which allows you to share code between frontend and backend and tap into the same ecosystem of packages, plus chances are you already know Node.js, Tauri is enabling 0 of this, at least presently.

> much easier and pretty much same result.

Actually better results even, because under macOS for example the webview is provided by Safari, but if you are using Chrome/Firefox as your browser of choice and you are using a Tauri app now you are using 2 browsers effectively, while if you ship a website you can use that website with whatever browser you prefer.

And with WebView, RAM will be spent on redundant copies (instances) of WebView.

If it's the same system dll, then it'll share all of the RO segments.

That's not how system frameworks work.

It's about memory management more than it is binary size. Rust is notorious for being turbo-charged with every LLVM optimization on gods green earth, so much so that the actual syntax of the language is beholden to the opinion of the compiler. Either way, I see it as a great step in the right direction, and would be perfect for apps like Discord or Spotify.

Most of the memory usage will come from the renderer process, which in a Tauri app is still a browser.

And most people have problem eith Electron's ram usage, which I don't think this addresses. No one really cares about 100mb

I'm really struck by the differences between Electron's website and Tauri's website. https://www.electronjs.org/ https://tauri.studio/

Tauri's website is way, way worse. Tauri uses unnecessary jargon where Electron's site uses simple, more direct language.

Electron:

> Build cross-platform desktop apps with JavaScript, HTML, and CSS

Tauri:

> Build smaller, faster, and more secure desktop applications with a web frontend

"web frontend" vs. "JavaScript, HTML, and CSS"

Electron and Tauri have icons with labels.

Electron:

> Web technologies, Open Source, Cross Platform

> Automatic updates, Native menus & notifications, Crash reporting, Debugging & profiling, Windows installers

Tauri says:

> Brownfield, FLOSS, Bundle

> Security, Patterns, Cross-platform

https://tauri.studio/en/docs/about/intro

> Tauri is a toolkit that helps developers make applications for the major desktop platforms - using virtually any frontend framework in existence. The core is built with Rust and the CLI leverages Node.js making Tauri a genuinely polyglot approach to creating and maintaining great apps.

Electron doesn't have an equivalent "about" page, but instead has this paragraph on its home page:

> It's easier than you think: If you can build a website, you can build a desktop app. Electron is a framework for creating native applications with web technologies like JavaScript, HTML, and CSS. It takes care of the hard parts so you can focus on the core of your application.

"virtually any frontend framework" "polyglot" vs. "takes care of the hard parts"

Exactly my thoughts. I feel like Tauri is trying to let Rust carry the project instead of writing decent marketing materials. Really the only thing I see on Tauri's site that makes me want to use it is Rust, while I can see many value props on Electron's site.

tauri saves space by not packaging a browser.

this means your app has hundreds of javascript versions to target

They don't say "JavaScript, HTML, and CSS" because it isn't just JavaScript, HTML, and CSS. It's any technology that can run in the browser, such as Yew or Maple for example. Arguably those Rust-based frontend libraries are the main focus, even, over something like React.

FLOSS also means a different thing from Open Source because of the "Libre" aspect.

I don't see why being different is considered bad here, as its whole shtick is that it's an alternative.

Please keep in mind that this project just reached _beta_. We are working to implement valuable feedback from the community, so please don't expect things like the landing page to be as polished as an 8 year old project.

Shout out to all of the hardworking people behind Tauri. ♥

> so please don't expect things like the landing page to be as polished as an 8 year old project.

I think problem is that it is over polished and slick not unpolished.

A step towards the right direction, I am curious how it performs in relation to Ultralight[0]!

[0]: https://github.com/ultralight-ux/Ultralight

Tauri distributables are still 10 times smaller than Ultralight. Regarding performance will have to do some reviews.

from the homepage https://tauri.studio/en/docs/about/intro The core is built with Rust and the CLI leverages Node.js

maybe make this text a bit more explicit? I'm guessing maybe you're using a message passing layer to keep the processes separate?

that's a great idea.

Tauri just uses the platform native webview, it's not a rendering engine.

I'm a bit surprised the new website doesn't mention this at all. The Github repo does.

I don't get the push for rust as a front-end language, it's very distracting with a lot of low-level features.

Can we just stick with "best tool for the job"?

Rust for performance-critical systems and, say, typescript for front-end? Using a single language for everything is a wet dream that always ends up in complexity and more work as you're fighting the "native" ecosystem.

what if I don't like typescript

you can write your frontend in whatever you want, for example using yew...

Don’t use a web based app stack?

I don't know, pick a better high level language: kotlin, swift, f#

Maybe you should spend like 5 minutes looking into the thing you're critiquing before critiquing it? Just a suggestion, given that Tauri literally uses typescript for front-end.

did spend 5 mins, saw absolutely no code so I made some assumption. Maybe they should make better docs that don't require 5 mins+ to figure that out.

Okay, so make a top-level comment critiquing their docs, rather than making an incorrect assumption and then critiquing it.

You don't need to offer a perspective on everything, and I prefer the critiques I read to be well-founded.

When WASM becomes a dominant platform, all the performance-critical features will become very important.

WASN will always need some kind of javascript glue to interact with the DOM.

I think that eventually, people will roll their own GUIs without using DOM.

The paradigm of Tauri is to pick the "best tool for the job". Bring your own frontend tech (JS, TS, RustWasm, etc).

Normally I'm on the defensive side for the JS ecosystem on Hacker News, but not today. While it's still the best option for web app development productivity right now, there are woefully bad issues with the Node ecosystem, from poor or lack of documentation for complex build tools to zero contracts between dependencies. Rust has the advantage of being able to break if things seem to not fit together. It's a popular language for more use-cases than just performance-critical applications even if it supports that.

> zero contracts between dependencies.

Isn't typescript contract?

This is not really about JS, if I want to replace JS I'll pick a language with similar characteristics that make it successful. Similar to how you replace C++ with rust, another language that gives you control of memory. For app developments they are simplicity and a focus on domain modelling with a good type system (this is typescript teritory), NOT memory safey.

And don't tell me that rust's type system is powerful too, yes, but it's also complex and the focus isn't domain modelling. Like C++ and golang's type systems, it's there to aid the compilers/borrow checker, not developers.

Example of such language in my other comment: kotlin, F#

I think Typescript won't check that two of your dependencies are compatible with each other; it will only check that your app is compatible with dependencies. Even then, the check isn't very strong, since TypeScript operates on a "as you want it" basis, which is nice in some ways but also means you could get overly permissive behavior, especially if you're using third party typings, which is fairly common.

> the focus isn't domain modelling, like C++ and golang's type systems

Could you please explain what you mean by this? I've honestly not heard this argument before so I'd be interested what domain modeling Rust doesn't encourage/support that, e.g. Go does.

I'm not saying that go and C++ have better type systems. I'm saying like rust, their type systems are built to aid the compiler. High-level languages like ocaml or f# have type systems made for domain modeling

I'm not sure I understand your point. Rust has ADTs, like OCaml and F#, and Go doesn't. Rust can be written almost like OCaml and F#, Go can't.

His point is that Rust is not user-friendly with a unnecessary cognitive load for user facing applications. I don't know why this comment section derails into the language properties and technical merits, giving its pretty simple to recognize that. The HN crowd might be above average and might tend to think that Rust is an easy enough language, but the reality for most people is that languages with the amount of complexity of the likes of Rust, C++ and Scala are not easy for the "average programmer" and we are not even talking about the people that just don't want to deal with unnecessary complexity.

Really, almost any GC'ed language out there is a better pick for this sort of task (except the ones that are poorly designed for this, like Go).

The point is not to be "easy;" environments that value being easy are environments that encourage bugs. The whole ethos of Rust is safety and thoroughness. True, it's not as user-friendly, if your definition of user friendly is "runs at any cost." If instead however you take the definition as "allows you to easily write programs that work right," it is probably one of the easiest languages.

You speak of "unnecessary complexity" like the complexity was just pulled out of thin air for the purpose of making Rust harder; no, the complexity is inherent to building a functioning application, the difference is whether it lives in your head or it lives in the compiler. Personally I'd rather the compiler handle things like bookkeeping, moving memory around, checking that the types and cardinalities are right, and ensuring errors are handled rather than repeatedly having to debug those things at runtime in an extremely slow and punishing feedback loop.

Its unnecessary complexity for the paradigm we are talking about, that is user facing, mostly UI applications.

Its necessary for system programming, and as we can see people talk about it whenever C++, C, OSes, Browsers, Games, etc.. are being talked about because it works really well in those domains.

But when you are building a UI, C#, Kotlin, Swift, Typescript and even Java are much more productive with good speed, safe (even safer than Rust), and with language constructions that map really well to this domain.

Rust achieved a very good set of features, but unfortunately the price is its complexity, which is a burden you don't need to take when you are creating UI's.

Sure you and i (im mostly a C++ dev) can use it to make UI's, but unless you are creating something really complex that needs every drop of performance and memory, like big Games or a Photoshop, you don't need this productivity and HR tax(its much harder to find people in C++ and Rust) that languages like Rust and C++ ask of you.

There's no such a thing as one language to rule them all, and Rust will not the best candidate for domains it was not designed for. Swift for instance is much better at this and with a very good performance, where it would also be a good fit for a Photoshop clone or a browser.

It's strange that some people view UIs as being some of the simplest software. Once you've considered the state management, asynchronous nature (meaning your code could be run in many different permutations), graphical elements (graphics' complexity upper bound being equivalent to what you might see in a video game), legacy APIs (old browsers, shims, or old OSes), and IO such as network requests, it ends up being incredibly complex. The number of hours I've seen being spent fighting Webpack are uncounted. From where I'm standing, it's clear the complexity is already there, it's just totally unmanaged.

Rust will make a great UI language once the ecosystem has matured and async has gotten polished more. If upgrading the "Webpack" of the future meant just resolving compiler errors, we would be in a much better world. Same goes for upgrading dependencies on the frontend, which at my company becomes a blocker every 2 weeks or so due to the NPM security advisories being released, accompanied by the total lack of visibility into the dependencies' interplay that the Node ecosystem gives you.

I'm not saying that Rust is not a good language for UI, and im also not saying UI is simple. The problem is that you are just comparing it to JavaScript which is untyped and easy to beat.

In my case i'm comparing it with languages that are also powerful, safe, fast and more well designed for this kind of scenario, which JavaScript or Python aren't.

But if i had just two picks, between JavaScript or Rust, of course i would choose Rust without blinking. But once there is more options.. (in this case you can read my comments above).

And i agree with you, that if you sum it all, maybe you get more productive (as in ready to ship) in Rust than with JavaScript.

Sure, those other languages would be fine, but they all have their own severe downsides..

C# - requires an obscure runtime (Mono) on most platforms

Kotlin - suffers from JVM's infamous GC pauses and startup time

Swift - not open source (not SwiftUI, the good part)

TypeScript - mostly same problems as JavaScript

Java - same problems as Kotlin

No one has managed to do open source cross-platform development well yet IMO. I'd be happy to be proven wrong.

Ocaml: https://github.com/revery-ui/revery

F#: https://safe-stack.github.io

To watch:

Kotlin NATIVE

Scala NATIVE

Note that even with Scala's complexity, the language's focus is first and foremost domain modelling & expressiveness.

Rust is first and foremost, a language for memory safety and raw performance, it just happens to have some level of expressiveness. Nothing wrong with that either.

Those are some interesting picks, thanks! Will definitely be checking them out.

Could you re-read my comments, I think go is a very lame language, at no point I said it would be good for anything. You're not convincing anyone by picking on low bar like C#, javascript & go to make rust seem like a good language for UI programming.

I would disagree. Types like `Result<T,E>` or `Option<T>` exist purely for the user; the compiler doesn't care that there is a convention for errors, nor would it be that bad for a compiler to have `nil` (there are certainly a bunch of compilers that can handle it). There are a number of convenience types available such as `Rc` which does reference counting. If `Rc` didn't exist, you could still survive and write the same applications, it's just that it would be more cumbersome.

You know, there are people like me that just can't stand Javascript. TypeScript is somewhat acceptable, but knowing Rust, I just prefer to use it anyway. It is just better.

I've been clicking around in the docs for a few minutes now and I still haven't figured out how to do anything beyond install it. What am I missing?

Is anyone developing a cross-platform alternative to native OS webviews? The web hasn't been heading in a good direction lately.

I'm doing this.

One difference is to be able to ditch Javascript and use a native language(Swift is the first one) to talk directly to webkit.

The other difference is that the apps are "managed" as Chrome manages the renderer process, so in the end you have one manager process and one service process for each app and many process for the UI apps.

The problem with Electron is that for each app, it will need many processes, and if you have more than one Electron app running, it will eat all the resources.

With the architecture proposed, it will be more light as there will be just one instance of the manager processes, and unlike Electron they would not be isolated as they are all centrally managed, also the fact that it wont need to use JS, will also put less pressure on memory resources.

It also uses RPC so that every app have a API that can be callable by others. This in turn can make it form a "network of apps" where the applications can consume the apis of the other apps installed. The RPC service is local first, but can fetch things in the "cloud" if the application needs to.

For me this is my take on what "Web 3.0" should look like.

I have a 0.1 version here and i'm just finishing the final touches before launching it..

Edit: Also i forgot to mention that the distribution of the application and resources(database and files) is over torrent with DHT routing, so you can share a unique address and serve your own applications over internet without depending on domains or a third-party hosting it for you.

Nice! If I understand correctly, the renderer process is shared across all apps, each app is either a service or a UI process, and all of the apps export an API that's routable from the local machine. Is that right?

Do you need / want any help?

Its like this: You have one manager process and one GPU process for everyone. (Mind you that this is chrome based, but its quite modified i must say).

Then for each application: You have a "service process" which is instantiated and is always running, this process asks for the manager to create its rpc service server. Then every rpc call is routed to it.

This application service process is already coded by the developer so he defines what every api does and also how it respond to resources like pages, images, videos, etc.. (it also uses RPC by default to route resources.. but its through HTTP/2 giving its gRPC/Protobuf)

This process, totally in control of the dev code also can hijack its own application launches, so its in charge of app launching and killing (from its own scope)

Then theres the UI process which is akin to renderer and its also coded by the dev, where the renderer is in Swift so totally customizable (Imagine being able to control the C++ renderer events, lifetime, frames, etc.. of the chrome renderer process; in this case you do, with Swift), giving you have a lot of power.

The developer control, codes and ship the service and the ui app. Once its installed, even without any UI, all other applications can consume its services over its RPC api, because there is a 'service process' running and serving those requests (imagine being able to deal with twitter or a google search api (all local and with the same tech) from your app that is specialized in something else)

> Do you need / want any help?

Yes of course! How can i reach you?

You've got alternatives like Flutter and ReveryUI which are both pretty solid for building cross platform applications without using web technologies or webviews.

And you can always just use some of the other GUI toolkits that have been coming out recently.

Should you bundle it with Deno, not Node, as Deno is also a rust project?

We don't bundle with node. We bundle with rust.

Is it a misleading title then? I thought you did an alternative to Electron

Being an Electron alternative and using Node.js as an optional bundler are not mutually exclusive.

Well, I'm lost. You won

Like Electron, with Tauri you write your GUIs with HTML, CSS, and Javascript. Electron uses Node for the client-side non-GUI functionality, while Tauri instead uses Rust binaries to accomplish same. That's the alternative part. Node is not needed at all in the final build, although it may be used to create your app before bundling for release.

Maybe we need to be more clear about how nodejs CAN be used in the construction of a Tauri app, and that it is neither a requirement to make a Tauri app nor a component that is shipped with a Tauri app.

Deno and pure Rust are on the roadmap. Node.js is only used as an alternative to the Cargo based CLI.

Deno is on our roadmap, but the focus right now is performance, flushing out features, and performing a security audit. As was also said, Rust is used to bundle your app.

So what are the benefits to using Tauri over Electron? Are app sizes smaller? Is the memory footprint smaller?

Yes, much smaller install size and memory footprint. We have a comparison table on our readme: https://github.com/tauri-apps/tauri#comparison-between-tauri...

Thanks!

Will FOSS and uh... indiscriminate distros face hurdles to bundling this? If this is good with interacting with CLI, Linux distros could experience a Cambrian explosion of GUIs. Ubuntu's flutter installer project could get leapfrogged.

I don't care about your YouTube videos, I don't care about your governance, I don't care about your book, tell me what it is in non-marketing speak and show me a screenshot on the front page and shut up about everything else.

Tell me what it is, show me what it looks like, provide a "Hello, World!" API example for opening a window on the front page. Stop contributing to landing pages that jerk the consumer around.

There's this silly game a play sometimes: I go to producthunt.com, open a bunch of links and, then, try to guess what each of them does. I fail most of the time.

> Tell me what it is, show me what it looks like, provide a "Hello, World!" API example for opening a window on the front page. Stop contributing to landing pages that jerk the consumer around.

They've got a point. Time to cut through the hype, get straight to the point and show some screenshots to catch their eyes.

If you can't manage that, the tab gets closed with in 5 seconds. Even if it has the Rust buzzword. (Because that trick always works on HN)

I dug around, and the only screenshots I can find are on a few project pages that use it.

But of course, there is not much to see, it's just a window with a web view inside of it.

https://guijs.dev/ https://github.com/samirdjelal/bidirectional/ https://github.com/mmpneo/simple-obs-stt

Wow you're right. I thought you were exaggerating a bit because there's a "Get started" button right there. But even clicking that I had to drill down through multiple badly named pages just to find the part that describes how the Rust portion of this works. Why is the selling point of this not shoved in your face from the second you load the page.

Like I wrote in another response, we are due for a landing page revamp, and we'll be sure to make a "nothing but the facts" hero for people like yourself who are concerned that their time is being wasted.

> for people like yourself

It's not for "people like me," it's for everyone. In terms of volume of traffic you're going to get, no one else cares about this stuff.

Here's an example of one of my projects where I do just that: https://www.planimeter.org/grid-sdk/ Literally! I tell people what my team has built. I show them a screenshot. I then provide API examples. Mine could be better if I provided screenshots per API example, too. Everyone can improve.

Your audience is technical, they don't want a non-technical pitch. Tell me it's faster than Electron, show me RAM usage comparisons, etc.

We actually had this at an earlier stage during the alpha, but got so caught up in the alpha that we just plain forgot to put the apps for mac, win and linux back up there. We'll try to get that done this weekend. We have a full "API Explorer" app that we built...

https://github.com/tauri-apps/tauri/tree/dev/examples/api

You're going to do great. Just steer the ship back in the direction of the elevator pitch experience. After that 20-30 second experience, if people are interested in more (provide Getting Started at the end of all of that, not the beginning,) they will click on it and want to learn more about what you have to offer.

Avoid putting things in people's face before they've gotten to know you. You're not trying to be a food blog throwing pop-ups in people's faces about how they need to subscribe to your newsletter. You're trying to be a competitor to Electron.

Here's what their website tells me what they do:

> Build cross-platform desktop apps with JavaScript, HTML, and CSS

Ah! OK. I'm interested. And see how specific they are? Don't be vague. Don't say "web front-end," what do you mean? React? They then show me screenshots! Of what big companies built!

Then. They provide a Getting Started section. Not great, could be better. I want to see how it's used. But this is the bar. Be better than that bar.

Edit: Even Electron's site provides Getting Started at the end.

Having the getting started button at the end is a good idea I think, we'll look into that.

We say "web frontend" because that's as descriptive as we can be really. We support any web framework that runs in a browser. As for screenshots of big companies' apps, we don't have any major companies that have adopted Tauri yet, as we just came out of alpha, but we will add a section like that as soon as we can.

It's difficult for us to demonstrate how Tauri is used in short snippets that could fit at the beginning of the Getting Started section. Electron's site doesn't have any code snippets either, just snippets for installing via npm and some example apps.

I understand the difficulties of competing with incumbents because size and usage are not your strong points yet, sort of. You all have over 16k stars on GitHub as a proxy for interest! My team still has under 1k.

It also doesn't help that we chose a language that isn't popular. But you all need to think about how decision making like that massively effects adoption.

You won't learn these lessons quickly, they take years, so ignore people who say you need to experiment and research what works. The biggest issues you'll face is that no one will tell you what's wrong unless you're faced with it in threads like this on HN or other places where you'll meet consumers.

The worst part of it is, these are the obnoxious glaring details. There might be massive decisions you make that consumers can't pinpoint for you. Thought-leaders don't often describe those details because of survivorship bias.

What I can see this team failing at, too, is that you need an anchor client. You're spending all this time on BS that doesn't mean anything at all.

Specifically, at GitHub, they already had users using Atom, which made for a great way to advertise Electron. It was Atom!

You need to essentially find whales (Read: engineering leaders at businesses) and make the product good enough for one of them to say, yeah I'll use this over Electron, and if they're an attractive user, pump them on your front page. Find a way to make a deal with them so that you can funnel developers to their hiring channels.

Great landing page. Straight to the point. OT question: what makes the engine multiplayer-first?

The engine is multiplayer first because you don't have to write any special code to implement it. When you start a game, if you set maxplayers to something beyond 1, it's multiplayer automatically.

When you create entities in the engine, all you have to do is specify what fields you want networked, and the game engine automatically serializes deltas for you on that field as they change.

It takes care of more advanced field networking like prediction as well.

You focus on making things, not making them networkable. If you want that, you just say it's networked. That's it.

Maybe you should put that pitch up there on the starting page, because personally I find it too bland. The screenshot doesn't tell me anything, might as well not put it up there.

The page is simple, yet it doesn't even render anything but the menu without javascript.

I think if time on page and average session metrics suggested that's what people wanted, that's what we would see. It's like complaining about how the news reports on inane stuff.

Sounds like a case of bad metrics. Time on page when your goal is to get people to use your software/framework isn't meaningful. In fact, I suspect better communication leads to shorter times.

Similar idea with news. The objectives of profit and conveying meaningful information aren't necessarily aligned.

Disregarding the subjectivity of 'meaningful,' the advice 'know your target audience' is good from both a product design and marketing presentation stand point.

I think that for both examples, having people's attention is a precursor to doing anything else. That's just my intuition though.

Maybe it is possible to have a landing page that people leave much more quickly but that is more successful. Maybe it is possible to keep your audience informed without them watching for very long.

You are assuming they have done analysis and A/B testing. More likely they simply copied the approach of consumer products, without thinking too deeply about the fact that developers are their only users.

I don't think it's so much 'nothing but the facts' but rather a little more effort to explain 'what it is'.

It's not that the site is 'marketing speak', it's just that it's a 3/10 on communications.

Even two sentences at the top would help.

I've spent a minute on it and I'm not sure what it is.

It's a way to make apps, but it doesn't have a front end? I don't even know what that means.

TBH it was pretty frustrating and also for me it was a waste of time.

Even though the project itself sounds very promising, because "Rust" and "Electron alternative".

But how can I know if it really is an Electron replacement if I'm not even sure if I can create native context menus or integrate it into the SysTray?

If you scroll down to the roadmap, you can see that system trays are supported. We don't yet support native context menus, but that would be a relatively simple addition. Our GitHub readme has a table comparing Electron's and Tauri's features, do you think it would be useful to include that on the website landing page?

So it would make sense to split the roadmap into what already exists, and call that the feature list, and the rest can remain as the roadmap.

Then provide screenshots/code samples for each item in the feature list.

That sounds like a solution. Or just add some screenshots/code samples to what is already implemented in the roadmap.

I actually thought it wasn't that bad. Some landing pages leave me utterly bewildered, but this one didn't.

Also, I liked the way they presented their roadmap.

I came here to ask, “where is the screenshot?”

It's a webview wrapper.

> ...the Tauri-team incubated and maintained WRY, which creates a unified interface to the system webview (and other goodies like Menu and Taskbar), leveraging WebKit on macOS, WebView2 on Windows and WebKitGTK on Linux.

https://github.com/tauri-apps/tauri

Doesn't using the "system" webview throw out the main selling point of Electron, which is that you're shipping the browser, so you no longer need to support more than one of them?

Perhaps, but using the system webview also means that you don't have massive amounts of bloat, both in distribution and on-disk size as well as memory usage, and you have a better chance at getting better performance.

Besides, all of the relevant engines are WebKit variants, so you're not targeting Trident or Gecko or anything.

Bear in mind that a lot of popular "apps", like Slack, Discord, etc., are web apps anyway, so there's a decent chance that the "support more than one of them" problem is already solved anyway, meaning you don't have to spend any more development time but you get huge increases in performance and responsiveness.

That is very true, and it's a nice differentiator relative to Electron— you still get your own app launcher and access to system APIs, but without shipping and launching the entirety of Chromium.

This is unbelievably harsh, and "your landing page sucks" is the most boring comment people can make on HN posts.

Yes, you're right. It's direct in an abrasive way, but I give specific actionable feedback about how to improve, and I'm not sorry.

I want people to be direct about how my projects need to improve, because I know how it doesn't meet my standards, but I don't know how it fails to meet other people's standards, which is more important if you're concerned with adoption.

See my other post in this thread for an example.

"Tauri is a toolkit that helps developers make applications for the major desktop platforms - using virtually any frontend framework in existence. The core is built with Rust and the CLI leverages Node.js making Tauri a genuinely polyglot approach to creating and maintaining great apps."

That's the first paragraph on the About page. Landing pages have multiple purposes and need to address different types of viewers, not just the neckbeards. The marketing speak is likely more for convincing IT manages this is a legit project and does not have common "deal breakers".

> The marketing speak is likely more for convincing IT manages this is a legit project and does not have common "deal breakers".

If this is the case, it's an excellent reason to not use Tauri. Making their decisions based on what IT managers want to read rather than what developers need to do their job? Good luck with that, might work in some bubbles but the rest of the world is trying to be productive.

Nope. Landing pages have one purpose, to funnel you further down into adoption or allow you a place to access things you've already adopted. That's it. Everything else is noise.

You just listed two purposes.

They are nowhere near ready for pitching IT managers. The only thing that matters right now is winning developer interest.

TL;DR Build native apps from JS by wrapping in a web view. Aside from native dependencies required during development for whatever playform you're building:

  yarn add @tauri-apps/cli
  yarn tauri init
  yarn tauri build

I'll admit you'll probably have a couple extra configuration steps in there. But I found it much easier to get started than with Electron and the resulting app seems pretty slick.

Came here to say this. It's a site designed for idiots not engineers. How does rendering work? Can't even tell if it's HTML based or some hipster immediate UI toolkit nobody's heard of. What do I need to give up to get a 640kb binary? etc etc.

Answering my own question, https://github.com/tauri-apps/wry , so looks like it loses one of the advantages of Electron in that you control the exact browser in use. Maybe that's incorrect. Who knows? Web site appears to not exist to provide such important details.

https://github.com/tauri-apps/tauri/blob/dev/ARCHITECTURE.md could lose a few thousand words, but this seems to be the real starting off point

Please don't break the HN guidelines like this. Fulminating, fault-finding, blaming rants hit on everyone's indignation and attract upvotes, and when we end up being a site where this is the top comment on the top submission, and the whole place fills up with toxic fumes. This isn't the community any of us wants to have.

https://news.ycombinator.com/newsguidelines.html

Sure thing, I'll edit the post. Edit: Oh, OK, well nevermind then.

Reply on news.ycombinator.com