Posted by archb 3 days ago
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)
" (And it's not Tauri, it's GPUI, so good guess everyone.) "
[0]: http://zed.dev/
GP you asked if there is accessibility P response: yes, here You then respond that worries you and dismiss the proof?
Apologies. I was noting that the lack of accessibility worried me (well, and weird accessibility breakage too).
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 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.
So Discord using gpui could mean it may get the needed features
You can’t exactly lump them together.
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.
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.
[1] https://gpui.rs/
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).
Yes please. The GPUI ecosystem is too fragmented
[x] smallcaps headings
[x] it's not this, it's that
[x] comically overselling marketing language
[x] detached third person perspective
slop confirmed
And do you really think that? Did you look at https://daybrite.dev/showcase/?
How about you step back and take a 5-minute look at the project and check your own snark.
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.
Opened a year ago. Still comments this week.
Why do people not use adblockers even this late since their introduction?
> 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())), )
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; }
}
}
}
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.
They have no shame in deploying a 300 MB hot mess bundle.
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.
use gpui::{black,red,green,blue,yellow,white};
let Self{text,..} = self;
v_flex()
.gap_3()
.bg(rgb(0x505050))
.size(px(500.0))
.justify_center()
.items_center()
.shadow_lg()
.border_1()
.border_color(black())
.text_xl()
.text_color(white())
.child(format!("Hello, {text}!"))
.child(
h_flex()
.gap_2()
.children(
[red(), green(), blue(), yellow(), black(), white()].map(|color|
div().size_8().bg(color)
)))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.
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.
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
After 10 or so of those you'll start dreaming of
border-left: 2px solid rgb(0 0 100%);
┠
or more explicitly
├2
that'd be perfectly paired with a dream-like visual designer that doesn't exist?
Also, this is basically what Tailwind code looks like.
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: ...)
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?
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.
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.
Things ship and change way too fast and the changes are massive.
You won't want it back. How much time do you spend surfing through your .o or .obj files today?
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.
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.
The solution, as usual in engineering, is negative feedback. Unfortunately, many people around here think that means "Shoot the messenger."
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.
the native app wins every single time. Give me native or give me death!
Consequently, porting my game engine from Java to Rust was more challenging than I had anticipated.
The fear of deskilling is very valid and is already messing things up.
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.
Of course people do.
Also check the Homebrew CPU running a custom port of Minix 2 with in-place ported C compilers, linkers and assemblers.
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.
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.
For reference, my src-tauri/target/ folder is 8.3gb.
Goodbye Electron, we barely knew you
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.
who downloads this? there's a website available
If it were simply the Chrome install that would imply Electron is 9GB+ by itself, which it most certainly is not.
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.
I dont have discord, so what i said is just conjecture, but bad update files laying around isn't uncommon imho.
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.
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.
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'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.
Inference cannot be controlled. The models are already out there. It's too late.
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.
> GPU-accelerated UI framework for Rust
It's either you peg a CPU while simply scrolling, or your GPU does a small amount of power efficient, buttery smooth, work.
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)
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.
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.
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.
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.
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.
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.
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.
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.
It’s kids playing Roblox on a decommissioned school laptop in a third-world country.
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?"
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.
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.
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.