This sentence underscores how whatever the job many people have now is going to need new language.
We have people who (presumably) were web developers directing AI agents to synthesize and maintain native apps by gesturing towards reference implementations and chatting about further requirements.
That doesn't sound like it involves web development or writing native apps in any way we used to use those terms, and it's not like the traditional usages of them don't still apply elsewhere.
I re-wrote one of my apps in Swift. I don't know Swift. It's been fun. When it gets stuck I look at the code; I have it teach me via analogy to the e.g. mobx/react concepts I do know. In some cases I've improved the LLMs code after learning how something works. In others I work it more like an informed PM - ok the sidebar opening is slow but... its about 10x faster in my electron version. How is the sidebar "mounted" or rendered? I dump tricks I know from web dev and ask how analogues; sometimes that breaks its anti-patterns. Other times I throw constraints I don't know much about - "This is a native version, can we aim to make it 3x faster to start-up? How".
Personally I was surprised how quickly I surpassed my original code, feature wise. Will it stand the test of time? Too early to tell - need to see if I'm still using the native version of the app in a year. But its been more fun and informative - and fast - than I'd expected.
Right fun is great but I'm speaking from a professional context. Examples should be production code at legitimate businesses.
For what it's worth I wholly agree with your point and that mirrors the personal project I have. But making personal projects a bit more fun and fluent is not the $10T proposition being championed at the professional level.
You know what they meant. This is the same argument that artists used when AI image generation came out, it's not very helpful. Being able to do something and actually doing it are different and we all benefit when web app makers rewrite their apps into native languages.
Maybe that was true in the past but it has definitely not been the case for the past 15 or 20 years for web developers who actually don't know anything about native development.
Well if you put it that way, some of them don't even know anything about the browser technology that powers their JavaScript framework used to generate static content.
So, you're saying that the person you're responding to is really saying, "Developers are too disabled to write native applications"? No, that's nonsense. "Laziness" is not the reason for Electron applications, but neither is it somehow an insinuation of disability.
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."
Also most native UI frameworks don't provide the primitives for modern UI. It's mostly just standard UI elements, sometimes with the possibility to theme them.
But most frameworks don't come even close to CSS and all the possibilities to create custom controls. It often requires to build everything from scratch in code, which is really hard for more complex layouts.
One could reply that it's a feature, since native UIs are more uniform and with less surprises you can concentrate on whatever the fuck you're doing instead of wondering what this app's designer was smoking.
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.
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).
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).
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.
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?
Well not really? You are going from a webpage (Electron) to a native application via Rust. Say you port a React website to a Rust native application, is anything about that code actually similar?
It seems like the value is having something performant. Their choices were 1) stick to a web framework their employees know well 2) a performant native app their employees don’t know as well. And they chose 2.
If a model can tell you anything you’d hope to have a human tell you, what’s the difference? It’s a different point of failure— models can go offline, but employees can also quit anytime too.
I share the intuition but pragmatically if the codebase will only ever be interacted with through AI agents it probably is nothing and wouldn't matter anyway. You can probably even generate an exhaustive amount of documentation instantaneously if you are concerned about a human knowing their way around.
There was already an electron-free native client for discord some years back, but they interfered with it. At this point, there's nothing at all impressive about this. It's not hard to ask AI to "RIIR" as been shown many times. However, I am glad that building stuff on electron might finally be seen as lazy and wasteful.
I just pray that Vencord will continue to work in some form, if only so I can use whatever font I want. I'm not a fan of many other changes they've made and I've thus had to reverse, but I'm willing to trade away the flexibility of CSS for an app that uses 5 times less RAM. Even better if it doesn't go away at all, but we'll see.
It's great they're working on improving performance, but as they move towards an IPO I'd be looking hard at getting off their platform altogether. They're already shoehorning ads and all kinds of nonsense into their app- it's only going to get worse after the IPO.
This has to be hyperbole. I built (with Claude) a P2P LAN voice-only chat app in Rust recently, using native frameworks for each platform (Swift, GTK, Win32), and it weighs in at about 5-6 MB depending on the platform. I have spent an enormous amount of time looking for places to squeeze it further. It has ephemeral channels and password protection, but that’s about it: no text chat, no video, no friends, blocklists, no concept of servers, etc. I can’t imagine everything else Discord has squeezes into another 5 MB.
Push-to-talk does not work well on in the browser at least on Wayland/Linux. The shortcut only gets sent to the active window, which for the type of contexts where push-to-talk is useful (e.g. gaming) is a dealbreaker. I've read stuff indicating that xdotool can manually handle things reasonably enough on X11, but I was never able to get it working reliably for any of the various Wayland replacements for xdotool, so when I've done voice calls, I've had to grudgingly use the desktop client.
Discord even sends its DPO (data protection officer/privacy team) tickets to outsourced offshore copy & paste template support farms/AI chatbots. I've requested my data numerous times, half of the time the ticket was closed without a response, and the ones that DID get a response were the same copy & paste template telling me my data package is being generated.
All data packages were missing 90% of my account data (bug? size issue with zip files?), no avenue to report this to Discord of course. :^)
It's crazy how much RAM electron needs, at my old startup the main product was an electron app, i initially used to run into this issue where AI wouldn't clean up the dev builds it spunned up for e2e testing and each could be over 500MB, it just get's to a point that the cross platform advantage is no longer worth it, i think it was one of the main reasons cursor had to move off electron to rust based builds.
I noticed this news and because one of my codex banked reset is expiring soon
I launch codex with astra+ultra on my tauri project because webview sometimes cause blank screen on user device to let it to rewrite the tauri projec to GPUI
It did those stuffs for me
- get rid of the CGO and MINGW toolchain for cross building windows on Linux
- wrote a compatbility layer to communicate the original app backend written using rust
- Achieve not ideal but acceptable UI/UX as the tauri project
- The new build using 24MB memory which is quite good and I do not even bother to check the tauri version
It amazing time to rewrite, though I still can't remember joy of old days that manual coding, but my lower back ask me to just embrace the Agentic coding...
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.
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.
Asking in good faith: In the agentic age why use abstractions like Electron at all? Shouldn't we write apps in lower-level system languages like Rust like Discord has done?
I am not a developer, but using this type of frameworks and toolkits means that a lot of useful (and sometimes "boring") things are already thought through and taken care of. This is probably most important for smaller projects and teams, but some of it probably applies to Discord scale operations as well :)
While you _should_ put some effort into tuning and fixing these things for your specific project, you will "mostly" get things like cross-platform support for all major desktop operating systems, some support for accessibility-tools like screen readers and voice over, devtools and debuggers, application installers, (push) notifications, caching, some aspects of security and cryptography, log handling, and file handling for free, or at least get a reasonable push in the right direction, with Electron.
The alternative is either getting each of these things from a different third party source, or making them all in-house.
With a popular abstraction layer like Electron + a web stack, you will to some extent encounter the same problems, mysterious log messages, design considerations and other issues as everyone else. This means that you can find documentation, stack overflow questions, new hires, consultants, blogs, LLMs, etc. that have the skills and knowledge you need, instead of researching and solving everything in-house.
> [...] using this type of frameworks and toolkits means that a lot of useful (and sometimes "boring") things are already thought through and taken care of.
You're falling in the trap of the cross-platform dream. Electron takes insane decisions about how your app is going to achieve cross-compatibility in the name of allowing web devs to do the work. It is simply the wrong tool for the AI age, since a versatile web dev can turn to an AI to help them achieve the work.
Consistent UI and control. I re-wrote my electron app in Swift. Its great. But... some of the UI is weird at times; weird patterns; weird behavior. And Apple's UI framework is one of the better ones. Even for AI, each platform will have its own quirks and just _finding_ them takes real users to expose. We take it for granted how flexible and powerful browser UI is, because there's so much baggage and performance related factors. But many UI frameworks are worse, and historically always were.
I think what we're seeing here - and likely to continue to see - is new versions of web UI that eschew a lot of the historical baggage given they don't need to support older websites. And possibly something more powerful. So I guess re-writes or partial ports that take only the parts we need. Presumably a bunch of people will try and hopefully, a few succeed.
Outside of macOS/iOS (maybe Android too?) there isn't really any guaranteed consistency between native apps on the platform because there are multiple options for native UI toolkits which render differently. Plus, designers would rather have a consistent (unique/recognizable) look across platforms.
I'm very interested in (and a total novice in) cross platform GUI application development. Hadn't heard of GPUI, though I had heard of Tauri. I looked at the GPUI front page and saw this mess of almost-CSS method chaining... Surely there's a better way? This seems horrible to me.
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.
IMHO Rust isn't a great language for describing UIs because it is too explicit in places that doesn't need to be for coding a UI.
Which is why in Slint (another Rust UI framework) we opted for a DSL. The application logic stays in Rust, but the UI is described in a language designed for it.
> Rust isn't a great language for describing UIs because it is too explicit in places that doesn't need to be for coding a UI.
That's is not about just Rust ... Any domain has its own optimal or sub-optimal language describing it. Criteria of optimality is a bit subjective of course. Like: INI, TOML, YAML, etc. are better (YMMV, again) for user facing configs than JSON or XML and so on.
I think that HTML is better for defining hierarchical UI structures and CSS and CSS selectors are (arguably again) better to define UI styling.
My Sciter[1] was initially using .FRM alike inputs (VisualBasic forms, good for IDE but bad for a human) but I quickly discovered that having styles, structure and code-behind-UI in single PL makes non-manageable mess. So Sciter uses HTML, CSS and JS we all familiar with. Not 100% match of course but good enough.
Slint is proprietary though, so that’s a dead end. I’m not going to use something which will inevitably be rug-pulled when you sell to private capital.
I'm not sure it matters anymore unfortunately. I've vibe coded a few apps using gpui-kit and it works well. It helps that gpui-kit provides a number of high quality components (e.g. the data table is especially good). But even where it doesn't (e.g. log output) Opus 5.5 was able to easily write one that worked perfectly.
It even added ANSI colour support... which I am still on the fence about but it did make the very good point that it means the logging is exactly the same in GUI and CLI mode.
All a language needs to be good at expressing UIs is some sort of tail lambda syntax like Swift and Kotlin. It's the perfect way to express a tree structure (which is essentially all UI) while also being in a true programming language (as opposed to a markup language like XML).
Well, keep in mind that you’re not expected to have the entire UI in one statement. You’re supposed to break this up into functions. That’s why stuff like Flutter and SwiftUI work.
Also, this is basically what Tailwind code looks like.
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
220 comments
[ 0.22 ms ] story [ 15.9 ms ] threadThis sentence underscores how whatever the job many people have now is going to need new language.
We have people who (presumably) were web developers directing AI agents to synthesize and maintain native apps by gesturing towards reference implementations and chatting about further requirements.
That doesn't sound like it involves web development or writing native apps in any way we used to use those terms, and it's not like the traditional usages of them don't still apply elsewhere.
This kind of work is something else.
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.
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?
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.
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.
[1] https://cancel.fm/ripcord/
Goodbye Electron, we barely knew you
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.
Maybe we should collectively use more of our personal tokens to re/write, extend and mix up the common(s) stacks at this point?
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
right?Your example would look like this:
More on why we chose a DSL vs code in Rust: https://slint.dev/blog/domain-specific-language-vs-imperativ...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.
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.
Also, this is basically what Tailwind code looks like.
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