Provide it the official client and point it at public api endpoints (or an LLM operated mitm proxy), set it to work to reimplement.
https://www.tomshardware.com/tech-industry/artificial-intell...
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.
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).
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/
> 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.
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...
Goodbye Electron, we barely knew you
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.
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.
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.
For reference, my src-tauri/target/ folder is 8.3gb.
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.
The fear of deskilling is very valid and is already messing things up.
Of course people do.
Activities will apparently still use Tauri. Is that going to be a compatibility nightmare due to WebKit? (At least until CEF comes out)
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!
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.
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.
https://nitter.click/svishnevskiy/status/2118081920194203799
Maybe we should collectively use more of our personal tokens to re/write, extend and mix up the common(s) stacks at this point?
Such a rewrite would have been unthinkable 2 years ago, but now it's table stakes.
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-...
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.
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).
edit: there is one https://github.com/Sidenai/sidex haven't tried it yet
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.
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.
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.