They’re showing how easy it is to vibe code a port of the app. A motivated developer outside Discord could do the same and release OpenDiscord or whatever if they cared enough to want to mod the app that way.
This is the way, LLMs are an enabler and force multiplier to help you build whatever interface you want on whatever protocol you have to reverse engineer.
Provide it the official client and point it at public api endpoints (or an LLM operated mitm proxy), set it to work to reimplement.
Hopefully they don't stop it from doing malware analysis. I've been using it to report malware C2s and it's a godsend for pulling apart the layers of crap they use.
Edit: A couple queries with it indicate it will still assist with malware analysis and considers it beneficial. Hopefully it stays that way.
This isn't universally true, and there's a lot of pressure to bake guardrails and moderation in: Mistral for instance went from one of the most unhinged to incredibly restrictive models with Mistral 4 Large release.
Several others have done similar to greater or lesser degrees in calendar 2026, but the pressure is there across the board to limit what the open models can do without modifications that could largely only be found locally and not from online providers.
I re-wrote one of my apps in Swift. I don't know Swift. It's been fun. When it gets stuck I look at the code; I have it teach me via analogy to the e.g. mobx/react concepts I do know. In some cases I've improved the LLMs code after learning how something works. In others I work it more like an informed PM - ok the sidebar opening is slow but... its about 10x faster in my electron version. How is the sidebar "mounted" or rendered? I dump tricks I know from web dev and ask how analogues; sometimes that breaks its anti-patterns. Other times I throw constraints I don't know much about - "This is a native version, can we aim to make it 3x faster to start-up? How".
Personally I was surprised how quickly I surpassed my original code, feature wise. Will it stand the test of time? Too early to tell - need to see if I'm still using the native version of the app in a year. But its been more fun and informative - and fast - than I'd expected.
Right fun is great but I'm speaking from a professional context. Examples should be production code at legitimate businesses.
For what it's worth I wholly agree with your point and that mirrors the personal project I have. But making personal projects a bit more fun and fluent is not the $10T proposition being championed at the professional level.
You know what they meant. This is the same argument that artists used when AI image generation came out, it's not very helpful. Being able to do something and actually doing it are different and we all benefit when web app makers rewrite their apps into native languages.
Also even without the RAM crisis, the main limitations (time) to optimizing software are gone. If you want to do something impactful, but don't have any good ideas: Take an existing website or application and build an optimized version of it. If you aren't sure where to start, build an isolated workflow out of an existing app or site you like, have the LLM benchmark it, then ask it to make it use 10x less ram / run 10x faster. Ask about what tools it can use to measure, what benchmarks it can come up with to repeatedly test it, how it can automate workflows in a measurable way. Then turn those into tools or specs you can share along with your work.
I always cared with ZRAM under GNU/Linux (I own an n270 netbook with 1GB of RAM and a NUC with 8GB but a Pentium Silver CPU, nothing fancy). Thus, Waterfox with their new Rust based ad blocking engine was a beast, even more with WebGPU enabled and NoScript, just enabling JS for the essential, if any. On top of that, the tab suspending extension. As I program in Rust I need every bit of RAM, even if I disable most debugging options at ~/.config/cargo.toml and I set the build jobs to 1 with "-j1 ".
On the netbook, well.. CWM, UXterm, Dillo, CLI/TUI mail, usenet, IRC and so on clients, groff, nsxiv, mpv, MuPDF... it runs snappier than the NUC for what it does. Programming? Golang for networking stuff -security, not like Rust, but far better than C-, simple C99 for small software, or S9/JimTCL.
Otter Browser for emergencies (JS pages from public institutions/govts in my country).
I had trouble reading more than the opening volley of the article due to popups. Am a Discord user, and rust application programmer: What GUI framework are they using? EGUI? GPUI? Something custom?
GPUI from comments? I meant to try GPUI, but backed off after an announcement pending its maintenance would be in question (?) a few months ago, and Zed broadly ending up being a false messiah, for my uses. (Not on the tier of JetBrains IDEs, a bug with a long thread they closed which (still I believe?) causes it to open cached versions of files, then clobber edits made since the cache, e.g. by other programs. I.e. the sort of bug which renders software too dangerous to use. I will not switch to a GUI framework from a group that ignores bugs of that severity reported by many people)
We've been using Iced for Totem [0], our cross-platform collaborative workspace app. Incidentally we took a similar route to what Discord is aiming to do, layering a rust engine with native UI (e.g. Swift on mobile) and it has been going well so far.
The one major concern I have with this framework, and with rust UI frameworks in general, is accessibility. That's something you get for free or nearly-free in other ecosystems but seems to require a fair bit of elbow grease here.
Still, I would wholeheartedly recommend Iced, with the one caveat that it hasn't yet hit 1.0 and version upgrades could be a little painful, and might bring big changes.
I've built a couple of desktop apps for myself recently using GPUI-kit [0] and it's been fantastic. I'm not a Rust programmer, so leaned heavily on Opus 5.5 for both, but the end result is two apps that are considerably faster than anything I could pay money for, and tailored to exactly what I need.
The Verge is paywalled now but the article really doesn't have much content other than "they're working on a Rust client and someone showed an early build using 290MB of RAM"
I'm very interested in (and a total novice in) cross platform GUI application development. Hadn't heard of GPUI, though I had heard of Tauri. I looked at the GPUI front page and saw this mess of almost-CSS method chaining... Surely there's a better way? This seems horrible to me.
IMHO Rust isn't a great language for describing UIs because it is too explicit in places that doesn't need to be for coding a UI.
Which is why in Slint (another Rust UI framework) we opted for a DSL. The application logic stays in Rust, but the UI is described in a language designed for it.
All a language needs to be good at expressing UIs is some sort of tail lambda syntax like Swift and Kotlin. It's the perfect way to express a tree structure (which is essentially all UI) while also being in a true programming language (as opposed to a markup language like XML).
I'd like to know it. I don't think that it can be substantially better. You have to compromise between the amount of customization you are allowed to do and the amount of options you have to pick values for.
I can't vouch for GPUI, I don't know how good its compromise is, but it bears enough similarities to other modern UI-toolkits. I don't think there is a better way, but if you know one, I'd like to know about it.
And, well, don't forget, it is a front-page example, that is not necessarily an example how one should compose their code, it demonstrates what you can do with GPUI. In real life code you'd probably move those children's construction into separate named functions, maybe you'd use some predefined styles to apply to individual elements, instead of picking fg/bg/text-colors, maybe sizes and some other attributes for each one explicitly, and maybe some other tricks.
That's a result of the borrow checker meeting dev ergonomics. Method chaining/functional style ks extremely common. GPUI is also fairly low level, it lets you do a ton of things!
I noticed this news and because one of my codex banked reset is expiring soon
I launch codex with astra+ultra on my tauri project because webview sometimes cause blank screen on user device to let it to rewrite the tauri projec to GPUI
It did those stuffs for me
- get rid of the CGO and MINGW toolchain for cross building windows on Linux
- wrote a compatbility layer to communicate the original app backend written using rust
- Achieve not ideal but acceptable UI/UX as the tauri project
- The new build using 24MB memory which is quite good and I do not even bother to check the tauri version
It amazing time to rewrite, though I still can't remember joy of old days that manual coding, but my lower back ask me to just embrace the Agentic coding...
Sure, a Rust implementation will perform better and use less RAM, but it's quite obvious that the transition to Rust will be done almost entirely by AI.
Don't get me wrong, the AI coded Rust version of Discord will most likely work just fine. The thing I'm wondering about is if it's a good idea to rewrite your whole codebase (which I assume is handwritten since Discord predates AI coding) with AI because now there is nobody that knows how it really works - I'm wondering what's the value of having a human-written codebase + the people who wrote it. Just feels like one shouldn't throw that into the trash like it's nothing?
It seems like the value is having something performant. Their choices were 1) stick to a web framework their employees know well 2) a performant native app their employees don’t know as well. And they chose 2.
If a model can tell you anything you’d hope to have a human tell you, what’s the difference? It’s a different point of failure— models can go offline, but employees can also quit anytime too.
I'm with you and I think a variety of companies are going to learn this in a highly expensive way over the next few years. Once your shared mental model of how the codebase works is gone it seems practically impossible to get it back. Like what would you even do if you change your mind in 3 years - sit everyone down to meticulously comb through all the AI code until they start to get how it works? Getting back to a similar level of understanding seems like it would take ages and effectively locks you into the new solution in a way that cannot be feasibly reversed.
How is this different from when you join a company and learn your corner of the codebase? In a sufficiently large enough codebase no one had the whole mental model in their head even before AI. What you did was find and ask that one person who knew enough about some part of the project to answer your questions. Now you can ask a model.
Well not really? You are going from a webpage (Electron) to a native application via Rust. Say you port a React website to a Rust native application, is anything about that code actually similar?
Here's the critical assumption: Somebody has to know how it works, in order for it to be usable.
That's not actually true. Nobody understands everything about how an airplane works, not even the lead engineers. Nobody understands everything about how a car works, or how medical billing works, or how taxes work, or how traffic flow works, or how a CPU works, or how almost anything works. You just need to understand the broad picture and be able to find the details when necessary.
Your post is absolute nonsense. Plenty of people know exactly how everything on a plane or car works, or a CPU. I've worked with tons of people who do.
The fear of deskilling is very valid and is already messing things up.
Your post is absolute nonsense. Even the people you are referring to do not know how everything works. Does your airplane engineer know the exact tensile strength of the tire as it hits the landing strip?
It's crazy how much RAM electron needs, at my old startup the main product was an electron app, i initially used to run into this issue where AI wouldn't clean up the dev builds it spunned up for e2e testing and each could be over 500MB, it just get's to a point that the cross platform advantage is no longer worth it, i think it was one of the main reasons cursor had to move off electron to rust based builds.
I just pray that Vencord will continue to work in some form, if only so I can use whatever font I want. I'm not a fan of many other changes they've made and I've thus had to reverse, but I'm willing to trade away the flexibility of CSS for an app that uses 5 times less RAM. Even better if it doesn't go away at all, but we'll see.
It's great they're working on improving performance, but as they move towards an IPO I'd be looking hard at getting off their platform altogether. They're already shoehorning ads and all kinds of nonsense into their app- it's only going to get worse after the IPO.
Network effects keep me on it. I'm waiting for the day it collapses so I can spin up a Teamspeak (or whatever) server again, but it's just too darn convenient for everybody else, so I'm stuck with it unless I want to become even more of a hermit.
Push-to-talk does not work well on in the browser at least on Wayland/Linux. The shortcut only gets sent to the active window, which for the type of contexts where push-to-talk is useful (e.g. gaming) is a dealbreaker. I've read stuff indicating that xdotool can manually handle things reasonably enough on X11, but I was never able to get it working reliably for any of the various Wayland replacements for xdotool, so when I've done voice calls, I've had to grudgingly use the desktop client.
This has to be hyperbole. I built (with Claude) a P2P LAN voice-only chat app in Rust recently, using native frameworks for each platform (Swift, GTK, Win32), and it weighs in at about 5-6 MB depending on the platform. I have spent an enormous amount of time looking for places to squeeze it further. It has ephemeral channels and password protection, but that’s about it: no text chat, no video, no friends, no blocklists, no concept of servers, etc. I can’t imagine everything else Discord has squeezes into another 5 MB.
It's probably left over old instances and updates that werent deleted properly. These apps tend to download the update as an entire bundle, rather than any sort of binary diff and patch.
Therefore, if you have an old install and have gone thru several (many) cycles of updates, the installation directory could be riddled with old versions and update files that make up the bulk of that 10 gig.
It can and it does, because it drops a ton of code for scenarios that do not exist. (Not these numbers, of course, but if you check the comments of that account.. well. Yeah. Some kid)
Electron rose to fame because one could just do everything with it and it was good enough.
Being able to do everything also means that the thing can do everything everywhere all at once, which is many lines of code.
___
The magic of electron was that it was "cheap", however, with code being all AI-generated, that's even cheaper. So now everything will be some slop rust until the point when people realize that there is a cost to be paid after all.
For electron, that has been RAM and performance. For the vibeslop.. well. We shall see.
Unironically, with LLMs, everyone should be looking to cut their system resource consumption (memory, disk, network, GPU, I/O traffic in general) and rewrite everything natively. Have a platform-independent business logic layer, and a platform-dependent UI/UX layer. Done. It's not even that hard, and has been done several times over; we quite literally have MVC/MVVM/etc that were invented two decades ago.
Operating systems developers should be looking to profile everything. Benchmarking and profiling used to be horribly time-consuming; nowadays, with agents, this is almost trivial. Then valuable engineer time can be spent looking at actually solving and optimising the workloads, from the kernel, to drivers, to user-mode libraries, to vendored applications.
About a decade ago programming was expensive, and we decided writing everything in JavaScript was OK, and wasted everyone's memory instead of using programmer time to write fast and efficient native applications. This is no longer the case.
> Unironically, with LLMs, everyone should be looking to cut their system resource consumption (memory, disk, network, GPU, I/O traffic in general) and rewrite everything natively.
Depends.
There is a lot of value in man-made software where the man knows exactly what happened where when why.
If you just revibe in rust, you get something that works at this point in time, but this deep architectural knowledge is completely lost and you're at the mercy of Dario not locking down your account for wrongthink.
That can still be fine for smaller tools where the cost of recreating them from scratch is alright, but revibing your core business thingy is likely a horrible idea, which I encourage people to do, as I'd love to have the business opportunity to take over their frustrated customerbase ca 5 years from now.
I don't think we should just 're-vibe' it as you put it. Naturally the rewrite should be progressive and thoughtful, backed by test-driven development at all levels, and regression tests every step of the way. To reiterate: writing code used to be a lot more expensive, which justified foisting React, Electron, JS on everyone. No longer the case.
I've mentioned in another comment, but my biggest pet peeve is that AI agent applications (Claude, GPT, etc) are themselves just Electron wrappers over their web pages. What a waste.
Serein[0] recently got on my radar, being exactly that (A Rust Discord client). Been using it for the last few weeks, and boy is it snappy! I rather like this trend of stuff being rewritten in Rust (usually via LLMs). Spotifast[1] being another great example.
Perhaps Discord caught wind that this is now possible, and don’t want to be left behind?
GPUI is quite a strange choice because there are so many forks of it, because Zed which made it is not interested in PRs that don't serve their use case of text editors, thus lots of common sense PRs for general desktop development were rejected.
It's great to see so many big companies making the switch to Rust. It is an amazing language and by now it has proven to be a solid multi-purpose language.
Many engineer consider Rust a systems programming language (and it is!), but it also offers great abstractions to write on a higher level, building API's and Interfaces
There was already an electron-free native client for discord some years back, but they interfered with it. At this point, there's nothing at all impressive about this. It's not hard to ask AI to "RIIR" as has been shown many times. However, I am glad that building stuff on electron might finally be seen as lazy and wasteful.
It's open source! Just if you want to pay for it, i'd like to continue working on it and throwing tokens at it but I don't really expect to make much from it. Theres links to the download page at the bottom too: https://diffy.run/downloads/
Thanks haha hitslop, it means "a property used to increase the interactive touch area of a component beyond its visible layout boundaries", which I thought was so funny when I came across it. Owned the domain since 2020, knew it would come in handy eventually!
Asking in good faith: In the agentic age why use abstractions like Electron at all? Shouldn't we write apps in lower-level system languages like Rust like Discord has done?
Consistent UI and control. I re-wrote my electron app in Swift. Its great. But... some of the UI is weird at times; weird patterns; weird behavior. And Apple's UI framework is one of the better ones. Even for AI, each platform will have its own quirks and just _finding_ them takes real users to expose. We take it for granted how flexible and powerful browser UI is, because there's so much baggage and performance related factors. But many UI frameworks are worse, and historically always were.
I think what we're seeing here - and likely to continue to see - is new versions of web UI that eschew a lot of the historical baggage given they don't need to support older websites. And possibly something more powerful. So I guess re-writes or partial ports that take only the parts we need. Presumably a bunch of people will try and hopefully, a few succeed.
I am not a developer, but using this type of frameworks and toolkits means that a lot of useful (and sometimes "boring") things are already thought through and taken care of. This is probably most important for smaller projects and teams, but some of it probably applies to Discord scale operations as well :)
While you _should_ put some effort into tuning and fixing these things for your specific project, you will "mostly" get things like cross-platform support for all major desktop operating systems, some support for accessibility-tools like screen readers and voice over, devtools and debuggers, application installers, (push) notifications, caching, some aspects of security and cryptography, log handling, and file handling for free, or at least get a reasonable push in the right direction, with Electron.
The alternative is either getting each of these things from a different third party source, or making them all in-house.
With a popular abstraction layer like Electron + a web stack, you will to some extent encounter the same problems, mysterious log messages, design considerations and other issues as everyone else. This means that you can find documentation, stack overflow questions, new hires, consultants, blogs, LLMs, etc. that have the skills and knowledge you need, instead of researching and solving everything in-house.
> [...] using this type of frameworks and toolkits means that a lot of useful (and sometimes "boring") things are already thought through and taken care of.
You're falling in the trap of the cross-platform dream. Electron takes insane decisions about how your app is going to achieve cross-compatibility in the name of allowing web devs to do the work. It is simply the wrong tool for the AI age, since a versatile web dev can turn to an AI to help them achieve the work.
We've barely begun seeing the impact of AI on software (IMHO). Things like vibecoding the Adobe suite are going to destroy Adobe. That's going to happen to other companies too. It'll take awhile but it will happen.
I've always disliked Electron apps in principle. The idea was you could write once, run anywhere, which is something we've heard before so many times but it never really works out that way. Back in the early days of Java we heard this mantra with applets and Java desktop apps and the reality was "write once, test everywhere".
The cost is simply too high. Nobody wants an entire browser engine packaged to run a desktop app. Security-wise, this is a nightmare. It's such a huge attack surface (eg [1]). And resource-wise it's also a nightmare. Honestly, Electron apps can't die fast enough for my liking.
What I think we'll see is a return to desktop apps because the cost of porting them to new platforms is dropping like a rock.
There are modding issues with Discord's migration but I believe modding itself is going to be an issue in a world where it's going to be increasingly easy to find and use exploits.
I also wonder if Discord is the best we can do here. I've always hated Discord from a UI/UX perspective. Nothing about it is intuitive (IMHO). There are like 3 different settings buttons. You join a Discord and you get yet another custom flow of having to go to this channel and select roles and do something before you can do something else blah blah blah. Everything feels shoe horned. And Discord channels are a worse repository for information than the old forums were.
You have not been paying attention the last two years, as they decided to go subscription instead of loaded with ads like anything nowadays owned by Future, like Toms Hardware, Anything Central.
If all products ditch Electron, it satisfies the NSA requirements of having AI-generated backdoors on your computer, while allowing you to reduce your RAM consumption and letting this precious silicon for Sam Altman (He's quoted saying RAM is better spent in data centers than in personal computers - and in an era where everything is Cloud, one might wonder why the base Macbook Pro has 32GB).
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)
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.
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.
> 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.
> 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 .
Maybe the good thing to come out of the RAM crisis is that engineers will care about memory usage again lol.
The bad thing here is that modding discord will become significantly harder and might have been their original intention here.
They’re showing how easy it is to vibe code a port of the app. A motivated developer outside Discord could do the same and release OpenDiscord or whatever if they cared enough to want to mod the app that way.
Ahem there is also the option to check out competitors ;)
This is the way, LLMs are an enabler and force multiplier to help you build whatever interface you want on whatever protocol you have to reverse engineer.
Provide it the official client and point it at public api endpoints (or an LLM operated mitm proxy), set it to work to reimplement.
I don't see any reason to think the web client is going away.
Some vibekiddie will reengineer this, and mod it.
How? Anthropic hard coded anti-reverse engineering instructions into Claude.
https://www.tomshardware.com/tech-industry/artificial-intell...
It may shock you to hear that there are other coding agents than Claude.
Hopefully they don't stop it from doing malware analysis. I've been using it to report malware C2s and it's a godsend for pulling apart the layers of crap they use.
Edit: A couple queries with it indicate it will still assist with malware analysis and considers it beneficial. Hopefully it stays that way.
Open models have no guardrails.
This isn't universally true, and there's a lot of pressure to bake guardrails and moderation in: Mistral for instance went from one of the most unhinged to incredibly restrictive models with Mistral 4 Large release.
Several others have done similar to greater or lesser degrees in calendar 2026, but the pressure is there across the board to limit what the open models can do without modifications that could largely only be found locally and not from online providers.
Can’t see it on my end, the clanker still finesses IDAPython just fine.
...so just don't use Claude?
I thought Claude was the tool for the AI script kiddies?
>vibekiddie
love this term, knew instantly what it means
depends if they decide to use any kind of obfuscation here to protect "IP"
They can just repackage the web app and mod that if all else fails.
oh won't someone think of the discord mods!? If its too hard for them to mod, they won't have time to groom children.
Mod as in modification, not moderation.
The good thing is AI enabling web developers to write native apps.
Is the average web developer benefitting from vibing languages they are not at all fluent with?
A bit like a translator who doesnt speak the language but has Google translate and a few beers in them right?
For example, is there still a massive .clone() problem in LLM generated Rust?
I re-wrote one of my apps in Swift. I don't know Swift. It's been fun. When it gets stuck I look at the code; I have it teach me via analogy to the e.g. mobx/react concepts I do know. In some cases I've improved the LLMs code after learning how something works. In others I work it more like an informed PM - ok the sidebar opening is slow but... its about 10x faster in my electron version. How is the sidebar "mounted" or rendered? I dump tricks I know from web dev and ask how analogues; sometimes that breaks its anti-patterns. Other times I throw constraints I don't know much about - "This is a native version, can we aim to make it 3x faster to start-up? How".
Personally I was surprised how quickly I surpassed my original code, feature wise. Will it stand the test of time? Too early to tell - need to see if I'm still using the native version of the app in a year. But its been more fun and informative - and fast - than I'd expected.
Right fun is great but I'm speaking from a professional context. Examples should be production code at legitimate businesses.
For what it's worth I wholly agree with your point and that mirrors the personal project I have. But making personal projects a bit more fun and fluent is not the $10T proposition being championed at the professional level.
This is the way. I don't know why it's hard for other people to figure out this process.
I mean, they were always able to. They just were too lazy to do it and didn't care about doing a good job enough to overcome that laziness.
You know what they meant. This is the same argument that artists used when AI image generation came out, it's not very helpful. Being able to do something and actually doing it are different and we all benefit when web app makers rewrite their apps into native languages.
Also even without the RAM crisis, the main limitations (time) to optimizing software are gone. If you want to do something impactful, but don't have any good ideas: Take an existing website or application and build an optimized version of it. If you aren't sure where to start, build an isolated workflow out of an existing app or site you like, have the LLM benchmark it, then ask it to make it use 10x less ram / run 10x faster. Ask about what tools it can use to measure, what benchmarks it can come up with to repeatedly test it, how it can automate workflows in a measurable way. Then turn those into tools or specs you can share along with your work.
About time, I'm tired of fighting. Free the RAM!
I always cared with ZRAM under GNU/Linux (I own an n270 netbook with 1GB of RAM and a NUC with 8GB but a Pentium Silver CPU, nothing fancy). Thus, Waterfox with their new Rust based ad blocking engine was a beast, even more with WebGPU enabled and NoScript, just enabling JS for the essential, if any. On top of that, the tab suspending extension. As I program in Rust I need every bit of RAM, even if I disable most debugging options at ~/.config/cargo.toml and I set the build jobs to 1 with "-j1 ".
On the netbook, well.. CWM, UXterm, Dillo, CLI/TUI mail, usenet, IRC and so on clients, groff, nsxiv, mpv, MuPDF... it runs snappier than the NUC for what it does. Programming? Golang for networking stuff -security, not like Rust, but far better than C-, simple C99 for small software, or S9/JimTCL. Otter Browser for emergencies (JS pages from public institutions/govts in my country).
I had trouble reading more than the opening volley of the article due to popups. Am a Discord user, and rust application programmer: What GUI framework are they using? EGUI? GPUI? Something custom?
GPUI from comments? I meant to try GPUI, but backed off after an announcement pending its maintenance would be in question (?) a few months ago, and Zed broadly ending up being a false messiah, for my uses. (Not on the tier of JetBrains IDEs, a bug with a long thread they closed which (still I believe?) causes it to open cached versions of files, then clobber edits made since the cache, e.g. by other programs. I.e. the sort of bug which renders software too dangerous to use. I will not switch to a GUI framework from a group that ignores bugs of that severity reported by many people)
We've been using Iced for Totem [0], our cross-platform collaborative workspace app. Incidentally we took a similar route to what Discord is aiming to do, layering a rust engine with native UI (e.g. Swift on mobile) and it has been going well so far.
The one major concern I have with this framework, and with rust UI frameworks in general, is accessibility. That's something you get for free or nearly-free in other ecosystems but seems to require a fair bit of elbow grease here.
Still, I would wholeheartedly recommend Iced, with the one caveat that it hasn't yet hit 1.0 and version upgrades could be a little painful, and might bring big changes.
[0] https://thinktotem.com
They use GPUI. Says so on X.
" (And it's not Tauri, it's GPUI, so good guess everyone.) "
Which I believe GPUI is the same framework that Zed (the editor)[0] is using
[0]: http://zed.dev/
Considering the fact that the gpui code only exists as a crate under the zed repo, I'd say you are correct.
I've built a couple of desktop apps for myself recently using GPUI-kit [0] and it's been fantastic. I'm not a Rust programmer, so leaned heavily on Opus 5.5 for both, but the end result is two apps that are considerably faster than anything I could pay money for, and tailored to exactly what I need.
[0] https://gpui-kit.com
The Verge is paywalled now but the article really doesn't have much content other than "they're working on a Rust client and someone showed an early build using 290MB of RAM"
I'm very interested in (and a total novice in) cross platform GUI application development. Hadn't heard of GPUI, though I had heard of Tauri. I looked at the GPUI front page and saw this mess of almost-CSS method chaining... Surely there's a better way? This seems horrible to me.
> div() .flex() .flex_col() .gap_3() .bg(rgb(0x505050)) .size(px(500.0)) .justify_center() .items_center() .shadow_lg() .border_1() .border_color(rgb(0x0000ff)) .text_xl() .text_color(rgb(0xffffff)) .child(format!("Hello, {}!", &self.text)) .child( div() .flex() .gap_2() .child(div().size_8().bg(gpui::red())) .child(div().size_8().bg(gpui::green())) .child(div().size_8().bg(gpui::blue())) .child(div().size_8().bg(gpui::yellow())) .child(div().size_8().bg(gpui::black())) .child(div().size_8().bg(gpui::white())), )
IMHO Rust isn't a great language for describing UIs because it is too explicit in places that doesn't need to be for coding a UI. Which is why in Slint (another Rust UI framework) we opted for a DSL. The application logic stays in Rust, but the UI is described in a language designed for it.
Your example would look like this:
More on why we chose a DSL vs code in Rust: https://slint.dev/blog/domain-specific-language-vs-imperativ...All a language needs to be good at expressing UIs is some sort of tail lambda syntax like Swift and Kotlin. It's the perfect way to express a tree structure (which is essentially all UI) while also being in a true programming language (as opposed to a markup language like XML).
> Surely there's a better way?
I'd like to know it. I don't think that it can be substantially better. You have to compromise between the amount of customization you are allowed to do and the amount of options you have to pick values for.
I can't vouch for GPUI, I don't know how good its compromise is, but it bears enough similarities to other modern UI-toolkits. I don't think there is a better way, but if you know one, I'd like to know about it.
And, well, don't forget, it is a front-page example, that is not necessarily an example how one should compose their code, it demonstrates what you can do with GPUI. In real life code you'd probably move those children's construction into separate named functions, maybe you'd use some predefined styles to apply to individual elements, instead of picking fg/bg/text-colors, maybe sizes and some other attributes for each one explicitly, and maybe some other tricks.
One improvement could be a better way to group and elide units, e.g.
Instead of
.border_1().border_color(rgb(0x0000ff))
You get
.border(1 0x0000ff)
(guess, this can only be in a macro)
Or at least have "color" which understands that it's allied to border instead of having to repeat "border"
> I don't think that it can be substantially better
Don't give up too early, there is no way it can't be, we don't really have any good systems optimized for ergonomics to reach anything great
This is basically what coding UI in Bevy was like before the `bsn!` macro
I'm never going to complain about SwiftUI again
That's a result of the borrow checker meeting dev ergonomics. Method chaining/functional style ks extremely common. GPUI is also fairly low level, it lets you do a ton of things!
Someone needs close the loop and make an HTML/CSS to GPUI transpiler
You mean this? https://gpuix.dev
So, Blitz? It's by Dioxus Labs and converts HTML and CSS into native Rust rendering like GPUI.
One person's mess is another person's Tailwind
I noticed this news and because one of my codex banked reset is expiring soon
I launch codex with astra+ultra on my tauri project because webview sometimes cause blank screen on user device to let it to rewrite the tauri projec to GPUI
It did those stuffs for me
- get rid of the CGO and MINGW toolchain for cross building windows on Linux
- wrote a compatbility layer to communicate the original app backend written using rust
- Achieve not ideal but acceptable UI/UX as the tauri project
- The new build using 24MB memory which is quite good and I do not even bother to check the tauri version
It amazing time to rewrite, though I still can't remember joy of old days that manual coding, but my lower back ask me to just embrace the Agentic coding...
Not sure what to think of this.
Sure, a Rust implementation will perform better and use less RAM, but it's quite obvious that the transition to Rust will be done almost entirely by AI.
Don't get me wrong, the AI coded Rust version of Discord will most likely work just fine. The thing I'm wondering about is if it's a good idea to rewrite your whole codebase (which I assume is handwritten since Discord predates AI coding) with AI because now there is nobody that knows how it really works - I'm wondering what's the value of having a human-written codebase + the people who wrote it. Just feels like one shouldn't throw that into the trash like it's nothing?
It seems like the value is having something performant. Their choices were 1) stick to a web framework their employees know well 2) a performant native app their employees don’t know as well. And they chose 2.
If a model can tell you anything you’d hope to have a human tell you, what’s the difference? It’s a different point of failure— models can go offline, but employees can also quit anytime too.
I'm with you and I think a variety of companies are going to learn this in a highly expensive way over the next few years. Once your shared mental model of how the codebase works is gone it seems practically impossible to get it back. Like what would you even do if you change your mind in 3 years - sit everyone down to meticulously comb through all the AI code until they start to get how it works? Getting back to a similar level of understanding seems like it would take ages and effectively locks you into the new solution in a way that cannot be feasibly reversed.
How is this different from when you join a company and learn your corner of the codebase? In a sufficiently large enough codebase no one had the whole mental model in their head even before AI. What you did was find and ask that one person who knew enough about some part of the project to answer your questions. Now you can ask a model.
When porting an app this way, don't functions/classes preserve the same functionality ?
Well not really? You are going from a webpage (Electron) to a native application via Rust. Say you port a React website to a Rust native application, is anything about that code actually similar?
Here's the critical assumption: Somebody has to know how it works, in order for it to be usable.
That's not actually true. Nobody understands everything about how an airplane works, not even the lead engineers. Nobody understands everything about how a car works, or how medical billing works, or how taxes work, or how traffic flow works, or how a CPU works, or how almost anything works. You just need to understand the broad picture and be able to find the details when necessary.
Your post is absolute nonsense. Plenty of people know exactly how everything on a plane or car works, or a CPU. I've worked with tons of people who do.
The fear of deskilling is very valid and is already messing things up.
Your post is absolute nonsense. Even the people you are referring to do not know how everything works. Does your airplane engineer know the exact tensile strength of the tire as it hits the landing strip?
We're losing a respect and understanding of how basic competence works.
> Nobody understands everything about how an airplane works, not even the lead engineers. Nobody understands everything about how a car works
Of course people do.
Doubtful. The engine engineer doesn’t know the chemical engineering of modern fuels nor the code in the engine controller.
This is textbook whataboutism.
It's crazy how much RAM electron needs, at my old startup the main product was an electron app, i initially used to run into this issue where AI wouldn't clean up the dev builds it spunned up for e2e testing and each could be over 500MB, it just get's to a point that the cross platform advantage is no longer worth it, i think it was one of the main reasons cursor had to move off electron to rust based builds.
It is a full browser, not surprising at all, only for those that never coded native applications.
Oh if you don't like large build artifacts Tauri might not be something to get excited about.
For reference, my src-tauri/target/ folder is 8.3gb.
Holy Jesus of Nazareth. I love it.
I just pray that Vencord will continue to work in some form, if only so I can use whatever font I want. I'm not a fan of many other changes they've made and I've thus had to reverse, but I'm willing to trade away the flexibility of CSS for an app that uses 5 times less RAM. Even better if it doesn't go away at all, but we'll see.
It's great they're working on improving performance, but as they move towards an IPO I'd be looking hard at getting off their platform altogether. They're already shoehorning ads and all kinds of nonsense into their app- it's only going to get worse after the IPO.
Network effects keep me on it. I'm waiting for the day it collapses so I can spin up a Teamspeak (or whatever) server again, but it's just too darn convenient for everybody else, so I'm stuck with it unless I want to become even more of a hermit.
The app size also went from 10 GB to 10 MB, start time went from 10 secs to 10 ms
Goodbye Electron, we barely knew you
I wonder where the 10GB come from. Quick check on Flatpak shows 240 MB download and 568 MB installed size for the Linux install.
https://flathub.org/en/apps/com.discordapp.Discord
I really hope with hardware prices going back to the last century, we finally get some best practices back.
In a perfect world it would be reduced to 0 MB.
https://news.ycombinator.com/item?id=30311982
Misinformation. Discord isn’t 10GB and nobody outside Discord has actually used the Rust port.
Source?
you must be joking 10GB haha
who downloads this? there's a website available
Push-to-talk does not work well on in the browser at least on Wayland/Linux. The shortcut only gets sent to the active window, which for the type of contexts where push-to-talk is useful (e.g. gaming) is a dealbreaker. I've read stuff indicating that xdotool can manually handle things reasonably enough on X11, but I was never able to get it working reliably for any of the various Wayland replacements for xdotool, so when I've done voice calls, I've had to grudgingly use the desktop client.
A standard exists for Wayland apps. https://flatpak.github.io/xdg-desktop-portal/docs/doc-org.fr...
What the fuck. That's amazing. 10GB->10MB can't simply be moving from Electron right?
This has to be hyperbole. I built (with Claude) a P2P LAN voice-only chat app in Rust recently, using native frameworks for each platform (Swift, GTK, Win32), and it weighs in at about 5-6 MB depending on the platform. I have spent an enormous amount of time looking for places to squeeze it further. It has ephemeral channels and password protection, but that’s about it: no text chat, no video, no friends, no blocklists, no concept of servers, etc. I can’t imagine everything else Discord has squeezes into another 5 MB.
Electron is a full Chrome instance, plus whatever else makes up the application.
Yes, and that only explains about 150MB.
If it were simply the Chrome install that would imply Electron is 9GB+ by itself, which it most certainly is not.
It's probably left over old instances and updates that werent deleted properly. These apps tend to download the update as an entire bundle, rather than any sort of binary diff and patch.
Therefore, if you have an old install and have gone thru several (many) cycles of updates, the installation directory could be riddled with old versions and update files that make up the bulk of that 10 gig.
It can and it does, because it drops a ton of code for scenarios that do not exist. (Not these numbers, of course, but if you check the comments of that account.. well. Yeah. Some kid)
Electron rose to fame because one could just do everything with it and it was good enough.
Being able to do everything also means that the thing can do everything everywhere all at once, which is many lines of code.
___
The magic of electron was that it was "cheap", however, with code being all AI-generated, that's even cheaper. So now everything will be some slop rust until the point when people realize that there is a cost to be paid after all.
For electron, that has been RAM and performance. For the vibeslop.. well. We shall see.
Unironically, with LLMs, everyone should be looking to cut their system resource consumption (memory, disk, network, GPU, I/O traffic in general) and rewrite everything natively. Have a platform-independent business logic layer, and a platform-dependent UI/UX layer. Done. It's not even that hard, and has been done several times over; we quite literally have MVC/MVVM/etc that were invented two decades ago.
Operating systems developers should be looking to profile everything. Benchmarking and profiling used to be horribly time-consuming; nowadays, with agents, this is almost trivial. Then valuable engineer time can be spent looking at actually solving and optimising the workloads, from the kernel, to drivers, to user-mode libraries, to vendored applications.
About a decade ago programming was expensive, and we decided writing everything in JavaScript was OK, and wasted everyone's memory instead of using programmer time to write fast and efficient native applications. This is no longer the case.
> Unironically, with LLMs, everyone should be looking to cut their system resource consumption (memory, disk, network, GPU, I/O traffic in general) and rewrite everything natively.
Depends.
There is a lot of value in man-made software where the man knows exactly what happened where when why.
If you just revibe in rust, you get something that works at this point in time, but this deep architectural knowledge is completely lost and you're at the mercy of Dario not locking down your account for wrongthink.
That can still be fine for smaller tools where the cost of recreating them from scratch is alright, but revibing your core business thingy is likely a horrible idea, which I encourage people to do, as I'd love to have the business opportunity to take over their frustrated customerbase ca 5 years from now.
I don't think we should just 're-vibe' it as you put it. Naturally the rewrite should be progressive and thoughtful, backed by test-driven development at all levels, and regression tests every step of the way. To reiterate: writing code used to be a lot more expensive, which justified foisting React, Electron, JS on everyone. No longer the case.
I've mentioned in another comment, but my biggest pet peeve is that AI agent applications (Claude, GPT, etc) are themselves just Electron wrappers over their web pages. What a waste.
>and you're at the mercy of Dario not locking down your account for wrongthink.
Inference cannot be controlled. The models are already out there. It's too late.
Good luck doing the full-hands-off one-shot revibe stuff this all is referring to with GLM-5.3.
That needs claude-like capabilities.
It also should not be done at all. But that approach needs it.
Using open weights models like GLM-5.3 can also speed up rewriting, but then you're rewriting and not revibing, which is a lot slower.
Serein[0] recently got on my radar, being exactly that (A Rust Discord client). Been using it for the last few weeks, and boy is it snappy! I rather like this trend of stuff being rewritten in Rust (usually via LLMs). Spotifast[1] being another great example.
Perhaps Discord caught wind that this is now possible, and don’t want to be left behind?
[0]: https://github.com/ViceVerse-cz/Serein
[1]: https://github.com/crmne/spotifast
https://archive.ph/udbZx
GPUI is quite a strange choice because there are so many forks of it, because Zed which made it is not interested in PRs that don't serve their use case of text editors, thus lots of common sense PRs for general desktop development were rejected.
It's great to see so many big companies making the switch to Rust. It is an amazing language and by now it has proven to be a solid multi-purpose language. Many engineer consider Rust a systems programming language (and it is!), but it also offers great abstractions to write on a higher level, building API's and Interfaces
The Linux desktop client was using a bit more memory than I expected. 1326 MB from a cold start, and I'm only in 11 servers.
I've never used GPUI. Does GPUI provide the same assurances of accessibility? Of proper CJK rendering?
Activities will apparently still use Tauri. Is that going to be a compatibility nightmare due to WebKit? (At least until CEF comes out)
Think still has no accessibility, and given that the public framework is abandoned might not get there
It render accetpable Chinese text, and the IME stuffs work on the control such as search box
If I understand correctly, they're ditching Electron but still using React but with their custom renderer.
There was already an electron-free native client for discord some years back, but they interfered with it. At this point, there's nothing at all impressive about this. It's not hard to ask AI to "RIIR" as has been shown many times. However, I am glad that building stuff on electron might finally be seen as lazy and wasteful.
GPUI is pretty great. I whipped this up the other week and now I no longer need to open VSCode: https://diffy.run
How come it's presented as paid software when the binaries are available on GitHub?
Also naming your company "__slop" is a bold move!
It's open source! Just if you want to pay for it, i'd like to continue working on it and throwing tokens at it but I don't really expect to make much from it. Theres links to the download page at the bottom too: https://diffy.run/downloads/
Thanks haha hitslop, it means "a property used to increase the interactive touch area of a component beyond its visible layout boundaries", which I thought was so funny when I came across it. Owned the domain since 2020, knew it would come in handy eventually!
DO TEAMS NEXT
Nah, ease of running it in the browser is a saving grace for us on Linux. MS does not offer an official Linux client.
Also Slack
With the browser sandbox gone, it will be a good test of faith. Here's to an RCE-free port
Link to post referenced in the article
https://nitter.click/svishnevskiy/status/2118081920194203799
Asking in good faith: In the agentic age why use abstractions like Electron at all? Shouldn't we write apps in lower-level system languages like Rust like Discord has done?
Consistent UI and control. I re-wrote my electron app in Swift. Its great. But... some of the UI is weird at times; weird patterns; weird behavior. And Apple's UI framework is one of the better ones. Even for AI, each platform will have its own quirks and just _finding_ them takes real users to expose. We take it for granted how flexible and powerful browser UI is, because there's so much baggage and performance related factors. But many UI frameworks are worse, and historically always were.
I think what we're seeing here - and likely to continue to see - is new versions of web UI that eschew a lot of the historical baggage given they don't need to support older websites. And possibly something more powerful. So I guess re-writes or partial ports that take only the parts we need. Presumably a bunch of people will try and hopefully, a few succeed.
> Consistent UI and control.
Neither of which is actually good for your users. Look like other apps on the platform, FFS.
I am not a developer, but using this type of frameworks and toolkits means that a lot of useful (and sometimes "boring") things are already thought through and taken care of. This is probably most important for smaller projects and teams, but some of it probably applies to Discord scale operations as well :)
While you _should_ put some effort into tuning and fixing these things for your specific project, you will "mostly" get things like cross-platform support for all major desktop operating systems, some support for accessibility-tools like screen readers and voice over, devtools and debuggers, application installers, (push) notifications, caching, some aspects of security and cryptography, log handling, and file handling for free, or at least get a reasonable push in the right direction, with Electron.
The alternative is either getting each of these things from a different third party source, or making them all in-house. With a popular abstraction layer like Electron + a web stack, you will to some extent encounter the same problems, mysterious log messages, design considerations and other issues as everyone else. This means that you can find documentation, stack overflow questions, new hires, consultants, blogs, LLMs, etc. that have the skills and knowledge you need, instead of researching and solving everything in-house.
> [...] using this type of frameworks and toolkits means that a lot of useful (and sometimes "boring") things are already thought through and taken care of.
You're falling in the trap of the cross-platform dream. Electron takes insane decisions about how your app is going to achieve cross-compatibility in the name of allowing web devs to do the work. It is simply the wrong tool for the AI age, since a versatile web dev can turn to an AI to help them achieve the work.
It doesn't say but it's likely a direct product of AI.
Someone should do this for Slack
discord's electron app was a study in bloatware, quite unlike nearly all other electron apps I've used.
Potentially even more lightweight: ditch Discord altogether.
Maybe we should collectively use more of our personal tokens to re/write, extend and mix up the common(s) stacks at this point?
RIP mods
Somehow we were able to do mods with native applications back in the last century of desktop computing.
RIP ripcord.
more for sam altman!
As the motto says, "you can just do things"
Such a rewrite would have been unthinkable 2 years ago, but now it's table stakes.
We are at a point where the "port this to rust, make no mistakes" meme is basically a reality.
We've barely begun seeing the impact of AI on software (IMHO). Things like vibecoding the Adobe suite are going to destroy Adobe. That's going to happen to other companies too. It'll take awhile but it will happen.
I've always disliked Electron apps in principle. The idea was you could write once, run anywhere, which is something we've heard before so many times but it never really works out that way. Back in the early days of Java we heard this mantra with applets and Java desktop apps and the reality was "write once, test everywhere".
The cost is simply too high. Nobody wants an entire browser engine packaged to run a desktop app. Security-wise, this is a nightmare. It's such a huge attack surface (eg [1]). And resource-wise it's also a nightmare. Honestly, Electron apps can't die fast enough for my liking.
What I think we'll see is a return to desktop apps because the cost of porting them to new platforms is dropping like a rock.
There are modding issues with Discord's migration but I believe modding itself is going to be an issue in a world where it's going to be increasingly easy to find and use exploits.
I also wonder if Discord is the best we can do here. I've always hated Discord from a UI/UX perspective. Nothing about it is intuitive (IMHO). There are like 3 different settings buttons. You join a Discord and you get yet another custom flow of having to go to this channel and select roles and do something before you can do something else blah blah blah. Everything feels shoe horned. And Discord channels are a worse repository for information than the old forums were.
[1]: https://www.sentinelone.com/vulnerability-database/cve-2026-...
"To continue reading *blah blah* *barfs* Verge subscription" WTF???
15 years reading the verge without subscription. What happened?
You have not been paying attention the last two years, as they decided to go subscription instead of loaded with ads like anything nowadays owned by Future, like Toms Hardware, Anything Central.
I assure you that you haven't missed anything:
> It’s not clear when Discord will make the full switch over to Rust, but Vishnevskiy says the company “hope to get it into testing with users soon.”
soon™
And yeah, The Verge was one of my favorite resources earlier too but I've stopped visiting it due to subscription requirement on most articles.
You've read them without a subscription for 15 years, but they had 15 years of salaries, server cost, etc. That is what happened
That's a direct benefit from AI.
If all products ditch Electron, it satisfies the NSA requirements of having AI-generated backdoors on your computer, while allowing you to reduce your RAM consumption and letting this precious silicon for Sam Altman (He's quoted saying RAM is better spent in data centers than in personal computers - and in an era where everything is Cloud, one might wonder why the base Macbook Pro has 32GB).
Hopefully we will get an Electron-free VSCode too at some point.
edit: there is one https://github.com/Sidenai/sidex haven't tried it yet
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).
Give me some examples, including their cross-platform story (including mobile).
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)
Cross platform is not an actual achievable goal if you wish to have a pleasant UX. One size does not, in fact, fit all.
> 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?
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.
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?
> 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.
> 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 .
> 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.