Electron being bad is a bit of a junior- to mid-level engineer tell in my eyes, the sort of thing you'd say if you've just learned that some apps use more RAM than others, maybe built a small Rust TUI and are now wondering why not everything is using Rust. Something you'd believe just before you learn what engineering trade-offs are.
So, yeah, enjoy rebuilding complete browsers, I guess? I'm sure they'll run more efficiently than the rendering engines that have been refined and tweaked over the course of now multiple decades.
Well, unless you leave out the annoying stuff, like a11y, IME, RTL, but who needs those things anyway, am I right.
Then you find out that iterating on a fully Rust-based app is sloooow, so you add a scripting layer, maybe integrate a little Lua VM or something that lets you execute JavaScript?
Congratulations. You've built a browser, just with fewer features, more bugs, and probably higher RAM usage. Good job.
Electron is bad, just because Rust is not a good language for building UIs doesn't make electron not bad. People that pick electron (and Rust / gpui) just completely ignore the entire host of other options that are available (I suspect because they want to avoid thinking).
I'm working on Slint. It is a declarative UI language that compiles to native code, the application logic can be written in Rust, C++, TS or Python, and it is cross platform, including mobile. Has accessibility through AccessKit. A live preview, so iterating on the UI doesn't mean recompiling Rust.
Compared to Electron, there is no browser, so binaries are a much smaller, use less memory, startup is fast. And the attack surface is also much smaller (no XSS)
Could you please explain why? In the context of a PC application. What OS-specific features do you think should be included (keyboard shortcuts?) that can't be copmile-time feature-gated by OS? I would guess the vast majority of functionality is not OS-specific, between Windows, Linux, and Mac.
> is a bit of a junior- to mid-level engineer tell in my eyes
There is absolutely no reason for Discord—a chat application—to run everything a browser does. Why do I need to play videos in the chat application? Why do individual avatars and even tags have to run custom shaders? It's called scope creep.
> a11y, IME, RTL
All of this can be done at the platform level. Win32 did this three decades ago. Comes with entire language packs.
> so you add a scripting layer, maybe integrate a little Lua VM or something that lets you execute JavaScript
See above: scope creep; features for features' sake.
> There is absolutely no reason for Discord—a chat application—to run everything a browser does
Chat apps are literally the central example of why Electron is a God-sent. Here's a video from a Rust guy explaining why there are quite a bit of reasons to do it https://www.youtube.com/watch?v=hnaGZHe8wws .
You don't need a full browser-engine just to render some text with images. The majority of the web api sprawl browsers implement is just baggage for that.
I remember thinking that about "why do i need to display images inline?", back when that idea was pretty novel.
Now i consider that a must have.
Similar for emojis...
It turns out a chat app is about human interaction, not exchanging text, and in human interaction context is a big deal. All these things add context to the chat environment.
Fortunately IRC still works, and you can go enjoy your text only environment if you want!
> Then you find out that iterating on a fully Rust-based app is sloooow
Maybe not anymore. I don't work on any Chrome-sized Rust codebases so I don't know, but iterating on anything is so much faster that it might work out fine.
Eh, it’s still pretty annoying. I have a small voice chat app, and it easily takes a couple of minutes to build releases for all three platforms (MacOS, Linux, Windows) on a MBP.
Could you please link to some GUI applications you've built in rust, and/or describe why you added those abstractions and built a browser? This doesn't match my experience.
What you posted doesn't match my experience, so I curious how you arrived at the conclusion that building a GUI application is like building a web browser, and why the abstraction layers you described are necessary as a baseline. I am asking you to post links to the rust GUI applications you've built where you ran into this.
> so I curious how you arrived at the conclusion that building a GUI application is like building a web browser
The way you phrased it, it's not. However if you've used Discord, you know that to render it you're essentially rebuilding a web browser due to the sheer variety of formatting, images, animation, audio, videos, languages, widgets, and whatnot that must all coexist in arbitrary forms in every server/room/forum.
It is perfectly possible to write an application and not need any web technology whatsoever. This sounds like a perfectly reasonable rewrite. Unless you think calc.exe should also be rewritten for Electron, to avoid creating a new browser in the long run.
My claim was much simpler, you've just ignored it as a junior who's never seen an app deteriorate over time because that's technically impossible, progress only marches forward!
But to your point - sure they are, not only in RAM, but also disk space, battery use, and startup speed etc. Some parts of them are fast, but in that suboptimal stuck-in-a-slow-niche kind of way like V8, which a better alternative would just get rid of (no doubt, great engineering once you learn about the almighty "trade-offs" that can excuse any performance failure)
What people here don't seem to understand is that with this new technology - and in fact any new technology - for unplanned catastrophe, it doesn't need this new technology to be super competent, but just the involved humans to be incompetent.
The question is not "will AI ever be so intelligent that it will murder us?", but "when will some moron be asleep at the console while the agent swarm discovered that pinging the Pentagon on port 666 launches all nukes"
I think (but do not have the data to confirm) that
- there's not as much of that happening as it _should_ yet
- where it does happen, you don't typically notice it (because typically you notice when something is bad, or broken, or slow, or buggy, and not when it is none of these things.)
The former is to the most extent a function of companies still not being confident (or smart) enough in making the right decisions on where to re-invest the productivity dividends that agentic engineering yields. It's obvious that the focus so far has been on "shipping things faster", and that there needs to be a shift towards "shipping things better".
> It's obvious that the focus so far has been on "shipping things faster", and that there needs to be a shift towards "shipping things better".
I agree! However, the entire thrust of our industry for decades has been about "shipping things faster". In my opinion, that's the primary reason for the overall decline of software quality over the years.
At this point, changing that requires changing an entire industry's culture and priorities. Not impossible, but very unlikely.
NATS and its built-in Jetstream stream persistence engine are a miracle. I love them both so much. And if your app is itself written in Go, you can just embed them for simple deployment scenarios (like Chatto does.)
I love Fluxer! Hampus is cool and what he's built is super impressive.
I would say the primary difference is that Chatto doesn't squarely aim for being a _Discord_ alternative. There are no plans for providing a Discord-compatible API (which I think Fluxer does.)
The other main difference is that Chatto is designed, on purpose, to serve individual communities from tiny deployments, instead of large mega-instances that power many communities. Chatto deliberately avoids content federation to remain compatible with business use cases, and also to stay simple enough so it can run from a single binary.
reply