Live data from Hacker News

Tauri – Electron alternative written in Rust

tauri.studio

181–190 of 435 posts

Re: Tauri – Electron alternative written in Rust

#181
post #111

Earlier quoted context omitted.

But you won't be developing a web app, you'd be developing a desktop app, much like with React Native. Having web developers learn C++ and Qt instead would be much more unacceptable.

By this logic requiring web devs to write ES3 code should be acceptable too. The platform changed significantly, improved significantly, in the past few years, some of these major advancements can't be ignored just because a browser doesn't implement them.

Nope, you can compile code back to whatever ECMAScript version you like with tools like Babel or TypeScript. So the devs don’t even notice that they’re compiling to 4-5 year old ES.

Re: Tauri – Electron alternative written in Rust

#182

Earlier quoted context omitted.

Per https://github.com/Fournux/tauri-vs-electron it uses just 20 MB of ram on linux. Why? I guess because webkit-gtk is less ram hungry than blink.

any idea why the memory usage difference on windows are very close but significantly different on linux?

WebView2 is chromium edge. This was the reason that I guessed webkit-gtk uses less ram than chromium.

Re: Tauri – Electron alternative written in Rust

#183

Earlier quoted context omitted.

> It makes perfect business sense to use electron. In many cases, it should also make perfect business sense to use PWAs. I've heard Adobe has brought a significant part of the Photoshop and Illustrator functionality into their web apps.

> I've heard Adobe has brought a significant part of the Photoshop and Illustrator functionality into their web apps. This is true. We managed to wrap a very large portion of the desktop code base into a “portable” library (with some customization at the point the library hits the OS, e.g., file IO.) This library is compiled specifically for the OS it’s going to run on (iOS, Web) to give us the best performance we ca…

There's a terrible performance regression in Illustrator 26 when working with files with many objects. Works fine in 25, UI freezes for several seconds in 26.

Windows 10, pulling in part of an engineering drawing from a PDF (so many thousands of objects).

Re: Tauri – Electron alternative written in Rust

#184

One very important thing I'd like to highlight: using one shared browser instance rather than N is not gonna make your apps that consume 1GB+ of memory suddenly consume much less than that, the problem for those apps is the code they run, it's not the language, it's not the platform, it's the badly written code, and Tauri doesn't change that.

i've forked chrome to create something like this (meant for native apps in a multi-process environment) and can confirm.

The multi-process architecture and the chrome platform is already a overkill just for a browser (in my opinion), its much more if for each application you have a browser process + gpu process + several renderers.

If you have only one main process, + 1 gpu and a process for each application running you solve that problem, even more if those process are not running javascript as in my case.

Re: Tauri – Electron alternative written in Rust

#185

Earlier quoted context omitted.

any idea why the memory usage difference on windows are very close but significantly different on linux?

WebView2 is chromium edge. This was the reason that I guessed webkit-gtk uses less ram than chromium.

ah, that makes sense. thanks

Re: Tauri – Electron alternative written in Rust

#186
post #173
post #165

Earlier quoted context omitted.

> but then XMPP got dumped by Google and Facebook.

And virtually everyone else, right? What is open standard used today?

XMPP is still alive (= there is a community maintaining protocol, clients and servers). I am using XMPP exclusively for chat since about one year, pulling in most of my friends. It seems that if users do not demand the usage of Internet Standards like XMPP we will be stuck with corporate walled gardens forever. See also: https://blog.samwhited.com/2019/02/whats-wrong-with-xmpp/

Re: Tauri – Electron alternative written in Rust

#187
What's the advantage of this? There are tons of projects other than Electron, that wrap a browser renderer, like CEF, NW.js etc.

As I understand, the heavy resource use of these apps is due to Chrome, replacing the thin OS shim with something, hardly curbs the resource usage.

Re: Tauri – Electron alternative written in Rust

#188

This is a really horrible project and should be avoided IMO. Not only are the instructions on their website incorrect for building & installation on M1 Macs, you cannot run the app without it crashing on M1. https://github.com/tauri-apps/tauri/issues/2421 https://github.com/tauri-apps/tauri/issues/2934 These things are not a big deal! Bugs happen. I would be more than happy to contribute and try to help fix these thi…

Hi folks, I'm the user from the screenshot above (thanks for sharing this btw). I have to say, this was a quite unpleasant and unwelcoming interaction as my question was genuine and I indeed did do some extensive research before asking this question in Discord. As a devtools founder myself (co-founded www.prisma.io) I highly value welcoming and helpful communities and offered my help to the people behind the Tauri pr…

[deleted]

Re: Tauri – Electron alternative written in Rust

#189

If anyone wants to know how it works: > [leverages] WebKit on macOS, WebView2 on Windows and WebKitGTK on Linux. So cross-platform compatibility isn't guaranteed, unlike Electron. https://github.com/tauri-apps/tauri

Saw a comparison, Electron app size of 138MB Vs Tauri in single digit MB is a big difference though.

Sure, but Neutralino[1] already does this, it's just not Written in Rust™

[1] https://neutralino.js.org/

Re: Tauri – Electron alternative written in Rust

#190

Earlier quoted context omitted.

Sorry but requiring web devs to ignore the last 4~5 years of progress is just unacceptable. Not that that would fix the situation, there are still rendering inconsistencies between browsers when using stuff like margins floats and tables.

Then do as I: develop in Firefox and if it works there (and isn't a PWA where maybe you get in trouble with Safari?) then it works everywhere. Less testing, less bugs. Whats not to like? Contrast to Chrome first developers who often get caught by cross browsers incompatibilities just like they did back in the days when they were IE first developers : )

I do this too, but still run into issues with Safari. Luckily, later Safari 14 versions and Safari 15 are not too bad.
Post reply on HN