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

Tauri: An Electron alternative written in Rust

tauri.studio

Post reply on HN
Print view View original

271–280 of 438 posts

Re: Tauri: An Electron alternative written in Rust

#271

Post by qbasic_forever »

gameswithgo wrote: post #195
qbasic_forever wrote: post #139

Earlier quoted context omitted.

We've had about 60 years and multiple huge attempts at it, and IMHO HTML & CSS _are_ the easy to use cross-platform GUI platform. Nothing else stuck--flash, java swing, qt, etc. were all super capable and promising but failed to gain mass usage. HTML & CSS is the way. Nothing in existence has as much capability, developer usage and talent pool, accessibility and internationalization features, etc. A good GUI system i…

I don't think HTML+CSS is the way because of innate goodness of them, but because the web led to so many people being expert at it, and so many tools being built around it, including a cross platform browser or too that are top notch to render it all. At the very least a proper gui library could precompile all of that stuff so you aren't literally parsing HTML and CSS to render things, and HTML And CSS parsers don't…

I don't disagree either to be honest, but the reality is we live in a world where almost every business is dependent on a presence that shows up in web browsers. This puts enormous pressure and real dollars spent on making web browsers and the HTML & CSS ecosystem super fast, accessible, etc. Thousands of developers are trained every day how to make basic HTML & CSS experiences. Any UI system that throws all that away and tries to build up a similar ecosystem from scratch is going to be churning and churning for years.

Don't forget browsers are pretty spectacular runtimes. V8 and its JIT compiler is arguably one of the best runtimes of any language in the world. Sure the very first view of a page is going to do some parsing, etc. but as it runs it gets faster and faster with core functions and components compiled on the fly into platform machine code. The sandbox and security and encryption support in browsers is top notch and supremely battle-tested and hardened. With WASM now pretty mainstream we're starting to see entirely new frontend UIs coded in languages like C++, Go, Rust, etc. that are incredibly fast too. If you squint hard enough the browser is really no different than the JVM or .NET CLR these days--it just has 20 more years or so and an order of magnitude more developers working on improving it.

Re: Tauri: An Electron alternative written in Rust

#272

Post by dfabulich »

CommonGuy wrote: post #226
dfabulich wrote: post #121

Earlier quoted context omitted.

People have been trying the WebView approach for years. (Projects include: Quark, Electrino, DeskGap, Revery, and Neutralino.) Historically, it worked terribly on Windows. On Windows, if you used the OS WebView, your Windows 7 users would be forced to use IE11 to run your app, even if they had a newer/better browser installed locally. On Windows 10, you'd get whatever random version of Edge was installed, or the new…

We use the WebView approach for Kreya[1], though not with Tauri. We had some occassional issues with Chromium/Safari differences, but otherwise it works fine. We use WebView2 on Windows, Safari on macOS and WebKit2GTK on Linux. Not shipping a whole Chromium installation on each install and update reduces the installer and on-disk size a lot! [1] https://kreya.app

https://kreya.app/docs/getting-started

I see issues here!

> Apple Silicon (M1) is not yet supported.

And on Linux,

> you may install Kreya by downloading the tarball. Note that both libgtk-3 and libwebkit2gtk-4.0 dependencies are required. Install them manually if they aren't present on your system.

libwebkit2gtk is, itself, _an embedded browser_, 44MB installed size, plus dependencies.

It's convenient that you can make Snapcraft install it for you, but that's not really different from making Snapcraft install Electron and running that.

Re: Tauri: An Electron alternative written in Rust

#273

Post by Neputys »

eivarv wrote: post #243
yannoninator wrote: post #196

I think the desktop seriously needs a production, RAM and developer friendly breakthrough that isn't Electron. Tauri may be it, but the desktop SO needs this moment, I don't want to see 50 years on and Electron is still being used.

For the GUI-parts (and more) there's always wxWidgets and Qt, at least.

No there isn't (with resigned sobbing tone) there isn't. Everything GUI related on desktop is depressing prehistoric garbage that still takes ages to make and if god forbid you want something nice you might as well shoot your self.

Re: Tauri: An Electron alternative written in Rust

#275

Post by jszymborski »

I just love that they have different "patterns", which truly makes this a flexible platform.

I'm personally a big fan of the "Lockdown" [0] pattern, which avoids spinning up a local server and has a far more conservative security model.

[0] https://tauri.studio/en/docs/usage/patterns/lockdown

Re: Tauri: An Electron alternative written in Rust

#276

Post by c-smile »

In what sense it is an alternative to ElectronJS?

If size than not that much as Tauri is based on Node.JS that is 56 Mb executable by itself.

Yet Node.JS is pure C/C++ code. It is not clear what does "written in Rust" mean at all and what benefits Rust provides in that setup.

For the comparison: my scapp.js.exe ( https://github.com/c-smile/sciter-js-sdk#demos ) that is Sciter.JS packaged as standalone exe without dependencies is of size 5.3mb - at least 10 times less than Node.JS, Tauri and ElectronJS.

That exe includes HTML/CSS, QuickJS (ES2020) engines and essential portions of Node.JS runtime: https://github.com/c-smile/sciter-js-sdk/blob/main/docs/md/m...

So is the question above, alternative in what sense?

Re: Tauri: An Electron alternative written in Rust

#277

Post by cozzyd »

albertzeyer wrote: post #102
the_duke wrote: post #29

Earlier quoted context omitted.

A major benefit of Electron is that you can develop against a single browser and runtime version and don't have to deal with all the small but time consuming compatibility quirks. On Windows the default webview engine is still not the new Chromium but old Edge (WebView2 has to be installed separately), Safari has a fair amount of issues and gtk-webkit can be very quirky as well. This is not so significant if your app…

But why would the system webview be less resource hungry? If it runs in an own process instance, the only memory you safe is (maybe) the executable code (i.e. maybe 100MB max). Or you would need some common runtime which is shared across the OS, and somehow use IPC to it. Then you can potentially save some more memory. But I don't think this exists. And I'm also not sure how much you really would save. The advantage…

100 MB / app is significant, especially on laptops.

Slack used to use so much memory on Linux that I couldn't afford to run the desktop app and ran it inside a Firefox tab for years... seems to have gotten better somehow.

Re: Tauri: An Electron alternative written in Rust

#278

Post by whywhywhywhy »

brundolf wrote: post #12

Looks like it uses system webviews instead of bundling a copy of Chromium? This to me seems like the real headlining feature, but strangely I had to dig pretty deep to find it: https://tauri.studio/en/docs/getting-started/technical-detai... I kind of wonder why it took this long for someone to try this approach. It just makes a whole lot more sense on the surface. Interesting thing I just thought about: since users d…

>I kind of wonder why it took this long for someone to try this approach. It just makes a whole lot more sense on the surface.

The current generation of web developers who grew up within the Chrome ecosystem has zero interest in spending time on cross browser support.

Even if the user had to install 4GB of chrome runtime they'd still argue it's better than them making it work in Chrome, Edge-Chrome and Safari WebKit.

Not saying everyone, maybe my companies hiring process is screwed but every developerbar 1 that I've worked with over the past 4 years has been the same and even getting them to test in one other browser than Chrome is honestly like pulling teeth.

Infuriates me as someone who's first job was CSS+HTML supporting IE 5.5-7.0, Firefox, Opera and Safari.

The amount of times I've heard "Can't we just tell them to use Chrome?" when talking about users is getting absurd.

The lack of understanding that a few hours of their job being slightly more difficult can add up to saving literal lifetimes of time saved or entire data centres of disk space when you extrapolate the savings across your user count. I know its maybe cheap to roll out a Steve Jobs quote but this one still resonates with me.

"Well, let's say you can shave 10 seconds off of the boot time. Multiply that by five million users and thats 50 million seconds, every single day. Over a year, that's probably dozens of lifetimes. So if you make it boot ten seconds faster, you've saved a dozen lives. That's really worth it, don't you think?"

https://www.folklore.org/StoryView.py?story=Saving_Lives.txt

Re: Tauri: An Electron alternative written in Rust

#279

Post by eivarv »

Neputys wrote: post #273
eivarv wrote: post #243

Earlier quoted context omitted.

For the GUI-parts (and more) there's always wxWidgets and Qt, at least.

No there isn't (with resigned sobbing tone) there isn't. Everything GUI related on desktop is depressing prehistoric garbage that still takes ages to make and if god forbid you want something nice you might as well shoot your self.

That's not my experience, at least. I haven't had any major issues I wasn't able to solve with either.

Even if I were more comfortable with web tech when I first started experimenting with this stuff (some time around 2012-2015) I still found the end result much better.

Re: Tauri: An Electron alternative written in Rust

#280

Post by hannofcart »

y2bd wrote: post #223
keskadale wrote: post #178

Question: Why do we need Electron alternatives? Why do we need to develop applications that need a bundled browser to run? Why can't we just use GTK/Qt?

The two main reasons I’ve always heard against QT in particular are 1. Non C++ devs don’t want to write C++/participate in the C++ ecosystem at all. While there are plenty of QT binding libraries for other languages, they seem to be of varying and unpredictable quality. 2. QT has potentially difficult licensing: https://www.qt.io/licensing/ Disclaimer: I’ve never used QT.

Their licensing is written horribly, to just FUD companies into buying their commercial license.

However, the library components offered under LGPL3 are all you need to ship a perfectly good desktop app. The GPL3 licensed stuff listed in the comparison chart on the page you linked are typically the utility applications like Qt Designer which you won't need to ship with your application anyway.

It's unfortunate how the company backing Qt is going about this. But it's a great framework overall.

(At my last firm, we shipped several apps via Qt and it's always been a joy to use.)

Post reply on HN