I wonder how much longer Slack’s web client is going to remain a first class product? Clearly, it was a good way to drive adoption, but seems that at this point they want ever more control.
> I wonder how much longer Slack’s web client is going to remain a first class product?
It never was? The Android client takes 10 seconds to start, runs my device hot and the UI is so bad that the first time I tried to respond to a thread I couldn't figure out how to get out of the thread view.
The desktop client uses 1GB of memory gobbles my CPU and takes 20 seconds to start.
The "least bad client", the web client still takes 10 seconds to start, for no obvious reason. Last week I looked into it, it turns out that every time the client makes a request to the server it the TTFB is 300 to 500ms, on a connection with 40ms ping. So their backend is just as fucked as all their clients.
Even their email notifications don't work: every time I click on the link they send me it doesn't take me to the mention!!!
They did corner the market so clearly they must be doing something, but really I just can't see it. I'm completely stumped.
>They did corner the market so clearly they must be doing something, but really I just can't see it. I'm completely stumped.
I've been wondering about this for a while now. Slack feels more like "just good enough" in terms of UX than anything special. It's just a chat application with terribly slow clients but somehow everyone is using it.
> They did corner the market so clearly they must be doing something, but really I just can't see it. I'm completely stumped.
One of the reasons is the lack of competition, e.g., we use Microsoft Teams instead, but its also an electron app with the same problems (and takes ages to start).
I guess this must be it. IRC could in theory do everything Slack does but setting up a server is a pain and shiny clients are rare...
I wonder about the rest of the competition, for a while everybody was using hipchat, I never used it myself, I wonder why nobody talks about it anymore.
There are many enterprises that have web-only workflows. Eliminating the web client for Slack would be like eliminating the web client for Google Docs.
now that they got all that money, I wouldn't be surprised if they killed the web app and moved away from Electron to do native apps that are harder to be messed with.
I'd love a better-performing, less memory-intensive and, well, more native Slack app; I'm all for that part. The "harder to mess with" part is a little more concerning.
(I didn't catch the original mention of BetterSlack a few days ago, so ironically, your "Welp, gotta withdraw this!" message here is the first I've heard of it. This seems to be my usual timing with such things, though...)
> to do native apps that are harder to be messed with
As someone who messes with native apps: this really isn't true, at least in my experience. Native apps tend to follow platform paradigms, which usually make them reasonably well designed and structured–sometimes more so than web applications. Usually adding functionality is simply a matter of finding the class that manages the component, rather than digging thorough a bunch of broken CSS (for IE 6 support) and minified goop.
You do it the same way exploit writers do. Attach a debugger to the process, find the memory address of the resource you want to modify, overwrite the address with the address of the modified resource you want to execute. You could also just use the debugger to force the program to execute functions with arguments you specify, that way you don't have to worry about mucking with the memory.
Usually you'd create a dynamic library that interposes a function, so you don't have to much around with using a debugger. This way you have a persistent modification that's much more resilient to changes caused by app updates. Exploit writers generally have different goals: their thing only really needs to work once, and only with the current configuration, since usually the bug they're relying on gets patched in the next version.
Also, depending on the platform, if a native application is following the platform guidelines, then quite a lot of things you want to change might be located in data files or "resource" section of the executable.
I haven't been messing much with Windows executables for quite a while, but back in the day, I'd "improve" many programs by just editing their resources.
