I'd rather have development resumed on Carlo. You can re-use the existing Chrome install on a user's device without having to rely on a system-provided WebView.
What if I don't have Chrome installed?
Tauri: An Electron alternative written in Rust
211–220 of 438 posts
Re: Tauri: An Electron alternative written in Rust
#212Earlier quoted context omitted.
you can't buy an M1 mac with more than 16GB of memory so it seems like you have bigger problems
My Mac isn't an M1, but it does only have 16GB of RAM. Yes, it goes into swap when Safari grows like that. It's mostly ok even with several GB of swap used, but can slow down. My solution is to restart Safari when it gets too bad, as it's obviously leaky. For a long time I used Firefox, was annoyed at how slow it would get on a busy browsing day, and didn't realise the memory consumption of Safari (also open) was ove…
I was going to comment this elsewhere, but workstation class problems require workstation class solutions. If 16GB isn't sufficient for your work you should upgrade. Unfortunately Apple has stopped making competitive workstation laptops.
As an example, the new MacBooks are not very competitive (for performance) with the latest XPS series from Dell.
Re: Tauri: An Electron alternative written in Rust
#213Earlier quoted context omitted.
Even basic things like reading and writing files from the filesystem are obnoxiously difficult in a pure browser or PWA environment. Storing state in general is full of enormous pitfalls and eccentricities, like 50mb limits for some browsers or just completely random total deletion of all app state at the browser's whim.
Seems like they are making a lot of progress on that front: https://web.dev/file-system-access/
Fine, but these are proposals. We want something we can work with today, something that we have the power to hack on that will expose new systems we come up with to HTML/JS, and that is the niche that Electron-like systems fill really well.
Re: Tauri: An Electron alternative written in Rust
#214Why doesn't Electron debundle itself into the Runtime vs Application? Much like .Net Runtime. Electron can then be installed in a single spot in the system and all Electron apps pick it up from that spot. You can install bundle the Electron Runtime in the installer (200mb installer is no biggie for a desktop app) but you get all the benefits of consolidating RAM usage across.
It's a simpler experience to just dl the app and install it when it's bundled and less chance of something odd breaking your app for your users. Unbundled you wind up with either a Java situation where you have to get your users to install a particular runtime because you built with a particular one or a MS runtime where every app comes bundled with it's own copy to make sure you have the right one so there's not that big of a savings.
Re: Tauri: An Electron alternative written in Rust
#215I'd rather have development resumed on Carlo. You can re-use the existing Chrome install on a user's device without having to rely on a system-provided WebView.
What if I don't have Chrome installed?
Then Carlo could auto-install it, and it wouldn't have to be a unique installation just for one app.
Re: Tauri: An Electron alternative written in Rust
#216Looks like it uses system webviews instead of bundling a copy of Chromium? This to me seems like the real headlining feature, but strangely I had to dig pretty deep to find it: https://tauri.studio/en/docs/getting-started/technical-detai... I kind of wonder why it took this long for someone to try this approach. It just makes a whole lot more sense on the surface. Interesting thing I just thought about: since users d…
It will, but browser diversity is not what you want for an electron-style app. The whole point of Electron is that it's a browser you control--you set the site permissions, you control the version and updates, you know exactly what it supports. That's what makes longer-lasting, more native experiences possible with a low development cost.
Re: Tauri: An Electron alternative written in Rust
#217Earlier quoted context omitted.
A major benefit of Electron is that you can develop against a single browser and runtime version and don't have to deal with all the small but time consuming compatibility quirks. On Windows the default webview engine is still not the new Chromium but old Edge (WebView2 has to be installed separately), Safari has a fair amount of issues and gtk-webkit can be very quirky as well. This is not so significant if your app…
> don't have to deal with all the small but time consuming compatibility quirks > Webviews are also a moving target so you need a big testing matrix I say this as a front-end web app dev who would most likely be affected by this kind of shift: it might be slightly less convenient, but I wholeheartedly think it's worth doing, on several levels. People built web apps 15 years ago in the dumpster-fire that was web stand…
That's fine for someone who already keeps current with front-end stuff, but someone who is a desktop app developer is more likely to just go native than try to make a desktop app that tracks 3+ browser engines of wildly varying versions (luckily 7 is out of support now, but it still might be desired to support for some desktop apps in which case now you have IE to deal with). Electron gives the promise of total code re-use across platforms which is what makes web technologies more suitable for desktop apps.
Re: Tauri: An Electron alternative written in Rust
#218Earlier quoted context omitted.
> the burden is then on the developer to make sure that they build essentially 3 (maybe more) UI's on platforms that might change under their feet Is this really different from the current state of web development? Front-end developers have to test against Chrome, Firefox, and Safari, at a minimum. For apps that are basically installable websites (like Slack, which has a perfectly functional webapp) this doesn't seem…
> Front-end developers have to test against Chrome, Firefox, and Safari, at a minimum. Do many companies actually do this though? I've only ever been with companies that test against Chrome. The one time at FF bug was found, that company told that client to switch to Chrome. I know there was a kerfuffle about Airbnb and Groupon only doing Chrome as well. https://www.reddit.com/r/AirBnB/comments/dv7v6n/customer_sup...…
In a previous company we had to do FF and Chrome. Not IE though, which was a big time saver. QA ran all their test cases on the latest stable of both FF and Chrome, and features would not be deployed to prod if they didn't work on both browsers.
Re: Tauri: An Electron alternative written in Rust
#219Earlier quoted context omitted.
As a developer shipping executables to MacOS, Windows, and Linux today this is the only assumption I can make. I cannot assume that dependencies exist or are the correct version, I can't assume the user knows that package managers exist or that the dependencies shipped by the package managers are correct, I can't assume anything exists on PATH or LD_LIBRARY_PATH, and I can't even assume that libc or libc++ on a syste…
I understand your point, however I still think it's unacceptable to have 1-1.5 GB of RAM consumed by simply two Electron applications running idle.
[deleted]
Re: Tauri: An Electron alternative written in Rust
#220Earlier quoted context omitted.
I mean, where are they now? Promising or DoA? I fear touching it because of it being a Google project (killedbygoogle.com)
We're pretty bought into Flutter. No cross platform toolkit is perfect but Flutter is miles ahead of everything else. For a not very scientific analysis: https://trends.google.com/trends/explore?date=today%205-y&q=...
It’s definitely not miles ahead of just about anything.
It has significant tradeoffs and fits some projects better than others.
React Native has quite a few benefits over Flutter. Especially if building for the web, I’d actually say Flutter is only usable now if you don’t build your web app with it. Which in my cost benefit analysis makes it miles behind RN, but of course, that’s why it depends.