[HN Gopher] Tauri vs. Electron - Real world application
___________________________________________________________________
Tauri vs. Electron - Real world application
Author : Levminer
Score : 144 points
Date : 2022-08-22 12:14 UTC (10 hours ago)
(HTM) web link (www.levminer.com)
(TXT) w3m dump (www.levminer.com)
| parker-codes wrote:
| Regarding point #4, I think the clear winner is Tauri. I'll
| clarify --
|
| While writing in Node is great if you don't know Rust, your users
| are being shipped an entire Node runtime, which has size, memory,
| and security issues. So in this case Electron has a "better" DX
| completely at the cost of the user.
|
| Tauri has JS/TS APIs, but if you need to do extensive backend
| work then it requires some learning at the benefit of your users.
| After learning Rust myself, I'd say it's the benefit of the
| developers too, but that's just my opinion. :)
| hasperdi wrote:
| You're implying that application written in Rust would not have
| no size, memory and security issues. That is of course not
| true.
| maleldil wrote:
| Do you think it's unreasonable to assume that an app written
| in Rust will be smaller, use less memory and be safer than a
| similar app written in JavaScript?
| noselasd wrote:
| The UI part of the app with its HTML/CSS/Javascript is
| normally the most the memory hungry part - there won't be a
| huge difference there between tauri and electron.
| UncleEntity wrote:
| I think it's safe to assume that of anything written in
| something which doesn't bundle an entire browser.
|
| Though I do think it's unrealistic that the legions of
| JavaScript devs are going to learn rust to make simple
| desktop apps because it doesn't really have a reputation of
| being an easy language to learn.
| moffkalast wrote:
| > Do you think it's unreasonable to assume that an app
| written _BY ME_ in Rust will be smaller, use less memory
| and be safer than a similar app written in JavaScript?
|
| No, it won't be. You gotta weigh years if not decades of
| Node/JS experience vs 0 years of Rust experience of the
| average dev. Development time will be far shorter too.
| pkulak wrote:
| > And if your user has the correct runtime for the webview used
| by Tauri you can just send them a single executable
|
| So does this mean all these comparisons are between a web bundle
| that runs on an existing VM, and a web bundledthat came packaged
| with a VM? Because I thought the whole point of Electron was that
| all the dependencies came packaged together, even if that adds
| 100 megs to the install.
| chippers wrote:
| disclaimer: contributor to Tauri
|
| This ends up often being my main contention with Rust, when
| making useful programs it often leads to large compile times
| mostly due to the linker. The mold linker can help greatly, but
| it's still not a great developer experience. Something I want
| to create in the future is a fully compiled Tauri application
| except it takes the webview sources at runtime, allowing a
| fast-as-possible development reload as long as you are only
| touching the frontend application and not the Rust side. On the
| Rust side there are a few options, one of them being developing
| something like WASM plugins on the backend where their
| individual dependencies are much less than a full application.
| esprehn wrote:
| Yup. Tauri is more like Ionic or Cordova than Electron. You get
| a mostly web based developer experience, but without the
| browser matrix simplification so you're still at the whim of
| the system WebView capabilities for the view layer.
|
| The good news is the built in webviews have come a long way
| since webcompat is much better across browsers, but it's still
| extra things to worry about and can produce problems on old
| MacOS or Windows pre-11.
|
| See also:
|
| https://tauri.app/v1/guides/architecture/process-model
|
| https://tauri.app/v1/api/js/
| typon wrote:
| Calling this a "real world application" is a big stretch
| imo...Javascript's problems really come to the forefront when
| implementing complex logic in the backend - Rust's excellent type
| system helps a lot with that.
|
| However, if you have an app that has a lot of interactivity,
| using the web_sys API is a huge pain that basically caused me to
| end development on my side project. Working with DOM APIs in
| Javascript is so much easier than working with them in Rust.
| orthecreedence wrote:
| I'm in a sweet spot for something like Tauri: I have an app
| that does a lot of cryptography and dealing with binary data in
| browserland is horrible. Embedding rust and leaning on it for
| the business logic and crypto stuff while _only_ relegating the
| UI to html /javascript has been a huge success for me.
|
| I think the rust frontend ecosystem has a long way to go before
| it can really compete with javascript and the many existing
| frontend frameworks.
| Dr_ReD wrote:
| As I see it, the difference between the Tauri approach and
| Electron becomes visible when you have multiple apps running.
|
| Each Electron app will load its own browser back-end in RAM,
| while all tauri apps will share the same runtime on disk and _in
| RAM_.
|
| This makes for quite a big difference as the number of running
| apps grows.
| bobblywobbles wrote:
| > #6 - Security "Tauri is very secure by default, on the other
| hand I can't say the same about Electron... With Electron you
| have full access to Node APIs, so a hacker could easily exploit
| the very powerful Node APIs."
|
| It's fair to believe this, given there's so much material out on
| the web affirming the fact. I've written about this at length in
| other places; applications with Electron pre version 5 [0]
| (released April 2019) were not secure. It's entirely possible and
| easy to build a secure Electron app today. I started building a
| secure app Electron template in 2020 [1] (that I still maintain)
| to address this security issue. I've also written about a history
| of the framework [2] and steps to build your own Electron app
| with today's best practices [3].
|
| [0] - https://github.com/electron/electron/releases/tag/v5.0.0
| [1] - https://github.com/reZach/secure-electron-template [2] -
| https://www.debugandrelease.com/the-ultimate-electron-guide/ [3]
| - https://www.debugandrelease.com/creating-a-simple-electron-a...
| frutiger wrote:
| This is a weird claim anyway.
|
| If you're loading first-party content into the view, then it's
| no less secure than running, e.g. a Node.js script (or Python,
| Ruby, C++ program, Rust program, etc.) as the current user. A
| program you downloaded being able to do things it's supposed to
| do is generally a feature, not a bug.
|
| If you are loading third-party content, then sure, it's a
| completely different ball game.
| atwood22 wrote:
| It's _possible_ to build a secure Electron app, but it's also
| very easy to build an insecure Electron app. Even if you follow
| best practices regarding context isolation, it's very easy to
| introduce a subtle security issue like
| contextBridge.exposeInMainWorld('myAPI', { send:
| ipcRenderer.send })
| chimen wrote:
| Flutter desktop? Anyone tried it?
| gbro3n wrote:
| Flutter is really compelling, would love to be given a project
| using it based on what I've seen of the environment and
| tooling. Dart is nice too. In my recent evaluation though I
| decided to go with PWAs unless I really need native only APIs.
| Modern web APIs are decreasing the argument for native.
| lobstrosity420 wrote:
| There is also Ionic if you need an extra push on what the Web
| APIs can do.
| orthecreedence wrote:
| I've evaluated both Tauri and Flutter + flutter_rust_bridge.
|
| I immediately felt really productive in Tauri/Svelte/rust. It
| just kind of clicked with me (completely new to Svelte, but
| been doing SPAs and JS desktop apps for some time as well as
| being in the rust scene for years). It was like the ease of
| electron, but with a better build framework for bundling rust.
| Really a good setup, easy to get into, easy and fast to build
| in.
|
| I think Flutter is a really great UI framework. The way it's
| set up really makes sense and makes it fairly easy to structure
| the UI. That said, I really do not like Dart _at all_. I found
| it difficult to learn a new language _and_ a new UI framework
| at the same time, and found myself pining for HTML /javascript
| again. flutter_rust_bridge obviously alleviated this a bit
| because it made it possible to move most of the logic into
| rust. I am honestly also worried about Flutter being a Google
| project. They tend to abandon projects quite a bit. I do like
| the promises of Flutter and didn't actually have any material
| issues with it. I think I might give it another go on the next
| app I build and see if I can get over the Dart hump.
| PhantomBKB wrote:
| Yes, it's excellent.
| mojzu wrote:
| I did a short evaluation a while back (while support for
| desktop/web was still in beta so much has probably changed),
| ended up going the PWA route. Developer experience was
| fantastic, code completion/debugging/documentation/compiling
| were all great and smooth experiences, Dart was easy to pick up
| quickly although some of the code generation stuff such as
| serialisation/deserialisation was a bit clunky. However the
| deciding factor at the time was that the end result felt very
| much like a mobile app forced into a desktop environment,
| things that users expected to have like copy+paste weren't
| there, keyboard shortcuts that users took for granted were a
| hassle to reimplement, the scrolling felt 'off' in a desktop
| environment and performance wise it could feel stuttery quite
| often.
|
| I quite like the fundamental ideas behind Flutter (a
| lightweight GUI runtime that can produce consistent results
| across many platforms) so hoping these are already or on their
| way to being ironed out
| davej wrote:
| A missing point of comparison is that Electron also has far more
| desktop APIs available. Electron also has support for some
| advanced primitives like BrowserViews which enable some very
| sophisticated use cases.
| Levminer wrote:
| Comparing Electron and Tauri - With a real world app
| hs86 wrote:
| Those RAM usage comparisons should consider the shared memory
| among those processes. Aren't those renderer and zygote processes
| forks of each other?
|
| I don't think that tools like htop or Process Explorer give us an
| easy at-a-glance answer to how much RAM multi-process browsers or
| Electron apps need. My current approach is to monitor the
| currently free RAM while at the same time closing the entire
| application. That delta at that moment is a more accurate
| representation of the app's memory consumption than summing up
| RSS values or working sets.
| jtolmar wrote:
| The page is doing something strange on scroll, it's almost
| unbearable on Firefox mobile
| yajjackson wrote:
| I noticed the same, could not figure out the cause.
| Levminer wrote:
| Thanks for pointing it out, I fixed it. I was using background-
| blur in CSS, Firefox mobile didn't like it I guess.
| [deleted]
| jupp0r wrote:
| "The app is compiled to a binary, which means you have to be an
| expert at reverse engineering to be able to de-compile the app."
|
| It just means that nobody has written automated tooling to do
| this. The procedure is super easy and the implication that there
| is any security benefit to the way Tauri bundling works is
| fundamentally flawed.
| intelVISA wrote:
| To be fair it's hard to understand what a "jump not equal" does
| if the numbers on FizzBuzz are accurate.
| piratey wrote:
| Using Tauri for my most recent project, I have to say the
| Development experience was phenomenal.
|
| Only downside that the article rightly points out us the
| knowledge of Rust, which was new to me.
|
| Also Tauri has Android & iOS targets on its roadmap too.
| MuffinFlavored wrote:
| What were your first impressions of Rust?
| thegeekpirate wrote:
| There's also https://wails.io, which uses Go instead of Rust.
| vindarel wrote:
| and https://neutralino.js.org/
|
| Their exciting part is
|
| > You can extend Neutralinojs with any programming language
| (via extensions IPC) and use Neutralinojs as a part of any
| source file (via child processes IPC).
|
| still:
|
| > Neutralinojs doesn't bundle Chromium and uses the existing
| web browser library in the operating system (Eg: gtk-webkit2 on
| Linux). Neutralinojs implements a WebSocket connection for
| native operations and embeds a static web server to serve the
| web content.
|
| Comparison with Electron, Tauri and more:
| https://github.com/Elanis/web-to-desktop-framework-compariso...
| cheriot wrote:
| > You have to rewrite your app's backend in Rust
|
| Tauri has "Other Bindings" on the roadmap, but, for now, this
| requirement is big limitation. imo, the article should have lead
| with that instead of burying it at #4.
| sysop073 wrote:
| It's only a limitation if your app is currently written in
| Javascript, which seems like a silly assumption. If your app is
| currently written in Rust, Electron has the equally big
| downside of "you have to rewrite your app's backend in
| Javascript"
| cheriot wrote:
| My impression is that Electron can wrap whatever backend you
| want to use. Is that not the case?
| orthecreedence wrote:
| I've embedded a rust logic core into electron, so yes,
| anything that can expose a C API can be loaded into
| electron.
|
| That said, after playing around with Tauri a bit I have to
| say it makes it magnitudes easier to embed rust. So if your
| target is rust, it's a much nicer option.
| moffkalast wrote:
| Tauri supports all languages, as long as they're Rust.
| leodriesch wrote:
| You could spawn any local server from Node and talk to it
| from the web side.
| api wrote:
| One thing I don't see mentioned is the horror of shipping for
| Windows. You'll need Windows to have the Edge runtime, which
| means you have to bundle it or install it as an add-on. People
| will complain about this, especially IT people, because Edge
| runtime runs some kind of stupid background service all the time
| for no clear reason. It's also brittle since you will have to
| constantly keep your installer up to date with new releases of
| the Edge runtime or use a fragile MS URL that could stop working
| at any time and that won't work behind some firewalls.
|
| TL;DR: trying to use the native web view on Windows is horrible
| because there is no native web view and MS can't bundle software
| for their own platform.
|
| Of course I suppose shipping any software for Windows is
| horrible...
| Levminer wrote:
| You are a little behind. Edge webview is included in Windows 11
| by default. On Windows 10 the installer downloads it
| automatically. You don't have to do anything.
| api wrote:
| Does it work on Windows 10 Enterprise running Crowdstrike in
| the EU during a full moon on an odd numbered day while it's
| raining?
|
| Being sarcastic of course, but... hey maybe I'll take another
| look.
| dfabulich wrote:
| Tauri has options to take care of that.
|
| Microsoft's WebView2 has three distribution options: the
| "evergreen bootstrapper," the "evengreen standalone installer,"
| and "fixed version" (where you embed a browser version in your
| installer).
|
| https://developer.microsoft.com/en-us/microsoft-edge/webview...
|
| Tauri supports all three of those mechanisms. If you choose to
| embed the browser directly in your installer, it adds 100MB+ to
| your installer size, but it's guaranteed to work anywhere.
| (They even support Windows 7.)
|
| https://tauri.app/v1/guides/building/windows#webview2-instal...
| easton wrote:
| It doesn't help for most corporate environments (at least, not
| yet), but Windows 11 ships with the Edge WebView2 Runtime. They
| are "evaluating" shipping it via Windows Update to Windows 10
| machines that are domain-joined:
| https://blogs.windows.com/msedgedev/2022/06/27/delivering-th...
| jupp0r wrote:
| "With Electron you have full access to Node APIs, so a hacker
| could easily exploit the very powerful Node APIs."
|
| This is not true, `nodeIntegration` has been disabled by default
| years ago in Electron 5.0 [1]. The default in Electron 20 will be
| a sandboxed renderer process that can't even read files from disk
| [2]. Security in Electron is great if you follow their security
| guidelines [3].
|
| [1] https://www.electronjs.org/docs/latest/breaking-
| changes#plan...
|
| [2] https://www.electronjs.org/docs/latest/breaking-
| changes#plan...
|
| [3] https://www.electronjs.org/docs/latest/tutorial/security
| vivekin wrote:
| I have been using Tauri to develop a Kubernetes IDE:
| https://github.com/nirops/yakiapp
|
| One additional thing from my experience, is if using Rust as a
| backend, the turnaround time for hot loading Rust changes is not
| trivial. This leads to longer times in building things vis-a-vis
| building in Electron with .ts/.js backend.
| Levminer wrote:
| Yes, good point you need a very good processor for instant hot
| reload.
| saidinesh5 wrote:
| Mold linker cut down a lot of the build time when we were
| writing a tauri app, but the build times were still .. not my
| favorite.
| orthecreedence wrote:
| I know there's probably docs somewhere, but what was the
| process to integrate mold into your build chain? Is it
| involved or fairly easy? I just heard of this for the first
| time and wondering if it could be useful to cut down build
| times in all my rust libs/apps...
|
| EDIT: found this: https://www.reddit.com/r/rust/comments/rhcn
| zt/mold_a_modern_...
| keraf wrote:
| The 5th point in this article is what makes me end up using
| Electron most of the time.
|
| As much as I love Tauri (and Wails), WebView requires to make
| sure the application renders exactly the same across all
| platforms. Sure, Electron comes with its downsides like the
| article rightfully points out. But having a UI that renders and
| behaves exactly the same on all platforms (thanks to the version
| locked Chromium bundled in the app) is really nice to have.
|
| I wish there would be the possibility to bundle a renderer (maybe
| a more lightweight one?) with Tauri or Wails instead of using
| WebView.
| BiteCode_dev wrote:
| If you only provide a desktop app yes.
|
| If you also provide a web app, then the work needs to be done
| anyway.
| pornel wrote:
| Is that _really_ such a big deal?
|
| Browser engines these days aren't so bad, especially if all you
| need from them is basic CSS for the UI. You still have a fully-
| fledged native language underneath it, so you're not limited to
| what Web APIs can do.
| jahewson wrote:
| There is no such thing as "basic CSS". Of all things it's the
| most wildly moving target I've ever encountered.
| pornel wrote:
| CSS evolves and there's always some new funky selector or
| effect coming, but the whole point is that you don't need
| to follow this year's latest hotness. If you slap rounded
| corners and box-shadow (very old by now) you have 90% of
| what Apple calls design lately. For Windows "metro" you
| don't even need rounded corners :)
| cageface wrote:
| I recently chose Electron over Tauri for the same reasons.
| Tauri would be a better fit for my app in some respects but
| it's a music player and Safari doesn't support all the audio
| formats I care about.
|
| https://github.com/milesegan/minimoon
| kitsunesoba wrote:
| The downside of that control though is an application that's
| arguably a little too specifically targeted -- it's
| understandable wanting to target the same engine but if your
| app breaks with different but reasonably recent versions of
| chromium I would say it's too brittle.
|
| It also widens attack vectors considerably when your entire
| userbase is all on the same probably-outdated build of
| electron-bundled chromium.
| Klonoar wrote:
| System webviews on macOS aren't updated after a certain
| point, so Tauri is not necessarily always a win re: your
| final point.
| WorldMaker wrote:
| But that's an Apple problem, not a "you" problem in that
| case. In Electron the security burden for tracking Chromium
| CVEs and sending updates out is entirely yours, whereas
| with Tauri you outsource it. In Electron, Chromium CVEs are
| your CVEs. In Tauri, Safari CVEs remain Apple's CVEs and
| technically entirely outside the scope of your application
| bundle. The trade-off for "old macOS webviews" is that it's
| _not your problem_ other than general, basic old pre-
| Chromium hegemony HTML kindness of building web apps that
| gracefully fail if features aren 't available, which is
| probably what you should do anyway?
| eropple wrote:
| Your users don't care whose fault it is. _Your_ app isn
| 't working. You can choose to cut those users off, and
| that's totally an option...sometimes.
|
| Mac users are probably a little more tolerant of this
| than non-Mac users, because of the general upgrade
| treadmill, but whether you can get away with it is a
| question only you can answer for your app.
| WorldMaker wrote:
| That's still a very different class of problem from a CVE
| break of a single-point-of-failure is the point. Someone
| decides to use your Electron app's old Chromium build and
| a known CVE in it as a target vector for infecting or
| remote controlling user's machines is a _very_ different
| problem from "because we are using system webviews this
| small CSS/JS feature doesn't work in this version of
| macOS, please upgrade". Even if the user rightfully
| blames you the app developer for both issues and doesn't
| allow you to point fingers upstream, one is a severe
| security threat that can destroy entire brands and the
| other is "mere tarnish" on a brand. (I know which class
| of problem I'd rather deal with, given the choice here.)
| jyap wrote:
| Just a correction to OP since I noticed it twice.
|
| Used of "exited" (to exit) when you mean "excited" (to be
| excited).
___________________________________________________________________
(page generated 2022-08-22 23:01 UTC)