They use GPUI. Says so on X.

" (And it's not Tauri, it's GPUI, so good guess everyone.) "

We're using GPUI for this.

I would also be wary of doing this in Rust because the GUI framework story is very much not finished

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

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

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:

    export component Hello inherits Rectangle {
        in property <string> text: "World";
        width: 500px; height: 500px;
        background: #505050;
        border-width: 1px; border-color: blue;
        drop-shadow-blur: 15px; drop-shadow-color: #0008;
        VerticalLayout {
            alignment: center; spacing: 12px;
            Text { text: "Hello, \{root.text}!"; font-size: 20px; color: white; horizontal-alignment: center; }
            HorizontalLayout {
                alignment: center; spacing: 8px;
                for c in [#f00, #0f0, #00f, #ff0, #000, #fff]: Rectangle { width: 32px; height: 32px; background: c; }
            }
        }
    }
    

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

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

HTML and CSS, for all their faults, are the best layout engine we have.

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.

I'm never going to complain about SwiftUI again

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

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!

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

Someone needs close the loop and make an HTML/CSS to GPUI transpiler

One person's mess is another person's Tailwind

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.

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.

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!

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.

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 ?

Your entire opinion is founded on assumptions.

It is a full browser, not surprising at all, only for those that never coded native applications.

Oh if you don't like large build artifacts Tauri might not be something to get excited about.

For reference, my src-tauri/target/ folder is 8.3gb.

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?

In a perfect world it would be reduced to 0 MB.

https://news.ycombinator.com/item?id=30311982

What the fuck. That's amazing. 10GB->10MB can't simply be moving from Electron right?

you must be joking 10GB haha

who downloads this? there's a website available

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.

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.

Discord is a text editor?

Oh, so the reduction in RAM usage is going to mean it's going to use my precious VRAM instead? No thanks.

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.

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.

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.

Not everyone is on a Macbook Pro. There is an enormous addressible market of people on lower end devices.

No snowflake feels responsible for the avalanche.

Exactly. Most people hating on electron have hundreds of tabs open

From that angle, sure. But maybe every program running on my machine doesn't need to run a full web browser instance.

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?"

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

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.

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.

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?

Use ripcord

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!

> 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

I’ve been using it in the normal web browser as a normal browser app.

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.

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

It render accetpable Chinese text, and the IME stuffs work on the control such as search box

Community managers must learn to never build a community on someone else's platform.

Except it’s confirmed to not be Tauri.

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.

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

How come it's presented as paid software when the binaries are available on GitHub?

Also naming your company "__slop" is a bold move!

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.

Consistent UI and control. I re-wrote my electron app in Swift. Its great. But... some of the UI is weird at times; weird patterns; weird behavior. And Apple's UI framework is one of the better ones. Even for AI, each platform will have its own quirks and just _finding_ them takes real users to expose. We take it for granted how flexible and powerful browser UI is, because there's so much baggage and performance related factors. But many UI frameworks are worse, and historically always were.

I think what we're seeing here - and likely to continue to see - is new versions of web UI that eschew a lot of the historical baggage given they don't need to support older websites. And possibly something more powerful. So I guess re-writes or partial ports that take only the parts we need. Presumably a bunch of people will try and hopefully, a few succeed.

I am not a developer, but using this type of frameworks and toolkits means that a lot of useful (and sometimes "boring") things are already thought through and taken care of. This is probably most important for smaller projects and teams, but some of it probably applies to Discord scale operations as well :)

While you _should_ put some effort into tuning and fixing these things for your specific project, you will "mostly" get things like cross-platform support for all major desktop operating systems, some support for accessibility-tools like screen readers and voice over, devtools and debuggers, application installers, (push) notifications, caching, some aspects of security and cryptography, log handling, and file handling for free, or at least get a reasonable push in the right direction, with Electron.

The alternative is either getting each of these things from a different third party source, or making them all in-house. With a popular abstraction layer like Electron + a web stack, you will to some extent encounter the same problems, mysterious log messages, design considerations and other issues as everyone else. This means that you can find documentation, stack overflow questions, new hires, consultants, blogs, LLMs, etc. that have the skills and knowledge you need, instead of researching and solving everything in-house.

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.

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.

Qt is not free

Somehow we were able to do mods with native applications back in the last century of desktop computing.

The bad thing here is that modding discord will become significantly harder and might have been their original intention here.

The good thing is AI enabling web developers to write native apps.

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.

They’ll never give up bloated javascript frontends and call you poor for wanting anything else while sipping on their overpriced lattes.

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

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.

not in a million years do I want to see personal computers turn into chromebooks

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.

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

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.

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

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

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