"It's not built on top of web browser technology: it responds quickly to input, sips gently from computer resources, and gets out of your way."
To contrast, MSN Messenger 4.7, an app with similar capabilities (IM, voice, and video calling), is only ~2MB --- with several third-party reimplementations being <1MB. Makes you wonder how small you can make an app for today's messaging services if you really tried... they don't need to be that big even if they don't include an entire web browser.
MSN Messenger probably uses WinAPI and being a Windows-only program it can get away with it.
There is place for 32 bit applications but not here! The job of a program is to do what it is supposed to do efficiently and get out of the way, and it better use all registers and instructions needed to do it.
Yeah it is. You need to move 7 bits through memory and through the CPU, is it more efficient to pad it with 25 blank bits and move 32 bits overall, or pad with 57 blank bits and move 64 bits overall?
Which is doing things "more efficiently" and "better using" the hardware?
your cpus arent capable of 32 bit calculations anymore... so the questions is: is the software emulation of your OS for 32 bit more efficient than the programming language overprovisions.
The CPU is naturally still able to do 32 bit calculations.
What you can't do is run a 32 bit application without emulation after a 64 bit system has booted.
The libraries are obviously also required, but it still won't be able to start without the emulation adding 0 to the memory blocks.
Windows in specific uses WOW64 -- Windows 32 on Windows 64. It's an emulation layer that doesn't actually hamper performance but does do things a bit differently than a native OS -- such as running all 32bit programs in 'user mode' rathe than with elevated permissions.
You can get a brief synopsis here - https://www.techsupportalert.com/content/how-windows7-vista6...
When can I finally get rid of this stupid "Program Files (x86)" folder which annoys me every time I click into the wrong one looking for my program, when even new programs are released as 32-bit?
A 32-bit binary will work just fine on a 64-bit OS, but not the other way around, and there's no reason such an app needs 64-bit, so why unnecessarily restrict compatibility?
1. macOS will deprecate 32-bit completely soon,
2. Linux needs 32-bit libs installed on the system, and many people don't have them,
3. Windows has really good backward compatibility and still supports 32-bit. But it's the only system.
So, distributing a 64-bit-only software actually makes sense.
When I install something, if it pulls in a ton of stuff, I'll reevaluate whether I actually need it. In fact, I was pretty excited when I finally got rid of my dependency on 32-bit stuff and could eliminate the 32-bit repo.
I like 64-bit because it keeps my system clean, but because it's "better". I definitely want a 64-bit OS so some things can use more than 4GB RAM, so why have two copies of everything? Just standardize on the thing nearly everyone uses: 64-bit.
Can we stop assuming that people are always going to have the latest hardware? Even then, 32-bit SoCs running Linux are still pretty common in various embedded things and other low-power devices --- exactly the use-case for a small and native chat client.
Slack client on an embedded platform? Are you ok?
It's not native (as in native windowing toolkit), it's Qt based which is probably where most of that 30MB is going, MSN Messenger is/was built on win32. Still, in the age of electron apps that's a huge improvement, it's good to see real desktop developers still exist.
IRC as a protocol probably can be used to build a service as friendly as Slack. I.e. it's not a problem to add URL autoexpansion, like in this WeeChat plugin: https://github.com/antekone/youtube-autoexpand . Of course it's not easily possible or practical to show pictures inside of the terminal window, but I think it's entirely possible to create a new modern Slack-competitive IRC client over a pure IRC network. What could be done on IRC can be seen in an old Microsoft app, Microsoft Comic Chat: https://en.wikipedia.org/wiki/Microsoft_Comic_Chat .
(disclaimer: i prefer IRC to Slack/Discord but I get why for many people IRC is a bad idea)
Whereas posting images directly into the chat window and having everyone see it is insanely useful.
Anyway I think saying that it's "insanely" useful is a gross exaggeration. You know what is insanely useful though? Having open source clients and access to logs without paying $100 per year per user.
Image pasting is for more than just memes. We can post screenshots of errors, or user data/visualisations, or sections of syntax-highlighted code. All of this is infinitely more agile than going through a bulky ticket system (which we also use once we’ve confirmed as bugs or decided how to use forwards). So no, it’s not an exaggeration at all.
IRC was fun in the 90s but seems to have stopped there? It was also never ~at all~ friendly for non-technical users, which is a complete non-starter nowadays.
-MemoServ(MemoServ@services.)- ***** MemoServ Help *****
-MemoServ(MemoServ@services.)- MemoServ allows users to send memos to registered users.
-MemoServ(MemoServ@services.)- For more information on a command, type:
-MemoServ(MemoServ@services.)- /msg MemoServ help <command>
-MemoServ(MemoServ@services.)- The following commands are available:
-MemoServ(MemoServ@services.)- DEL Alias for DELETE
-MemoServ(MemoServ@services.)- DELETE Deletes memos.
-MemoServ(MemoServ@services.)- FORWARD Forwards a memo.
-MemoServ(MemoServ@services.)- HELP Displays contextual help information.
-MemoServ(MemoServ@services.)- IGNORE Ignores memos.
-MemoServ(MemoServ@services.)- LIST Lists all of your memos.
-MemoServ(MemoServ@services.)- READ Reads a memo.
-MemoServ(MemoServ@services.)- SEND Sends a memo to a user.
-MemoServ(MemoServ@services.)- SENDOPS Sends a memo to all ops on a channel.
-MemoServ(MemoServ@services.)- ***** End of Help *****
For anyone who knows what I mean, it might be interesting to write such a "lightweight" web client for e.g. Slack, restricting yourself to whatever JS abilities were available in 2000 or so, yet imitate as much of the features and appearance of the web client today as possible. Chances are it will still work with "modern" browsers too, and use a tiny fraction of the resources of the current one. All the better if it gets noticed and DMCA'd.
It is also single-threaded (without workers, which have their own limitations), and any large calculation can block that main thread.
The only apps that consistently send my laptop fans in to a flying rage are Electron based apps.
800Mb to VS Code
650Mb to Slack
Is slack's web socket taking 600Mb?
An app's resource use should just justified by what the app does. It's really telling when a 3D game engine uses about the same resources as an electron app.
I’d open source comms tools leaned more into business use cases (mattermost does this well) then there could be more usage
I imagine that's true for companies whose users stick to internal workspaces, but often the most active/vocal users (1) participate in multiple (often professional) non-company workspaces, and (2) don't want to run Yet Another Chat client.
On Linux, I use weechat to connect to a local bitlbee for Discord and Hangouts. When I was using Slack I used wee-slack  with success, but it looks like bitlbee has a plugin for Slack, too . This lacks a few of the features of Ripcord (e.g. voip, graphical emoji, emoji completion), but it works.
 - https://github.com/wee-slack/wee-slack
 - https://wiki.bitlbee.org/
I checked for:
* Thread support (yes)
* Drag n drop images (yes)
* SSO support (yes)
* Quick Switcher (yes)
* Default dark mode (yes (!!))
There are some things missing, like search, fine grained notification controls for muting, profile editing, code snippets, moving emojis, etc. But for daily communication, I'll give it a try. Feels fast and light.
Edit: After some time, I think I will keep it around for when I am on the go and want to preserve battery. I do not think I'll use it full time because I miss some of the colourful whimsy of the Slack client.
Isn't that a feature?
I would think that worst case, slack could kick users off for breaking their terms of service (assuming there is a clause for that). But a random software maker is not subject to slack's terms.
The gist of Blizzard’s argument was that the software was designed for the sole purpose of facilitating customer violations of their EULA causing monetary harm to Blizzard.
Disclaimer: I used to be a customer service representative of Blizzard Europe, but not since 2012.
Slack would also need to prove monetary harm. I can't imagine a more efficient client would hurt their service. Maybe just their pride.
Could you elaborate? Slack provides client tokens and they don't seem to forbid that in the way Discord does (in fact they explicitly provide client tokens via OAuth).
However, I could have sworn there were a few full-fledged clients that Slack didn't like. I feel like one of them was a terminal-based client.
Works really well though. I've been lazy about addressing a mic-not-working issue on the linux client, and had been resorting to using the webapp when I wanna voice
This ends up working fine for me though re: voice
Low footprint is nice too
Yes, TOS are not legal documents. We all know that. That doesn't make Discord beholden to granting everybody the same access to their service. I don't know why people feel the need to bring the law into it; it was never relevant to start with, so making a point of it is unhelpful.
It's against the terms to use the user api (although it will work until you get caught), I'm not sure if they explicitly ban 3rd party clients (they very well may) but this effectively does the same thing.
Bot on normal account detection is based on outlier usage statistics from regular accounts, like too many requests or something.
All Ripcord requests (to discord) actually have Ripcord in their User Agent header, discord can immediately detect it's usage, they have not banned anyone for using the software specifically, only for the same reason they have been banning Selfbots (Users ending up spamming the API)
If you want something that doesn't suck, look somewhere other than Discord. It sucks that it's so embedded into so many groups but Discord isn't a very friendly entity.
Pretty funny the iterations chatting over the internet has went through over the years. Feels like bell-bottoms just came back into fashion.
They are working mainly on their own server and Trillian for web, but the desktop version is still alive https://trillian.im/news/
Mostly. It doesn't show messages with the facebook link-preview.
I hate what Google did to GTalk and Hangouts
However I do wish this was an open source project. Seems odd to close something like this off in this day and age. Seems like another one of these chat clones destined to die off unfortunately.
Even in the case of those programs you mentioned though, aren't they still plagued by a slow/electron based client?
*edit: I just looked into Matrix. Looks awesome. Wish my friends used chat programs like this. I will try to implement this with some of my closer friends.
- Back-end: Qt5, breakpad, QtKeychain
- Front-end: TypeScript, webpack, babel, react, redux, redux-observable, redux-persist, QML.
The best part is that we can truly "code one, deploy everywhere". I was able to compile Ben to both desktop (MacOS, Windows) and mobile (iOS, Android) from same one codebase.
Though it's still far from feature-complete but I hope I can finally uninstall the official Slack app for good. You can try latest build here 
I think it's fair to refer to it as native.
But if this is stable and lightweight I might use it. Gonna test it for a while.
Just because there are a bunch of group chat apps already, doesn't mean people won't switch to a better one.
This seems to be a common hurdle on non-Electron Slack clients (well at least on the one or two others I tried within the last few years that I can't remember the names of now).
If you're familiar with HAR files, this is what's used
So, what are chances that Discord may feel "offended" by user login with and using Ripcord?
I do have one question. <!here> is how you notify everyone in a channel about your msg. Can you customize this in the settings? otherwise, its a small adjustment I can make as you already have an app that I like more than the native slack app on macOS.
This seems like the only functionality that would keep me from using Ripcord full-time.
The software now doesn't sync users to a sqlite local database if there's over 10k members in a guild, as a precaution
Discord is a pretty decent company so far IMO, I figure if they're okay with 3rd party clients then they'll be extra lenient on the rules. So far their success has been how much the community loves love (not to mention how well it works).