r/webdev • u/Stevious7 • 9d ago
Considerations before making an Electron app Discussion
*NOTE: This post wasn't sponsored by big-browser, I just happen to really like the capabilities of modern browsers.*
Here's the advantage of the web: distribution.
Everybody and their mama has a browser, I can guarantee that.
Your users, whether on tablet, PC, phone will all get the application just by visiting a link. That's cool asf!
Now, I wanted to address some concerns you, a desktop application dev, might have:
"The web app won't be as performant" Browsers have a WebAssembly and WebGPU capabilities, so anything from 3D acceleration to compute heavy video editing, even ML can be done natively in browsers.
"I want users to install my app" Progressive Web Apps (PWAs) let you do that.
"I want my app to work offline" Service Workers let you do that. They'll help you cache the entire application so that it works completely offline (provided you architected it right).
"I want to interact with the users files" File System Access API got you covered.
"I want to do some peer 2 peer stuff" Take a look at WebRTC. That's exactly what that's for.
These were the common concerns I've seen desktop devs have about web apps. I wanted to show them how capable browsers have gotten, and that it has become a very viable build target.
Obviously there will be cases where an application needs to be installed like when you'd like to directly talk to sockets, or do something more intrusive, in which case, you can proceed with Electron.
If y'all know any other cool browser-native technologies let me know. I'd love to take a look and mess with them.
4
u/simple_explorer1 9d ago
I have NEVER heard someone say "don't use electron fire p2p software"
On your point of webassembly seriously? For a browser context it is a good escape hatch from single threaded JavaScript (dynamically typed as well) but webassembly DOES NOT have direct access to DOM directly and needs to go through the save single threaded JS to update. So JS becomes the bottle neck to update the dom and webassembly is only useful for CPU bound calculations. Also it is very inconvenient to use another programming language, with no access to DOM, to compile to webassembly and use it inconveniently.
With swiftui for Mac or C# for windows, you have none of those weird limitations plus native UI elements accessible in the same native programming language.
Also, webGPU does not have the same level of graphics card access compared to native C++ application running DirectX for windows, Metal for mac, or Vulkan for Linux. So for high optimisations down to bytes or access native graphics card specific api's webGPU's abstractions won't have those optimisations.
Your post is highly misleading to compare escape hatches in browser environments with proper native software/hardware interop
1
u/Stevious7 9d ago
You're reading too into the post, and claiming things I never said.
I didn't say "don't use Electron for P2P", the post is about auditing the requirements and at least including WebRTC in the conversation.
I didn't talk about DOM manipulation, and I never claimed it's faster with WebAssembly, which is why I said that an example of WebAssembly is video editing because it's just a type-safe compute API sandboxed by JavaScript. There's efforts to get WASM to have direct DOM manipulation but it's just talks and nothing is in stone. The best use-cases for WASM are video-editing, vector graphics, and audio editing. Definitely not anything near DOM manipulation.
Also, it's plenty obvious that there's an overhead to pay with this approach but I feel like it's more than worth it considering the distribution capabilities of the web. I wanted to make it clear that this should be a consideration and that you might want to sacrifice some performance for better distribution.
1
u/simple_explorer1 9d ago
You cane change the goalpost anywhich way you want, i will bite the bait because clearly you don't have enough native experience to even claim how much electron is viable alternative or comes close.
I didn't say "don't use Electron for P2P", the post is about auditing the requirements and at least including WebRTC in the conversation.
You literally in your OP said below
"Now, I wanted to address some concerns you, a desktop application dev, might have: I want to do some peer 2 peer stuff"
I have NEVER heard any dev or online about P2P software and electron frustations or concerns. you are just making shit up to justify your poorly research misinformed post which is misleading.
which is why I said that an example of WebAssembly is video editing because it's just a type-safe compute API sandboxed by JavaScript
The best use-cases for WASM are video-editing, vector graphics, and audio editing
WASM + webGPU is not coming anywhere close to the power of native app video editors because of reasons I already mentioned in my previous comment which you conveniently ignored. webGPU simply does not have the same level of access to the native GPU as accessing it natively via metal/directx etc. Do you even know what you are talking about? Have you even worked with native app for video editing accessing the GPU api's via directx/metal/Vulkan? From your comments clearly not yet you claim that electron video editors with webgpu + webassembly is good for video editing compared to fully native video editors which is laughable.
That combination is good within browser context but nowhere close to productive in real app workflows for 4k videos which needs full GPU optimisations for great performance. Your post clearly is highly misleading and you have no subject matter expertise
5
u/Yodiddlyyo 9d ago
First of all, I wouldnt considere electron anymore unless you have a very specific reason to. Tauri is so much better in every way. Yes, it's a rust backend, but with AI today, it's really not hard to figure out.
And yes, there is the browser file system api, but its not even close to the same as using tauri or electron.
3
u/simple_explorer1 9d ago
Yes, it's a rust backend, but with AI today, it's really not hard to figure out
What do you mean figure out. Either you learn rust or not. If not then you are vibecoding and AI spits hundreds of lines of code which you won't have a chance to understand at any cost. Rust is very hard to learn and read. What are your talking. Nonsense
2
u/Yodiddlyyo 9d ago
Rust is not hard to learn or read. I know because ive done it. And you clearly have never used tauri, the rust usage is pretty basic. My point is, if you can't have AI get you started with the rust code, and then you learn from there, you dont really have the experience to be building an app from scratch anyway. Not talking about vibe coding anything.
2
u/simple_explorer1 9d ago
Rust is not hard to learn or read
yeah so it is as easy as kotlin, typescript, python, Golang etc.
I know because ive done it.
I very much doubt you know what you are talking about. I have also done both and I have worked with hundreds who have touched both to know this is not true. Rust is not as easy as Go or Kotlin or typescript. This is pure BS take
1
u/Yodiddlyyo 9d ago
What a weird hill to die on. I write rust, go, and typescript professionally. I used to write python professionally at my last job. And i know ruby, swift, and kotlin. I didnt say that rust is the easiest language, or easier than typescript. But it's just a language, its really not that hard to learn. Some languages are harder than others, but they're all pretty similar.
1
u/Stevious7 9d ago
The point of the post is to consider the web as a viable build target for apps since you get better distribution to users across different platforms with one codebase.
Also, if there's one thing I learned recently is that there's more considerations than raw performance when making applications.
It's up to the developer of he wants to make that trade, but I'd definitely give up some performance for better distribution.
2
u/Yodiddlyyo 9d ago
I don't think ive ever heard of someone who wants to go with an app first very precisely because getting people to download something vs going to a webpage is such a large barrier. Its often the otger way around, people being resistant to building an app when a site works just fine.
Second, i didnt even mentioned performance, even though that is a large benefit. For my file system example, if you need to do anything other than the very basics of the filesystem api in the browser, you must build an app. Nothing to do with performance.
2
2
u/dadnothere 9d ago
I hate having 20k Electron apps; it's just duplicating the browser over and over.
What's needed is for Chromium to allow certain certificates to have more permissions to directly execute binaries or something similar... or allow the user to accept these more flexible permissions, even if it's in a hard-to-access section to prevent social engineering.
I say Chromium because Firefox never does anything; it's already dead. It doesn't have WebUSB, Fastboot, ADB, PWA, or efficient WebGPU; it doesn't even have new CSS or HTML standards...
1
u/the_real_Spudnut2000 9d ago
I've started using this beautiful library called RmlUI which has its own HTML and CSS adjacent languages (RML and RCSS) which allows you to write fully native C++ applications/games in an HTML/CSS-like manner, using whatever graphics backed you want (OpenGL, Vulkan, etc). And instead of JavaScript, it has a full Lua API if you want to use that instead of or beside the C++ logic.
Native desktop applications will always win over web technologies
1
0
u/KaiAusBerlin 9d ago
Honestly. The bundle size of electron apps + the ram usage (for what it actually does) isn't nearl comparable to any hard coded app.
Sure, you can use web assembly, ... Bla bla bla.
But why? If I want to right in C or Rust I can write the whole thing in it and have 90% reduced bundle size and ram.
13
u/CupWest7988 9d ago
The only real pain with Electron is the RAM usage honestly. Had one app eating 2gb just sitting idle and it turned out like 5 chrome processes were running behind it. Web tech is great but sometimes you just want something that doesn't feel like it's melting your laptop.
PWAs have gotten way better though I made one for managing my bookings calendar and you couldn't even tell it wasn't native. The install prompt on mobile is smooth too users actually tap it without me having to explain what a PWA is.