Hacker News Reader

Comment by hendrikmans | Hacker News Reader

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.

View on HN

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).

Give me some examples, including their cross-platform story (including mobile).

Cross platform is not an actual achievable goal if you wish to have a pleasant UX. One size does not, in fact, fit all.

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.

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)

> 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.

> Why do I need to play videos in the chat application?

You know exactly that the moment that Discord launches a new version that no longer plays videos, people will whine about it.

> All of this can be done at the platform level. Win32 did this three decades ago.

Yeah, but they're porting to Rust and GPUI and not that.

> 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!

> a11y, IME, RTL

Artcraft it's doing that in every software application;

> so you add a scripting layer, maybe integrate a little Lua VM or something that lets you execute JavaScript?

Every Arftcraft software can be command line driven and it's still fast and small compared to your bloated crap.

> 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.

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.

You are comparing Discord to calc.exe. This is not a serious argument.

You are stating that any move away from electron is a junior engineer decision—also not serious imo.

Sir, this is a W-- a thread about Discord moving from Electron to Rust/GPUI. Why are you reframing the discussion like this?

> 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.

What top-level engineering experience led you to believe the magic of multiple decades guaranteeing improvements?

Are you claiming that browsers, their renderers, V8 etc. are slow and unoptimized?

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)

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.

I don't understand this question. GPUI's unstable to non-existing a11y, IME, RTL etc. support is well documented.

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.

But that's not what I wrote at all?

> 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.

Reply on news.ycombinator.com