love this term, knew instantly what it means

https://www.tomshardware.com/tech-industry/artificial-intell...

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.

It’d probably be trickier with multiplayer games given the slopmachine would probably assume you wanna cheat in it

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.

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.

Provide it the official client and point it at public api endpoints, set it to work to reimplement.

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

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.

FLOSS, easy to self host, and works nicely.

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.

people like you are the worst its one thing to open your mouth and try to get some klout for working at a place, that's pathetic enough, its another thing to try and dump kool aid down people's throats. pathetic.

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?

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.

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.

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

Incidentally, I think it's kind of ableist to throw around the concept of ableism in places it doesn't make sense. Disability is a set of concrete barriers corresponding to real solutions which do not get the funding and consideration they deserve. Disability is not "when some people do a thing and others don't."

We developed on Windows NT and deployed onto HP/UX and Solaris.

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.

Also things like accessibility. It's quite easy to make web ui accessible, much harder to do it with custom native control.

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.

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

"No one gets TWO sticks of RAM until everyone has at least ONE stick of RAM!"

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

Activities will apparently still use Tauri. Is that going to be a compatibility nightmare due to WebKit? (At least until CEF comes out)

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?

That's not actually true. Nobody understands everything about how an airplane works, not even the lead engineers. Nobody understands everything about how a car works, or how medical billing works, or how taxes work, or how traffic flow works, or how a CPU works, or how almost anything works. You just need to understand the broad picture and be able to find the details when necessary.

Of course people do.

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.

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.

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.

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.

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.

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.

Consequently, porting my game engine from Java to Rust was more challenging than I had anticipated.

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!

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.

[1] https://cancel.fm/ripcord/

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.

Goodbye Electron, we barely knew you

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.

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.

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.

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.

who downloads this? there's a website available

https://flathub.org/en/apps/com.discordapp.Discord

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

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

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

15 years reading the verge without subscription. What happened?

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

https://nitter.click/svishnevskiy/status/2118081920194203799

Such a rewrite would have been unthinkable 2 years ago, but now it's table stakes.

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.

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.

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

Neither of which is actually good for your users. Look like other apps on the platform, FFS.

Also, testing is easier with electron if your desktop app started life as a web app.

edit: there is one https://github.com/Sidenai/sidex haven't tried it yet

> 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())), )

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?

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.

[1] https://sciter.com

They have no shame in deploying a 300 MB hot mess bundle.

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.

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

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

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

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

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.

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.

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.

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.

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 .

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!

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)

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.

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

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)

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.

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

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

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

[0]: http://zed.dev/

So Discord using gpui could mean it may get the needed features

You can’t exactly lump them together.

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.

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/

[2] https://gpui.rs/examples/

[0] https://gpui-kit.com

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

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

[x] smallcaps headings

[x] it's not this, it's that

[x] comically overselling marketing language

[x] detached third person perspective

slop confirmed

Yes please. The GPUI ecosystem is too fragmented

Why do people not use adblockers even this late since their introduction?

Opened a year ago. Still comments this week.

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

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!

The diff viewing experience in zed is really polished IMO.

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.

Even MIT/Apache software can change license and start charging, as we've seen in the past with some project.

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.

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

Also, what real choices of owned plattforms besides old school forums are there?

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

ActivityPub, AT Protocol, Nostr, to name a few.

Bully on me for expecting narcissists to grow a spine.

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.

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

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.

If everyone buys faster computers, the developers will correspondingly stuff more "features" in there to make it slower.

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.

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

* Also often how modern DRM works, it just prevents the OS from reading back data on the GPU buffer for that application, so the GPU (and display output port) are the only things that actually see the data.

I don't know about GPUI in particular, but it's possible to make GPU-accelerated rendering use less VRAM by generating graphics with shaders on the fly instead of uploading sprites/bitmaps drawn by the CPU.

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

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.

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?

electron is a blight on computing