Live data from Hacker News

Tauri: An Electron alternative written in Rust

tauri.studio

241–250 of 438 posts

Re: Tauri: An Electron alternative written in Rust

#241
post #167

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…

What we need is a subset of HTML features that are known to work across all major browser. From Firefox, Safari /WebKit on other MacOS, and Chrome. Or something that compiles to the compatible HTML code for those platform with 100% accuracy. Unless that happens, you are dealing with godzillion number of edge cases in hundreds of different System Browser. But even if such language or subset of feature exist, it will s…

    What we need is a subset of HTML features that are known to work across all major browser. From Firefox, Safari /WebKit on other MacOS, and Chrome.
What, you mean like standards? Web standards?

Re: Tauri: An Electron alternative written in Rust

#242
post #168

Why doesn't Electron debundle itself into the Runtime vs Application? Much like .Net Runtime. Electron can then be installed in a single spot in the system and all Electron apps pick it up from that spot. You can install bundle the Electron Runtime in the installer (200mb installer is no biggie for a desktop app) but you get all the benefits of consolidating RAM usage across.

Well, the .Net runtime isn't exactly the most successful story from an end user perspective, where you occasionally run into weird problems with mismatched runtimes or missing runtimes or similar. Granted, it's not that often, but it feels like a lot of apps relying on it just ship their own copies of the runtime. Still saves resources if multiple apps use the same runtime version, but...

If the installer could do this instead..

Check if the app is supported by an existing runtime, if not download it and make it available globally, otherwise use the current runtime and download only the app

Re: Tauri: An Electron alternative written in Rust

#243

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.

Re: Tauri: An Electron alternative written in Rust

#244
post #16

Earlier quoted context omitted.

As a developer shipping executables to MacOS, Windows, and Linux today this is the only assumption I can make. I cannot assume that dependencies exist or are the correct version, I can't assume the user knows that package managers exist or that the dependencies shipped by the package managers are correct, I can't assume anything exists on PATH or LD_LIBRARY_PATH, and I can't even assume that libc or libc++ on a syste…

Bill Gates, is that you? This was Bill's excuse on why Microsoft does not try to optimize the code for their software. Just make the users buy new hardware for each of our sofware updates. Makes perfect sense. /s

I've never had a customer report performance issues relating to memory usage or a market analysis that suggested we should improve memory size or disk space used in the binaries we ship.

What I have gotten are expensive bills for network bandwidth and cloud platforms when backends are too chunky or download sizes too large.

Which of the two do you suggest we optimize for, the one that costs money and gets complaints, or the thing people argue about on HN and Reddit but mysteriously never materialized in reports?

Re: Tauri: An Electron alternative written in Rust

#246
post #93

Earlier quoted context omitted.

Also: a lot of our "Electron" apps are essentially Electron frontends to the existing web frontend. For example, Slack-the-Electron-app and Slack-the-web-app are fundamentally identical, aside from likely some platform integration features and so on. That means that, likely, a lot of these Electron apps would already work in, for example, a Safari or Edge webview, since the web version has to anyway. I sincerely doub…

Slack originally was platform specific webviews, and migrated to avoid issues like what is mentioned in this thread. One of the engineers who did it has even commented on HN to explain this.

This is probably the comment you're talking about: https://news.ycombinator.com/item?id=18763449. I was unconvinced then, and I am even more unconvinced now as I run a fully native Cocoa Slack client on my Mac that was written by one person reverse engineering APIs.

Re: Tauri: An Electron alternative written in Rust

#247
post #232

Earlier quoted context omitted.

I think they're overstating the browser compatibility problem too. It was really bad 15 years ago, but today it is almost a non-issue. Between significantly improved standardization of web technologies, and new tricks like polyfills, I think it has become pretty uncommon for apps to not just work on multiple browsers without any tinkering.

"almost a non-issue" doesn't sound very convincing to me. As someone who doesn't write GUIs often, I just don't want to have to worry about it at all. What's the cost of electron over webviews? 100mb hdd space? On the other side of the trade, never having to worry about cross platform concerns again? Not having to support or test on multiple platforms? Seems like a no brainer to me. But it's entirely possible, even l…

I really don’t share your point of view, but I understand it, for me feels like we as developers are getting worse and worse with the time, we get every year more powerful machines but our software is getting worse every year, who cares about performance if is cheap to develop, maybe if our apps uses less resources it would have less impact in the environment (less energy consumption is better for everyone, except for the lazy developers).

I really hate electron apps, for example you have teams, that is written in electron, in linux is somehow better than the web version but is just way worse than the windows/mac versions, in web you can view 2 cams, linux 4 but in mac and windows you have more cams at the same time and also a lot of features that are missing in linux, so I don’t see too much the benefits of electron here, just pure laziness of microsoft not willing to invest in a better cross platform app.

Re: Tauri: An Electron alternative written in Rust

#248

Earlier quoted context omitted.

That's fine for someone who already keeps current with front-end stuff, but someone who is a desktop app developer is more likely to just go native than try to make a desktop app that tracks 3+ browser engines of wildly varying versions (luckily 7 is out of support now, but it still might be desired to support for some desktop apps in which case now you have IE to deal with). Electron gives the promise of total code…

> Electron gives the promise of total code re-use across platforms which is what makes web technologies more suitable for desktop apps. I am not sure what the point is of Electron: a shitty-resource hungry app that literally is a wrapped web-app. Instead of writing platform specific apps that leverage the power and capabilities of those platforms, we get a jack of all trades and master of none. Electron is a business…

> I am not sure what the point is of Electron: a shitty-resource hungry app that literally is a wrapped web-app

The point is that its effectively a web app.

> What value does electron add to the user?

They have a desktop app faster than if it was being built natively.

Re: Tauri: An Electron alternative written in Rust

#249

This kind of makes me think... is there room for a much more stripped down version of Chromium that is suitable for lower memory footprint? Or is this impossible? It looks like Tauri uses system webviews, which use a lot less memory, but the burden is then on the developer to make sure that they build essentially 3 (maybe more) UI's on platforms that might change under their feet. That's why the Electron approach is…

Have you seen how Sciter.JS has been developing https://github.com/c-smile/sciter-js-sdk

There are a few working examples, and they have dramatically lower memory footprint and are quicker to start than full fat browsers.

Re: Tauri: An Electron alternative written in Rust

#250
post #163

Earlier quoted context omitted.

tauri does use webview but its moving away from it in favor of a rust native solution called WRY.

Interesting. So according to @baxrob, Tauri took over control of https://github.com/webview/webview project for the past year. And now I'm told they are moving away from it. I'm left wondering why take over a project if they're going to ditch it. For lack of a better term.

We didn't take over control, rather we helped setup an independent org around webview and other related repos. At the time, the original author of webview expressed plans to work on it a lot. However, this didn't really happen. Webview is stuck with some nasty bugs and missing features, and none of the members of the Tauri team had enough C experience to fix it efficiently. Instead, we created our own pure Rust solution (https://github.com/tauri-apps/wry). We've already given it way more features than the original webview project, and it doesn't carry the bugs that plagued webview either. The next release of Tauri (about a month or so out) will use Wry, and will have features such as multi-window and fancy window styling (frameless, fullscreen, custom controls, etc...).
Post reply on HN