Discord should have a set of native open-source clients.
So, as we all know, the Discord desktop apps are using Electron and React. Electron is basically a chromium browser and a Node.js backend, and React is a JavaScript UI library for creating reactive interfaces, used for websites. Unfortunately, using electron for a Desktop app has some performance overheads. Having native clients on the other side is much harder to maintain, because each operating system requires different platforms - on Linux you would probably use GTK or Qt, on macOS you would use AppKit or SwiftUI and on Windows - UWP, WPF or WinUI. Maintaining this to have the same set of features would be extremely hard. However, if those clients would be open-source, they could be maintained by the community! With multiple open-source user-maintained clients, we would get native performance on all platforms which could still be moderated by Discord - because every pull request has to be accepted manually. I think that would be a great solution to the electron problem, and would give us much more benefits than just that! On macOS we could get touchbar support, and probably we would be able to resize the window with Magnet. (Also maybe Discord would stop appearing in Using Significant Energy!) On Linux, we would be able to finally get AppImages, and support for GTK themes, if we ended up using GTK, which would make the app look much more like it was made for the system! We would also get better window resizing on all platforms! I think these are some good reasons to have native open-source clients.
-
I agree on the fact we should have native clients. However I think your solution is not the "right" one.
First, let's think like Discord. What are the reasons **not to** allow custom clients:
- Feature compatibility: they just want the servers to communicate with the client the way they designed and as soon as they release the update.- Branding and advertising: when you see a screenshot of a Discord conversation without a modded client you almost always know it's Discord.
- Analytics: some unofficial clients may decide not to send analytics.
- Business perspective 1: other projects/corporations may re-use their code against them.
- Business perspective 2: custom clients may use some tricks to provide global emojis without a Nitro subscription.
Now, I'm going to explain why I think all of the reasons given above (again, not given nor endorsed in any way by Discord themselves).
- Feature compatibility is an actual thing and may be the most valuable reason. However, like any other app when you download an unofficial client you do not expect all the features to be present/working, as long as you can chat you can always launch the actual client when you need to do some more-specific configuration.
- Branding would have been a fair point a few years ago, nowadays almost everyone uses Discord on places the screenshots may end up (and if they don't it's because they have reasons not to). New people coming to Discord don't come from screenshots.
- Analytics isn't a valid reason either since you can disable them in the official client anyway (or at least, disable some of them). The only required analytics that can be omitted are platform analytics but why would you need platform analytics if it's not to improve the support on these platforms anyway? (and no, updating this ram-eater electron app isn't "improving")
- Business perspective 1: We're not asking to open-source the server-side so this argument would be purely invalid. You don't need to open-source the official client to allow custom clients anyway so this argument is even more invalid.
- Business perspective 2: not everybody would be able to see them tho since it would be client-dependent.
Again, that's only reasons I could think of and why they are wrong. If you think of any "valid" reason, I'd be glad to hear them.
> However, if those clients would be open-source, they could be maintained by the community!
Better, if those clients were **created and maintained** by the community from the ground up, it'd mean that Discord would have no extra work to do so no excuse.
It could already start today, there are a few good promising Discord clients being built (not the ones you expect tho, I'm strongly thinking about a terminal-based one) even if they break the TOS. People who want to do something will do it anyway, you can't forbid people to code things.Allowing custom clients would let more people start their project without being remembered every day that their project breaks the TOS.
So in summary, what we ask is custom clients to be allowed. The official client may or may not be open-sourced, I think Discord won't open-source but it doesn't matter. Asking Discord to create new native clients themselves will never be accepted nor considered.
It could make the app more usable for people who just want to leave it in the background without having to worry about how much memory it takes (seriously, hundreds of MB is a lame joke).
0 -
I do agree with most of your points, but I believe Discord could hand-pick some of the community made clients and give links to them on their website as unofficial clients, if they were to for example be capable of sending the analytics, wouldn’t cause any API spamming and not give nitro features without nitro. That would let us have custom clients, while some of them would be much more popular because Discord approved them.
0 -
And I 100% agree on “created and maintained”.
0 -
> Having native clients on the other side is much harder to maintain, because each operating system requires different platforms - on Linux you would probably use GTK or Qt, on macOS you would use AppKit or SwiftUI and on Windows - UWP, WPF or WinUI. Maintaining this to have the same set of features would be extremely hard.
That argument is invalid if you use a cross-platform toolkit such .net core and avalonia (http://avaloniaui.net/).
However, the developers would have to learn a new language. Plus, there are three codebases to maintain (the desktop app, the web app, and the mobile apps) instead of just two (the web app and the mobile apps.) However, even that is mostly void once avaloniaui gets better mobile support (it is open source so discord could help with that). Also, there is work on making a webassembly version of avaloniaui which would drop them down to one app, but that is a long way off at present.
0
Please sign in to leave a comment.
Comments
4 comments