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)
The fact they're using gpui is... Bad. Is someone trying to make it integrate with native accessibility frameworks? If not (and if they force the native app on us) this transition is going to lock out a ton of people who use assistive technologies.
Yes, see: https://github.com/longbridge/gpui-kit. I've been following these rust UI toolkits and things like accessibility have consistently been missing. This is the first time I've seen a UI library that appears complete enough to build a real product with.
Yeah, that's what worries me. Pretty much every Rust UI library I've seen which isn't wxdragon/Relm/GTK lacks accessibility. And most of them don't even have the primitives for it (given that most of them are abandoned).
You are dismissing again the answer you are getting. Why do you think it is lacking accessibility despite using a framework claiming " GPUI Kit ships 75+ documented components and primitives, WebAssembly support, AccessKit accessibility"
I don't know why people are ignoring the pink elephant here. For medium scale projects, like a Discord app is going to be, LLMs are now at a superhuman level of competence, including on higher level architectural/structural type decisions. I would be beyond surprised if the rewrite wasn't largely done by Claude (or similar). And in this context accessibility is also just a prompt away, if it wasn't included from the get-go, which it probably would have been.
Accessibility isn't just something you one-shot. It takes a lot of back-and-forth and testing with actual screen readers/accessibility scanning tools to be good.
I'm not dismissing it, just uncertain how good it is. Quality over quantity and all that. You can have 75 or 100 or 200 UI components and some can be perfectly accessible while others might not be even things accesskit supports right now. Or Accesskit may only partially support a widget. As I've said downthread, I'm hoping that Discord using a UI toolkit like this will cause upstream effects with respect to Accesskit coverage, so we'll have to see when they start migrating people over to it.
This is exactly why I started working on Day (https://daybrite.dev) as a successor to Skip (https://skip.dev). It uses platform-native toolkits everywhere, and so accessibility comes for free.
I haven't exactly "launched" it yet, but I'm already shipping apps through the App/Play Stores. See https://daybrite.dev/showcase/ for the 5-minute tour.
Yes, and this is good progress (my comment downthread was before I just looked). According to it it uses accesskit, which is quite good already but still in development so accessibility would not be as good as using UIA directly. I am hopeful though that accesskit (which is also used in Godot) will keep getting better and these gaps can be closed.
This is one angle. I do not see it as a deal breaker in the way you phrase it. I suppose we all have our own. If everyone's had to be satisfied, we'd have no software!
I think in the specific case of Discord, I.e. from a big company, I agree they should handle this properly. As a broader standard, I am not as concerned.
This is a dealbreaker for me even if I didn't want it to be. If your application does not either interact with a11y frameworks (UIA, AT-SPI, NSAccessibility, ...) or does not implement an equivalent that communicates with my screen reader, I literally cannot use your application. I could OCR your application, or use AI and have it use your app for me via screenshots, but neither are even remotely comparable to using the native platform accessibility frameworks.
Could someone use AI to make the GPUI kit become accessible? You (or someone else) mentioned that it doesn't even have the primitives so is it a non starter?
No, I mentioned that most rust UI toolkits lack even the primitives. The primitives for even basic accessibility, without accessibility frameworks, would be things like focus events, carrot navigation, navigation in containers such as list/combo boxes, line/paragraph handling in multi-line edit boxes and the like. Adding native accessibility forces you to do a lot of this but just in a different way than routing text directly to a screen reader.
As for me doing it? According to prior comments in this thread it's already done, although I haven't tested it so I don't know how complete it is. Adding UIA support to a framework is different from making that support good (screen readers can be very picky). As an example, say you have a label of an edit box. If you position the label just right within it's parent container a screen reader will pick it up automatically and just announce it as you focus the edit box. But if you don't, all you'll hear is "edit <contents|blank>". There are ways around this (e.g., you can override label detection) but the "ideal" state is that the screen reader picks up that stuff automatically and you just give it the bounds of the various controls and UI elements.
It’s potentially a dealbreaker for millions of people whether they want it to be or not unfortunately. For them accessibility is not optional or can otherwise be taken as a “wait and see” issue.
gpui does have a11y support for accessibility, Zed just hasn't piped it through yet. I'm also pretty sure Discord is using their own fork of gpui with patches to add any missing functionality they needed
weird how the website doesn't have a single screenshot on it, considering it's for a GRAPHICAL user interface. You'd think the examples page would have some screenshots, but in fact it's just example code snippets with no indication of what the code would render as.
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.
I use gpui-kit because it's far and away the prettiest toolkit for Rust and because the underlying gpui crate provides the nicest abstractions over state and async.
But gpui-kit is slop for clankers. The name change from gpui-component to gpui-kit was messy with lots of dangling links remaining for weeks. What little documentation exists is impenetrable Claude speak or buried in "skills.md" files. The APIs are typically incomplete in a way that a human would've never signed off on. e.g. there's no way to enumerate the backing contents of combo boxes, there are multiple tooltip APIs (but even then only buttons can get tooltips). Mac support is clearly just a checkmark that no human has ever looked at (e.g. the way in which menus are mangled). The examples are unhelpful here because, well, see the second point.
Not a bad showing for what's mostly a one man show. But that raises the second problem. Zed's largely distanced themselves from the open source version of gpui and gpui-kit has one human developer. It's a rickety foundation for a commercial app (which is likely why Discord appears to have forked gpui).
Based on Zed's gpui but we have applied a lot of patches so it's basically a private fork at this point. We're hoping to work with Zed to upstream these patches!
Yes, check if you want. I don't even mind AI but snarkily recommending your own project (which has an extremely "default vibed" landing page) as if it's an established tool is bad manners.
There was no "snark" intended, Nick. GPUI is simply the wrong approach here. Read the dozens of other comments in this thread regarding immaturity, in-accessibility, and overall unsuitability of that kind of framework for this kind of application. If you have some kind of counter-argument to that, then make it.
How about you step back and take a 5-minute look at the project and check your own snark.
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.
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.
> 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.
That's is not about just Rust ... Any domain has its own optimal or sub-optimal language describing it. Criteria of optimality is a bit subjective of course. Like: INI, TOML, YAML, etc. are better (YMMV, again) for user facing configs than JSON or XML and so on.
I think that HTML is better for defining hierarchical UI structures and CSS and CSS selectors are (arguably again) better to define UI styling.
My Sciter[1] was initially using .FRM alike inputs (VisualBasic forms, good for IDE but bad for a human) but I quickly discovered that having styles, structure and code-behind-UI in single PL makes non-manageable mess. So Sciter uses HTML, CSS and JS we all familiar with. Not 100% match of course but good enough.
My experience has been that DSLs don't scale well. For simple things they provide a veneer of ease-of-use but eventually they were an albatross with Chef just as they were with QML and Slint. With both Slint and various Qt bindings for Rust marshalling data between Rust and the UI is painful. With Slint you get the added bonus of things just not yet existing in the DSL. That's a result of both immaturity and a strong focus on mobile at the expense of desktop. But the result is same. gpui has a killer dock widget, QML has the primitives to approximate one, and it's pretty much a no-go with Slint (though there's a third-party dock widget for Slint it's written in C++).
Here's a more idiomatic version of the previous example. IME gpui (and iced) is a lot easier to extend than something with a DSL, and if you check out the gpui example you'll see that gpui provides convenient methods to get consistent styles vs the Slint example where you hardcode widths and sizes. Those hex color abbreviations give me a facial tic every single time.
Slint is proprietary though, so that’s a dead end. I’m not going to use something which will inevitably be rug-pulled when you sell to private capital.
Slint is an open source, free software. The whole framework is on GitHub. A rug pull can't take back what's already released, and one could always fork if needed.
Btw, a rug pull can happen under even the most permissive licenses. As we've seen in the past with some project changing license or direction. That's more or less already happened with GPUI when Zed refocused development on its own needs rather than other GPUI users resulting in several forks.
I'm not sure it matters anymore unfortunately. I've vibe coded a few apps using gpui-kit and it works well. It helps that gpui-kit provides a number of high quality components (e.g. the data table is especially good). But even where it doesn't (e.g. log output) Opus 5.5 was able to easily write one that worked perfectly.
It even added ANSI colour support... which I am still on the fence about but it did make the very good point that it means the logging is exactly the same in GUI and CLI mode.
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.
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).
Well, keep in mind that you’re not expected to have the entire UI in one statement. You’re supposed to break this up into functions. That’s why stuff like Flutter and SwiftUI work.
Also, this is basically what Tailwind code looks like.
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!
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?
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.
> How is this different from when you join a company and learn your corner of the codebase?
Because most AI generated code is incredibly verbose and noisy. This can be true for any codebase, but it is especially egregious in AI codebases. It is hard to prevent that by just saying "be concise" because knowing exactly where to be concise is the measure of true skill/intelligence.
Every time I have success with AI coding, it is because whatever I need done can work as a pure function, where the probability I have to return to it is very very low.
Making sense of a codebase is like putting together a puzzle. A purely AI generated codebase is like trying to put it together without a picture on the pieces.
This is more like ALL the developers have just joined a company where no other devs work and can pass along institutional knowledge. You know, the thing that makes all that complexity wieldy.
I think if people change their mind in six months, let alone 3 years, they would just rewrite it again with something different, or just double down on the AI rewrite to rewrite the rewrite to fix the gaps and so on. It's a rabbit hole.
What people are completely missing with AI is that when a company/someone makes the decision (which is most these days) to go heavily on the AI route, they are probably going to keep going that way.
We don't really know what’s the right balance of AI and People right now.
My personal take would be to leverage AI to fix and improve what already exists in a maintainable way and wait for others to experiment with going heavily AI. It's worked great for Apple who is generally years behind in a lot of things because they wait it out for others to experiment with things.
Back in the day you'd read reference manuals which would tell you about the library, they might be hand written or a listing of the addresses and names. Today in the modern day, we still use reference manuals for writing C and C++. It's just encoded in websites, e.g. https://pubs.opengroup.org/onlinepubs/9699919799/functions/c... and https://en.cppreference.com/
But there are still libraries where familiarising yourself with the header is important, for example stb's libraries. man(1) and GNU Info were both invented to be computer-stored reference manuals, and indeed to this day you can type `man 3p open` to get the POSIX documentation of the system up in front of you.
I am not aware of many codebases that have manuals as complete as this, but back in the day (1970s-era to the 1990s-era) there would be internal documentation written as par of course for the specification created by the waterfall model of development. Post-2010 companies are very lackadaisical about documenting internal interfaces and libraries because they come from startup cultures where "move fast and break things" is the name of the game.
> How much time do you spend surfing through your .o or .obj files today?
Those are not the source of truth for the application logic. But the higher level code is.
The application code describes the behavior of the program and the compiler translates it into a different representation following a set of known, deterministic rules. This is unlike an LLM producing code from a prompt, which is why the source code is still the source of truth, and not a bunch of prompts.
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 share the intuition but pragmatically if the codebase will only ever be interacted with through AI agents it probably is nothing and wouldn't matter anyway. You can probably even generate an exhaustive amount of documentation instantaneously if you are concerned about a human knowing their way around.
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?
With GPUI quite a lot can be shared. Styling is similar, components can have same names. If your application logic is already cleanly separated, the resulting code can be quite similar.
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.
They know the tires are rated for hitting a landing strip under XYZ conditions, they know how to test the tires to ensure they're still confirming to the expectations of that rating, and they're in contact with the trusted organization that's responsible for issuing that rating. Each expert has a comprehensive understanding of their field, and the fields comfortably overlap with no gaps. For any given perspective, there are several people with the complete picture of that perspective.
Contrast this with a vibe-coded "airplane" where nobody actually understands the tires and you're basically operating on a set of assumptions. The tires are not rated and there's no trusted organization. Maybe it works, but you don't actually know. Very different; don't play language games.
You're putting forth a ridiculous argument. An airplane engineer doesn't need to know how to create the universe from scratch just to work their way up to maintaining airplanes, but they sure as hell understand how the major systems work, how those systems interact, and how to diagnose problems. They don't just tinker around blindly.
It's funny that I was just having this discussion with somebody yesterday. I guess it's always a question of degree. An airplane engineer may still not need to know every bit of detail regarding how all of their tools are produced before they can make use of the tools to build an airplane. But I agree that you raised a valid point in that at least they know how the components of an airplane itself fit together. Maybe it would be similar to how software engineers don't necessarily need to know all the details about how a computer is built (even though in some cases this would be beneficial), but if they don't even have the understanding of the actual _software_, building which is literally their job, it might be going too far. Similarly, a car driver doesn't necessarily need to know all the mechanics about a car, but is a software engineer more like a car driver or a car builder? Or indeed, is what we're currently doing with agents akin to wielding tools to build a system, which we still understand on a high level, or driving a black box? There is a balance there which people are still figuring out as everything is still rapidly in flux.
My understanding was that for every component there's someone somewhere who understands exactly how it works at least in terms of smaller components/abstractions and for each of those, recursively, someone knows how it works
This sounds awfully like the self-soothing mantra slop-kiddies everywhere tell themselves.
Plenty of people have a deep understanding of software/hardware, as that's the context here. I personally can take you from usermode, through the kernel (both NT and Linux), down to the hardware interface, explaining the vast majority of systems along the way, and critically, as they relate to performance concerns.
So can plenty of others who actually know+understand things.
You picked very bad examples. There are plenty of people who know exactly how everything in a plane or car works, how taxes work, how medical billing works, how a Cpu works.
Cal used to require EECS students learn how to make a basic CPU. Students at CalTech learn how to make advanced planes as student projects.
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.
More than that: it's a full browser that doesn't share any of the system browser libraries (using it's own browser engine) and also NodeJS. You can often save almost ~300-500 megabytes by switching to something like Tauri (even Tauri+NodeJS) that uses the system's own browser framework.
... EMACS is a full word processor? It's a bit spartan in terms of how the interface feels, but functionally it's a lot better than what modern writers get given in vibecoded packages
they recently added google searchability or something adjacent to that. I received a lot of pings in various discord servers about it being opt-out and that by default my messages are searchable now apparently
Discord even sends its DPO (data protection officer/privacy team) tickets to outsourced offshore copy & paste template support farms/AI chatbots. I've requested my data numerous times, half of the time the ticket was closed without a response, and the ones that DID get a response were the same copy & paste template telling me my data package is being generated.
All data packages were missing 90% of my account data (bug? size issue with zip files?), no avenue to report this to Discord of course, because the only words their "privacy team" know is... :^)
I was going to paste exactly what they sent me, but it turns out some of my data request tickets have been deleted by them.
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.
Perhaps https://flatpak.github.io/xdg-desktop-portal/docs/doc-org.fr... ? From a quick skim of the page it's not immediately obvious if that actually will allow PTT to work, though; I'm only suspecting that because I don't see any of its siblings that would even conceivably allow for PTT.
No clue if it's possible or not. I was not able to find any way to do it when I last checked around a year ago, but maybe something has changed since then, or maybe it just isn't implemented in Firefox yet.
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.
Can someone explain to me why a text editor needs to be GPU-accelerated? Literally, you are only blitting a few icons and painting text. What am I missing? To be clear, I am not here to doubt that the toolkit is good. Rather, I am asking why is "GPU-accelerated" important? Most people in 2026 that use an IDE are also equipped with a multi-GHz CPU has has plenty of compute to paint whatever pixels necessary at more than 60Hz refresh rate.
I think you underestimate how intense drawing text is, with all the aliasing and whatnot that goes on, spanning the full width of a 4k monitor, and don't realize all the IDEs you mention are GPU accelerated. You can get a feel for its worth by using a terminal that isn't GPU accelerated, or turn off GPU acceleration in VSCode, Microsoft office, etc. Add in images and video, and you get people complaining about poor battery life.
It's either you peg a CPU while simply scrolling, or your GPU does a small amount of power efficient, buttery smooth, work.
This is a very good reply! I stand corrected, and thank you to do so in a very polite and succinct manner. A better way to think about GPUs in 2026: They are used as a co-processor and are very efficient to paint pixels.
I tried Zed quite a bit and I didn’t noticed much performance difference vs VSCode. Might be an overrated angle even though developers eat that stuff up in marketing.
Zed's performance only really shows in huge windows, lots of layout things going on, big files, etc. Basic usage doesn't show it on modern high spec dev machines.
Can't confirm. Found it to be faster basically always. Starts FAST, opening a project or switching is "blink and you miss it", so is basically every dialog and menu
Fair point. It would be better to say: "Primarily text-based GUIs". I was looking for a good way to describe apps that are not primarly showing video or rendering 3D graphics.
a lot of discord is non-text. People share videos and images all the time. Everyone has profile pictures and profiles are customizeable with banners and animated backgrounds. It's not an IRC chatroom app.
If you're using an OS newer than Windows XP, then the app window is going to be rendered by a GPU-based compositor anyway. It's going to exist in VRAM either way. CPU-based rendering will just do extra work to upload the pixels to VRAM.
I don't know about GPUI in particular, but it's possible to make GPU-based rendering use less VRAM by generating graphics with shaders on the fly instead of using pre-rendered sprites/bitmaps like it used to be done with CPU-based rendering (e.g. computed gradients and drop shadows, large text rendered straight from curves instead of a prerendered atlas)
because OSes have different UI toolkits with their own vendor lock-in, quirks, limitations, preferred languages, legacy baggage, and random bursts of "everything is now deprecated except the newest fad which will be deprecated next year" and "we're making everything flat and/or semitransparent!". Then most of the time the stock widgets are too basic to even support what Discord wants. This is an expensive PITA to develop and test for, and it's what lead app developers to run away to Electron.
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...
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.
Haven't been checking this for 5 years but has something changed or there's still a risk that Discord will ban your account for not using the official client?
That part of the terms of service is still there, although they don't go out of their way to ban people unless they act like bots or whatever. I don't worry too much about Vencord, since all I'm using it for is editing CSS.
Discord could be knobheads about it, but I think they realise there's little point in actually implementing any checks and banning accounts unless said accounts actually cause problems. That section of the terms of service is probably there just as a catch-all just so they have a reason to ban, just so they don't need a good reason.
Who cares? I've never had performance issues with Slack, Discord and the like. It runs fast enough on my MBP. They could make it faster by removing the casino lights and prompts and upsells, and research other ways to monetize. Electron is not the issue with Discord, it's their constant annoying nagging.
Apps end up being implicitly targeted for performance at a certain level of computer. If your computer is faster than that level (which it seems it is), you won't face any problems. if your computer is slower, you will face problems.
But the kicker is, if everyone buys faster computers, the developers will correspondingly stuff more "features" in there to make it slower so the same number of people are still screwed. This is the recorded history of software engineering.
> They could make it faster by removing the casino lights and prompts and upsells, and research other ways to monetize. Electron is not the issue with Discord, it's their constant annoying nagging.
Amen. I hate Discord, and I loathe that I have to use it just because "gamers" use it and it became the default for video game communities.
A MacBook Pro is one of the most performant possible computers you could try this on. Electron apps are absolutely terrible without those kinds of resources (RAM especially). Keep in mind that Discord is also an app intended to be used by people who are gaming or streaming video as it’s original purpose, so it should be using as little CPU as possible to not interfere with e.g. the game.
Slack used to be a sizable portion of my old business stack on an 8GB X1 Carbon.
Windows doesnt leave you a lot of change from 8GB these days.
I used to have issues as Firefox would open a tab, cap out my available memory and 3cx would start stuttering causing voice issues.
The solution was to move to a carbon with 32GB RAM, but like, I should probably expect more out of Windows/Slack/3CX/Firefox in the first place. Feeding the beast more RAM is no longer a financially viable alternative for a lot of people.
I agree, but that's where we are and I've never been hampered. Electron is not going away.
I run Slack, Discord, Signal, Bitwarden, Asana, VS Code, GitHub - all idling quietly on a 16GB MPB M2. Was the same on my M2.
It's overblown, I don't care about Electron, how it's made (I understand how), who makes it, no dog in the hunt, but there is too much FUD about it, IMO.
In lot of corporate offices, it’s SFF and 1 liter desktops with 8 gb of ram and windows. You use Slack and Chrome, plus MDM software and you barely have enough compute left to move the cursor.
Yeah it's not as bad as people make it seem, but it's also far from ideal. Especially with how many tools we have nowadays to build performant desktop apps, a company of that size should really not be using electron if they know better.
I really feel for them. Back in the day I couldn't play a game while I had Skype open. I was so happy when my friend groups switched to TeamSpeak which used miniscule amount of resources in comparison to Skype. Well until 2015 came and we all switched to discord lol
Me, but also everyone a bit. Almost nobody cares about one of those applications in isolation. You start caring when you get a few of them and run out of ram. Sure, you can run Slack and Discord or something similar at the same time. But once you do, can you comfortably do other work without any visible slowdown? Or is this the threshold for "I need more than 8GB of ram?" You may be spending $ because of decisions like that.
Hot take: We should be able to comfortably run generic office desktops today with 4GB ram. We don't because too many people think "Who cares?"
I haven't run any laptop or a desktop with less than 16GB of RAM for over 2 decades. That's table stakes and a minimum. My uConsole CM5 Lite has 16GB. My 14 year old TP X230 has 32GB. I don't know what to tell you, if you want to swap to disk, then suffer the consequences.
1. You can't imagine that <8GB is enough for office work. It still is with enough care.
2. You can't imagine that a lot of this usage is waste. Sure you can buy more ram, but what if you needed half the memory and didn't swap?
I've got 30GB in use (some of it already compressed) and around 20GB of that is useless copies of some browser engine in various apps. It's insane that anyone is accepting that as table stakes and tells the user to "suffer the consequences" rather then raging at the current state of the industry.
We ran quick and responsive office suites in a fraction of that decades ago and 4GB in a common office machine should handle this just fine. (And still can on 8GB on a well configured machine. 4GB is tight but may be still comfortable on Linux)
No. I want the great native rewriting and de-Chroming to start, and I want the companies that don't follow to suffer the consequences of getting rejected from the more lean machines.
1. You can't imagine that <8GB is enough for office work. It still is with enough care.
Perhaps with DOS?
I don't need to imagine it, I've used 4/8GB early Airs, netbooks, slow Gateways and Dells. Turtles. I don't want to optimize my RAM. If something runs away, I'll kill it. I need more RAM. What you are saying is romantic in principle, and I don't disagree with the principle, but that's a dream and we need more RAM. I can subsist on rice and beans and tofu, but I don't want to.
Notable on the mobile app side that react native is getting tossed out along with electron.
It makes sense and I think they are going to be more teams moving in this direction.
Now that agents are good enough to one shot native UI from a Figma spec, these extra layers will be seen more as adding unnecessary complexity and ram bloat.
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.
The fragmentation around GPUI really is unfortunate. It seems to be the only framework that is complete enough for serious products. E.g. you can pair it with accesskit and have accessibility, it has a good number of components including difficult to write ones like text editors with highlighting.
I'm looking forward to Blitz personally. And I don't think it's true that it's the only complete enough solution as there are many in Rust like slint, iced, egui etc.
Slint yes but it’s commercial. Iced didn’t have a real accessibility story when I looked a few months ago. Ditto for egui. Also egui is immediate mode only which limits its general applicability.
Slint is under multiple license, including the open-source GPL and a royalty free license. What specifically bothers you about the licensing? (I work on Slint, genuinely curious)
Correct. This is a class of products that I really would rather not go commercial for. It's extremely difficult to change after the fact so from a business standpoint it puts us in a place where if the vendor decides to start cranking prices or they sell their business and the new owner does, then we are in a really difficult position.
It's not actually about paying money or not, I've signed up for many a patreon or what not to support open source projects I use. I fully believe in paying people for software. But for core things like this I do prefer MIT/APACHE.
My app is proprietary though, so I can't use the royalty free license. I've definitely licensed commercial software before. For example, I've licensed OCR software for many years.
The difference to me is that with OCR I can change it out with acceptable effort in the case that the vendor does something that we can't agree to. But it's just too hard to swap out a UI library. That's a major rewrite. It's too risky, to the point I'd rather spend resources bringing an MIT/APACHE UI kit up to my needs than risk being locked in with a vendor.
Yes it can be made accessible, it's just not in the repo and needs to be integrated with other libraries. Things like https://github.com/longbridge/gpui-kit do it for you.
Was no one else using Discord as a progressive web app, striking the best balance between resource footprint, no additional local apps on their device, still preserving their native UI, etc?
> Was no one else using Discord as a progressive web app
Going by me and my friends, no.
> striking the best balance between resource footprint
If this is the best balance possible, then that balance is horrible. Having to pull along a whole browser is a massive ball and chain on any program that I wish I could cut off anywhere I see it.
> no additional local apps on their device
This isn't an advantage for my use cases, nor any of my friends apparently.
> still preserving their native UI
As in preserving Discord's or your OS's UI?
I don't care about the former. I'd use DiscordMessenger[1] if it was mostly feature complete and Discord didn't ban third-party clients.
The latter isn't really preserved in any meaningful opinion by shoving it into a browser. The difference in UX post-install between a PWA and a seperate browser window (or a seperate app) is zero to me. It's still not native.
Electron apps do this. PWAs do not because you are already running the browser.
> > no additional local apps on their device
> This isn't an advantage for my use cases,
It objectively is, because (a) you don't have to run Electron next to a browser (b) your Electron app lags behind in security fixes compared to Chrome or whatever you use to browse, and (c) PWAs have a much stricter permission/capability model than native apps, so you can run PWAs from publishers you don't trust that much.
With a native app, which I still welcome for perf/mem reasons, I'll have to configure opensnitch (or smth of the sort) to take care of the outgoing telemetry calls... A system-wide uBO would be a nice to have!
Facebook is one of the worst places to build a community. You now have to pay to post more than two links a month, even.
And you might be impressed how far forums have come. Open source Discourse forum now has built-in Discord like voice and video chat, along with real time text posts. (It also powers some extremely large communities with millions of users.)
Oh I agree in general, I don't have FB. And discourse forum is probably what I would have tried too, but can it really scale to millions of active users? The largest I know are some linux forums, but they are way smaller.
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.
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.
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?
Yeah a few of those projects have existed for a while, but certainly things have picked up steam with the emergence of better LLMs. The issue with third-party clients is that Discord doesn't like them, and you're in violation of their ToS, meaning they can ban your account at any time. A bit risky, if you're networked into a bunch of communities (unfortunately so, but the effect is rather strong).
I actually really dislike the zed diff viewer. I tried to like it many times, couldn't get used to it. That's why I was still just using VSCode. That was about 6 months ago, so maybe I should take another look tho
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.
Outside of macOS/iOS (maybe Android too?) there isn't really any guaranteed consistency between native apps on the platform because there are multiple options for native UI toolkits which render differently. Plus, designers would rather have a consistent (unique/recognizable) look across platforms.
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.
I hope that next apps that use Electron will ditch it for native technologies, maybe for Rust or C++. Please, Spotify, do the same. Look at Telegram's working speed and performance.
99% of the important parts here are not Rust itself but whatever stack is drawing the UI. This whole article is based on a Twitter post, except it's longer yet still has info missing, so I just went to https://x.com/svishnevskiy/status/2118081920194203799 and the answer is GPUI.
Only true today for Linux. For both Windows and Mac we ship an ARM64 client. With this new Rust version we're also going to ship an ARM64 Linux client.
I didn't see it mentioned in the article, but does this mean that you will no longer be able to use Discord exclusively via the browser, without installing a native app? Because that's my preferred way to use Discord, since the browser nicely sandboxes it, whereas a native application generally runs unrestricted.
Microsoft has already had execs saying the next big thing is AI rewriting stuff to Rust. You think you are joking, but I'm sure it is on someone's roadmap in the Teams org.
Of course, being the Teams org they'd likely still find a way to end up with a bloated mess even after a Rust rewrite.
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
We need all the apps, websites etc services to take time to optimize their stuff for RAM, CPU use etc.. it's nuts we have these insanely powerful devices and crappy software and sites can bring them to their knees.
I highly doubt they'd throw away decade of engineering of the JavaScript application, to rewrite it from scratch using native platform UIs. Probably would change desktop wrapper from Electron to Tauri or something else
In what way it isn't free? The LGPL license is fine for Discord's use case. There's only a small number of components that are GPL-only that would otherwise require the commercial license but none of them are required for Discord to work, all of the important ones are LGPL.
What?? As much as I despise Discord this is a positive trend, hope other companies follow suit. Javascript on desktop is a plague on computing and the sooner it dies, the better.
Hey, I work at Discord, specifically on this effort. Our entire focus here has been about improving performance and making the client really feel great.
It's difficult to believe Discord's intent is to make the client great when the recent updates have been to shove Best Buy ads into it. Even to the point of surfacing ads as friend dm notifications! In fairness, I'm jaded since I lost my account due to a sudden ultimatum to share my phone number -- extortion for my PII. So it is impossible for me to believe Discord operates in good faith.
In fairness these are probably distinct teams at discord. A team of engineers focused on performance probably _genuinely_ cares about that.
But there’s other teams and forces at play as well. So I agree with your overall sentiment but the SDEs who worked on this are perhaps not the ones shovelling adware into our faces.
This is a fair point, but it's basically being proud of making the monstrous privacy-destroying ad machine go 10% faster. With how they pressure people to doxx themselves to them (phone number verification) or be completely locked out of their accounts, there is enough predatory tactics in that company that no one should feel proud of working there.
I don't work at Discord, but I know of very few companies that don't have "malicious" tactics in one sense or another. Ultimately they are trying to improve their own bottom line and that _rarely_ aligns with what's best for people.
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.
Discord says using modified or alternative clients is against their terms of service, and they have banned people for it in the past (if they do something detectable, like enabling A/B testing feature flags that their account ID doesn't match :/)
They're not exactly friendly to that sort of thing, I wouldn't be surprised if they add some traps to catch people making their own client.
So I'd +1 the sibling comment's suggestion to consider alternatives to Discord, if you're setting up your own community
> So then hide your client better? Just because a company has a policy does not mean you need to follow it.
How, it sounds like they're trying to catch you, e.g. I took...
> and they have banned people for it in the past (if they do something detectable, like enabling A/B testing feature flags that their account ID doesn't match :/)
...to mean they push out changes just to detect the clients who don't conform. I'm sure they could be very sneaky about it in a way that would be hard to "just do better" For instance: have some client behavior change that's hidden behind a feature flag or even calendar date, wait a long time until all official clients are updated, then trigger it and ban the laggards who can be assumed to be using an unofficial client.
Since discord announced that they would be scanning ID a lot of alternatives have sprung up, chatto and Armada are both looking promising as alternatives, plus the chatto vibed marketing materials on their Dev chat gave me a laugh the other week!
I like matrix, its like the new IRC for almost real time developer chat, I also do this via Discord but I'd prefer an open alternative. If you have experience running a matrix server do you find the data storage an issue? It sounded like if you federate and join the bigger channels you can balloon your storage pretty fast.
I mostly host for myself and a couple friends, so data storage hasn't been an issue. I'm sure at some point I may need to prune the attachment store, but I put it on a spinning HDD so capacity isn't an issue. (You can rent a storage VPS and those tend to have oodles of disk space.)
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.
There are literally dozens of open-source Discord clients already, both vibe-coded and not; and have been for many years. Nobody needed to prove this was possible, least of all Discord.
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.
As well as literally any other Chinese / open model.
I'm not surprised Anthropic and OpenAI are trying their best to ban / severely handicap competition and crack down on opensource. It's a major threat to their existence.
From the article itself, "Regarding the blocking of reverse engineering, we have received direct confirmations. The first comes from our own alumnus Jarred Walton, who was trying to run checks on the software he's developing. He notes that such work had been performed with no issue until yesterday, October 31, and that switching to Opus 4.8 let him continue his work."
Just tossed the clanker at some stuff in Cyberpunk 2077, seems to be reversing it fine. Mind you I’m using my Claude sub in OMP so maybe I’m getting a less shitty system prompt (also I have the defensive CVP which presumably allows a lil more rev work than normal, though it’s still not enough for interesting things on Opus 5.5)
It’d probably be trickier with multiplayer games given the slopmachine would probably assume you wanna cheat in it
Please don't post snark like this on HN. It's not what this site is for, and destroys what it is for. If you wouldn't mind reviewing https://news.ycombinator.com/newsguidelines.html and taking the intended spirit of the site to heart, we'd be grateful.
Also most native UI frameworks don't provide the primitives for modern UI. It's mostly just standard UI elements, sometimes with the possibility to theme them.
But most frameworks don't come even close to CSS and all the possibilities to create custom controls. It often requires to build everything from scratch in code, which is really hard for more complex layouts.
One could reply that it's a feature, since native UIs are more uniform and with less surprises you can concentrate on whatever the fuck you're doing instead of wondering what this app's designer was smoking.
Depends on the UI framework. Most frameworks don't have enough features to make the UI actually good. It's not even about looks, much more about layout. CSS is really good with conditional layout: hide something and everything reflows around it, responsive layout (not just mobile, but also when making app windows smaller/larger). Typography is another issue with a lot of native UI frameworks. Even adaptive DPI support is not yet easy with most native frameworks.
Also things like accessibility. It's quite easy to make web ui accessible, much harder to do it with custom native control.
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.
Maybe that was true in the past but it has definitely not been the case for the past 15 or 20 years for web developers who actually don't know anything about native development.
Well if you put it that way, some of them don't even know anything about the browser technology that powers their JavaScript framework used to generate static content.
So, you're saying that the person you're responding to is really saying, "Developers are too disabled to write native applications"? No, that's nonsense. "Laziness" is not the reason for Electron applications, but neither does it implicate disability in this context.
Incidentally, I think it's kind of ableist to toss around the concept of ableism this lightly. Disability is a set of concrete barriers which go unacknowledged and a set of real accommodations which go unimplemented. Disability activism entails acknowledging those barriers and implementing those accommodations; it does not entail the idea that everyone is always trying their best and nobody is ever negligent.
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).
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.
Well, Discord is a pretty complex app. It’s loading/caching images, subscribing to many chats at once, needs to be able to hop into a call at any time, and also renders (most) arbitrary Markdown.
SO annoying that pay only subscription only articles continue to rank in the top pages of this.. a paid only or subscription only article that is not accessible to everyone should automatically no be considered for 1st page ranking
I don't know about that.
I am porting my Rust slop to Go and Zig simultaneously right now and the LLM is finding bugs in the Rust code as it is generating the Go and Zig code.
But.. maybe, maybe this is the opposite of google translate in the 00's - maybe, if you keep porting back and forth, you will eventually arrive at perfection :P
It's not about the bugs we fix, but the bugs we make along the way
I've found multiple passes with different models & 100% line coverage help. Need to push further with fixing. Coverage requirements also cut down on duplication (not entirely, still need to be vigilant) since it increases effort having to include coverage on new code
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.
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.
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)
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.
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).
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)
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/
The fact they're using gpui is... Bad. Is someone trying to make it integrate with native accessibility frameworks? If not (and if they force the native app on us) this transition is going to lock out a ton of people who use assistive technologies.
Yes, see: https://github.com/longbridge/gpui-kit. I've been following these rust UI toolkits and things like accessibility have consistently been missing. This is the first time I've seen a UI library that appears complete enough to build a real product with.
Yeah, that's what worries me. Pretty much every Rust UI library I've seen which isn't wxdragon/Relm/GTK lacks accessibility. And most of them don't even have the primitives for it (given that most of them are abandoned).
This response doesn't make sense?
GP you asked if there is accessibility P response: yes, here You then respond that worries you and dismiss the proof?
> This response doesn't make sense?
Apologies. I was noting that the lack of accessibility worried me (well, and weird accessibility breakage too).
You are dismissing again the answer you are getting. Why do you think it is lacking accessibility despite using a framework claiming " GPUI Kit ships 75+ documented components and primitives, WebAssembly support, AccessKit accessibility"
To be clear, GPUI Kit is not the same as GPUI. I am not sure if Discord is using GPUI Kit, but accessibility natively is possible with either.
It's reasonable to be concerned that Discord may not have focused on accessibility while rewriting.
It's less reasonable to be concerned that it may be impossible to write accessible apps using GPUI, as that is now possible (https://github.com/zed-industries/zed/blob/main/crates/gpui/...) although this is a fairly recent addition.
It's also less reasonable to assume that an app made with GPUI Kit will automatically be accessible. You still need to put effort into it.
I don't know why people are ignoring the pink elephant here. For medium scale projects, like a Discord app is going to be, LLMs are now at a superhuman level of competence, including on higher level architectural/structural type decisions. I would be beyond surprised if the rewrite wasn't largely done by Claude (or similar). And in this context accessibility is also just a prompt away, if it wasn't included from the get-go, which it probably would have been.
Accessibility isn't just something you one-shot. It takes a lot of back-and-forth and testing with actual screen readers/accessibility scanning tools to be good.
I'm not dismissing it, just uncertain how good it is. Quality over quantity and all that. You can have 75 or 100 or 200 UI components and some can be perfectly accessible while others might not be even things accesskit supports right now. Or Accesskit may only partially support a widget. As I've said downthread, I'm hoping that Discord using a UI toolkit like this will cause upstream effects with respect to Accesskit coverage, so we'll have to see when they start migrating people over to it.
This is exactly why I started working on Day (https://daybrite.dev) as a successor to Skip (https://skip.dev). It uses platform-native toolkits everywhere, and so accessibility comes for free.
I haven't exactly "launched" it yet, but I'm already shipping apps through the App/Play Stores. See https://daybrite.dev/showcase/ for the 5-minute tour.
Oh that looks fricking neat! Might wanna port my little diff-tool to this for funsies!
It was real world use by COSMIC that motivated Iced to add a11y support in the first place
So Discord using gpui could mean it may get the needed features
COSMIC runs a fork of iced and things don’t make it back upstream nearly fast enough due to the one-maintainer-bus-factor.
You can’t exactly lump them together.
I don't understand. You can do accessibility with GPUI today. I linked a repo that shows how.
Yes, and this is good progress (my comment downthread was before I just looked). According to it it uses accesskit, which is quite good already but still in development so accessibility would not be as good as using UIA directly. I am hopeful though that accesskit (which is also used in Godot) will keep getting better and these gaps can be closed.
Yeah, and big products like discord using them should help push that along.
Turns out the browser (electron) wasn‘t always horrible after all.
This is one angle. I do not see it as a deal breaker in the way you phrase it. I suppose we all have our own. If everyone's had to be satisfied, we'd have no software!
I think in the specific case of Discord, I.e. from a big company, I agree they should handle this properly. As a broader standard, I am not as concerned.
This is a dealbreaker for me even if I didn't want it to be. If your application does not either interact with a11y frameworks (UIA, AT-SPI, NSAccessibility, ...) or does not implement an equivalent that communicates with my screen reader, I literally cannot use your application. I could OCR your application, or use AI and have it use your app for me via screenshots, but neither are even remotely comparable to using the native platform accessibility frameworks.
Could someone use AI to make the GPUI kit become accessible? You (or someone else) mentioned that it doesn't even have the primitives so is it a non starter?
No, I mentioned that most rust UI toolkits lack even the primitives. The primitives for even basic accessibility, without accessibility frameworks, would be things like focus events, carrot navigation, navigation in containers such as list/combo boxes, line/paragraph handling in multi-line edit boxes and the like. Adding native accessibility forces you to do a lot of this but just in a different way than routing text directly to a screen reader.
As for me doing it? According to prior comments in this thread it's already done, although I haven't tested it so I don't know how complete it is. Adding UIA support to a framework is different from making that support good (screen readers can be very picky). As an example, say you have a label of an edit box. If you position the label just right within it's parent container a screen reader will pick it up automatically and just announce it as you focus the edit box. But if you don't, all you'll hear is "edit <contents|blank>". There are ways around this (e.g., you can override label detection) but the "ideal" state is that the screen reader picks up that stuff automatically and you just give it the bounds of the various controls and UI elements.
It’s potentially a dealbreaker for millions of people whether they want it to be or not unfortunately. For them accessibility is not optional or can otherwise be taken as a “wait and see” issue.
Neatly phrased comment, where „fuck the blind“ would have sufficed.
gpui does have a11y support for accessibility, Zed just hasn't piped it through yet. I'm also pretty sure Discord is using their own fork of gpui with patches to add any missing functionality they needed
I really hope Zed gets in the support, I'm curious to try it given all the good things said about it (particularly on HN :))
Could maybe use the browser client as a workaround.
Considering the fact that the gpui code only exists as a crate under the zed repo, I'd say you are correct.
weird how the website doesn't have a single screenshot on it, considering it's for a GRAPHICAL user interface. You'd think the examples page would have some screenshots, but in fact it's just example code snippets with no indication of what the code would render as.
[1] https://gpui.rs/
[2] https://gpui.rs/examples/
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
I use gpui-kit because it's far and away the prettiest toolkit for Rust and because the underlying gpui crate provides the nicest abstractions over state and async.
But gpui-kit is slop for clankers. The name change from gpui-component to gpui-kit was messy with lots of dangling links remaining for weeks. What little documentation exists is impenetrable Claude speak or buried in "skills.md" files. The APIs are typically incomplete in a way that a human would've never signed off on. e.g. there's no way to enumerate the backing contents of combo boxes, there are multiple tooltip APIs (but even then only buttons can get tooltips). Mac support is clearly just a checkmark that no human has ever looked at (e.g. the way in which menus are mangled). The examples are unhelpful here because, well, see the second point.
Not a bad showing for what's mostly a one man show. But that raises the second problem. Zed's largely distanced themselves from the open source version of gpui and gpui-kit has one human developer. It's a rickety foundation for a commercial app (which is likely why Discord appears to have forked gpui).
Thanks for the extra context, definitely useful to know.
We're using GPUI for this.
Are you using Zed's crate or a private fork?
Based on Zed's gpui but we have applied a lot of patches so it's basically a private fork at this point. We're hoping to work with Zed to upstream these patches!
> We're hoping to work with Zed to upstream these patches!
Yes please. The GPUI ecosystem is too fragmented
[flagged]
Looks like vibeslorp. Just checked the GitHub and I see you created it. Come on man.
[x] rule of three
[x] smallcaps headings
[x] it's not this, it's that
[x] comically overselling marketing language
[x] detached third person perspective
slop confirmed
Absolutely none of those bullet-critiques are accurate.
And do you really think that? Did you look at https://daybrite.dev/showcase/?
Funny. Have you ever built anything?
Yes, check if you want. I don't even mind AI but snarkily recommending your own project (which has an extremely "default vibed" landing page) as if it's an established tool is bad manners.
There was no "snark" intended, Nick. GPUI is simply the wrong approach here. Read the dozens of other comments in this thread regarding immaturity, in-accessibility, and overall unsuitability of that kind of framework for this kind of application. If you have some kind of counter-argument to that, then make it.
How about you step back and take a 5-minute look at the project and check your own snark.
that's loser talk right there.
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
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"
Could you link this bug report please? I would love to take a look at it to see if i could fix it
https://github.com/zed-industries/zed/issues/38109
Opened a year ago. Still comments this week.
I would also be wary of doing this in Rust because the GUI framework story is very much not finished
> I had trouble reading more than the opening volley of the article due to popups.
Why do people not use adblockers even this late since their introduction?
iPhone
There are adblockers on phones including iPhones too.
I use a DNS one but it's not perfect.
AdGuard and similar free ones via VPN are good.
please download uBlock Origin from the App Store
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...> 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.
That's is not about just Rust ... Any domain has its own optimal or sub-optimal language describing it. Criteria of optimality is a bit subjective of course. Like: INI, TOML, YAML, etc. are better (YMMV, again) for user facing configs than JSON or XML and so on.
I think that HTML is better for defining hierarchical UI structures and CSS and CSS selectors are (arguably again) better to define UI styling.
My Sciter[1] was initially using .FRM alike inputs (VisualBasic forms, good for IDE but bad for a human) but I quickly discovered that having styles, structure and code-behind-UI in single PL makes non-manageable mess. So Sciter uses HTML, CSS and JS we all familiar with. Not 100% match of course but good enough.
[1] https://sciter.com
I love Sciter, but the curse of Discord is bloated web.
They have no shame in deploying a 300 MB hot mess bundle.
My experience has been that DSLs don't scale well. For simple things they provide a veneer of ease-of-use but eventually they were an albatross with Chef just as they were with QML and Slint. With both Slint and various Qt bindings for Rust marshalling data between Rust and the UI is painful. With Slint you get the added bonus of things just not yet existing in the DSL. That's a result of both immaturity and a strong focus on mobile at the expense of desktop. But the result is same. gpui has a killer dock widget, QML has the primitives to approximate one, and it's pretty much a no-go with Slint (though there's a third-party dock widget for Slint it's written in C++).
Here's a more idiomatic version of the previous example. IME gpui (and iced) is a lot easier to extend than something with a DSL, and if you check out the gpui example you'll see that gpui provides convenient methods to get consistent styles vs the Slint example where you hardcode widths and sizes. Those hex color abbreviations give me a facial tic every single time.
Slint is proprietary though, so that’s a dead end. I’m not going to use something which will inevitably be rug-pulled when you sell to private capital.
Slint is an open source, free software. The whole framework is on GitHub. A rug pull can't take back what's already released, and one could always fork if needed.
Btw, a rug pull can happen under even the most permissive licenses. As we've seen in the past with some project changing license or direction. That's more or less already happened with GPUI when Zed refocused development on its own needs rather than other GPUI users resulting in several forks.
I'm not sure it matters anymore unfortunately. I've vibe coded a few apps using gpui-kit and it works well. It helps that gpui-kit provides a number of high quality components (e.g. the data table is especially good). But even where it doesn't (e.g. log output) Opus 5.5 was able to easily write one that worked perfectly.
It even added ANSI colour support... which I am still on the fence about but it did make the very good point that it means the logging is exactly the same in GUI and CLI mode.
isn't that basically QML?
> 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
> .border(1 0x0000ff)
After 10 or so of those you'll start dreaming of
right?If you're dreaming, why would you stop at that when you could dream of much more visually compelling solid left thick border in a single symbol
┠
or more explicitly
├2
that'd be perfectly paired with a dream-like visual designer that doesn't exist?
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).
This is basically what coding UI in Bevy was like before the `bsn!` macro
Well, keep in mind that you’re not expected to have the entire UI in one statement. You’re supposed to break this up into functions. That’s why stuff like Flutter and SwiftUI work.
Also, this is basically what Tailwind code looks like.
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'm never going to complain about SwiftUI again
HTML and CSS, for all their faults, are the best layout engine we have.
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.
Honestly I'd pick this over whatever is going on with tailwind.
On a more serious note I feel like it's not bad but could be improved if they managed to break it down by styling domain (sort of like SwiftUI).
Something along the lines of .flex(gap: 2).text(size: "xl", color: ...)
honestly I'm not sure why they didn't choose to define a curated subset of HTML/CSS and use a parser. That's what the code is defining anyway
One person's mess is another person's Tailwind
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?
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.
I believe institutional knowledge used to work on a ship of Theseus model. It's going to be completely different going forward.
> How is this different from when you join a company and learn your corner of the codebase?
Because most AI generated code is incredibly verbose and noisy. This can be true for any codebase, but it is especially egregious in AI codebases. It is hard to prevent that by just saying "be concise" because knowing exactly where to be concise is the measure of true skill/intelligence.
Every time I have success with AI coding, it is because whatever I need done can work as a pure function, where the probability I have to return to it is very very low.
Making sense of a codebase is like putting together a puzzle. A purely AI generated codebase is like trying to put it together without a picture on the pieces.
This is more like ALL the developers have just joined a company where no other devs work and can pass along institutional knowledge. You know, the thing that makes all that complexity wieldy.
>change your mind in 3 years
I think if people change their mind in six months, let alone 3 years, they would just rewrite it again with something different, or just double down on the AI rewrite to rewrite the rewrite to fix the gaps and so on. It's a rabbit hole.
What people are completely missing with AI is that when a company/someone makes the decision (which is most these days) to go heavily on the AI route, they are probably going to keep going that way.
We don't really know what’s the right balance of AI and People right now.
My personal take would be to leverage AI to fix and improve what already exists in a maintainable way and wait for others to experiment with going heavily AI. It's worked great for Apple who is generally years behind in a lot of things because they wait it out for others to experiment with things.
I don’t think this changes just because you don’t do a rewrite. This is happening already as engineering leans more on AI tools in our own company.
Things ship and change way too fast and the changes are massive.
Also Reflections on Trusting Trust taken to a whole new level.
I'd say they're betting on AI getting good and reliable enough to not have to go back to the "old" practice.
But are they betting more than they can afford to lose, is the thing.
Yes, I wouldn't make that bet.
Brother, me neither. If you've done it for a while, maybe even reduced your staff or had a bunch of normal turnover in the interrim... ouch.
Once your shared mental model of how the codebase works is gone it seems practically impossible to get it back.
You won't want it back. How much time do you spend surfing through your .o or .obj files today?
Back in the day you'd read reference manuals which would tell you about the library, they might be hand written or a listing of the addresses and names. Today in the modern day, we still use reference manuals for writing C and C++. It's just encoded in websites, e.g. https://pubs.opengroup.org/onlinepubs/9699919799/functions/c... and https://en.cppreference.com/
But there are still libraries where familiarising yourself with the header is important, for example stb's libraries. man(1) and GNU Info were both invented to be computer-stored reference manuals, and indeed to this day you can type `man 3p open` to get the POSIX documentation of the system up in front of you.
I am not aware of many codebases that have manuals as complete as this, but back in the day (1970s-era to the 1990s-era) there would be internal documentation written as par of course for the specification created by the waterfall model of development. Post-2010 companies are very lackadaisical about documenting internal interfaces and libraries because they come from startup cultures where "move fast and break things" is the name of the game.
> How much time do you spend surfing through your .o or .obj files today?
Those are not the source of truth for the application logic. But the higher level code is.
The application code describes the behavior of the program and the compiler translates it into a different representation following a set of known, deterministic rules. This is unlike an LLM producing code from a prompt, which is why the source code is still the source of truth, and not a bunch of prompts.
Determinism is something you'll have to give up if you want to stay employed, I'm afraid.
The solution, as usual in engineering, is negative feedback. Unfortunately, many people around here think that means "Shoot the messenger."
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 share the intuition but pragmatically if the codebase will only ever be interacted with through AI agents it probably is nothing and wouldn't matter anyway. You can probably even generate an exhaustive amount of documentation instantaneously if you are concerned about a human knowing their way around.
Isn't that a concern peopld would have about all software? Not sure if there's something particular to a rewrite about this necessarily.
Would i rather have a massively bloated cross-platform electron app, or a native app in rust assisted by ai?
the native app wins every single time. Give me native or give me death!
You’d think we learned this during all the front-end rewrites of the 2010s…
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?
With GPUI quite a lot can be shared. Styling is similar, components can have same names. If your application logic is already cleanly separated, the resulting code can be quite similar.
I think there are lots of common patterns you find in GC’d languages that don’t translate well into idiomatic rust.
Consequently, porting my game engine from Java to Rust was more challenging than I had anticipated.
Your entire opinion is founded on assumptions.
[flagged]
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.
[flagged]
They know the tires are rated for hitting a landing strip under XYZ conditions, they know how to test the tires to ensure they're still confirming to the expectations of that rating, and they're in contact with the trusted organization that's responsible for issuing that rating. Each expert has a comprehensive understanding of their field, and the fields comfortably overlap with no gaps. For any given perspective, there are several people with the complete picture of that perspective.
Contrast this with a vibe-coded "airplane" where nobody actually understands the tires and you're basically operating on a set of assumptions. The tires are not rated and there's no trusted organization. Maybe it works, but you don't actually know. Very different; don't play language games.
You're putting forth a ridiculous argument. An airplane engineer doesn't need to know how to create the universe from scratch just to work their way up to maintaining airplanes, but they sure as hell understand how the major systems work, how those systems interact, and how to diagnose problems. They don't just tinker around blindly.
It's funny that I was just having this discussion with somebody yesterday. I guess it's always a question of degree. An airplane engineer may still not need to know every bit of detail regarding how all of their tools are produced before they can make use of the tools to build an airplane. But I agree that you raised a valid point in that at least they know how the components of an airplane itself fit together. Maybe it would be similar to how software engineers don't necessarily need to know all the details about how a computer is built (even though in some cases this would be beneficial), but if they don't even have the understanding of the actual _software_, building which is literally their job, it might be going too far. Similarly, a car driver doesn't necessarily need to know all the mechanics about a car, but is a software engineer more like a car driver or a car builder? Or indeed, is what we're currently doing with agents akin to wielding tools to build a system, which we still understand on a high level, or driving a black box? There is a balance there which people are still figuring out as everything is still rapidly in flux.
My understanding was that for every component there's someone somewhere who understands exactly how it works at least in terms of smaller components/abstractions and for each of those, recursively, someone knows how it works
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.
In my country in order to earn a true CS degree you need to learn both Chemistry and EE.
Also check the Homebrew CPU running a custom port of Minix 2 with in-place ported C compilers, linkers and assemblers.
I had to learn geology and engineering drawing, because the first two years syllabus overlapped with civil and electromechanical engineering.
"I'm clueless and don't know how anything works, therefore experts don't exist" is one of the worst takes to come out of this godforsaken tech.
This sounds awfully like the self-soothing mantra slop-kiddies everywhere tell themselves.
Plenty of people have a deep understanding of software/hardware, as that's the context here. I personally can take you from usermode, through the kernel (both NT and Linux), down to the hardware interface, explaining the vast majority of systems along the way, and critically, as they relate to performance concerns.
So can plenty of others who actually know+understand things.
You picked very bad examples. There are plenty of people who know exactly how everything in a plane or car works, how taxes work, how medical billing works, how a Cpu works.
Cal used to require EECS students learn how to make a basic CPU. Students at CalTech learn how to make advanced planes as student projects.
[dead]
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.
More than that: it's a full browser that doesn't share any of the system browser libraries (using it's own browser engine) and also NodeJS. You can often save almost ~300-500 megabytes by switching to something like Tauri (even Tauri+NodeJS) that uses the system's own browser framework.
I mean so is lynx
Lynx was created for UNIX systems that used around 8 MB, and was text only, JavaScript was yet to be invented.
Lynx is a "full browser" in the same way that Emacs is a "full word processor."
... EMACS is a full word processor? It's a bit spartan in terms of how the interface feels, but functionally it's a lot better than what modern writers get given in vibecoded packages
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.
Its not Tauri, they're using GPUI
You're right! Apologies. My brain saw Rust and Electron and went right to Tauri.
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.
Misinformation. Discord isn’t 10GB and nobody outside Discord has actually used the Rust port.
Source?
It's a joke.
In a perfect world it would be reduced to 0 MB.
https://news.ycombinator.com/item?id=30311982
they recently added google searchability or something adjacent to that. I received a lot of pings in various discord servers about it being opt-out and that by default my messages are searchable now apparently
Discord even sends its DPO (data protection officer/privacy team) tickets to outsourced offshore copy & paste template support farms/AI chatbots. I've requested my data numerous times, half of the time the ticket was closed without a response, and the ones that DID get a response were the same copy & paste template telling me my data package is being generated.
All data packages were missing 90% of my account data (bug? size issue with zip files?), no avenue to report this to Discord of course, because the only words their "privacy team" know is... :^)
I was going to paste exactly what they sent me, but it turns out some of my data request tickets have been deleted by them.
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...
I get a 404 for that link.
Perhaps https://flatpak.github.io/xdg-desktop-portal/docs/doc-org.fr... ? From a quick skim of the page it's not immediately obvious if that actually will allow PTT to work, though; I'm only suspecting that because I don't see any of its siblings that would even conceivably allow for PTT.
No clue if it's possible or not. I was not able to find any way to do it when I last checked around a year ago, but maybe something has changed since then, or maybe it just isn't implemented in Firefox yet.
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.
That is horrible, is it really that common that electron apps eventually consume all your storage with each update?
if the app cleaned up the update properly, then no. For example, signal desktop is fine.
I dont have discord, so what i said is just conjecture, but bad update files laying around isn't uncommon imho.
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.
Yeah I have to agree here - the days of being scared of complete rewrites are pretty much over.
> 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.
npm memes https://programmerhumor.io/javascript-memes/javascript-exper...
From the website https://gpui.rs/, I see this description:
Can someone explain to me why a text editor needs to be GPU-accelerated? Literally, you are only blitting a few icons and painting text. What am I missing? To be clear, I am not here to doubt that the toolkit is good. Rather, I am asking why is "GPU-accelerated" important? Most people in 2026 that use an IDE are also equipped with a multi-GHz CPU has has plenty of compute to paint whatever pixels necessary at more than 60Hz refresh rate.I think you underestimate how intense drawing text is, with all the aliasing and whatnot that goes on, spanning the full width of a 4k monitor, and don't realize all the IDEs you mention are GPU accelerated. You can get a feel for its worth by using a terminal that isn't GPU accelerated, or turn off GPU acceleration in VSCode, Microsoft office, etc. Add in images and video, and you get people complaining about poor battery life.
It's either you peg a CPU while simply scrolling, or your GPU does a small amount of power efficient, buttery smooth, work.
This is a very good reply! I stand corrected, and thank you to do so in a very polite and succinct manner. A better way to think about GPUs in 2026: They are used as a co-processor and are very efficient to paint pixels.
You can cache the glyphs in an atlas and avoid re-rendering each glyph every time. But this comes with its own complications and tradeoffs.
I tried Zed quite a bit and I didn’t noticed much performance difference vs VSCode. Might be an overrated angle even though developers eat that stuff up in marketing.
Zed's performance only really shows in huge windows, lots of layout things going on, big files, etc. Basic usage doesn't show it on modern high spec dev machines.
Can't confirm. Found it to be faster basically always. Starts FAST, opening a project or switching is "blink and you miss it", so is basically every dialog and menu
Discord is a text editor?
Fair point. It would be better to say: "Primarily text-based GUIs". I was looking for a good way to describe apps that are not primarly showing video or rendering 3D graphics.
a lot of discord is non-text. People share videos and images all the time. Everyone has profile pictures and profiles are customizeable with banners and animated backgrounds. It's not an IRC chatroom app.
Oh, so the reduction in RAM usage is going to mean it's going to use my precious VRAM instead? No thanks.
If you're using an OS newer than Windows XP, then the app window is going to be rendered by a GPU-based compositor anyway. It's going to exist in VRAM either way. CPU-based rendering will just do extra work to upload the pixels to VRAM.
I don't know about GPUI in particular, but it's possible to make GPU-based rendering use less VRAM by generating graphics with shaders on the fly instead of using pre-rendered sprites/bitmaps like it used to be done with CPU-based rendering (e.g. computed gradients and drop shadows, large text rendered straight from curves instead of a prerendered atlas)
Yeah, so why not use OS then for rendering and roll your own rendering pipeline?
because OSes have different UI toolkits with their own vendor lock-in, quirks, limitations, preferred languages, legacy baggage, and random bursts of "everything is now deprecated except the newest fad which will be deprecated next year" and "we're making everything flat and/or semitransparent!". Then most of the time the stock widgets are too basic to even support what Discord wants. This is an expensive PITA to develop and test for, and it's what lead app developers to run away to Electron.
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...
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.
Haven't been checking this for 5 years but has something changed or there's still a risk that Discord will ban your account for not using the official client?
That part of the terms of service is still there, although they don't go out of their way to ban people unless they act like bots or whatever. I don't worry too much about Vencord, since all I'm using it for is editing CSS.
Discord could be knobheads about it, but I think they realise there's little point in actually implementing any checks and banning accounts unless said accounts actually cause problems. That section of the terms of service is probably there just as a catch-all just so they have a reason to ban, just so they don't need a good reason.
Use ripcord
Ripcord's last official update was in 2021?[1] Why in the name of all that is holy would I use that?
[1] https://cancel.fm/ripcord/
it can send and receive messages what more do you want
Voice chat and functional sharescreen with audio on Linux.
It's abandoned. Does it even work anymore? Or are there thirdparty patches for it?
Who cares? I've never had performance issues with Slack, Discord and the like. It runs fast enough on my MBP. They could make it faster by removing the casino lights and prompts and upsells, and research other ways to monetize. Electron is not the issue with Discord, it's their constant annoying nagging.
Not everyone is on a Macbook Pro. There is an enormous addressible market of people on lower end devices.
Apps end up being implicitly targeted for performance at a certain level of computer. If your computer is faster than that level (which it seems it is), you won't face any problems. if your computer is slower, you will face problems.
But the kicker is, if everyone buys faster computers, the developers will correspondingly stuff more "features" in there to make it slower so the same number of people are still screwed. This is the recorded history of software engineering.
People playing games trying to squeeze out a few more frames.
Or a few more Eve clients
> They could make it faster by removing the casino lights and prompts and upsells, and research other ways to monetize. Electron is not the issue with Discord, it's their constant annoying nagging.
Amen. I hate Discord, and I loathe that I have to use it just because "gamers" use it and it became the default for video game communities.
A MacBook Pro is one of the most performant possible computers you could try this on. Electron apps are absolutely terrible without those kinds of resources (RAM especially). Keep in mind that Discord is also an app intended to be used by people who are gaming or streaming video as it’s original purpose, so it should be using as little CPU as possible to not interfere with e.g. the game.
Slack used to be a sizable portion of my old business stack on an 8GB X1 Carbon.
Windows doesnt leave you a lot of change from 8GB these days.
I used to have issues as Firefox would open a tab, cap out my available memory and 3cx would start stuttering causing voice issues.
The solution was to move to a carbon with 32GB RAM, but like, I should probably expect more out of Windows/Slack/3CX/Firefox in the first place. Feeding the beast more RAM is no longer a financially viable alternative for a lot of people.
The software bloat isn't ever going to go away. If you had 512 GB of RAM, would you care? We need cheap RAM.
Discord takes over 2 seconds to launch for me, which is ridiculous for a mostly text-based app.
In fact, there's almost no electron app that feels good to launch. I care very much about having things I interact with on a daily basis feel quick.
From that angle, sure. But maybe every program running on my machine doesn't need to run a full web browser instance.
I agree, but that's where we are and I've never been hampered. Electron is not going away.
I run Slack, Discord, Signal, Bitwarden, Asana, VS Code, GitHub - all idling quietly on a 16GB MPB M2. Was the same on my M2.
It's overblown, I don't care about Electron, how it's made (I understand how), who makes it, no dog in the hunt, but there is too much FUD about it, IMO.
In lot of corporate offices, it’s SFF and 1 liter desktops with 8 gb of ram and windows. You use Slack and Chrome, plus MDM software and you barely have enough compute left to move the cursor.
> there is too much FUD about it, IMO.
Yeah it's not as bad as people make it seem, but it's also far from ideal. Especially with how many tools we have nowadays to build performant desktop apps, a company of that size should really not be using electron if they know better.
You’re not representative of the target demographic for Discord, dude.
It’s kids playing Roblox on a decommissioned school laptop in a third-world country.
I really feel for them. Back in the day I couldn't play a game while I had Skype open. I was so happy when my friend groups switched to TeamSpeak which used miniscule amount of resources in comparison to Skype. Well until 2015 came and we all switched to discord lol
No snowflake feels responsible for the avalanche.
Discord runs games inside it now, although it's just a wrapper around a frame for the game it still doesn't help if its heavy.
Me, but also everyone a bit. Almost nobody cares about one of those applications in isolation. You start caring when you get a few of them and run out of ram. Sure, you can run Slack and Discord or something similar at the same time. But once you do, can you comfortably do other work without any visible slowdown? Or is this the threshold for "I need more than 8GB of ram?" You may be spending $ because of decisions like that.
Hot take: We should be able to comfortably run generic office desktops today with 4GB ram. We don't because too many people think "Who cares?"
I haven't run any laptop or a desktop with less than 16GB of RAM for over 2 decades. That's table stakes and a minimum. My uConsole CM5 Lite has 16GB. My 14 year old TP X230 has 32GB. I don't know what to tell you, if you want to swap to disk, then suffer the consequences.
There are two problems here:
1. You can't imagine that <8GB is enough for office work. It still is with enough care.
2. You can't imagine that a lot of this usage is waste. Sure you can buy more ram, but what if you needed half the memory and didn't swap?
I've got 30GB in use (some of it already compressed) and around 20GB of that is useless copies of some browser engine in various apps. It's insane that anyone is accepting that as table stakes and tells the user to "suffer the consequences" rather then raging at the current state of the industry.
We ran quick and responsive office suites in a fraction of that decades ago and 4GB in a common office machine should handle this just fine. (And still can on 8GB on a well configured machine. 4GB is tight but may be still comfortable on Linux)
No. I want the great native rewriting and de-Chroming to start, and I want the companies that don't follow to suffer the consequences of getting rejected from the more lean machines.
1. You can't imagine that <8GB is enough for office work. It still is with enough care.
Perhaps with DOS?
I don't need to imagine it, I've used 4/8GB early Airs, netbooks, slow Gateways and Dells. Turtles. I don't want to optimize my RAM. If something runs away, I'll kill it. I need more RAM. What you are saying is romantic in principle, and I don't disagree with the principle, but that's a dream and we need more RAM. I can subsist on rice and beans and tofu, but I don't want to.
Exactly. Most people hating on electron have hundreds of tabs open
Notable on the mobile app side that react native is getting tossed out along with electron.
It makes sense and I think they are going to be more teams moving in this direction.
Now that agents are good enough to one shot native UI from a Figma spec, these extra layers will be seen more as adding unnecessary complexity and ram bloat.
https://archive.ph/udbZx
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.
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.
The fragmentation around GPUI really is unfortunate. It seems to be the only framework that is complete enough for serious products. E.g. you can pair it with accesskit and have accessibility, it has a good number of components including difficult to write ones like text editors with highlighting.
I'm looking forward to Blitz personally. And I don't think it's true that it's the only complete enough solution as there are many in Rust like slint, iced, egui etc.
Slint yes but it’s commercial. Iced didn’t have a real accessibility story when I looked a few months ago. Ditto for egui. Also egui is immediate mode only which limits its general applicability.
Slint is under multiple license, including the open-source GPL and a royalty free license. What specifically bothers you about the licensing? (I work on Slint, genuinely curious)
Probably that it's not non copy left like MIT so they can't just use it without sharing code back.
But they even can. (royalty-free license)
For free without paying, like the other GUI frameworks.
Correct. This is a class of products that I really would rather not go commercial for. It's extremely difficult to change after the fact so from a business standpoint it puts us in a place where if the vendor decides to start cranking prices or they sell their business and the new owner does, then we are in a really difficult position.
It's not actually about paying money or not, I've signed up for many a patreon or what not to support open source projects I use. I fully believe in paying people for software. But for core things like this I do prefer MIT/APACHE.
But Slint is open source and you can for it if we were to change the license, and the royalty free license is free of charge.
Even MIT/Apache software can change license and start charging, as we've seen in the past with some project.
My app is proprietary though, so I can't use the royalty free license. I've definitely licensed commercial software before. For example, I've licensed OCR software for many years.
The difference to me is that with OCR I can change it out with acceptable effort in the case that the vendor does something that we can't agree to. But it's just too hard to swap out a UI library. That's a major rewrite. It's too risky, to the point I'd rather spend resources bringing an MIT/APACHE UI kit up to my needs than risk being locked in with a vendor.
The royalty free license is free of charge, no need to pay
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)
It render accetpable Chinese text, and the IME stuffs work on the control such as search box
Yes it can be made accessible, it's just not in the repo and needs to be integrated with other libraries. Things like https://github.com/longbridge/gpui-kit do it for you.
Think still has no accessibility, and given that the public framework is abandoned might not get there
Not quite abandoned, just that the Zed team stopped focussing on it. I've been building with this, very active GPUI framework: https://gpui-kit.com
Was no one else using Discord as a progressive web app, striking the best balance between resource footprint, no additional local apps on their device, still preserving their native UI, etc?
> Was no one else using Discord as a progressive web app
Going by me and my friends, no.
> striking the best balance between resource footprint
If this is the best balance possible, then that balance is horrible. Having to pull along a whole browser is a massive ball and chain on any program that I wish I could cut off anywhere I see it.
> no additional local apps on their device
This isn't an advantage for my use cases, nor any of my friends apparently.
> still preserving their native UI
As in preserving Discord's or your OS's UI?
I don't care about the former. I'd use DiscordMessenger[1] if it was mostly feature complete and Discord didn't ban third-party clients.
The latter isn't really preserved in any meaningful opinion by shoving it into a browser. The difference in UX post-install between a PWA and a seperate browser window (or a seperate app) is zero to me. It's still not native.
[1] https://github.com/DiscordMessenger/dm
> Having to pull along a whole browser
Electron apps do this. PWAs do not because you are already running the browser.
> > no additional local apps on their device > This isn't an advantage for my use cases,
It objectively is, because (a) you don't have to run Electron next to a browser (b) your Electron app lags behind in security fixes compared to Chrome or whatever you use to browse, and (c) PWAs have a much stricter permission/capability model than native apps, so you can run PWAs from publishers you don't trust that much.
> Electron apps do this. PWAs do not because you are already running the browser.
Sometimes, I might actually not be running the browser. And even if I am, a native app is still better.
> you don't have to run Electron next to a browser
I don't quite see the point you're making here?
> your Electron app lags behind in security fixes compared to Chrome or whatever you use to browse
Any app I download is sandboxed to the point I don't see this as a benefit of any magnitude.
Not to mention I might want the option of not updating (although I think this is an option with PWAs nowadays, although I've never actually tried).
> PWAs have a much stricter permission/capability model than native apps
Ditto.
> so you can run PWAs from publishers you don't trust that much.
I don't want to do that in the first place.
Native apps can do all those things better already. Can we please just have native apps instead?
I do this on FF through https://github.com/filips123/PWAsForFirefox. Works really quite well, and allows me to run uBlock Origin still ;)
With a native app, which I still welcome for perf/mem reasons, I'll have to configure opensnitch (or smth of the sort) to take care of the outgoing telemetry calls... A system-wide uBO would be a nice to have!
I’ve been using it in the normal web browser as a normal browser app.
Most people have ditched discord because if you try to do anything of value discord deletes the server
Community managers must learn to never build a community on someone else's platform.
But you do realise your advice is ignored by roughly 99.9% of people who use FB and co. and this is still where the people are?
Also, what real choices of owned plattforms besides old school forums are there?
Facebook is one of the worst places to build a community. You now have to pay to post more than two links a month, even.
And you might be impressed how far forums have come. Open source Discourse forum now has built-in Discord like voice and video chat, along with real time text posts. (It also powers some extremely large communities with millions of users.)
Oh I agree in general, I don't have FB. And discourse forum is probably what I would have tried too, but can it really scale to millions of active users? The largest I know are some linux forums, but they are way smaller.
Oh yes, it's used by Roblox, Blizzard, Unity, Epic, etc. Often the big companies remove the branding, but it's Discourse under the hood.
> what real choices of owned plattforms besides old school forums are there?
ActivityPub, AT Protocol, Nostr, to name a few.
And what thriving communities build up on those protocols?
Close-knit ones, the sort that don't trade principles for outreach.
Bully on me for expecting narcissists to grow a spine.
If everyone listened to this advice most communities would not be built
It used to be how all communities were built before the platforms.
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-...
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.
If I understand correctly, they're ditching Electron but still using React but with their custom renderer.
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
Yeah a few of those projects have existed for a while, but certainly things have picked up steam with the emergence of better LLMs. The issue with third-party clients is that Discord doesn't like them, and you're in violation of their ToS, meaning they can ban your account at any time. A bit risky, if you're networked into a bunch of communities (unfortunately so, but the effect is rather strong).
GPUI is pretty great. I whipped this up the other week and now I no longer need to open VSCode: https://diffy.run
Have you considered zed instead? What does this offer that zed doesn't?
The diff viewing experience in zed is really polished IMO.
I actually really dislike the zed diff viewer. I tried to like it many times, couldn't get used to it. That's why I was still just using VSCode. That was about 6 months ago, so maybe I should take another look tho
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!
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.
Outside of macOS/iOS (maybe Android too?) there isn't really any guaranteed consistency between native apps on the platform because there are multiple options for native UI toolkits which render differently. Plus, designers would rather have a consistent (unique/recognizable) look across platforms.
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.
For low budget teams with a decent amount of web experience, you'll still ship faster with electron.
Also, testing is easier with electron if your desktop app started life as a web app.
I hope that next apps that use Electron will ditch it for native technologies, maybe for Rust or C++. Please, Spotify, do the same. Look at Telegram's working speed and performance.
99% of the important parts here are not Rust itself but whatever stack is drawing the UI. This whole article is based on a Twitter post, except it's longer yet still has info missing, so I just went to https://x.com/svishnevskiy/status/2118081920194203799 and the answer is GPUI.
Hopefully it'll support arm64, I just found out the current version is amd64 only, despite being electron and also runnable on android.
Only true today for Linux. For both Windows and Mac we ship an ARM64 client. With this new Rust version we're also going to ship an ARM64 Linux client.
I didn't see it mentioned in the article, but does this mean that you will no longer be able to use Discord exclusively via the browser, without installing a native app? Because that's my preferred way to use Discord, since the browser nicely sandboxes it, whereas a native application generally runs unrestricted.
It will still be usable in the browser. I don’t think it’s in the article, but there are posts about it from the CTO on Twitter
FWIW, rust can be compiled to WASM, so it's technically possible to also have a web app perhaps with a pinch of JavaScript.
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
Microsoft has already had execs saying the next big thing is AI rewriting stuff to Rust. You think you are joking, but I'm sure it is on someone's roadmap in the Teams org.
Of course, being the Teams org they'd likely still find a way to end up with a bloated mess even after a Rust rewrite.
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
We need all the apps, websites etc services to take time to optimize their stuff for RAM, CPU use etc.. it's nuts we have these insanely powerful devices and crappy software and sites can bring them to their knees.
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.
I highly doubt they'd throw away decade of engineering of the JavaScript application, to rewrite it from scratch using native platform UIs. Probably would change desktop wrapper from Electron to Tauri or something else
Except it’s confirmed to not be Tauri.
Link to post referenced in the article
https://nitter.click/svishnevskiy/status/2118081920194203799
Source tweet: https://x.com/svishnevskiy/status/2118081920194203799
Source posted yesterday: https://news.ycombinator.com/item?id=50371421
What is the advantage of GPUI over Qt? As I understand, Qt has excellent Rust support in 2026.
Qt is not free
In what way it isn't free? The LGPL license is fine for Discord's use case. There's only a small number of components that are GPL-only that would otherwise require the commercial license but none of them are required for Discord to work, all of the important ones are LGPL.
Too expensive for Discord?
Someone should do this for Slack
What?? As much as I despise Discord this is a positive trend, hope other companies follow suit. Javascript on desktop is a plague on computing and the sooner it dies, the better.
Since GenAI can build you a bespoke Native UI software layer cheaply, why not?
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.
Hey, I work at Discord, specifically on this effort. Our entire focus here has been about improving performance and making the client really feel great.
It's difficult to believe Discord's intent is to make the client great when the recent updates have been to shove Best Buy ads into it. Even to the point of surfacing ads as friend dm notifications! In fairness, I'm jaded since I lost my account due to a sudden ultimatum to share my phone number -- extortion for my PII. So it is impossible for me to believe Discord operates in good faith.
In fairness these are probably distinct teams at discord. A team of engineers focused on performance probably _genuinely_ cares about that.
But there’s other teams and forces at play as well. So I agree with your overall sentiment but the SDEs who worked on this are perhaps not the ones shovelling adware into our faces.
This is a fair point, but it's basically being proud of making the monstrous privacy-destroying ad machine go 10% faster. With how they pressure people to doxx themselves to them (phone number verification) or be completely locked out of their accounts, there is enough predatory tactics in that company that no one should feel proud of working there.
I don't work at Discord, but I know of very few companies that don't have "malicious" tactics in one sense or another. Ultimately they are trying to improve their own bottom line and that _rarely_ aligns with what's best for people.
Yeah look Discord is more than one person. A lot of us really care about making the most performant client and that's why we did this.
[flagged]
You're saying this to a random person who doesn't like the software you use. How absolutely puerile. Please either grow up or stop commenting.
Thanks, but I already left hell (Discord) for heaven (open, self-hostable platforms).
Please drop a stripped .pdb right next to the binary or at least make it downloadable :)!
[flagged]
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.
Discord says using modified or alternative clients is against their terms of service, and they have banned people for it in the past (if they do something detectable, like enabling A/B testing feature flags that their account ID doesn't match :/)
They're not exactly friendly to that sort of thing, I wouldn't be surprised if they add some traps to catch people making their own client.
So I'd +1 the sibling comment's suggestion to consider alternatives to Discord, if you're setting up your own community
So then hide your client better? Just because a company has a policy does not mean you need to follow it.
> So then hide your client better? Just because a company has a policy does not mean you need to follow it.
How, it sounds like they're trying to catch you, e.g. I took...
> and they have banned people for it in the past (if they do something detectable, like enabling A/B testing feature flags that their account ID doesn't match :/)
...to mean they push out changes just to detect the clients who don't conform. I'm sure they could be very sneaky about it in a way that would be hard to "just do better" For instance: have some client behavior change that's hidden behind a feature flag or even calendar date, wait a long time until all official clients are updated, then trigger it and ban the laggards who can be assumed to be using an unofficial client.
Since discord announced that they would be scanning ID a lot of alternatives have sprung up, chatto and Armada are both looking promising as alternatives, plus the chatto vibed marketing materials on their Dev chat gave me a laugh the other week!
I can recommend both Matrix and Discourse forum as excellent open source selfhostable alternatives.
I like matrix, its like the new IRC for almost real time developer chat, I also do this via Discord but I'd prefer an open alternative. If you have experience running a matrix server do you find the data storage an issue? It sounded like if you federate and join the bigger channels you can balloon your storage pretty fast.
I mostly host for myself and a couple friends, so data storage hasn't been an issue. I'm sure at some point I may need to prune the attachment store, but I put it on a spinning HDD so capacity isn't an issue. (You can rent a storage VPS and those tend to have oodles of disk space.)
Take a look at Chatto. https://chatto.run/
FLOSS, easy to self host, and works nicely.
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.
There are literally dozens of open-source Discord clients already, both vibe-coded and not; and have been for many years. Nobody needed to prove this was possible, least of all Discord.
Ahem there is also the option to check out competitors ;)
I don't see any reason to think the web client is going away.
They can just repackage the web app and mod that if all else fails.
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...
Local AI for starters, stop relying on a single timesharing AI vendor.
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.
DeepSeek + DSH can do it with a fraction of the cost
As well as literally any other Chinese / open model.
I'm not surprised Anthropic and OpenAI are trying their best to ban / severely handicap competition and crack down on opensource. It's a major threat to their existence.
It may shock you to hear that there are other coding agents than Claude.
Wait until they find out about Abliteration models
They did not. Everyone has misinterpreted what Anthropic actually did and say. This attention economy is exhausting...
This is what an Anthropic dev said:
>"to steer it away from recreating someone else's specific game"
This just means exact clones, not reverse-engineering. The article is blatantly lying. And easy to disprove by... trying it yourself.
From the article itself, "Regarding the blocking of reverse engineering, we have received direct confirmations. The first comes from our own alumnus Jarred Walton, who was trying to run checks on the software he's developing. He notes that such work had been performed with no issue until yesterday, October 31, and that switching to Opus 4.8 let him continue his work."
...so just don't use Claude?
I thought Claude was the tool for the AI script kiddies?
Can’t see it on my end, the clanker still finesses IDAPython just fine.
Anti video-game-reverse-engineering, to be specific. It’ll refuse to decompile or reverse engineer any video game.
Just tossed the clanker at some stuff in Cyberpunk 2077, seems to be reversing it fine. Mind you I’m using my Claude sub in OMP so maybe I’m getting a less shitty system prompt (also I have the defensive CVP which presumably allows a lil more rev work than normal, though it’s still not enough for interesting things on Opus 5.5)
It’d probably be trickier with multiplayer games given the slopmachine would probably assume you wanna cheat in it
>vibekiddie
love this term, knew instantly what it means
depends if they decide to use any kind of obfuscation here to protect "IP"
I mean, why would you want to mod the desktop client of discord instead of the web client?
[flagged]
Please don't post snark like this on HN. It's not what this site is for, and destroys what it is for. If you wouldn't mind reviewing https://news.ycombinator.com/newsguidelines.html and taking the intended spirit of the site to heart, we'd be grateful.
Mod as in modification, not moderation.
[dead]
The good thing is AI enabling web developers to write native apps.
Most electron projects exist because engineering organizations couldn't afford to hire platform specialists for every platform they want to run on.
Also most native UI frameworks don't provide the primitives for modern UI. It's mostly just standard UI elements, sometimes with the possibility to theme them.
But most frameworks don't come even close to CSS and all the possibilities to create custom controls. It often requires to build everything from scratch in code, which is really hard for more complex layouts.
One could reply that it's a feature, since native UIs are more uniform and with less surprises you can concentrate on whatever the fuck you're doing instead of wondering what this app's designer was smoking.
Depends on the UI framework. Most frameworks don't have enough features to make the UI actually good. It's not even about looks, much more about layout. CSS is really good with conditional layout: hide something and everything reflows around it, responsive layout (not just mobile, but also when making app windows smaller/larger). Typography is another issue with a lot of native UI frameworks. Even adaptive DPI support is not yet easy with most native frameworks.
Also things like accessibility. It's quite easy to make web ui accessible, much harder to do it with custom native control.
> hide something and everything reflows around it, responsive layout (not just mobile, but also when making app windows smaller/larger)
Show me a few web apps that are "really good" with this, and don't achieve it by making 30%+ of the screen be spacing.
Maybe they should take the hint and not make a modern UI, given where UIs like that have taken us.
There were cross-platform C/C++ libraries in the late 80's to early 90's like Visix Galaxy. However, it was not free - far from it.
We developed on Windows NT and deployed onto HP/UX and Solaris.
Uh Qt is still around. Licensing might be as bad as this Visix Galaxy though these days.
certainly not valid for the most used electron projects
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.
This is the way. I don't know why it's hard for other people to figure out this process.
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.
Web devs already barely understood their tools. CSS was the closest thing to vibecoding before AI could write code.
You're painting with a very wide brush.
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.
Some of us are long enough in the business, to know that having Web development skills doesn't preclude having native development skills.
Maybe that was true in the past but it has definitely not been the case for the past 15 or 20 years for web developers who actually don't know anything about native development.
Well if you put it that way, some of them don't even know anything about the browser technology that powers their JavaScript framework used to generate static content.
That is correct.
Your use of "lazy" here really comes off as "ableist".
"I can do it, and you didn't do it, therefore you must be lazy, because I certainly am not lazy"
What's lazy is not diving into the reasons that people may or may not do things.
So, you're saying that the person you're responding to is really saying, "Developers are too disabled to write native applications"? No, that's nonsense. "Laziness" is not the reason for Electron applications, but neither does it implicate disability in this context.
Incidentally, I think it's kind of ableist to toss around the concept of ableism this lightly. Disability is a set of concrete barriers which go unacknowledged and a set of real accommodations which go unimplemented. Disability activism entails acknowledging those barriers and implementing those accommodations; it does not entail the idea that everyone is always trying their best and nobody is ever negligent.
Create a problem (RAM shortage), sell a solution (AI tools to migrate). Awesome
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).
About time, I'm tired of fighting. Free the RAM!
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.
With PCs, it was never about having a lot of RAM, it was about not having less RAM than others. So it's fine if everyone gets less RAM.
Sounds kind of socialist :-)
"No one gets TWO sticks of RAM until everyone has at least ONE stick of RAM!"
Luckily one person with monster RAM doesn't ruin it for everyone else, but there's RAMflation if everyone gets it
They’ll never give up bloated javascript frontends and call you poor for wanting anything else while sipping on their overpriced lattes.
[dead]
With the browser sandbox gone, it will be a good test of faith. Here's to an RCE-free port
Has anyone run the math on how many terawatts of power electron is responsible for wasting on needless abstractions?
electron is a blight on computing
Not exactly about Discord, but I once looked into GPUI, saw the Cargo.toml file and decided to give up on Rust UIs forever.
It's too bad electron didn't just rebuild itself to help so many applications all at once.
Cool. Is it still spying on everyone and everything on the user's computer though?
Full circle! Back to native code and use libraries like Qt, Dear ImGUI, and so forth LOL!
RIP mods
Somehow we were able to do mods with native applications back in the last century of desktop computing.
It doesn't say but it's likely a direct product of AI.
This wasn't on my 2026 bingo card but I love it!
300mb still is a lot
Well, Discord is a pretty complex app. It’s loading/caching images, subscribing to many chats at once, needs to be able to hop into a call at any time, and also renders (most) arbitrary Markdown.
Kopete did that under 100MB 15-20 years ago.
an aternative approach is to use using DOM Virtualization. that can save a lot of ram. i wonder if they tried that before the rewrite
Good. We need to save RAM to run AI models.
Everything consumes less ram than Electron
discord's electron app was a study in bloatware, quite unlike nearly all other electron apps I've used.
SO annoying that pay only subscription only articles continue to rank in the top pages of this.. a paid only or subscription only article that is not accessible to everyone should automatically no be considered for 1st page ranking
Still a bit high for a messaging app.
At this stage I think it is safe to say that Discord is no longer "a messaging" app, since it is basically a social media platform in its own right.
Rust? What GUIs have Rust bindings?
I kinda wish we went the other way, and all apps were web apps: easier to modify on the client side, etc.
not in a million years do I want to see personal computers turn into chromebooks
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?
Ram was honestly the biggest reason not to use the discord app and this is great but isn't the thing converted with ai?
Or just use ripcord and use what maybe 2mb of resources
RIP ripcord.
more for sam altman!
We are at a point where the "port this to rust, make no mistakes" meme is basically a reality.
I don't know about that. I am porting my Rust slop to Go and Zig simultaneously right now and the LLM is finding bugs in the Rust code as it is generating the Go and Zig code.
But.. maybe, maybe this is the opposite of google translate in the 00's - maybe, if you keep porting back and forth, you will eventually arrive at perfection :P
It's not about the bugs we fix, but the bugs we make along the way
I've found multiple passes with different models & 100% line coverage help. Need to push further with fixing. Coverage requirements also cut down on duplication (not entirely, still need to be vigilant) since it increases effort having to include coverage on new code
"just 290MB of RAM."
"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.
You've read them without a subscription for 15 years, but they had 15 years of salaries, server cost, etc. That is what happened
paywall is better than ads
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.
Now do slack please
About fucking time.
[flagged]
[flagged]
[dead]
[dead]
[dead]
[dead]
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.
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!
> 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.
> 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.
> 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.
But that's not what I wrote at all?
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
You mean Zed? https://zed.dev/