> In our Linux test it opens in under a second and uses about 200 MB of idle RAM
Is it just me or does anyone else feel that 200 MB is a lot for a native chat app written in Rust, that's essentially a remote interface for the WhatsApp on your phone?
I remember back in the day, apps like Miranda IM (and early versions of Trillian) used only digits of RAM, even when you had multiple plugins talking several protocols at the same time, whilst having a ton of advanced features not found in WhatsApp. Yes I get that times have changed and software has become bloated etc, but 200 MB still feels a bit too much.
> Is it just me or does anyone else feel that 200 MB is a lot for a native chat app written in Rust, that's essentially a remote interface for the WhatsApp on your phone?
> I remember back in the day, apps like Miranda IM (and early versions of Trillian) used only digits of RAM, even when you had multiple plugins talking several protocols at the same time
I think what's happening in the second one is that because you're using the native OS toolkits a bunch of stuff is shared, whereas with these "self-contained" "native"-y apps you end up having to load up the whole world and aren't sharing things with everything else
I'd love to be proven wrong but I feel like if you use e.g. Qt you're gonna have to hold onto a bunch of stuff that you wouldn't if you were "just" using OS-native stuff (though maybe that gets shared if you're using the exact same version? Is there something that can be done in this space?)
Also, I looked at how dates are written in a screenshot and thought that "2 days ago" would be so much better than "Tuesday". Because you do not have to compute in your head how many days ago Tuesday was.
Sounds reasonable, but IME apps that use relative timestamps switch to absolute time past certain threshold, and then I end up with two adjacent entries "14:38” and "15 minutes ago" and scratching my head.
I hate relative timestamps, I find it much easier to remember specific week days, so I very much prefer this style so I don't have to compute in my head which day of the week I got the text.
Anyway, I tried this application and it seems to mix different styles depending on how long ago you got the text: "yesterday", "Friday", "18 Oct 2026".
Egui is pretty bad idea. It uses "immediate mode" rendering which means whole window is redrawn on every mouse move. I ran PhotoCraft (built in Rust + egui) in a VM wihout a GPU and the UI felt like it was running on 3 fps. If you use egui, try running it without a GPU before releasing.
Egui is definitely not what you want to use on a 4K screen. It is only good for tiny screens of embedded devices.
Why there is no reactive UI that tracks all dependencies and redraws only what needs to be redrawn? (not React, it also re-calculates (but not redraws) everything on every change).
Also why does it visually look like bad version of Telegram? And Telegram can run without a phone present.
To use memoization you must use immutable structures (otherwise React is unable to detect changes) which are a pain to use and are slow if not designed properly. Do not believe me, try designing for example an algorithm that accepts a huge immutable sorted list with keys, a large sorted list of bulk deletes/inserts and produces a new sorted list with minimum operations. I made 2 or 3 prototypes and they still are not good and not even working properly.
In my book, a good UI framework simply attaches to a mutable model made of arbitrary objects, detect changes and displays it with minimum number of operations. Doesn't require to use any proxies or immutable data or store data in components. Shouldn't be difficult. Why nobody made it, I do not understand.
In my head it's retained mode + the diffing layer, which sounds the same but if you try to write an "immediate-mode" API (say, using hooks) in React you'll find yourself churning a lot.
At least unless you use the magic React compiler that memo-izes everything correctly.
> Why there is no reactive UI that tracks all dependencies and redraws only what needs to be redrawn?
Nowadays the focus seems to be on video game-style interfaces that redraw every frame. The justification for this is typically that computers are so fast they can now come up with the entire interface every frame, so why not take advantage of that and forget all this retained-mode complexity?
They don't realize that this is a classic case of the developer's machine fallacy, where the developer has a machine so vastly more powerful than any of their users' that they produce a terrible experience for said users. This is also why games these days typically require upscaling even on 5090, because developers usually have that or something even more powerful and they think the bleeding edge is pushing even THAT machine to its knees.
Developers should be testing their software on the most entry-level, bottom of the barrel Chromebooks from 2015, running the heaviest and most bloated operating system they can think of. If people still optimized their software for that, then maybe computers would still feel almost as fast as the Apple II from 1977.
That's actually a very good point, I haven't seen any care for power consumption from software developers in many many years. The only people who seem to still care about it are hardware developers like Valve and Apple. I admit I never thought about it myself either.
I would figure that doing less work generally requires less power, but some developers are crazy and act like they own the whole CPU, generate tons of heat, stress out the cooling system etc. with multithreaded bullshit that did NOT need to be multithreaded.
it's an incredible waste of resources, especially at high resolutions, to redraw a Gui application like you would a videogame at 60 FPS. These immediate mode UI frameworks were made in particular for that case, to be embedded in real time software, not for a UI where the state is idle or changes only occasionally.
> Why there is no reactive UI that tracks all dependencies and redraws only what needs to be redrawn?
There's plenty of them. Slint, Floem, iced, Vizia, fltk etc. Slint and fltk in particular also exhibit excellent performance and very little resource usage even without a GPU.
dont get me wrong, I like the extra performance, but every single alternative whatsapp client has the same issue where it's missing enough core features that you end up needing to go to the browser version often enough to be a nuisance and I end up just using the browser instead (which I hate, I really really would prefer a performant client instead!)
It’s really a shame that all of these unofficial clients are like this. APIs are APIs, if they’re on the public internet why can’t anybody call them? If there’s potential for abuse then that should be secured server side anyway, since needing a unofficial client isn’t going to stop hackers
Eventually the unofficial client gets "fingerprinted" and its over. Its easy to remove the suspension, though. I vaguely remember it was through email.
Eh, there's no humans any longer IIRC. It's all down to whether their support AI blesses you or not.
I got banned for trying to move my chats from Android to iOS using the app rather than the special tool I didn't know you were supposed to use. I was lucky I eventually got unlocked.
I want a decent WhatsApp client that doesn't crash constantly and where you can search properly, but it's not worth the risk of getting banned again.
I actually wish they'd delete the warning so then anyone who gets banned from WhatsApp for using an unofficial client would have a more legit cause of action against WhatsApp. Meta wouldn't be able to defend themselves with "well you were warned" if you weren't warned.
I think this doesn't apply to European users, as WhatsApp announced around one year ago that under Digital Markets Act they were required to allow interoperability with third party providers [0].
That's the annoying thing with WhatsApp, Slack, Discord, etc. Let's say I've got a personal client (that I'm definitely not using...) which works so much better than the official one. I cannot distribute it or use it according to their rules. It's forced enshitification, even though we have better options.
On the good side though - if you're replicating the official behaviour close enough... maybe nobody will know. But then you have to make sure everything, including key sort order, and JA4 of requests matches. And that's tough...
> In our Linux test it opens in under a second and uses about 200 MB of idle RAM
Is it just me or does anyone else feel that 200 MB is a lot for a native chat app written in Rust, that's essentially a remote interface for the WhatsApp on your phone?
I remember back in the day, apps like Miranda IM (and early versions of Trillian) used only digits of RAM, even when you had multiple plugins talking several protocols at the same time, whilst having a ton of advanced features not found in WhatsApp. Yes I get that times have changed and software has become bloated etc, but 200 MB still feels a bit too much.
> Is it just me or does anyone else feel that 200 MB is a lot for a native chat app written in Rust, that's essentially a remote interface for the WhatsApp on your phone?
> I remember back in the day, apps like Miranda IM (and early versions of Trillian) used only digits of RAM, even when you had multiple plugins talking several protocols at the same time
I think what's happening in the second one is that because you're using the native OS toolkits a bunch of stuff is shared, whereas with these "self-contained" "native"-y apps you end up having to load up the whole world and aren't sharing things with everything else
I'd love to be proven wrong but I feel like if you use e.g. Qt you're gonna have to hold onto a bunch of stuff that you wouldn't if you were "just" using OS-native stuff (though maybe that gets shared if you're using the exact same version? Is there something that can be done in this space?)
With Qt, on my KDE Linux, a simple app usually stays well below 60 to 100 MB.
> Is it just me or does anyone else feel that 200 MB is a lot for a native chat app written in Rust ...
That was my first thought. But considering it as a significant improvement from > 1 GB, I guess it is what it is.
> I remember back in the day, apps like Miranda IM (and early versions of Trillian) used only digits of RAM ...
Sadly this was true for many apps.
Also, I looked at how dates are written in a screenshot and thought that "2 days ago" would be so much better than "Tuesday". Because you do not have to compute in your head how many days ago Tuesday was.
Sounds reasonable, but IME apps that use relative timestamps switch to absolute time past certain threshold, and then I end up with two adjacent entries "14:38” and "15 minutes ago" and scratching my head.
Signal does that and I hate it when it happens.
There are other minor problems as well:
- Screenshots don't age well: you need to know the screenshot time and do math
- They need to be maintained, which means the screen keeps updating even if nothing else is happening
I hate relative timestamps, I find it much easier to remember specific week days, so I very much prefer this style so I don't have to compute in my head which day of the week I got the text.
Anyway, I tried this application and it seems to mix different styles depending on how long ago you got the text: "yesterday", "Friday", "18 Oct 2026".
Egui is pretty bad idea. It uses "immediate mode" rendering which means whole window is redrawn on every mouse move. I ran PhotoCraft (built in Rust + egui) in a VM wihout a GPU and the UI felt like it was running on 3 fps. If you use egui, try running it without a GPU before releasing.
Egui is definitely not what you want to use on a 4K screen. It is only good for tiny screens of embedded devices.
Why there is no reactive UI that tracks all dependencies and redraws only what needs to be redrawn? (not React, it also re-calculates (but not redraws) everything on every change).
Also why does it visually look like bad version of Telegram? And Telegram can run without a phone present.
React doesn't re-calc on every change either if you use memoization and such properly.
To use memoization you must use immutable structures (otherwise React is unable to detect changes) which are a pain to use and are slow if not designed properly. Do not believe me, try designing for example an algorithm that accepts a huge immutable sorted list with keys, a large sorted list of bulk deletes/inserts and produces a new sorted list with minimum operations. I made 2 or 3 prototypes and they still are not good and not even working properly.
In my book, a good UI framework simply attaches to a mutable model made of arbitrary objects, detect changes and displays it with minimum number of operations. Doesn't require to use any proxies or immutable data or store data in components. Shouldn't be difficult. Why nobody made it, I do not understand.
This is incorrect. You don’t need to use immutable structures to have stable references which is what matters.
Use context liberally instead of plumbing things through prop’s needlessly and you’re halfway there.
React isn't immediate mode by my understanding.
In my head it's retained mode + the diffing layer, which sounds the same but if you try to write an "immediate-mode" API (say, using hooks) in React you'll find yourself churning a lot.
At least unless you use the magic React compiler that memo-izes everything correctly.
> Why there is no reactive UI that tracks all dependencies and redraws only what needs to be redrawn?
Nowadays the focus seems to be on video game-style interfaces that redraw every frame. The justification for this is typically that computers are so fast they can now come up with the entire interface every frame, so why not take advantage of that and forget all this retained-mode complexity?
They don't realize that this is a classic case of the developer's machine fallacy, where the developer has a machine so vastly more powerful than any of their users' that they produce a terrible experience for said users. This is also why games these days typically require upscaling even on 5090, because developers usually have that or something even more powerful and they think the bleeding edge is pushing even THAT machine to its knees.
Developers should be testing their software on the most entry-level, bottom of the barrel Chromebooks from 2015, running the heaviest and most bloated operating system they can think of. If people still optimized their software for that, then maybe computers would still feel almost as fast as the Apple II from 1977.
https://danluu.com/input-lag/
And obviously all computers have infinite capacity batteries to maintain game-level power consumption.
Or are plugged into a world with infinite quantity of renewable energy.
That's actually a very good point, I haven't seen any care for power consumption from software developers in many many years. The only people who seem to still care about it are hardware developers like Valve and Apple. I admit I never thought about it myself either.
I would figure that doing less work generally requires less power, but some developers are crazy and act like they own the whole CPU, generate tons of heat, stress out the cooling system etc. with multithreaded bullshit that did NOT need to be multithreaded.
Not sure why multi threading is a victim. It really depends.
PDFCraft works fine for me on a 4k screen connected to an older laptop with an integrated Intel graphics card, blazing fast and smooth.
I am using it on a 2017 intel macbook and its faster than anything else on that device
What is the argument here?
Basically every device has a GPU.
Why is it bad on 4K?
Did you measure anything in a real setup?
>What is the argument here?
it's an incredible waste of resources, especially at high resolutions, to redraw a Gui application like you would a videogame at 60 FPS. These immediate mode UI frameworks were made in particular for that case, to be embedded in real time software, not for a UI where the state is idle or changes only occasionally.
> Basically every device has a GPU.
Many VMs and remote desktops don't. (Or can't really make use of)
The argument is that it's wasteful? Even if I had a GPU, I'd rather use it to do inference for insurance rather than drawing a simple UI?
Why do I have to state the obvious like that?
> Why there is no reactive UI that tracks all dependencies and redraws only what needs to be redrawn?
There's plenty of them. Slint, Floem, iced, Vizia, fltk etc. Slint and fltk in particular also exhibit excellent performance and very little resource usage even without a GPU.
nothing stops you to render gui at 5 fps. most people won't notice
dont get me wrong, I like the extra performance, but every single alternative whatsapp client has the same issue where it's missing enough core features that you end up needing to go to the browser version often enough to be a nuisance and I end up just using the browser instead (which I hate, I really really would prefer a performant client instead!)
Looks great, but... how can one trust it with credentials/communication? (nothing against the developer, more the principle of the thing)
ummm, you can read the code...
but you shouldn't trust these unofficial clients, easy way to get your whatsapp account banned
Yes, it would be great if we could set up our own test WhatsApp server.
It's called an XMPP server.
In their own README:
> Using an unofficial client may be against WhatsApp's terms of service and could get an account suspended.
Same for all of these unofficial clients.
It’s really a shame that all of these unofficial clients are like this. APIs are APIs, if they’re on the public internet why can’t anybody call them? If there’s potential for abuse then that should be secured server side anyway, since needing a unofficial client isn’t going to stop hackers
Dammit. I installed it, it worked beautifully, and now I don't want to risk it.
Eventually the unofficial client gets "fingerprinted" and its over. Its easy to remove the suspension, though. I vaguely remember it was through email.
Eh, there's no humans any longer IIRC. It's all down to whether their support AI blesses you or not.
I got banned for trying to move my chats from Android to iOS using the app rather than the special tool I didn't know you were supposed to use. I was lucky I eventually got unlocked.
I want a decent WhatsApp client that doesn't crash constantly and where you can search properly, but it's not worth the risk of getting banned again.
It's irresponsible that the warning is hidden down in "Acknowledgements" and if you go via the homepage to download there's no warning at all.
I actually wish they'd delete the warning so then anyone who gets banned from WhatsApp for using an unofficial client would have a more legit cause of action against WhatsApp. Meta wouldn't be able to defend themselves with "well you were warned" if you weren't warned.
Oh, but it's in Meta's ToS of course! Didn't you study those before agreeing to them? /s
Too bad. WhatsApp might be a reasonable service if you could trust the client not to spy on you.
I think this doesn't apply to European users, as WhatsApp announced around one year ago that under Digital Markets Act they were required to allow interoperability with third party providers [0].
0: https://www.whatsapp.com/legal/dma-notice-non-users
I presume if I use this my phone number will be blacklisted from WhatsApp.
That's the annoying thing with WhatsApp, Slack, Discord, etc. Let's say I've got a personal client (that I'm definitely not using...) which works so much better than the official one. I cannot distribute it or use it according to their rules. It's forced enshitification, even though we have better options.
On the good side though - if you're replicating the official behaviour close enough... maybe nobody will know. But then you have to make sure everything, including key sort order, and JA4 of requests matches. And that's tough...
it seems like we're entering the next phase of "written in rust": UIs
It's a bit basic. I installed it and then uninstalled it.