Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Tauri: Rust-based Electron alternative releases beta

tauri.studio

Post reply on HN
Print view View original

161–170 of 177 posts

Re: Tauri: Rust-based Electron alternative releases beta

#161

Post by politician »

oscargrouch wrote: post #160
politician wrote: post #29

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 proce…

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?

Re: Tauri: Rust-based Electron alternative releases beta

#162

Post by fabiospampinato »

francisl wrote: post #159
fabiospampinato wrote: post #156

Earlier quoted context omitted.

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.…

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, t…

> 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.

Re: Tauri: Rust-based Electron alternative releases beta

#163

Post by oscargrouch »

politician wrote: post #161
oscargrouch wrote: post #160

Earlier quoted context omitted.

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 proce…

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?

Re: Tauri: Rust-based Electron alternative releases beta

#164

Post by cyanydeez »

jackson1442 wrote: post #91
dfabulich wrote: post #76

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 fronte…

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

Re: Tauri: Rust-based Electron alternative releases beta

#165

Post by adamnemecek »

abeltensor wrote: post #50
adamnemecek wrote: post #31

Earlier quoted context omitted.

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.

Re: Tauri: Rust-based Electron alternative releases beta

#166

Post by ironmagma »

oscargrouch wrote: post #157
Zababa wrote: post #108

Earlier quoted context omitted.

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 comp…

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.

Re: Tauri: Rust-based Electron alternative releases beta

#167

Post by oscargrouch »

silon42 wrote: post #146
juancampa wrote: post #64

Earlier quoted context omitted.

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"

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

Re: Tauri: Rust-based Electron alternative releases beta

#168

Post by oscargrouch »

ironmagma wrote: post #166
oscargrouch wrote: post #157

Earlier quoted context omitted.

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 comp…

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…

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.

Re: Tauri: Rust-based Electron alternative releases beta

#169

Post by ironmagma »

oscargrouch wrote: post #168
ironmagma wrote: post #166

Earlier quoted context omitted.

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…

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…

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.

Re: Tauri: Rust-based Electron alternative releases beta

#170

Post by oscargrouch »

ironmagma wrote: post #169
oscargrouch wrote: post #168

Earlier quoted context omitted.

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…

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 inc…

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.

Post reply on HN