32 ms·

Tauri – Electron alternative written in Rust

558 points by WolfOliver 5y ago

deleted 5y ago
[deleted]
forgotmyoldacc 5y ago
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 https://github.com/tauri-apps/tauri
- pjmlp 5y ago
  Yes, the lazy devs path, helping Google to spread Chrome everywhere.
  - YPPH 5y ago
    Does the Chrome engine, embedded within Electron, contain any Chrome features which one could legitimately call into question (such as sync)? If not, what's wrong with it "spread[ing]" everywhere? It's hardly lazy dev work. It's a pragmatic approach to developing cross platform apps quickly. Apps that, it might be added, don't have a horrendous UI, which is common with other frameworks.
    - niyaven 5y ago
      > If not, what's wrong with it "spread[ing]" everywhere? Because then it's a monopoly. I'm taking shortcuts but having a single browser engine controlled by a single company means that you rely on that company to define what is tomorrow's web like.
      - bredren 5y ago
        Without this kind of thing happening at times, we might still be using Flash.
        fabianhjr 5y ago
        Yeah, it had nothing to do with work on open standards like HTML5 and CSS3. (And WebGL for more advanced rendering needs) /s
        kbelder 5y ago
        Electron feels to me a lot like stand-alone flash apps used to feel. I get that same feeling when I open an program using it; kind of a 'oh...' slight disappointment. I get that it makes sense sometimes for a developer to sacrifice performance and size for ease of development... but as a user, it feels like a loss, a sign the developer will be taking too many shortcuts, or that I just won't like their general design philosophy.
  - fabiospampinato 5y ago
    Arguably that's like observing that the same feature works differently in 2+ browsers and blaming web devs for it. It's the job of the browser people to make correct, or at least consistent, platforms. While part of being a web dev unfortunately is also dealing with this you can't necessarily blame web devs when Safari breaks IndexedDB for the nth time, or when after using ES2018 features like regex lookarounds you discover that Safari still hasn't implemented them (which year are we in now, 2022?). You may also discover that mobile and desktop browsers work differently in some aspects, not everybody even has the resources to test every single thing in 3+ desktop browsers (which may require at least 1 VM already if you are not developing on macOS, which I think might even be illegal to run in a non-mac hardware, bizarrely) and 3+ mobile browsers (which may require at least one physical device or a macOS VM for the iPhone, and another physical device or another VM for Android, and all these VMs aren't exactly lightweight). Besides an Electron app doesn't necessarily have to run anywhere else, there's no point in checking compatibility with Gecko when your app never has to run there.
    - pjmlp 5y ago
      Arguably that's like observing that the same feature works differently in 2+ POSIX OSes and blaming devs for it. It's the job of the OS people to make correct, or at least consistent, platforms.
- dmitryminkovsky 5y ago
  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.
  - fabiospampinato 5y ago
    I don't know about that, one data point: an ES2018 feature, regex lookarounds, is still not implemented in Safari. And the JS engine is the thing that's the most compatible across browsers, nowhere near the level of incompatibility of the rendering engine for example.
    - nine_k 5y ago
      Ignore stuff that was added to HTML, CSS, and JS for last 4-5 years. You'll still have a pretty solid? GUI platform, likely more capable and accessible than Qt or GTK or AWT. With the usual compiler / transpiler stack, you'll have a nice, fast-to-market, non-esoteric development environment. All without the need to ship 100MB binaries.
      - fabiospampinato 5y ago
        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.
        nine_k 5y ago
        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.
        fabiospampinato 5y ago
        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.
- silon42 5y ago
  It would be better to use Rust+Servo (no JS, or at least optional) IMO
  - simion314 5y ago
    >(no JS, or at least optional) IMO reply At this point why not focus on some actual GUI toolokit, like write a Qt clone in Rust, for real world apps we don't need all the CSS and HTML crap, you need simple layout, GUI components and an option WebView you can embed in the app if needed. Probably there is no commercial interest to pay professional developers with real experience to implement this.
    - sanxiyn 5y ago
      People are doing that too. https://sixtyfps.io/ https://sixtyfps.io/ is basically a Qt clone in Rust, actually developed by previous Qt developers.
      - detaro 5y ago
        I don't think "basically a Qt clone" is a fair framing, in both directions. (sixtyfps aims to cover things Qt doesn't, Qt does things sixtyfps doesn't and won't for a long time if at all)
    - seumars 5y ago
      I believe the interest is there, it's just not as easy as it seems: https://raphlinus.github.io/rust/druid/2020/09/28/rust-2021.html https://raphlinus.github.io/rust/druid/2020/09/28/rust-2021....
    - jackosdev 5y ago
      egui is a really fantastic Rust GUI toolkit, best I've used in any language
    - MathCodeLove 5y ago
      HTML and CSS, while not perfect, are still the best tools I've found to create a pleasant UI. Other libraries like Qt do work, but it's more difficult to get things looking exactly how you want them to look.
- krapp 5y ago
  "cross-platform compatibility" isn't guaranteed on the web either, yet somehow "cross-platform compatible" websites exist. It isn't a problem that's so difficult it requires wrapping a 60Mb runtime around every individual app instance.
  - kitsunesoba 5y ago
    I’ve always felt that engine inconsistencies in electron-alikes are a bit overblown, particularly now with the old IE-based webview out of the picture (modern Windows uses a Blink-based webview). They’re all capable of the basics, and the greatest inconsistencies will be found in newer features. Stick to a slightly older well supported set of features and you’ll be fine. There are some significant differences between engines when it comes to things like local file access, but that’s what the native component of electron/tauri/etc is there for.
  - awestroke 5y ago
    Everyone is basically using Chrome or Safari nowadays - so WebKit. Very little incompatibilities to consider compared to writing something that works on different WebView implementations
    - ben-schaaf 5y ago
      WebKit and Blink have many significant differences, especially when it comes to supporting newer features. In terms of incompatibilities they're about as different as Gecko is from Blink, if not more so.
      - capableweb 5y ago
        Not sure how familiar you are with the history of browser engines, but Blink and WebKit are definitely more similar than Gecko and Blink. Gecko comes from the heritage of Netscape. Blink comes from the chain of KHTML > WebKit WebCore. They don't share any points, while Blink probably wouldn't have existed without WebKit. But yes, today there are differences between WebKit and Blink.
- brnt 5y ago
  > WebKitGTK Is there something like WebkitQt? Guess it would use WebEngine.
  - fabianhjr 5y ago
    Webkit not WebEngine. ( https://webkitgtk.org/ https://webkitgtk.org/ )
- dmingod666 5y ago
  Saw a comparison, Electron app size of 138MB Vs Tauri in single digit MB is a big difference though.
  - fastball 5y ago
    Sure, but Neutralino[1] already does this, it's just not Written in Rust™ [1] https://neutralino.js.org/ https://neutralino.js.org/
    - cozzyd 5y ago
      Does neutralino run on platforms other than a minimal SUSE? </obligatory physics joke>
- gr__or 5y ago
  I'd argue Babel-ing and polyfill-ing the webcompat delta is wiser than shipping chromium
- favorited 5y ago
  This is a feature. It means every process doesn't have its own copy of Chrome. It might mean more testing for developers, but it's a benefit for users.
- ummonk 5y ago
  And here I was hoping it would use Servo.
  - fault1 5y ago
    Servo is kind of dead, no? I'm not sure anyone is working on it for their day job, at least.
deleted 5y ago
[deleted]
AndrewDucker 5y ago
Lots of their roadmap for 2021 is still undone. Something be to worry about?
- dagurp 5y ago
  The repository seems very active so I wouldn't worry too much
- Hamuko 5y ago
  Probably not worth worrying, but I also wouldn't expect to download Tauri-powered apps anytime soon.
- OJFord 5y ago
  They had a feature-freeze for a security audit, I'd guess that's a big contributor, and also that possibly there's a bunch of unmerged progress as a result.
- capableweb 5y ago
  Is there any company/project that made and published their 2021 in the beginning of the year, and successfully completed all the tasks verbatim in the end of the year? My guess is that the number of companies/project who completed everything is close to 0.
  - mkl 5y ago
    Most organisations would have updated the roadmap when obstacles arose, so it does seem a bit strange.
gspr 5y ago
Aaand still bundling what amounts to an entire web browser just to do what one has always been able do in Qt/GTK/whateverTK. Sad.
- roblabla 5y ago
  It doesn't bundle it though, it uses the one that comes by default on the OS. Which is already a huge improvement, because it should, in theory, be able to share resources across different apps (e.g. the DLL should only be loaded once in physical memory, etc...).
  - gspr 5y ago
    Ah, good point! Thanks for the clarification.
diimdeep 5y ago
Imagine trying to use app built with this in five to ten years that not recently updated or maintained, very scary.
- Xevi 5y ago
  Care to elaborate why that would be more problematic than any other app that hasn't been updated or maintained in that period of time?
  - oscargrouch 5y ago
    Not the op but, giving this rely in whatever is on the host OS, the DLL's on the host OS will evolve changing its interface or even not ship anymore while with applications that rely the bare minimum like electron this is not a issue.
WolfOliver 5y ago
I'm using electron for https://www.monsterwriter.app/ https://www.monsterwriter.app/ and i'm looking for a lightweight alternative since a while. This seems to be a good fit. I guess when you can reduce the api calls to bindings (accessing filesystem, network, etc.) cross platform compatibility should not be a problem.
- WolfOliver 5y ago
  I would be curious if anybody onboarded an Tauri application into the Mac App Store and if it builds for M1?
  - twarge 5y ago
    It cheerfully builds and runs on M1.
    - EugeneOZ 5y ago
      No: https://github.com/tauri-apps/tauri/issues/2421 https://github.com/tauri-apps/tauri/issues/2421 https://github.com/tauri-apps/tauri/issues/3088 https://github.com/tauri-apps/tauri/issues/3088
- jhgb 5y ago
  Have you tried Sciter?
  - WolfOliver 5y ago
    no, but looks like it natively builds for m1 :)
    - c-smile 5y ago
      That's correct. Sciter supports ARM and M1 targets natively: Windows, MacOS and Linux. As also H/W rendering with backends: DirectX, OpenGL, Vulkan(coming) and Metal (coming).
  - 5y ago
giorgioz 5y ago
At https://www.waiterio.com https://www.waiterio.com we use plain webviews for Android, iOS and macOS without any framework and Electron for Windows and Linux. The problem with frameworks is that once a year Apple make a change to their signature and it can break the framework for several weeks/months before a fix/hack around is found. By using native webviews you can quickly implement the change needed and get back online in days.
- WolfOliver 5y ago
  would this work for Windows and Linux too?
  - giorgioz 5y ago
    Vanilla webviews is definitely possible on Windows with Webview2 https://docs.microsoft.com/en-us/microsoft-edge/webview2/ https://docs.microsoft.com/en-us/microsoft-edge/webview2/ The problem though was compatibility since that webview might be based on old versions of Edge which used to be a much more outdated browser than Safari/Chrome. So far in 5 years of using Electron Windows never broke Electron except on a minor instance. Our Windows Electron app doesn't work on Windows 10 S. The problem might have became fixable by now but Windows S had so little marketshare that we never found time to fix that issue.
  - WolfOliver 5y ago
    I mean MacOS, not Windows
    - giorgioz 5y ago
      yes we already had a macOS published on the App Store for 2 years written as a thin Swift app with WKWebView: https://apps.apple.com/us/app/waiterio-restaurant-pos-system/id1191198720 https://apps.apple.com/us/app/waiterio-restaurant-pos-system... https://developer.apple.com/documentation/webkit/wkwebview https://developer.apple.com/documentation/webkit/wkwebview The app store reviewers will allow apps with only webview only if you are offering some feature that would not be possible to implement in the browser alone.
fiatjaf 5y ago
When are we going to get back truly native apps? Flutter Desktop works great, and there are a bunch of nice GUI libraries for Rust, also some new developments for the JRE.
- krapp 5y ago
  Probably never. The web is becoming, if it hasn't already become, the universal platform for application development and distribution, and javascript the One True programming language. Every holdout will eventually and inevitably be assimilated, either transpiled into javascript or compiled into WebAssembly. And it's partly the fault of the native programming community. It should be as easy to write a native, cross-platform application as it is to write html, css and javascript. Native developers should recognize what works about the web paradigm and adapt to it. There should be forks of these technologies specifically designed for native application development rather than documents. But that never happened, GUI development is still basically programming and it still sucks and now the train has left the station. The only relevant innovation likely to happen now will be iterating on the web-app model. I mean, I'm looking at the layout tutorial for Flutter now[0]. It's nesting function calls and you have to update a yaml file to include an image, whereas with HTML it's a simple table or maybe grid and the img tag. This example for Rust[1] is ridiculously verbose and noisy compared to the web stack. All GUI programming is. Meanwhile I can write a fully functioning website with nothing but a text editor. No need to install a language runtime, package manager or IDE, no need to learn a company specific workflow or follow a style guide. No need to memorize a new set of quirky verbs for a CLI. I don't even like the web-app paradigm, but I can totally understand why it won. [0]https://docs.flutter.dev/development/ui/layout/tutorial https://docs.flutter.dev/development/ui/layout/tutorial [1]https://github.com/gabdube/native-windows-gui https://github.com/gabdube/native-windows-gui
  - kaba0 5y ago
    With all due respect, I think the web’s layouting (or lack of) is the most complicated out of any framework I have ever used (including qt, swing, javafx, winforms, wpf). I think the great majority of web devs would have trouble recreating something like bulma (regarding layouting) even without responsiveness — I definitely would have quite a bit of trouble doing that. So if anything, we are just accustomed to the web’s way and other (saner) approaches look stranger for some reason (even though with some insane complexity js frameworks come back and mimic the two decade old frameworks here and there)
Narretz 5y ago
I wonder if the processing / size overhead of Chromium / Node could be reduced by making both more modular? I.e. compiling only the features you need. But I guess Chromium isn't built for that.
deleted 5y ago
[deleted]
IceWreck 5y ago
If someone is looking for the Go alternative, there is Wails. https://wails.io/ https://wails.io/
- makapuf 5y ago
  Nice (linux is coming soon though)
  - IceWreck 5y ago
    Wails works on Linux, has been for years but they decided to delay the Linux version for the latest release for some reason.
- mfollert 5y ago
  > Wails automatically makes your Go methods available to Javascript, so you can call them by name from your frontend! It even generates Typescript versions of the structs used by your Go methods, so you can pass the same data structures between Go and Javascript. That sounds really great!
  - OJFord 5y ago
    That does sound really nice - would love that with Tauri. I've never used Typescript, so at the moment I just have the pain of untyped structures in JS-land (and making sure I get it right passing back in to Rust-land) - but, at least as far as I know, if I did use TS I'd just suffer from manually duplicating data structures instead. (I suppose ultimately I intend to do that, it's just so imperfect anyway that I haven't bothered yet.)
The_rationalist 5y ago
the fact it use Apple internet explorer make it a dead on arrival. One does not needs more than three braincells to understand the the true electron successor will simply have an api that enable a range of allowed chromium versions installed natively. If not found then it will transparently auto install the desired version, at the same time making this version available for other apps.
ReleaseCandidat 5y ago
Is there a comparison somewhere (not the one in the GitHub README) which features of Electron are missing in Tauri?
flohofwoe 5y ago
Here's a similar, older and slightly less hipster project for Go, C, C++ (and more languages via C-API bindings): https://github.com/webview/webview https://github.com/webview/webview ...I wouldn't go as far as calling a simple WebView widget wrapper an "Electron alternative" though.
- dolmen 5y ago
  According to the About page of Tauri, the Tauri team is maintaining the Rust bindings of Webview. Source: https://tauri.studio/en/docs/about/intro#polyglots-not-silos https://tauri.studio/en/docs/about/intro#polyglots-not-silos
- Per_Bothner 5y ago
  For DomTerm (https://bothner.org https://bothner.org) I've used both webview/webview and wry (on Linux only) - and both are usable. The main problem with webview is that it is semi-abandoned (last checkin was in March) and the features set is pretty minimal. Wry is actively developed and has more features. However, the wry-based executable is quite a bit bigger than the webview-based one. And of course leaning to use Rust is an issue.
  - Per_Bothner 5y ago
    Oops: For the record, DomTerm is https://domterm.org https://domterm.org, while bothner.org is (I believe) some unrelated German family. (My personal/family website is bothner.com.)
danuker 5y ago
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.
- pygy_ 5y ago
  Because sometimes you want a desktop app right now and are most productive with Web technologies.
- Icathian 5y ago
  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.
  - danuker 5y ago
    I would distribute a web app as a website, not as an Electron app.
- jaggirs 5y ago
  Because you can use the same code for both interfaces.
- sdeframond 5y ago
  I believe it is because it is easier to find developpers familiar with the Web than with any other cross platform toolkit. Put another way, it is easier for a web developer to get started with electron than to learn a new language.
- ss108 5y ago
  Because some of us have to build things which, for biz/customer reasons, have to be desktop apps, but we, as devs, are more familiar with web technologies/there are more web libs out there.
yayr 5y ago
Is there still an easy way to use node.js with Tauri? I'd appreciate an easy to use cross-platform tool on the backend. Or is it better to build the backend features needed (e.g. file access, config management, network etc.) fully in rust?
- Aeolun 5y ago
  If you do that, wouldn’t it be NW.js?
  - yayr 5y ago
    that seems to use Chromium on the frontend and not the native webviews
fabiospampinato 5y ago
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.
- parhamn 5y ago
  This is a great point. I think last I measured a basic electron browser/webview is about ~20-36mb which is not far from an about:blank chrome tab. The 300mb+ memory usage you see is mostly the javascript from the apps themselves. Either way, I'm glad more people are in the space!
  - c-smile 5y ago
    According to Tauri's documentation (https://github.com/tauri-apps/tauri https://github.com/tauri-apps/tauri) minimal app: Tauri Electron Memory Consumption Linux 180 MB 462 MB Note Tauri is full fledged Client/Server with WebView (client) running in separate process with RPC between UI process and Rust code (Server). For the comparison: Standalone Sciter (scapp.exe, https://github.com/c-smile/sciter-js-sdk/tree/main/bin https://github.com/c-smile/sciter-js-sdk/tree/main/bin) takes ~8 MB of RAM (with minimal Cairo and GDI backends). That's 20 times less than even Tauri. WebView based solutions are not suitable for applets - small portable desktop applications.
    - account-5 5y ago
      I was going to ask how this compared to Scoter, thanks.
- mysterydip 5y ago
  Back in the day people coded lightweight because it wouldn't run otherwise, and speed mattered in single core sub-GHz CPUs. We don't have that same constraint today, how do we get people to write more efficient code?
dgudkov 5y ago
Tauri looks like an alternative to WebView2 + .NET Core.
jokoon 5y ago
I have a hard time understanding why platforms like electron are so popular. The predictions from Gary Bernhardt seem to really be true, in the future everything will be javascript. I wonder if somebody actually tried to make an OS that only has a browser, that's what Chrome OS actually is, after all.
- fastball 5y ago
  We built our product for the web. People wanted our product as a desktop app. So we wrapped it in Electron and now we have 3 desktop apps. People wanted our product as a mobile app. So we wrapped it in Capacitor and now we have two mobile apps. There are just two of us building this product.
  - AtlasBarfed 5y ago
    So efficient for you, but 1000x more resources everywhere it runs. I wonder if someone can quantify the carbon impact of Electron just from Slack.
    - adwn 5y ago
      > So efficient for you, but 1000x more resources everywhere it runs. And yet, to the people who do use their app on the desktop, this is obviously a preferable situation to not using the app – which would probably be the case had the developers decided against Electron.
      - microtonal 5y ago
        And yet, we have single indie developers writing multiplatform Qt [1] and macOS native [2] Slack apps. Last time I checked, Ripcord used 30-40MiB RAM, a small fraction of the official Slack client. Writing native apps (or a Qt app) would well be in reach of Slack. In fact, they already have native apps. E.g. Slack for iOS/iPadOS is native [3], just allowing M1 Mac users to use the iPadOS version would most likely be a large net improvement in resource use for those who'd choose to install the iPadOS version. Unfortunately, they disallow iPadOS installs on macOS to force people to use the terrible Electron version. [1] https://cancel.fm/ripcord/ https://cancel.fm/ripcord/ [2] https://shrugs.app https://shrugs.app [3] https://twitter.com/slackhq/status/931599784137363459?lang=en https://twitter.com/slackhq/status/931599784137363459?lang=e...
rattlesnakedave 5y ago
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/2421 https://github.com/tauri-apps/tauri/issues/2934 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 things. However, when this was mentioned (politely!) to the devs in the discord by a user one was actively hostile in reply: https://imgur.com/a/sHzSaae https://imgur.com/a/sHzSaae This does not seem like a team that cares about its users one bit. I'll take the perf hit (is there one?) and stick to electron. EDIT: After posting this knee jerk comment spawned from a night of frustration using Tauri a couple weeks ago, I think I would like to retract calling it a “horrible project.” It’s technically interesting, and even good (when it works, I hear), but this was easily the worst experience I’ve ever had in FOSS.
- roflc0ptic 5y ago
  “Sorry if I was rude but it was intentional… if you fcking people would read…” I don’t know if this is a reason to embargo a project in its entire (is this person in charge? What do the other devs think of this behavior?), but jeez, that is unpleasant.
  - rattlesnakedave 5y ago
    I agree the one interaction is not enough to embargo the whole project. If it works for you, great! I even find the work they’re doing with rust technically interesting. However, the damn thing just not working AND that interaction (not me in screenshot) really put me over the edge after a night of trying and failing to get my app to build + run.
  - egeozcan 5y ago
    For starters, I'd never introduce a project with such people exposed to the community in my company. We always get paid support when available but humans sometimes don't read and they do ask stupid questions, and such answers can get some people responsible with the choice in big trouble, or at the very least, it forces us to drop it for an alternative. I'd expect them to have some sort of code of conduct and remain compliant to it.
synergy20 5y ago
Last time I checked it's using libwebkit to render html/js/css, which means, on top of my chrome typical daily browser, Tauri brings another browser(memory and CPU) into the system, which nearly doubled my 'browser resource' consumed on the computer, not good.
- dangoor 5y ago
  Tauri uses Wry[1], so it should actually be using the webview that comes with your OS. FWIW, every Electron app includes its own copy of Chromium, so that's even worse from this perspective. [1] https://github.com/tauri-apps/wry https://github.com/tauri-apps/wry (edited to fix that Tauri uses Wry and not Webview)
  - synergy20 5y ago
    I just ran vscode on ubuntu and checked its memory usage, you're correct that vscode brings its own chromium instead of sharing any libraries with my running chrome. Wry said to use 'default web engine', which under Gnome is libwebkitgtk(i.e. webkit engine), that is different from its default browser firefox which uses Gecko as the engine. so Electron and Tauri both will bring their own demanding/heavy cpu/memory needs from their built-in web-engine that shares nothing with your already running heavy browsers. Neither is a light-weight solution.
    - dangoor 5y ago
      Neither is as lightweight as native, but if you've got a collection of apps running against OS webviews vs a collection of apps running against their own Chromiums, it seems like the webview ones would share at least some memory. (It could just be that all you gain is disk space and smaller downloads, which I agree isn't that much of a win)
      - synergy20 5y ago
        When I was playing with Tauri I had to install libwebkitgtk etc for it, since neither firefox nor chrome brings in that dependency. Unless you're using some gtk browser that disk space was not saved by Tauri at all. Anyways other than Tauri is a Rust-flavor, on the resource usage side, it shall not have much difference from using Electron, which uses Nodejs.
polycaster 5y ago
Is "written in Rust" a registered trademark already?
- Emanation 5y ago
  They call it rust, because everything written in it becomes derelict after 180days of its first 3 'written in rust' posts
  - maxbond 5y ago
    Let's put this meme to bed. Tauri has been developed for two years now. People don't just write Rust because it's trendy. If you want to throw stones at Rust, there are many more substantial criticisms to make. Our compilation times are long. Those sweet, ergonomic macro interfaces are only possible because of proc-macro dark magic that tends to be very verbose and special case-y. There's no spec. Unsafe is overused. Et cetera.
    - Fiahil 5y ago
      And where are GATs ? (See also: https://blog.rust-lang.org/2021/08/03/GATs-stabilization-push.html#so-what-are-gats https://blog.rust-lang.org/2021/08/03/GATs-stabilization-pus...)
    - kybernetyk 5y ago
      >People don't just write Rust because it's trendy. [Citation needed]. Because when your unique selling point is "it's like $otherproduct but written in $language" then well ...
      - bocytron 5y ago
        Here's your citation: https://insights.stackoverflow.com/survey/2020#most-loved-dreaded-and-wanted https://insights.stackoverflow.com/survey/2020#most-loved-dr... Rust is #1 loved language, almost 20 points above the second one.
torginus 5y ago
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.
- mtsr 5y ago
  The big difference is this doesn’t run it’s own instance of Chrome, but runs on the OS native browser.
Simplicitas 5y ago
Rust and Electron haters can do all the hating within this one post here.
- sanjayio 5y ago
  What a great idea. I don’t understand the hate for either at all. They’re tools for a job.
- SavantIdiot 5y ago
  Drake turning away: ElectronJS 0.06GB app Drake approving: Any modern game requiring 100GB of content
  - dylan604 5y ago
    The meme is bad, but seeing it as text is even worse.
    - chana_masala 5y ago
      I like it a lot this way actually, haha.
  - mysterydip 5y ago
    I'd love to see some electron apps that use 60MB of RAM. Can you share some examples?
    - steveklabnik 5y ago
      Right now, the various Electron apps I have running: 1Password, 155mb Discord, 441mb Element: 38.7mb Signal: 91mb Slack: 46.2mb A few higher but a couple that are lower...
      - microtonal 5y ago
        How are you measuring this? Slack on my Mac is 325 MiB on disk (probably because it is a universal binary). A freshly-started Slack uses 461MiB RAM for all it's processes (usually getting worse when it has been running for a while).
mmargerum 5y ago
What do you get from this you cannot get from building your app in QT, Flutter, or Lazarus?
- hiccuphippo 5y ago
  Probably the "written in rust" label.
- zem 5y ago
  having a gui toolkit that works with your language, rather than having to change your language to the one the gui toolkit uses.
_8j50 5y ago
Is this similar to wails for golang? Whatever happened to Servo, I was hoping for it to compete with webview
munro 5y ago
I used this a bit, it was really great. Writing a Rust backend & exposing it to TypeScript was really slick! There was one issue I ran into that made me think about jumping to Electron mid project, but I can't remember what it was now, but I think it was something like making my app bleed the entire MacOS window while still being moveable. The other downside is you're going to be tempted to go down the rabbit hole and do everything in Rust. [1] [1] https://github.com/Submersible/sycamore-mac https://github.com/Submersible/sycamore-mac
- outworlder 5y ago
  > The other downside is you're going to be tempted to go down the rabbit hole and do everything in Rust. Downside? :)
- rileyphone 5y ago
  Thanks, I came to this thread to find personal anecdotes about using it but of course it's just hacker news hackernewsing about electron and what have you. I think I'm going to start my project with Tauri+Svelte and see how that feels.
razetime 5y ago
is this what the new Zed editor is planning on using?
scottwitcher83 5y ago
rileyphone 5y ago
For some practical examples: https://tauri.studio/en/showcase/ https://tauri.studio/en/showcase/ In particular I'm looking at https://github.com/kimlimjustin/xplorer https://github.com/kimlimjustin/xplorer
hackerlytest 5y ago
msie 5y ago
I really miss the days where many things were made from scratch like operating systems and compilers. Nowadays it's something built on Linux, Android or Chrome.
bharathlohray 5y ago
Jaffa's word for earthlings?
Mehmetvarta 5y ago
h_mei_ser_22312 5y ago
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.
meltedcapacitor 5y ago
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.

558 points by WolfOliver 5y ago

deleted 5y ago

[deleted]

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 https://github.com/tauri-apps/tauri

pjmlp 5y ago
Yes, the lazy devs path, helping Google to spread Chrome everywhere.
- YPPH 5y ago
  Does the Chrome engine, embedded within Electron, contain any Chrome features which one could legitimately call into question (such as sync)? If not, what's wrong with it "spread[ing]" everywhere? It's hardly lazy dev work. It's a pragmatic approach to developing cross platform apps quickly. Apps that, it might be added, don't have a horrendous UI, which is common with other frameworks.
  - niyaven 5y ago
    > If not, what's wrong with it "spread[ing]" everywhere? Because then it's a monopoly. I'm taking shortcuts but having a single browser engine controlled by a single company means that you rely on that company to define what is tomorrow's web like.
    - bredren 5y ago
      Without this kind of thing happening at times, we might still be using Flash.
      - fabianhjr 5y ago
        Yeah, it had nothing to do with work on open standards like HTML5 and CSS3. (And WebGL for more advanced rendering needs) /s
      - kbelder 5y ago
        Electron feels to me a lot like stand-alone flash apps used to feel. I get that same feeling when I open an program using it; kind of a 'oh...' slight disappointment. I get that it makes sense sometimes for a developer to sacrifice performance and size for ease of development... but as a user, it feels like a loss, a sign the developer will be taking too many shortcuts, or that I just won't like their general design philosophy.
- fabiospampinato 5y ago
  Arguably that's like observing that the same feature works differently in 2+ browsers and blaming web devs for it. It's the job of the browser people to make correct, or at least consistent, platforms. While part of being a web dev unfortunately is also dealing with this you can't necessarily blame web devs when Safari breaks IndexedDB for the nth time, or when after using ES2018 features like regex lookarounds you discover that Safari still hasn't implemented them (which year are we in now, 2022?). You may also discover that mobile and desktop browsers work differently in some aspects, not everybody even has the resources to test every single thing in 3+ desktop browsers (which may require at least 1 VM already if you are not developing on macOS, which I think might even be illegal to run in a non-mac hardware, bizarrely) and 3+ mobile browsers (which may require at least one physical device or a macOS VM for the iPhone, and another physical device or another VM for Android, and all these VMs aren't exactly lightweight). Besides an Electron app doesn't necessarily have to run anywhere else, there's no point in checking compatibility with Gecko when your app never has to run there.
  - pjmlp 5y ago
    Arguably that's like observing that the same feature works differently in 2+ POSIX OSes and blaming devs for it. It's the job of the OS people to make correct, or at least consistent, platforms.
dmitryminkovsky 5y ago
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.
- fabiospampinato 5y ago
  I don't know about that, one data point: an ES2018 feature, regex lookarounds, is still not implemented in Safari. And the JS engine is the thing that's the most compatible across browsers, nowhere near the level of incompatibility of the rendering engine for example.
  - nine_k 5y ago
    Ignore stuff that was added to HTML, CSS, and JS for last 4-5 years. You'll still have a pretty solid? GUI platform, likely more capable and accessible than Qt or GTK or AWT. With the usual compiler / transpiler stack, you'll have a nice, fast-to-market, non-esoteric development environment. All without the need to ship 100MB binaries.
    - fabiospampinato 5y ago
      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.
      - nine_k 5y ago
        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.
        fabiospampinato 5y ago
        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.
silon42 5y ago
It would be better to use Rust+Servo (no JS, or at least optional) IMO
- simion314 5y ago
  >(no JS, or at least optional) IMO reply At this point why not focus on some actual GUI toolokit, like write a Qt clone in Rust, for real world apps we don't need all the CSS and HTML crap, you need simple layout, GUI components and an option WebView you can embed in the app if needed. Probably there is no commercial interest to pay professional developers with real experience to implement this.
  - sanxiyn 5y ago
    People are doing that too. https://sixtyfps.io/ https://sixtyfps.io/ is basically a Qt clone in Rust, actually developed by previous Qt developers.
    - detaro 5y ago
      I don't think "basically a Qt clone" is a fair framing, in both directions. (sixtyfps aims to cover things Qt doesn't, Qt does things sixtyfps doesn't and won't for a long time if at all)
  - seumars 5y ago
    I believe the interest is there, it's just not as easy as it seems: https://raphlinus.github.io/rust/druid/2020/09/28/rust-2021.html https://raphlinus.github.io/rust/druid/2020/09/28/rust-2021....
  - jackosdev 5y ago
    egui is a really fantastic Rust GUI toolkit, best I've used in any language
  - MathCodeLove 5y ago
    HTML and CSS, while not perfect, are still the best tools I've found to create a pleasant UI. Other libraries like Qt do work, but it's more difficult to get things looking exactly how you want them to look.
krapp 5y ago
"cross-platform compatibility" isn't guaranteed on the web either, yet somehow "cross-platform compatible" websites exist. It isn't a problem that's so difficult it requires wrapping a 60Mb runtime around every individual app instance.
- kitsunesoba 5y ago
  I’ve always felt that engine inconsistencies in electron-alikes are a bit overblown, particularly now with the old IE-based webview out of the picture (modern Windows uses a Blink-based webview). They’re all capable of the basics, and the greatest inconsistencies will be found in newer features. Stick to a slightly older well supported set of features and you’ll be fine. There are some significant differences between engines when it comes to things like local file access, but that’s what the native component of electron/tauri/etc is there for.
- awestroke 5y ago
  Everyone is basically using Chrome or Safari nowadays - so WebKit. Very little incompatibilities to consider compared to writing something that works on different WebView implementations
  - ben-schaaf 5y ago
    WebKit and Blink have many significant differences, especially when it comes to supporting newer features. In terms of incompatibilities they're about as different as Gecko is from Blink, if not more so.
    - capableweb 5y ago
      Not sure how familiar you are with the history of browser engines, but Blink and WebKit are definitely more similar than Gecko and Blink. Gecko comes from the heritage of Netscape. Blink comes from the chain of KHTML > WebKit WebCore. They don't share any points, while Blink probably wouldn't have existed without WebKit. But yes, today there are differences between WebKit and Blink.
brnt 5y ago
> WebKitGTK Is there something like WebkitQt? Guess it would use WebEngine.
- fabianhjr 5y ago
  Webkit not WebEngine. ( https://webkitgtk.org/ https://webkitgtk.org/ )
dmingod666 5y ago
Saw a comparison, Electron app size of 138MB Vs Tauri in single digit MB is a big difference though.
- fastball 5y ago
  Sure, but Neutralino[1] already does this, it's just not Written in Rust™ [1] https://neutralino.js.org/ https://neutralino.js.org/
  - cozzyd 5y ago
    Does neutralino run on platforms other than a minimal SUSE? </obligatory physics joke>
gr__or 5y ago
I'd argue Babel-ing and polyfill-ing the webcompat delta is wiser than shipping chromium
favorited 5y ago
This is a feature. It means every process doesn't have its own copy of Chrome. It might mean more testing for developers, but it's a benefit for users.
ummonk 5y ago
And here I was hoping it would use Servo.
- fault1 5y ago
  Servo is kind of dead, no? I'm not sure anyone is working on it for their day job, at least.

deleted 5y ago

[deleted]

AndrewDucker 5y ago

Lots of their roadmap for 2021 is still undone. Something be to worry about?

dagurp 5y ago
The repository seems very active so I wouldn't worry too much
Hamuko 5y ago
Probably not worth worrying, but I also wouldn't expect to download Tauri-powered apps anytime soon.
OJFord 5y ago
They had a feature-freeze for a security audit, I'd guess that's a big contributor, and also that possibly there's a bunch of unmerged progress as a result.
capableweb 5y ago
Is there any company/project that made and published their 2021 in the beginning of the year, and successfully completed all the tasks verbatim in the end of the year? My guess is that the number of companies/project who completed everything is close to 0.
- mkl 5y ago
  Most organisations would have updated the roadmap when obstacles arose, so it does seem a bit strange.

gspr 5y ago

Aaand still bundling what amounts to an entire web browser just to do what one has always been able do in Qt/GTK/whateverTK. Sad.

roblabla 5y ago
It doesn't bundle it though, it uses the one that comes by default on the OS. Which is already a huge improvement, because it should, in theory, be able to share resources across different apps (e.g. the DLL should only be loaded once in physical memory, etc...).
- gspr 5y ago
  Ah, good point! Thanks for the clarification.

diimdeep 5y ago

Imagine trying to use app built with this in five to ten years that not recently updated or maintained, very scary.

Xevi 5y ago
Care to elaborate why that would be more problematic than any other app that hasn't been updated or maintained in that period of time?
- oscargrouch 5y ago
  Not the op but, giving this rely in whatever is on the host OS, the DLL's on the host OS will evolve changing its interface or even not ship anymore while with applications that rely the bare minimum like electron this is not a issue.

WolfOliver 5y ago

I'm using electron for https://www.monsterwriter.app/ https://www.monsterwriter.app/ and i'm looking for a lightweight alternative since a while. This seems to be a good fit. I guess when you can reduce the api calls to bindings (accessing filesystem, network, etc.) cross platform compatibility should not be a problem.

WolfOliver 5y ago
I would be curious if anybody onboarded an Tauri application into the Mac App Store and if it builds for M1?
- twarge 5y ago
  It cheerfully builds and runs on M1.
  - EugeneOZ 5y ago
    No: https://github.com/tauri-apps/tauri/issues/2421 https://github.com/tauri-apps/tauri/issues/2421 https://github.com/tauri-apps/tauri/issues/3088 https://github.com/tauri-apps/tauri/issues/3088
jhgb 5y ago
Have you tried Sciter?
- WolfOliver 5y ago
  no, but looks like it natively builds for m1 :)
  - c-smile 5y ago
    That's correct. Sciter supports ARM and M1 targets natively: Windows, MacOS and Linux. As also H/W rendering with backends: DirectX, OpenGL, Vulkan(coming) and Metal (coming).
- 5y ago

giorgioz 5y ago

At https://www.waiterio.com https://www.waiterio.com we use plain webviews for Android, iOS and macOS without any framework and Electron for Windows and Linux. The problem with frameworks is that once a year Apple make a change to their signature and it can break the framework for several weeks/months before a fix/hack around is found. By using native webviews you can quickly implement the change needed and get back online in days.

WolfOliver 5y ago
would this work for Windows and Linux too?
- giorgioz 5y ago
  Vanilla webviews is definitely possible on Windows with Webview2 https://docs.microsoft.com/en-us/microsoft-edge/webview2/ https://docs.microsoft.com/en-us/microsoft-edge/webview2/ The problem though was compatibility since that webview might be based on old versions of Edge which used to be a much more outdated browser than Safari/Chrome. So far in 5 years of using Electron Windows never broke Electron except on a minor instance. Our Windows Electron app doesn't work on Windows 10 S. The problem might have became fixable by now but Windows S had so little marketshare that we never found time to fix that issue.
- WolfOliver 5y ago
  I mean MacOS, not Windows
  - giorgioz 5y ago
    yes we already had a macOS published on the App Store for 2 years written as a thin Swift app with WKWebView: https://apps.apple.com/us/app/waiterio-restaurant-pos-system/id1191198720 https://apps.apple.com/us/app/waiterio-restaurant-pos-system... https://developer.apple.com/documentation/webkit/wkwebview https://developer.apple.com/documentation/webkit/wkwebview The app store reviewers will allow apps with only webview only if you are offering some feature that would not be possible to implement in the browser alone.

fiatjaf 5y ago

When are we going to get back truly native apps? Flutter Desktop works great, and there are a bunch of nice GUI libraries for Rust, also some new developments for the JRE.

krapp 5y ago
Probably never. The web is becoming, if it hasn't already become, the universal platform for application development and distribution, and javascript the One True programming language. Every holdout will eventually and inevitably be assimilated, either transpiled into javascript or compiled into WebAssembly. And it's partly the fault of the native programming community. It should be as easy to write a native, cross-platform application as it is to write html, css and javascript. Native developers should recognize what works about the web paradigm and adapt to it. There should be forks of these technologies specifically designed for native application development rather than documents. But that never happened, GUI development is still basically programming and it still sucks and now the train has left the station. The only relevant innovation likely to happen now will be iterating on the web-app model. I mean, I'm looking at the layout tutorial for Flutter now[0]. It's nesting function calls and you have to update a yaml file to include an image, whereas with HTML it's a simple table or maybe grid and the img tag. This example for Rust[1] is ridiculously verbose and noisy compared to the web stack. All GUI programming is. Meanwhile I can write a fully functioning website with nothing but a text editor. No need to install a language runtime, package manager or IDE, no need to learn a company specific workflow or follow a style guide. No need to memorize a new set of quirky verbs for a CLI. I don't even like the web-app paradigm, but I can totally understand why it won. [0]https://docs.flutter.dev/development/ui/layout/tutorial https://docs.flutter.dev/development/ui/layout/tutorial [1]https://github.com/gabdube/native-windows-gui https://github.com/gabdube/native-windows-gui
- kaba0 5y ago
  With all due respect, I think the web’s layouting (or lack of) is the most complicated out of any framework I have ever used (including qt, swing, javafx, winforms, wpf). I think the great majority of web devs would have trouble recreating something like bulma (regarding layouting) even without responsiveness — I definitely would have quite a bit of trouble doing that. So if anything, we are just accustomed to the web’s way and other (saner) approaches look stranger for some reason (even though with some insane complexity js frameworks come back and mimic the two decade old frameworks here and there)

Narretz 5y ago

I wonder if the processing / size overhead of Chromium / Node could be reduced by making both more modular? I.e. compiling only the features you need. But I guess Chromium isn't built for that.

deleted 5y ago

[deleted]

IceWreck 5y ago

If someone is looking for the Go alternative, there is Wails. https://wails.io/ https://wails.io/

makapuf 5y ago
Nice (linux is coming soon though)
- IceWreck 5y ago
  Wails works on Linux, has been for years but they decided to delay the Linux version for the latest release for some reason.
mfollert 5y ago
> Wails automatically makes your Go methods available to Javascript, so you can call them by name from your frontend! It even generates Typescript versions of the structs used by your Go methods, so you can pass the same data structures between Go and Javascript. That sounds really great!
- OJFord 5y ago
  That does sound really nice - would love that with Tauri. I've never used Typescript, so at the moment I just have the pain of untyped structures in JS-land (and making sure I get it right passing back in to Rust-land) - but, at least as far as I know, if I did use TS I'd just suffer from manually duplicating data structures instead. (I suppose ultimately I intend to do that, it's just so imperfect anyway that I haven't bothered yet.)

The_rationalist 5y ago

the fact it use Apple internet explorer make it a dead on arrival. One does not needs more than three braincells to understand the the true electron successor will simply have an api that enable a range of allowed chromium versions installed natively. If not found then it will transparently auto install the desired version, at the same time making this version available for other apps.

ReleaseCandidat 5y ago

Is there a comparison somewhere (not the one in the GitHub README) which features of Electron are missing in Tauri?

flohofwoe 5y ago

Here's a similar, older and slightly less hipster project for Go, C, C++ (and more languages via C-API bindings): https://github.com/webview/webview https://github.com/webview/webview ...I wouldn't go as far as calling a simple WebView widget wrapper an "Electron alternative" though.

dolmen 5y ago
According to the About page of Tauri, the Tauri team is maintaining the Rust bindings of Webview. Source: https://tauri.studio/en/docs/about/intro#polyglots-not-silos https://tauri.studio/en/docs/about/intro#polyglots-not-silos
Per_Bothner 5y ago
For DomTerm (https://bothner.org https://bothner.org) I've used both webview/webview and wry (on Linux only) - and both are usable. The main problem with webview is that it is semi-abandoned (last checkin was in March) and the features set is pretty minimal. Wry is actively developed and has more features. However, the wry-based executable is quite a bit bigger than the webview-based one. And of course leaning to use Rust is an issue.
- Per_Bothner 5y ago
  Oops: For the record, DomTerm is https://domterm.org https://domterm.org, while bothner.org is (I believe) some unrelated German family. (My personal/family website is bothner.com.)

danuker 5y ago

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.

pygy_ 5y ago
Because sometimes you want a desktop app right now and are most productive with Web technologies.
Icathian 5y ago
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.
- danuker 5y ago
  I would distribute a web app as a website, not as an Electron app.
jaggirs 5y ago
Because you can use the same code for both interfaces.
sdeframond 5y ago
I believe it is because it is easier to find developpers familiar with the Web than with any other cross platform toolkit. Put another way, it is easier for a web developer to get started with electron than to learn a new language.
ss108 5y ago
Because some of us have to build things which, for biz/customer reasons, have to be desktop apps, but we, as devs, are more familiar with web technologies/there are more web libs out there.

yayr 5y ago

Is there still an easy way to use node.js with Tauri? I'd appreciate an easy to use cross-platform tool on the backend. Or is it better to build the backend features needed (e.g. file access, config management, network etc.) fully in rust?

Aeolun 5y ago
If you do that, wouldn’t it be NW.js?
- yayr 5y ago
  that seems to use Chromium on the frontend and not the native webviews

fabiospampinato 5y ago

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.

parhamn 5y ago
This is a great point. I think last I measured a basic electron browser/webview is about ~20-36mb which is not far from an about:blank chrome tab. The 300mb+ memory usage you see is mostly the javascript from the apps themselves. Either way, I'm glad more people are in the space!
- c-smile 5y ago
  According to Tauri's documentation (https://github.com/tauri-apps/tauri https://github.com/tauri-apps/tauri) minimal app: Tauri Electron Memory Consumption Linux 180 MB 462 MB Note Tauri is full fledged Client/Server with WebView (client) running in separate process with RPC between UI process and Rust code (Server). For the comparison: Standalone Sciter (scapp.exe, https://github.com/c-smile/sciter-js-sdk/tree/main/bin https://github.com/c-smile/sciter-js-sdk/tree/main/bin) takes ~8 MB of RAM (with minimal Cairo and GDI backends). That's 20 times less than even Tauri. WebView based solutions are not suitable for applets - small portable desktop applications.
  - account-5 5y ago
    I was going to ask how this compared to Scoter, thanks.
mysterydip 5y ago
Back in the day people coded lightweight because it wouldn't run otherwise, and speed mattered in single core sub-GHz CPUs. We don't have that same constraint today, how do we get people to write more efficient code?

dgudkov 5y ago

Tauri looks like an alternative to WebView2 + .NET Core.

jokoon 5y ago

I have a hard time understanding why platforms like electron are so popular. The predictions from Gary Bernhardt seem to really be true, in the future everything will be javascript. I wonder if somebody actually tried to make an OS that only has a browser, that's what Chrome OS actually is, after all.

fastball 5y ago
We built our product for the web. People wanted our product as a desktop app. So we wrapped it in Electron and now we have 3 desktop apps. People wanted our product as a mobile app. So we wrapped it in Capacitor and now we have two mobile apps. There are just two of us building this product.
- AtlasBarfed 5y ago
  So efficient for you, but 1000x more resources everywhere it runs. I wonder if someone can quantify the carbon impact of Electron just from Slack.
  - adwn 5y ago
    > So efficient for you, but 1000x more resources everywhere it runs. And yet, to the people who do use their app on the desktop, this is obviously a preferable situation to not using the app – which would probably be the case had the developers decided against Electron.
    - microtonal 5y ago
      And yet, we have single indie developers writing multiplatform Qt [1] and macOS native [2] Slack apps. Last time I checked, Ripcord used 30-40MiB RAM, a small fraction of the official Slack client. Writing native apps (or a Qt app) would well be in reach of Slack. In fact, they already have native apps. E.g. Slack for iOS/iPadOS is native [3], just allowing M1 Mac users to use the iPadOS version would most likely be a large net improvement in resource use for those who'd choose to install the iPadOS version. Unfortunately, they disallow iPadOS installs on macOS to force people to use the terrible Electron version. [1] https://cancel.fm/ripcord/ https://cancel.fm/ripcord/ [2] https://shrugs.app https://shrugs.app [3] https://twitter.com/slackhq/status/931599784137363459?lang=en https://twitter.com/slackhq/status/931599784137363459?lang=e...

rattlesnakedave 5y ago

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/2421 https://github.com/tauri-apps/tauri/issues/2934 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 things. However, when this was mentioned (politely!) to the devs in the discord by a user one was actively hostile in reply: https://imgur.com/a/sHzSaae https://imgur.com/a/sHzSaae This does not seem like a team that cares about its users one bit. I'll take the perf hit (is there one?) and stick to electron. EDIT: After posting this knee jerk comment spawned from a night of frustration using Tauri a couple weeks ago, I think I would like to retract calling it a “horrible project.” It’s technically interesting, and even good (when it works, I hear), but this was easily the worst experience I’ve ever had in FOSS.

roflc0ptic 5y ago
“Sorry if I was rude but it was intentional… if you fcking people would read…” I don’t know if this is a reason to embargo a project in its entire (is this person in charge? What do the other devs think of this behavior?), but jeez, that is unpleasant.
- rattlesnakedave 5y ago
  I agree the one interaction is not enough to embargo the whole project. If it works for you, great! I even find the work they’re doing with rust technically interesting. However, the damn thing just not working AND that interaction (not me in screenshot) really put me over the edge after a night of trying and failing to get my app to build + run.
- egeozcan 5y ago
  For starters, I'd never introduce a project with such people exposed to the community in my company. We always get paid support when available but humans sometimes don't read and they do ask stupid questions, and such answers can get some people responsible with the choice in big trouble, or at the very least, it forces us to drop it for an alternative. I'd expect them to have some sort of code of conduct and remain compliant to it.

synergy20 5y ago

Last time I checked it's using libwebkit to render html/js/css, which means, on top of my chrome typical daily browser, Tauri brings another browser(memory and CPU) into the system, which nearly doubled my 'browser resource' consumed on the computer, not good.

dangoor 5y ago
Tauri uses Wry[1], so it should actually be using the webview that comes with your OS. FWIW, every Electron app includes its own copy of Chromium, so that's even worse from this perspective. [1] https://github.com/tauri-apps/wry https://github.com/tauri-apps/wry (edited to fix that Tauri uses Wry and not Webview)
- synergy20 5y ago
  I just ran vscode on ubuntu and checked its memory usage, you're correct that vscode brings its own chromium instead of sharing any libraries with my running chrome. Wry said to use 'default web engine', which under Gnome is libwebkitgtk(i.e. webkit engine), that is different from its default browser firefox which uses Gecko as the engine. so Electron and Tauri both will bring their own demanding/heavy cpu/memory needs from their built-in web-engine that shares nothing with your already running heavy browsers. Neither is a light-weight solution.
  - dangoor 5y ago
    Neither is as lightweight as native, but if you've got a collection of apps running against OS webviews vs a collection of apps running against their own Chromiums, it seems like the webview ones would share at least some memory. (It could just be that all you gain is disk space and smaller downloads, which I agree isn't that much of a win)
    - synergy20 5y ago
      When I was playing with Tauri I had to install libwebkitgtk etc for it, since neither firefox nor chrome brings in that dependency. Unless you're using some gtk browser that disk space was not saved by Tauri at all. Anyways other than Tauri is a Rust-flavor, on the resource usage side, it shall not have much difference from using Electron, which uses Nodejs.

polycaster 5y ago

Is "written in Rust" a registered trademark already?

Emanation 5y ago
They call it rust, because everything written in it becomes derelict after 180days of its first 3 'written in rust' posts
- maxbond 5y ago
  Let's put this meme to bed. Tauri has been developed for two years now. People don't just write Rust because it's trendy. If you want to throw stones at Rust, there are many more substantial criticisms to make. Our compilation times are long. Those sweet, ergonomic macro interfaces are only possible because of proc-macro dark magic that tends to be very verbose and special case-y. There's no spec. Unsafe is overused. Et cetera.
  - Fiahil 5y ago
    And where are GATs ? (See also: https://blog.rust-lang.org/2021/08/03/GATs-stabilization-push.html#so-what-are-gats https://blog.rust-lang.org/2021/08/03/GATs-stabilization-pus...)
  - kybernetyk 5y ago
    >People don't just write Rust because it's trendy. [Citation needed]. Because when your unique selling point is "it's like $otherproduct but written in $language" then well ...
    - bocytron 5y ago
      Here's your citation: https://insights.stackoverflow.com/survey/2020#most-loved-dreaded-and-wanted https://insights.stackoverflow.com/survey/2020#most-loved-dr... Rust is #1 loved language, almost 20 points above the second one.

torginus 5y ago

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.

mtsr 5y ago
The big difference is this doesn’t run it’s own instance of Chrome, but runs on the OS native browser.

Simplicitas 5y ago

Rust and Electron haters can do all the hating within this one post here.

sanjayio 5y ago
What a great idea. I don’t understand the hate for either at all. They’re tools for a job.
SavantIdiot 5y ago
Drake turning away: ElectronJS 0.06GB app Drake approving: Any modern game requiring 100GB of content
- dylan604 5y ago
  The meme is bad, but seeing it as text is even worse.
  - chana_masala 5y ago
    I like it a lot this way actually, haha.
- mysterydip 5y ago
  I'd love to see some electron apps that use 60MB of RAM. Can you share some examples?
  - steveklabnik 5y ago
    Right now, the various Electron apps I have running: 1Password, 155mb Discord, 441mb Element: 38.7mb Signal: 91mb Slack: 46.2mb A few higher but a couple that are lower...
    - microtonal 5y ago
      How are you measuring this? Slack on my Mac is 325 MiB on disk (probably because it is a universal binary). A freshly-started Slack uses 461MiB RAM for all it's processes (usually getting worse when it has been running for a while).

mmargerum 5y ago

What do you get from this you cannot get from building your app in QT, Flutter, or Lazarus?

hiccuphippo 5y ago
Probably the "written in rust" label.
zem 5y ago
having a gui toolkit that works with your language, rather than having to change your language to the one the gui toolkit uses.

_8j50 5y ago

Is this similar to wails for golang? Whatever happened to Servo, I was hoping for it to compete with webview

munro 5y ago

I used this a bit, it was really great. Writing a Rust backend & exposing it to TypeScript was really slick! There was one issue I ran into that made me think about jumping to Electron mid project, but I can't remember what it was now, but I think it was something like making my app bleed the entire MacOS window while still being moveable. The other downside is you're going to be tempted to go down the rabbit hole and do everything in Rust. [1] [1] https://github.com/Submersible/sycamore-mac https://github.com/Submersible/sycamore-mac

outworlder 5y ago
> The other downside is you're going to be tempted to go down the rabbit hole and do everything in Rust. Downside? :)
rileyphone 5y ago
Thanks, I came to this thread to find personal anecdotes about using it but of course it's just hacker news hackernewsing about electron and what have you. I think I'm going to start my project with Tauri+Svelte and see how that feels.

razetime 5y ago

is this what the new Zed editor is planning on using?

scottwitcher83 5y ago

rileyphone 5y ago

For some practical examples: https://tauri.studio/en/showcase/ https://tauri.studio/en/showcase/ In particular I'm looking at https://github.com/kimlimjustin/xplorer https://github.com/kimlimjustin/xplorer

hackerlytest 5y ago

msie 5y ago

I really miss the days where many things were made from scratch like operating systems and compilers. Nowadays it's something built on Linux, Android or Chrome.

bharathlohray 5y ago

Jaffa's word for earthlings?

Mehmetvarta 5y ago

h_mei_ser_22312 5y ago

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.

meltedcapacitor 5y ago

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.