The nice thing about this question for old-timers is that we can recycle the answers we already heard about using Java for cross-platform desktop development from 20+ years ago. Or the rationale for using a cross-platform toolkit with C++ from 30+ years ago.
You get substandard desktop applications that tend to frustrate people who are deeply immersed in any one ecosystem and expect native applications to have deep integration with each platform and comply with each platform’s design sensibilities.
But history shows that applications written against cross-platform toolkits have done just fine, as have applications that completely embraced “going native” on particular platforms.
I’m left with the thought that either strategy works if you go “all in,” the mistakes come from:
1. Going cross-platform but then doing ridiculous back-flips to try to make the app feel really, really native. Just take what the platform gives you, and accept that you’re giving people a web-like experience that happens to have some native affordances. Learn to live with the few complaints from retro-grouches.
Or, 2. Going native, but skimping on deep integration and fully embracing the look and feel of each platform. This is one of those “penny-wise, pound-foolish’ strategies: You ship faster, but you lose the big benefits of a cross-platform tool, and you don’t satisfy the users that appreciate what a native app offers in look, feel, and integration.
Ha, I meant it in the opposite way, that it avoids making either mistake. Yes, it consumes a lot of resources, but it's success has proven that users don't mind this as much as commenters on hacker news seem to.
And it's a program that is slick, intuitive, and supports so, so many use cases without ever feeling overloading.
Disagree fully. As an app I feel Discord is slow (on an Intel 9700K), clunky, and not really intuitive. Just the text input delay is noticeably slower than example Word or Sublime text.
I'm only member of 6 channels and have maybe only that many private messages open at a time, maybe it becomes more intuitive it there are more? But I don't understand how that would be.
One thing that is extra annoying is that the settings window can't be a separate window, so every time I have to adjust audio settings I get muted and lose the chat focus.
Over-100-server lurker here. I majoritarily use servers, not DMs, and could see why people that use a lot of DMs would find the layout inconvenient.
I think the UI mostly makes sense, it has a hierarchy from left to right, so it is essentially a amped-up tree-view. You could argue for actually using a tree view (a la TeamSpeak), at least on desktop, and I wouldn't disagree, but it kind of makes sense given parity with the mobile app.
I don't see a need for minimal input delay for text, compared to a code editor, as when writing natural languages, they are mostly formed in sentences and therefore have a lot of "buffer" in my brain, I don't need a closed feedback loop to type. Suppose that someone that relies on that would be rightfully befuddled with any delay.
It uses 156 megabytes of memory even on this high-volume scenario, so I would say that while baseline performance is low, it doesn't get slower, which is good.
That being said, I can always find what I want in the UI, it is rather internally consistent. The voice features are excellent and it has less outages than Slack, in my experience!
I'm using Discord (with BetterDiscord and a CSS theme overtop) on an i5 4460, and I can barely notice any latency when typing. The only time when I can get input latency past 100ms is when I'm rendering something in Blender, or have a high-CPU game running in the foreground.
The UI is getting worse, as they overload existing UI elements with new functionality. On mobile, they replaced the "recent mentions" button with a "stages" button (I don't use stages), making it harder to look for recent mentions just to promote their Clubhouse clone. On desktop, they replaced the "upload image" button with a button to open a "upload image or create thread" menu (I find Discord's implementation of threads to be half-baked, threads expire quickly unlike forum threads, you have to pay to reduce expiration, and they override server-wide mutes). You have to double-click to skip the menu.
Not to mention stuffing their UI with payment prompts left and right, showing emotes you can't use in the emote menu, replacing useful screen estate with "get nitro" and "boost servers" buttons.
- you want to make sure that people respect the importance of your app by not running it along with everything else because it needs 10x the amount of resources a native app would
Users don't care anymore. Phones have 12GB of RAM. A $500 laptop will have plenty of RAM, CPU power, and storage for the average user to not even notice anything. HN and reddit are the only ones who can't seem to grasp the idea that it's not 1995 anymore, and apps taking even 1-2 GB of RAM isn't that big of a deal for the average user.
Do I want my CAD software as an electron app. Obviously not, but for most applications electron is just as good an option as anything else.
Sure, if you constrain “average user” to America. If you go to other places like India, where people don’t have $500 lying around to drop on the latest notebook, you’ll find a lot of repurposed laptops that have several-year-old specs still finding active use. Machines with 2 GB RAM and 250 GB spinning rust are not as uncommon as you might think.
And sure, if you just run one app and that’s it, you might get away with acceptable performance. But now try to install it over slow or metered Internet. Try to run it alongside Chrome/Discord/Eclipse/Spotify/Android Studio. Try to install all those apps without chewing up your disk space. These aren’t hypothetical scenarios, these are very real usability concerns.
> and apps taking even 1-2 GB of RAM isn't that big of a deal for the average user.
I live in France, a first world country, just checked Amazon, the N°1 best seller laptop currently has 4GB of RAM, a 64GB SSD, and a 1366x768 screen and a dual-core Intel Celeron CPU which does not even reach 3Ghz: https://www.amazon.fr/HP-14s-dq0000sf-Ultraportable-Microsof...
this is what the average user looks like (and will still look like in a few years, if people buy a laptop today it's generally to keep it 5 years). I have never ever ever seen anyone say "hey, my computer is fast" it's always "do you think you could look at it, it's super slow / it has viruses / ..."
Yea, these are poor reasons imho. Relying on mommy Chrome and the hellscape of ECMA transpilers seems like the opposite of "cross platform" since you rely on a much more unstable foundation...
You get substandard desktop applications that tend to frustrate people who are deeply immersed in any one ecosystem and expect native applications to have deep integration with each platform and comply with each platform’s design sensibilities.
But history shows that applications written against cross-platform toolkits have done just fine, as have applications that completely embraced “going native” on particular platforms.
I’m left with the thought that either strategy works if you go “all in,” the mistakes come from:
1. Going cross-platform but then doing ridiculous back-flips to try to make the app feel really, really native. Just take what the platform gives you, and accept that you’re giving people a web-like experience that happens to have some native affordances. Learn to live with the few complaints from retro-grouches.
Or, 2. Going native, but skimping on deep integration and fully embracing the look and feel of each platform. This is one of those “penny-wise, pound-foolish’ strategies: You ship faster, but you lose the big benefits of a cross-platform tool, and you don’t satisfy the users that appreciate what a native app offers in look, feel, and integration.