And if that was the case, can you compromise on feature? If not, and its not currently technically possible to achieve your performance ideal and have parity of features, then what? Is the right choice then to not release a desktop client for slack at all? And that could be ideal for you, but might still not be the right ideal for me, hoping to run it on a modded gameboy hardware. Your ideal could be that you absolutely need under 20ms response times on all UX actions, while never exceeding 100mb RAM. The idea of an ideal is itself a choice of trade offs. I understand you mean the user experience is still not ideal, but when would it ever be? When will performance or RAM usage be "ideal"? What does that mean? Should it compute in 0ms and use 0% RAM? There is no right ideal, or true ideal. To argue they made the wrong choice, you have to show they made the wrong trade offs.
#Slack desktop app 3rd party software#
To be honest, this all feels like moving the goalposts, and is why I usually refrain from getting into these discussions.Īll software engineering choices are compromised choices made from carefully considered trade offs. Every application does not need to function and look exactly the same. Hell, I'd argue that the consistency of UI/UX on Apple products matters more for the initial purchase and wow-factor than it does once a user has settled into their environment.
I'll also point out one more time that Telegram is what people bring up every time this discussion rolls around, so they're clearly doing something right and people must not think it looks _that_ out of place. The applications that keep me coming back are the ones that are smooth and don't interrupt my train of thought (most everything here), or have some big use case (Photoshop) that keeps me coming back.
The rest of the apps I find myself using don't use those same UI/UX patterns/designs, and I don't think it matters that much: Photoshop, Terminal, Telegram, Bear, Fantastical. Mmmm, that's really vague though - what exactly feels out of place? The only applications I use on a daily basis that feel like they're "Mac" are Safari, Messages, Xcode, and I guess Finder. (EDIT: Per reply below, turns out Adium did use a web view for presentation!) I know I'd prefer not to have previews and emojis, but I'm sure my colleagues find them useful. Maybe the detractors would prefer that the app did less. They would essentially be re-inventing a modular layout and rendering engine (aka a web browser). I wonder how much RAM Adium would have used to do the same things, and I wonder how much time the developers of an equivalent cross-platform app would have spent if they had been split trying to optimise lots of different platforms. Slack is doing much more than Adium: web previews, document previews, pulling in pre-rendered fragments from the server and modular stylesheets. An old favourite of mine, Adium, probably never used 600 MB because I'm pretty sure my PowerBook G4 had less RAM than that.īut I think it's a mistake to jump to the conclusion that these apps should be written in a native framework rather than a web view. When these kinds of things come up there's often complaint that desktop apps running in the browser are inefficient. And it still uses less memory than Slack.
It's true that a single one of its workers consume as much memory as a whole Emacs instance, but the development pace is staggering. It's light and nimble compared to alternatives. Look at Visual Studio Code, for instance.
#Slack desktop app 3rd party download#
While spinning up an entire browser for a single app has memory usage implications – namely, the baseline consumption is high, as is download size – the biggest issue is that it is easy to be wasteful when using web technologies. Every time you remove a barrier, you open up doors for more people. Electron makes it possible to create and ship apps very very quickly. Hint: most are not obsessing over TOP, Activity Monitor, or whatever your OS uses. Assuming your users even care about that. If it's a better product, it may take over market share. Well, by all means, create a Slack competitor in hand-optimized assembly if you wish. It's like pointing to 64KB demoscene games and saying "see, you can write a game in 64KB, why does this one take multiple gigabytes". Some posters seem to think that, because you CAN build a chat app consuming a few megabytes of RAM, it means you should and it's practical.