Live data from Hacker News

Tauri – Electron alternative written in Rust

tauri.studio

411–420 of 435 posts

Re: Tauri – Electron alternative written in Rust

#411
post #258

Earlier quoted context omitted.

> would you rather have three teams developing one app on three platforms (windows, mac, linux) or one team developing one app for all platforms? I would rather have one team developing a cross-platform application in a language that isn't Javascript.

We'd love to. What do you suggest we use? Java swing? C Gtk? C++ Qt? All of those often look ugly and are harder to use.

It's amazing how bad the options for native UI frameworks are, even without considering cross-platform, more so once you do. Android is actually decent but with caveat it only works on Android... Windows had a decent WPF but then they came up with 5 other framworks that got rebranded and now nobody knows what to use anymore. Is WinUI the latest and greatest there? Wouldn't be cross platform anyway.

Perhaps Unity? But that's more tailored for 3d scenes, rather than UI widgets.

Genuinely looking for suggestions on what is the best choice to pick there.

Re: Tauri – Electron alternative written in Rust

#412
Maybe a naive question:

Why not just run a local server (localhost should be secure)? I mean: You create a web app and kind of a backend / some logic anyway.

You could embed all assets and the server into one executable file and distribute it. The user then runs this executable and uses their default system browser.

Re: Tauri – Electron alternative written in Rust

#413

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

I guess but compatibility issues on the web, while they existe, are pretty discrete these days. Browser monoculture is exceedingly worse, both practically and from a business perspective, in my opinion.

It's much bigger than you think.

If I'm building an electron app, it's because I need native code running in nodejs/V8 as native addons, often in the render process, or I'm using bleeding edge APIs not available on Safari.

This type of framework is simply not an option.

Re: Tauri – Electron alternative written in Rust

#414

Earlier quoted context omitted.

I can't believe you seriously just suggested Google is going to abandon Chrome. Next up, Microsoft is going to abandon Word. Also, Facebook is going to abandon Facebook. This is why no one takes these conversations seriously. All vitriol, no substance.

IE still had released, but it stopped moving forward after 6 because there was no longer a good reason for ms to invest. I doubt google would spend much on chrome if no other browser were popular.

But chromium is opensource. Even if google stop devoting to chrome, we can develop it. In fact, I think Mozilla should turn to chromium too like Microsoft, just be aware of keeping the licence open.

Re: Tauri – Electron alternative written in Rust

#415
post #74

Why do people use such a tool? I did not enjoy Electron due to its sluggishness, and I believe that it is a strictly Pareto-inferior solution: * Creating a web app has the same UI performance, but does not require you to download and update. * Creating a native app has the same installation and update requirements, but allows much better UI performance.

I feel you've answered your own question. If you want to make a single app that can be web or offline, and cross-platform, Electron and friends allow you to do that. It's a trade-off of dev effort for user experience, and as much as many devs hate that philosophy it allows many things to exist that otherwise would not be worth the effort.

I would distribute a web app as a website, not as an Electron app.

Re: Tauri – Electron alternative written in Rust

#416
post #400

Earlier quoted context omitted.

Hmm it matters because when everyone basically uses competition, it doesn't matter if a few people use something else

Just because only 17M people live in the Netherlands, does not mean it's OK to block them. Just because people in wheelchairs don't wall, does not mean we don't need to build streets such they can get around too. Just because some people use the Greek script, does not mean ASCII is enough. It's called accessibility, and it's a very good thing.

You are arguing against a straw man

Re: Tauri – Electron alternative written in Rust

#417
post #221

Earlier quoted context omitted.

There’s plenty of weird cruft in Firefox’s ~30 year old codebase that causes bugs and unspecified behavior. For example, Firefox’s ContentEditable code deletes things “backwards” compared to all other browsers and operating systems (bugzilla: https://bugzilla.mozilla.org/show_bug.cgi?id=1735608 ) - this behavior isn’t standardized in any spec, and Firefox is different from other browsers. There are plenty of gotchas…

> There’s plenty of weird cruft in Firefox’s ~30 year old codebase that causes bugs and unspecified behavior. Just wondering where you're getting "30 years" from? That asked, a Chrome-shaped monoculture doesn't help anybody. We need more competing implementations, not less. Anyone feel like collaborating on such?

Netscape was founded in 1994, Firefox is derived from Gecko (1997) layout code code open-sourced from Netscape in 1998. See https://en.m.wikipedia.org/wiki/Gecko_(software) for some background. I was thinking 1994 when I wrote the comment, but it’s closer to ~25 years if you reckon from Gecko’s birth year of 1997.

Re: Tauri – Electron alternative written in Rust

#418
Lot of talk on how it's a bad idea to use web tech for desktop apps because bloat.

Web tech is ultimately an API. APIs don't create bloat, developers do.

What is missing (or unknown) is tooling to avoid bloat.

One could have something like a compiler of sorts that analyses the HTML+CSS+JS of an app to be packaged and generates just enough code to implement what's actually in use. It only needs to implement the semantic (for example no need for a CSS parser in the app if the CSS is not generated on the fly in response to user interaction, it can compile straight to layout code).

Even packaging an existing browsing engine, it should be possible with a bit care (no aggressive use of runtime generated code and the like) to make an advanced dead code remover that recompiles the embedded browser without all the stuff the app being packaged does not use (e.g. no video => no video decoding code, no use of CSS feature XYZ => not compiled in). It could even be brute forced in the presence of an exhaustive test suite: for each function in the embedded browser, replace the body with an exception, run the test suite, remove if it passes, repeat.

This also applies to GTK or Qt which suffer the same problem as electron (must be co-packaged with the distro, or compiled on): with efficient dead code removal you could make AppImages (or similar all-in formats) that are not zillions megabytes each.

Re: Tauri – Electron alternative written in Rust

#419

Earlier quoted context omitted.

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

I’m on the Photoshop team, so cannot speak to AI issues. Have you tried filing a report here? https://community.adobe.com/t5/illustrator/ct-p/ct-illustrat...

I get that it is basically an impossible problem to triage incoming issues on such large and widely used software, but my impression of the popular "community" approach is that it is useless and designed to provide an outlet for complaints rather than to identify issues.

Re: Tauri – Electron alternative written in Rust

#420

Earlier quoted context omitted.

I’m on the Photoshop team, so cannot speak to AI issues. Have you tried filing a report here? https://community.adobe.com/t5/illustrator/ct-p/ct-illustrat...

I get that it is basically an impossible problem to triage incoming issues on such large and widely used software, but my impression of the popular "community" approach is that it is useless and designed to provide an outlet for complaints rather than to identify issues.

On the Photoshop team we have dedicated staff to monitor, triage, and respond to these issues. You’re right in that we cannot address _everything_ that comes in from these boards- the sheer volume is too much. Nevertheless we do use it to identify top customer issues and our dev schedule prioritizations are influenced by them.

To wit: I’m known on the team for sussing out information from corrupted PSDs, and get called on about once a quarter to look into a bad file that’s come in. That wouldn’t happen as frequently without the community site.

Post reply on HN