Is that macOS and Apple Silicon only? In this case indeed it's a no-brainer not to use Electron (why even use it in the first place?). If you ever want to support Intel processors, Linux and its many variants and Windows that will be a different story.
Show HN: I rewrote my Mac Electron app in Rust
391–400 of 465 posts
Re: Show HN: I rewrote my Mac Electron app in Rust
#392Earlier quoted context omitted.
Possibly but not guaranteed. For desktop apps UI quality and rendering speed is paramount. There's a lot of stuff buried inside Chrome that makes graphics fast, for example, deep integration with every operating systems compositing engine, hardware accelerated video playback that is integrated with the rendering engine, optimized font rendering... a lot of stuff. If your Rust UI library is as advanced and well optimi…
Having worked on a graphical application in rust for a (albeit not a complex one) computers today are fast.. latencies top out at 3 ms with cpu based rendering in an application with just a few rendering optimizations. The fact that you just draw on the screen instead of doing whatever html parsing / DOM/IR is probably doing it? And doing rendering on the gpu means extra delay in the processing moving from cpu to gpu…
Can you clarify this? Seems to me that no matter how you render your UI, it has to go to the GPU framebuffer at some point.
For any non-trivial case where I can enable GPU acceleration for an app, it's been anywhere from equivalent to much more responsive.
What apps have you experienced delays with by enabling GPU acceleration?
Re: Show HN: I rewrote my Mac Electron app in Rust
#393Earlier quoted context omitted.
This is akin to saying if you rewrite it in Assembly it would be better than Rust. True, but what are the tradeoffs? Why doesn't everyone write it in assembly? It _would_ be bigger and eat more RAM and CPU. But that does not imply "shittier". There are parameters like dev time, skills available in the market, familiarity, the JS ecosystem etc that sometimes outweigh the disadvantage of being bigger/slower. You're poi…
This is something I think a lot of people miss about Rust - outside of slow compile times and personal preference, there is no reason not to choose Rust over JavaScript/TypeScript (unless of course you're working in the browser). It does everything JavaScript can do, but it does it faster and with more stability. At the end of the day, these features pay out huge dividends. And this isn't Rust zealotry! I think this…
> there is no reason not to choose Rust
Sounds like Rust zealotry to me, followed by a mild attempt to walk it back.
Re: Show HN: I rewrote my Mac Electron app in Rust
#394Beware the greenfield effect. I don’t want to comment on the technology choices specifically here, but in general the whole “we rewrote our app in X and now it’s better” is essentially a fact of life no matter the tech choices, at least for the first big rewrite. First, you’re going to make better technical choices overall. You know much better where the problems lie. Second, you’re rarely going to want to port over…
Yes and no, Rust is suitable to solve a certain set of problems in a certain way. Or you could say: Rust brings certain qualities to the table that may or may not suit your project.
A hacker blog I read regularly made a challenge about the fastest tokenizer in any language. I just had learned basic Rust and decided why the heck not. I spent 15 minutes with a naive/lazy approach and entered the result. It won second place, where the third place was a C implementation and the first place was highly optimized assembler.
This is not nothing and if I had written this in my main language (python) I wouldn't even have made the top 10.
So if you want a language where the result is comparably performant while giving you some confidence in how it is not behaving, Rust is a good choice. But that isn't the only metric. People understanding the language is also important and there other languages shine. Everything is about trade offs.
Re: Show HN: I rewrote my Mac Electron app in Rust
#395Earlier quoted context omitted.
Tauri does not do this in all cases, as WebkitGTK on Linux has performance issues and is often the ugly duckling of everything. I also feel like I will have to, yet again, trot out the comment from a Slack dev that explains why they moved _from_ per-platform webviews to Chromium. This isn't new ground being charted, plenty of companies and teams have been down this path and Electron exists for a reason. (I am not say…
Slack in web works fine in several platform browsers still though.
That's not what the comment was even remotely disputing.
Re: Show HN: I rewrote my Mac Electron app in Rust
#396[flagged]
Re: Show HN: I rewrote my Mac Electron app in Rust
#397Earlier quoted context omitted.
We actually haven't rolled out cross platform support yet with the Tauri version, so we will see how that goes. Our UI needs are simple, luckily. What kind of rendering differences were you seeing with Tauri? Was there one platform that worked the best/worst for your app? We'd love to support Windows next. With the Electron version of the app, we had issues running our bundled binaries on Macs with Intel chip. That c…
> I recently went the other way (started a project in Tauri, moved to Electron) because of frustration with rendering differences between the web views employed on different platforms. This is our #1 frustration with Tauri. The OS-provided system webviews are not stable, repeatable, consistent platforms to build upon. Tauri decided that a key selling point of their platform was that Tauri builds won't bundle a browse…
> Please just let us bundle a modern chrome with our apps.
please, no.
I wish software companies had to pay the hardware they require for their users, then we would have devs using Rust instead of JS and optimizing using ASM just to save parts of cents per instance. And we wouldn't see companies like MS kill well designed and performed native apps for a electron app
Re: Show HN: I rewrote my Mac Electron app in Rust
#398Earlier quoted context omitted.
The promise of Electron is the version of chrome you develop on is the version that ships with your app. If it looks right on your machine, it looks right on whoever is running it. This is much nicer than when doing web development and deciding which browsers/browser versions to test and support. Tauri does not bundle chrome with your app. This makes the bundle size much smaller. But the tradeoff is you end up render…
That does not answer the question. The question is not if Electron feels better for developers because it renders consistently. The question is if that matters. Is it a big issue? Does any user actually care?
I care, for sure. Electron apps have been better than tauri apps so far, from what I’ve used.
Re: Show HN: I rewrote my Mac Electron app in Rust
#399> The trickiest part of the migration was learning Rust. LLMs definitely help, but the Rust/Tauri community just isn’t as mature compared to Electron.
Can you recommend useful resources?
Re: Show HN: I rewrote my Mac Electron app in Rust
#400Earlier quoted context omitted.
Counterpoint: if you rewrite a Rust app, ANY Rust app and turn it into a perfectly rewritten Electron app, it will 100 percent still be shittier, bigger, slower and eat more RAM and CPU.
Possibly but not guaranteed. For desktop apps UI quality and rendering speed is paramount. There's a lot of stuff buried inside Chrome that makes graphics fast, for example, deep integration with every operating systems compositing engine, hardware accelerated video playback that is integrated with the rendering engine, optimized font rendering... a lot of stuff. If your Rust UI library is as advanced and well optimi…
Point of information: I believe this project uses Tauri, which actually does use web technology and even JavaScript for rendering, it just does it with the native web renderer of the platform so you're not dragging around a superfluous extra copy of Chrome in RAM for each and every individual app:
"Write your frontend in JavaScript, application logic in Rust, and integrate deep into the system with Swift and Kotlin."
"Bring your existing web stack to Tauri or start that new dream project. Tauri supports any frontend framework so you don’t need to change your stack."
"By using the OS’s native web renderer, the size of a Tauri app can be little as 600KB."
So you write your frontend with familiar web technology and your backend in Rust, although it's all running in one executable.
I am curious if it would be all that much worse if your backend was also JavaScript, let's say in Node.js, but it certainly depends on what that back end is doing.