21 ms·

When a rewrite isn’t: rebuilding Slack on the desktop

289 points by kgraves 7y ago

TimWolla 7y ago
I already noticed that after the workspace selector looked different Slack was no longer being regularly killed by the OOM killer. Finally.
kndjckt 7y ago
Give me Grammarly and Dark Mode and then I'll stop using the browser version
- dewey 7y ago
  I'd rather not send my keystrokes to two companies at the same time. Not sure they changed that but this is always at the back of my mind when I see someone use Grammarly via the browser extension: https://techbeacon.com/security/grammarly-leaks-everything-youve-ever-typed-service-everything https://techbeacon.com/security/grammarly-leaks-everything-y...
  - kndjckt 7y ago
    Excellent point :/ Is there a security-conscious Grammarly alternative?
    - jamesponddotco 7y ago
      I use their macOS application instead, and make sure not to type anything sensitive. Not as easy as using their browser extension, but it is safer. Been trying Language Tool as well: https://languagetool.org/ https://languagetool.org/ Not nearly as good as Grammarly, though, but it works with more languages and even has a plugin for vim.
pixelbath 7y ago
Good news for the Slack team, as this means they'll no longer be the poster child for "look how bloated Electron apps are! Slack takes up x gigabytes of RAM!" Great work, Slack team.
- mac01021 7y ago
  I can still say "Look how bloated Electron apps are! Slack takes up half a gig of RAM!".
steeve 7y ago
I was so happy they had finally gone native. The disappointment is strong. On a side note, SBlack, a lightweight slack client is very impressive on memory usage [1]. 1. https://www.sblack.online/ https://www.sblack.online/
- btmiller 7y ago
  How does this work? I thought Slack deprecated their IRC gateway; is this all API-based then?
  - swalladge 7y ago
    > Sblack works exactly like a browser with small tweaks. Looks like it just wraps the website in this case. Yes there are clients that use the API. Slack offers a http rest-like api as well as a websockets realtime api. For example, wee-slack[1] (weechat plugin for slack) and slack-term[2] (curses client in golang). [1]: https://github.com/wee-slack/wee-slack https://github.com/wee-slack/wee-slack [2]: https://github.com/erroneousboat/slack-term https://github.com/erroneousboat/slack-term
  - wlesieutre 7y ago
    They advertise 20 MB instead of 180 MB and not being Electron, so I would bet it's Slack's web client wrapped in macOS's built-in WKWebView, plus some custom CSS to support dark mode. >Sblack works exactly like a browser with small tweaks. We inject the dark mode style at the end of the Slack’s html, and that’s it. Another benefit of this is that Safari/WebKit does better with battery life than Chrome. I'll have to give this client a look.
pwinnski 7y ago
"We acknowledge that nobody should ever rewrite from scratch... but after five years we're rewriting from scratch because we know better."
- bdcravens 7y ago
  It’s an iterative rewrite, which is how you should do it. “Rewrites are bad” refers to a blank slate and reimplementing.
  - pwinnski 7y ago
    I didn't choose the framing, they did. Here are the first sentences of the first two paragraphs: > Conventional wisdom holds that you should never rewrite your code from scratch, and that’s good advice. > Still, software codebases have life spans.
    - bdcravens 7y ago
      Yes, those sentences set up the rest of the article, establishing the thesis: Those two sentences are true, and not necessarily at odds with one another. The author spends the rest of the article explaining this, and how they accomplished it.
zeusly 7y ago
I wonder if they increased their efforts after seeing VS Code (also a complex Electron app) run fast and memory-efficient. Before VS Code everyone just accepted Electron's memory bloat, maybe slack even had plans to go fully native b/c no one thought it could be done properly.
- doc_gunthrop 7y ago
  > memory-efficient. Not how I'd describe a text editor that consumes 700MB+ of RAM at any given time.
  - spookthesunset 7y ago
    Yes, because vs code is just a mere text editor.
  - wgoodall01 7y ago
    Replace "text editor" with "IDE," and that 700mb figure doesn't seem so extravagant.
    - flukus 7y ago
      It does to those of use that remember upgrading to (I think) 128MB of RAM to run Visual C++ 6, it's not like a heap of new features have been added since.
mtarnovan 7y ago
How about a native client? I think it's safe to assume that Slack has the resources for this.
- _bxg1 7y ago
  No matter the available resources, maintaining three separate desktop apps as well as a web app would mean fewer features and more bugs across the board. And Linux would probably be left on Electron (with less support attention), if not abandoned altogether.
  - sagichmal 7y ago
    Past a certain point, the downsides of Electron outweigh the downsides of native apps. We've crossed that Rubicon years ago.
    - bengale 7y ago
      If this was the case we wouldn't see so many Electron apps. You just don't perceive enough of the upsides to see why the decisions are being made.
      - wlesieutre 7y ago
        The upsides are for the companies shipping it, the downsides are for the users. So it's not a surprising outcome.
        _bxg1 7y ago
        Tell that to people who want to use modern services on a Linux workstation
        wlesieutre 7y ago
        That's nice for them, but no matter what OS you're on the desktop client is probably crappier than loading up the webpage, with the one upside of giving you a separate icon in the dock and app switcher. Even with the performance improved, the "stuff the whole app in one web view" implementation is still showing. Clearly this isn't an Electron limitation; VS Code handles multiple windows just as well as any other text editor. Slack's desktop client is basically "It's a web browser except worse and with the URL bar hidden." Since chat requires an internet connection and it's not like Slack's desktop version launches particularly fast, I'm not sure that it does anything better than using a browser. We'll see if they support multiple instances on iOS 13. If they do, maybe we can get a Mac version based on that for something closer to native desktop behavior.
nottorp 7y ago
They say React. How is this a desktop app? It's still in a browser.
- pwinnski 7y ago
  Electron makes it a desktop app. That part has not changed.
  - nottorp 7y ago
    Just because you don't see the browser it doesn't mean it's not still there. No, js/html "applications" are not desktop apps, they're web pages. Doesn't matter how you hide it.
    - theredbox 7y ago
      Is Sublime Text a native app or a web page?
      - bdcravens 7y ago
        Native. VS Code is a web page by this definition however.
      - guessmyname 7y ago
        Sublime Text is 100% a native desktop application written in C++ with the Skia graphics library [1][2]. However, only a tiny fraction of Skia’s functionality is actually used, just for rasterizing lines and blitting images. Font rendering is done by using the underlying platform APIs to do the glyph rasterisation. The editor also exposes an ABI/API that plugins can use via Python scripts. C++ provides the cross-platform functionality, Skia provides the cross-platform UI, custom code was written to target specific parts of the UI in macOS (using Cocoa) and Linux (using GTK). A tiny web driver is used to render a super-minimal set of HTML tags for tooltips. [1] https://news.ycombinator.com/item?id=11689481 https://news.ycombinator.com/item?id=11689481 [1] https://skia.org/ https://skia.org/
    - 7y ago
deleted 7y ago
[deleted]
_bxg1 7y ago
The most interesting details: - The first iteration was largely powered by jQuery(!) - Every workspace got its own isolated Electron process because they didn't anticipate multiple workspaces in their initial architecture Honestly it's amazing they got as far as they did with the above limitations. Sounds like this rewrite was sorely needed after their phase of rapid growth. Glad they pulled it off.
- mosdl 7y ago
  They switched to React, which will increase their memory usage and be slower than pure js.
  - untog 7y ago
    > be slower than pure js There's no way of knowing, without knowing what they were doing previously. The whole point of React is to leverage the virtual DOM to avoid unnecessary (and very slow) DOM manipulations. Given the sheer number of things Slack has on any given page it isn't unreasonable to expect that React will make things quicker, even if it has a penalty at startup time.
dstaley 7y ago
The post doesn't say, so does anyone know if the new React version is also available on the web?
- _bxg1 7y ago
  There would be no reason for it not to be; it's possible it hasn't rolled out yet, though.
- methyl 7y ago
  I see the new interface (mainly chat input) and notification that Slack just became snappier on the web.
me551ah 7y ago
For me the gold standard of Chat applications is always going to be mIRC. It supports a ton of plugins, consumes 10-50mb of memory and little to no CPU. You could be connected to multiple servers and channels with DCC scripts running and you still wouldn't notice that it's even running. Even though Slack is using react now, they are still using electron under the hood. Which means it can never match the snappiness of a native application like mIRC.
- ausjke 7y ago
  mirc is windows only? there are many web-based irc these days and they worked well
  - ausjke 7y ago
    interesting, so I checked out mirc and reported it's windows-only(hope to save someone sometime), and since I used irc over browser so I added some info for that. Still, obviously someone disliked this sort of comments and downvoted, I'm always surprised by downvotes like this sort, any bystander can shed some lights? Am I supposed to always write a cheerful comment for basic neutral truths?
    - dingo_bat 7y ago
      I guess down votes are because most software is windows only. Also the general topic of the thread was native clients, so expecting a web client was not very appropriate.
  - AdamJacobMuller 7y ago
    Can you find me a web-based IRC client which runs in <100MB of memory?
- tonyarkles 7y ago
  Not mIRC, but I run x-chat and Slack side-by-side on a daily basis. Wholly different experience... I don’t think I’ve ever had to kill x-chat for pegging a CPU and killing my battery :)
oflannabhra 7y ago
This is great, but that ship long sailed for me. I still use Slack extensively, but for the past year+ exclusively in Safari tabs. Memory usage and Energy usage (I'm on a MacBook Pro) have both quartered (or more).
- voicedYoda 7y ago
  For over a year i was running 5+ Slacks in the Electron app, and continuously noticed how much memory was being hogged up. After some basic research, I realized that Electron is basically a wrapper of a Chrome instance. Suddenly i understood where my ram was disappearing to because so many "native" apps running in Electron were literally just spawning new chrome instances and gobbling up ram. I now do my best to keep my website apps running just in Firefox containers. Electron feels like the last rush of "write once, deploy everywhere" days of flash and Adobe air. God save us all.
Klonoar 7y ago
I will consider this benchmark vindication both for myself and the times I've had to argue as to why Electron isn't the issue, as well as the commentator from many moons ago who worked at Slack, dropped in here and explained why Electron wasn't the problem (rather, poor engineering on Slack's part was), and then was ripped to shreds over it. In fact I'm sure this comment will bring out native fanatics in force. At any rate, good for them. Seems like they reengineered themselves to a happy medium. I can definitely see myself installing it again at some point.
- matchbok 7y ago
  And yet, the performance is still bad. And that is only 1 of many reasons why electron is bad.
  - _verandaguy 7y ago
    A hundred times this; 500-1000mb of idle memory usage by a chat client is patently silly.
    - therealdrag0 7y ago
      Sure, but on my MBP it's never been a problem. I've never had slack lag regularly or notice it impacting other programs. :shrug:
- DaiPlusPlus 7y ago
  I’m still skeptical. The memory usage chart from the article shows only a slight (10%?) improvement for single-workspace Slack clients, now at around 250MB. Yes, getting a 5+ workspace client down from ~800+MB to 300MB should be applauded - but the 250MB floor is still too high. I want to know what’s in the 250MB it’s still using.
  - penagwin 7y ago
    In my experience at least ~100/150MB will be electron's minimum anyway, certainly impressive what they've done but I think they've basically hit bedrock unless they either improve electron itself or switch to something different.
ausjke 7y ago
so this new Desktop app will run inside a browser? or it still uses Electron underneath? It's unclear to me after reading the post. It's certainly not a native app though.
- _bxg1 7y ago
  You're correct about what "native" means; the article never uses the word "native", though. This is still an Electron app, just a vastly improved one.
  - ausjke 7y ago
    thanks. realized the native is from a comment and just updated, so this is an improved electron slack desktop app then.
charlieegan3 7y ago
I got this update in the browser, does anyone know what happened to the subdomains? (e.g mycompany.slack.com)
k__ 7y ago
I hoped the go for Revery. Would be cool to see a native Reason app from such a big player :)
deleted 7y ago
[deleted]
bfrog 7y ago
Well there goes my last hope of ever getting a native slack client in my lifetime. I miss hipchat often. They had enough sense to make the client native.
- s_y_n_t_a_x 7y ago
  Not really, they could use React Native, even for desktop.
  - pjmlp 7y ago
    Actually that would be much better. There is hope though, React Native for Windows team did a presentation showing how bad Electron resource usage was versus their React Native for Windows prototype. So maybe they could do some advocacy to the VSCode team and start a migration movement.
    - s_y_n_t_a_x 7y ago
      This rewrite is the first step of that, going from jQuery to React. React Native for Windows is ready for production, it powers their new Skype. It's being rewritten right now from C# to C++ for better performance in their vnext branch. You have the option to use react-native-web (Twitter's way) to run your React Native app on the web, or use ReactXP (Microsoft's way). React Native Web forks React Native. ReactXP wraps React and React Native. Two different approaches. Personally I prefer ReactXP because React Native Web will always be too far behind React Native. It's easier for ReactXP to update. Both projects have major backers and power major products.
- charrondev 7y ago
  Are you sure HipChat was a native client? At least on MacOS I’m pretty sure it was some web view. If not Electron, one of the others. I was very happy when we switched from HipChat to slack.
  - guessmyname 7y ago
    HipChat was originally built using Adobe Air (2012) [1]. Then they switched to QT using WebView (2013) [2]. Then they created Stride using Electron (2017) [3] Finally they created a partnership with Slack (2018) [4]. [1] https://www.engadget.com/2013/02/14/hipchat-ditches-adobe-air-for-a-native-mac-client/ https://www.engadget.com/2013/02/14/hipchat-ditches-adobe-ai... [2] https://techcrunch.com/2013/02/14/with-3500-paying-customers-hipchat-launches-a-native-mac-client-to-vanquish-the-lousy-adobe-air-app/ https://techcrunch.com/2013/02/14/with-3500-paying-customers... [3] https://techcrunch.com/2017/09/07/atlassian-launches-stride-its-slack-competitor/ https://techcrunch.com/2017/09/07/atlassian-launches-stride-... [4] https://www.atlassian.com/partnerships/slack https://www.atlassian.com/partnerships/slack
deleted 7y ago
[deleted]
Despegar 7y ago
Slack is eventually going to write native apps once they realize that productivity software shouldn't be developed like an ad product from Google. It will take Teams winning because it gets included in the Office 365 subscription for several quarters before they come to the realization that they need to compete on user experience.
- heavenlyblue 7y ago
  Google’s Ad product always had a desktop client called Adwords Editor.
- basch 7y ago
  an electron app (teams) beating them will lead them to the conclusion that they shouldnt use electron? I mean, I agree, losing mass marketshare SHOULD lead to a major shakeup on trajectory, and competing on desktop user experience would be a logical next step. But... back to the first sentence of this comment.
  - Despegar 7y ago
    Teams is winning because it's being bundled with Office 365. The business model and distribution lets them compete effectively with an inferior product. Slack doesn't have that luxury.
    - Guillaume86 7y ago
      Teams is so inferior I'm not sure they compete for the same market, when team chat become really important Teams is just not an acceptable option in my experience (we had to switch away from Teams last year because there was too many bugs/frustrating issues and basic features missing, like a actually usable search feature).
      - basch 7y ago
        its about momentum though too. your point in time experience is quite different than the trajectory/velocity of the product, and its rate of change.
acemarke 7y ago
I know that popular opinion in the Twitterverse is that "Redux is dead", but I note that both Twitter and Slack just released major rewrites that use Redux heavily. I talked about Redux usage stats and comparison with other alternatives in my "State of Redux" talk at Reactathon earlier this year [0], and my post "Redux - Not Dead Yet!" also addresses some of these aspects [1]. Also, quick plug for our current focus. I'm working on some tutorials for our new Redux Starter Kit package [2], and then will be working on tackling additional functionality to push it towards a 1.0 release [3]. After that, we'll get started on a major revamp of the Redux docs [4] to improve the learning flow, better organize the content, cover more real-world usage topics, and teach using Redux Starter Kit as the "default way to write Redux". [0] https://blog.isquaredsoftware.com/2019/03/presentation-state-of-redux/ https://blog.isquaredsoftware.com/2019/03/presentation-state... [1] https://blog.isquaredsoftware.com/2018/03/redux-not-dead-yet/ https://blog.isquaredsoftware.com/2018/03/redux-not-dead-yet... [2] https://redux-starter-kit.js.org/ https://redux-starter-kit.js.org/ [3] https://github.com/reduxjs/redux-starter-kit/issues/82 https://github.com/reduxjs/redux-starter-kit/issues/82 [4] https://github.com/reduxjs/redux/issues/3313#issuecomment-450601554 https://github.com/reduxjs/redux/issues/3313#issuecomment-45...
- fooddood 7y ago
  Isn't the common sentiment now that Redux is no longer considered a must-have for all greenfield projects? Also aren't communication apps a perfect use case for Redux due to the need to have events from multiple sources happen in a single store in a linear order?
  - acemarke 7y ago
    That's part of what I was getting at, and what I talk about in the first couple links. Lots of folks have used Redux because they were _told_ they "need" to use it. That's always been overkill. And, yes, there are plenty of other viable alternatives that overlap Redux's capabilities in various ways (Apollo, MobX, React context, etc). So sure, it's not a "must-have", because you should _always_ evaluate tools and determine what's really appropriate for your use case rather than just blindly using something. But, at the same time, Redux is still very widely used (~50% of React apps), and not going away. So, there's a big difference between "not an automatic must-have" (which is true) and "dead/dying" (which is not).
ebg13 7y ago
In their side-by-side memory usage comparison, what the hell is happening on the left at 6 teams that isn't happening at 5 teams and happening at 3 teams that isn't happening at 2 teams? What the is happening on the right at 6 teams that isn't happening at 5 teams?
- mh- 7y ago
  They're buckets, it's 6 or more teams ("6+") not 6. The only one that doesn't make sense to me is _2 teams_. Unless they had some specific hack to reuse processes for a 2nd team, how can the incremental memory usage of that 2nd team be almost nothing? Thinking about it, though- separate teams were lazily loaded and the usage behaviors of people with different numbers of teams probably varies substantially enough to cause these artifacts. e.g. I imagine this is "3-5 teams logged in" not "3-5 teams actively loaded". (disclaimer: I don't work for Slack, just speculating.)
  - ebg13 7y ago
    You're probably right, but, if "6+" means "100 teams", then "6+" is the wrong label.
- zhobbs 7y ago
  Also curious about the 3 vs 2 on the left. For 6, it says 6+, so maybe that is a mean that could include outliers with tons of active workspaces.
nik736 7y ago
So for people who only use one team nothing has changed?
- _bxg1 7y ago
  They also reworked their whole codebase to use React instead of jQuery, among other things. Please read the article before commenting.
  - nik736 7y ago
    I read the article, but for me as a user it doesn't matter at all if the client is written in jQuery, plain javascript, React or some new shiny framework. Memory usage seems to be the same, as long as I don't feel any performance difference nothing has changed.
    - _bxg1 7y ago
      They also talked about a different loading strategy which will gradually request content as needed instead of doing it all up-front, dramatically decreasing time-to-first-interaction. And code quality has a huge impact on user experience in the long run. Writing it off as a non-factor is laughably ignorant.
- phlyingpenguin 7y ago
  The hack I used to use to inject CSS into the app for a dark theme is no longer viable. So that changed.
  - jumbopapa 7y ago
    I got the dark theme to work. Would you be interested in a write up?
    - passivepinetree 7y ago
      I would! I imagine others would be as well.
mcguire 7y ago
"Conventional wisdom holds that you should never rewrite your code from scratch, and that’s good advice." Speaking as someone who has done a fair number of rewrites as well as watching rewrites fail, conventional wisdom is somewhat wrong. 1. Do a rewrite. Don't try to add features, just replace the existing functionality. Avoid a moving target. 2. Rewrite the same project. Don't redesign the database schema at the same time you are rewriting. Try to keep the friction down to a manageable level. 3. Incremental rewrites are best. Pick part of the project, rewrite and release that, then get feedback while you work on rewriting the next chunk.
- tptacek 7y ago
  #3 is in fact what they did, and what this post is mostly about, though their releases were apparently internal.
- leeoniya 7y ago
  > Don't redesign the database schema at the same time you are rewriting. 100%. rewriting all layers simultaneously is the first step to never finishing.
- taeric 7y ago
  I internalize this as every rewrite is a race to feature parity. Keep your races small and be prepared to call them off and devote energy elsewhere.
- razemio 7y ago
  Thank you! I read the first sentence and had to speak "bullshit" out loud. Sometimes rewriting something feels so good. Especially after some time has past and you are still in the process of learning. You apply all the things you have learned and your are amazed how much better it has become.
  - tptacek 7y ago
    Rewriting things always "feels so good", which is why people offer up the advice not to do it.
deleted 7y ago
[deleted]
bredren 7y ago
This must have been a forgone conclusion--but was there never consideration of writing this natively for MacOS / iPadOS?
djsumdog 7y ago
So big re-engineering rewrite .. and they're still going with electron? I mean, I guess it's good they're getting memory usage down for multiple teams, but other than that, it still seems like a bad start. I realize native apps on the three big platforms is difficult, but they're not using any native components what-so-ever. It's their web interface in a window. They could have used existing toolkits like QT, Gtk or something else, themed them to look like the Slack we're familiar with, and ditched the electron bloat. I've tried to write a couple of prototypes in electron and have worked on some electron projects and I just don't see why people are flocking to it. Every tutorial is based around huge amounts of boilerplate or scaffolding, and unit testing always seems to require weird freaky hacks with modules. I mean I guess if it works for them, good on them, but I'm still not going to take this as a sign to recommend or try new projects in Electron.
- fjabre 7y ago
  I think Slack’s web interface is ideal. I fail to see the need for a slack desktop client.
0xDEEPFAC 7y ago
Yikes! The legacy version used up to 2 gb of memory? I guess its good they got it down to only 1 gb... For reference AIM 4.2 system requirements was 6mb of RAM and 6mb of disk space.
electronstudio 7y ago
Is it still an Electron app? The only reason for using Electron is surely because you don't have the manpower to develop a proper native app. But then how have you got the manpower for a rewrite?!
- BinaryIdiot 7y ago
  Yes. The biggest change here is moving away from direct DOM API usage to React and not having multiple instances of a browser window inside of electron. Considering this took _two years_ it's kinda incredible they couldn't rewrite it natively in that amount of time or less. I'm guessing the only reason this took two years is due to the incremental approach they initially took.
- catacombs 7y ago
  The post shows a wireframe that says it is still an Electron app, which blows my mind because the last language anyone should use to build a native app is JavaScript.
akstrfn 7y ago
Switching to ripcord on my laptop was a breath of fresh air. I always wonder why don't these companies develop proper desktop clients that dont wreck mid range laptops...
- SkyMarshal 7y ago
  For anyone else who didn't know about Ripcord: https://cancel.fm/ripcord/ https://cancel.fm/ripcord/ Their first marketing bullet: "It's not made from a web browser" :D
- bmurphy1976 7y ago
  I never heard of ripcord. I just downloaded it and gave it a try. It suffers the same problems as every single native (non-electron) chat client I've ever used. Primarily it's hideous and you can't change the UI size uniformly. As an older dev who's eye sight isn't as good as it was 30 years ago when I started, it's getting harder and harder to use native apps because the default fonts are so goddamn small. Oh sure, you can dork around in the font preferences dialog and change some things, but there is no option to scale all of the UI (UI => Scale => 120%). It ends up being a hodgepodge of unreadable small text mixed with reasonably sized by but poorly styled and colored larger text that's nearly as hard to read because of the lack of space separating elements. Of course everything gets more crowded when you increase the size, instead of doing what it should do and also increasing the space between elements to let everything breath. In an Electron app, I can Ctrl-+, Ctrl-+ and everything looks great. I have yet to find a single native app that I use regularly where this isn't an issue. The only ones that comes close (no surprise here) is Sublime Text. These problems just don't happen with Electron apps. Electron technology may be slower than native, but it sure nails UI scaling. I'll take a UI I can actually see over one that runs more efficiently any day.
  - tumult 7y ago
    You can set `QT_SCALE_FACTOR=2` (or whatever) as an environment variable and the entire UI will scale. But by default, it should be trying to use your desktop scaling and DPI settings -- you might want to try changing those, first.
zerr 7y ago
Just hire proper native desktop developers (e.g. C++) and do another rewrite.
- saagarjha 7y ago
  Slack’s library that they share between their mobile apps is written in C++.
  - zerr 7y ago
    That's great (and an obvious choice), but I mean the proper native desktop GUI app.
rob74 7y ago
Hmmm... trying to optimize their Electron app is nice, but how about a real desktop app instead of a heavyweight browser engine masquerading as one? Would be really nice, especially for an app you have to have running in the background the whole time. But the chances for that are slim, I'm afraid...
gnicholas 7y ago
I went to get the update on my Mac, and it shows a new version from July 8. The release notes say: "Slack is a little faster, thanks to a few small but important changes". Huh? This seems to be the right update (4.0.0), but on Slack's website the release notes [1] show the release date to be July 15. Is this the same version as I'd get via the Mac update? If so, what's with the press push today (Verge and others), if this has been out for weeks? Also, why is it described as "a little faster" and "a wee bit faster overall" (in the web release notes)? Is it a wee bit faster, or much faster? 1: https://slack.com/intl/en-gb/release-notes/mac?geocode=en-gb https://slack.com/intl/en-gb/release-notes/mac?geocode=en-gb
- entropicdrifter 7y ago
  The changes that made it faster and use fewer resources have been incremental for the last year. This is just the last of the modernization updates that has completely removed the last of the original architecture's source code
  - gnicholas 7y ago
    Thanks for the additional background. So will this release improve performance much for those who have the prior update?
- eridius 7y ago
  Slack's app is two components. The first is the desktop app itself. The second is the web part, which can be updated separately from the desktop app. The release notes for the app are talking specifically about the desktop app component. The fact that the web part can be updated separately is why you can hit ⌘R and have new features appear in your workspace. In my case, I quit and relaunched the (same version of the) desktop app and suddenly my sidebar looked different and I had a popup telling me that Slack was now faster.
Nyashka 7y ago
Dark mode? No? Fck you.
deleted 7y ago
[deleted]
stephen82 7y ago
I guess they need to invest some time to experiment with QuickJS[1] so they can produce a binary executable and check how well it performs and how much memory it consumes on any system. I'm really curious about it! [1] https://bellard.org/quickjs/ https://bellard.org/quickjs/ P.S.: Yes, Fabrice Bellard did his thing again!
vzaliva 7y ago
I hope they will do a decent Linux port. For example, maximum font zoom was limited by 150%. It does not allow to zoom more than that. On 13" screen with 3840x2160 pixels it is not enough. Fonts are too small to read comfortably.
vasilakisfil 7y ago
With all this amount of profit and market share they should be more eco friendly and write a native client instead.
briandear 7y ago
Could someone please explain to me why a publicly traded company can’t write an actual, native Mac (or Windows/Linux) client instead of force feeding the lowest common denominator approach of React “native?” Imagine the performance and UI improvements of Slack could write a Swift app using standard Mac/iOS conventions. React “native” can be a treat approach for resource constrained organizations, but there is little excuse for a big tech company to shortcut using pseudo-native cross-platform approaches. For what Slack is, it’s still terrible when it comes to efficiency and stability. It’s lazy.
riston 7y ago
There's a lot of discussions that Slack should go for a full native application. Yes memory/CPU usage would be much smaller but then again this cross-platform maintenance hell begins. You can look at Skype's example it didn't end well, Linux version was lagging totally behind, also Mac client wasn't up to date and now Skype also released web client :D.
Sodman 7y ago
I've noticed that the browser version of slack has been crashing increasingly frequently in recent weeks, I wonder if this is because of their "Run the entire old + new systems in parallel" approach? Got the "modern-only" update today and it seems much more stable!
viraptor 7y ago
It's not clear to me from the post - did they do the same changes on the website version? Should I expect the same improvement there, or are those completely separate implementations.
brailsafe 7y ago
Gitlab is approaching rewrites in sensible way. Slowly replacing discrete components of jQuery / rails views with Vue components, but only if necessary
kup0 7y ago
I was so hoping that they had dropped Electron.. but nope. At least they’re focusing on performance, but the achilles heel will always be there. That said, as much as I dislike Electron, Microsoft has done a fine job with VSCode, so there are ways to do Electron “better”, even if the “best” Electron apps are still mediocre compared to native apps
- gilgoomesh 7y ago
  They're proud that they can operate in just 500MB of RAM for an app that shows scrolling lists of text. The economics of RAM has changed somewhat but 1990s me is still appalled.
  - untog 7y ago
    It isn't scrolling lists of text, though. It's user profiles, rich text, colored code snippets, images, uploaders for both, reactions, contextual menus, channel lists... I'm not saying they can't do better, but the app does do quite a lot.
    - redwall_hp 7y ago
      The Textual IRC client for Mac does this with like 40-60MB of RAM, and that's still using a WebKit view for the chat pane. The rest of the UI is pure Cocoa and way nicer.
    - SquareWheel 7y ago
      Interactive embeds, notifications, inline messages, voice and video calling, an extensive app API...
  - loudandskittish 7y ago
    Seriously. I'm not sure how we got to a place where 500MBs of RAM for apps that don't even have a quarter of the functionality of apps that needed 500KBs of RAM became normal and acceptable.
- ComputerGuru 7y ago
jupp0r 7y ago
> Time spent rewriting something that already works is time that won’t be spent making our customers working lives simpler, more pleasant, and more productive. With that being said, can we please have dark mode now?
royge 7y ago
I am expecting that they'll rewrite it into a proper native desktop client. :( Anyway, I'll just use the browser version.
deleted 7y ago
[deleted]
jpalomaki 7y ago
Creating native Slack client with the same features as current is not trivial. Just think all the apps, their embedded UI, voice/video calls. Likely the only reasoble way to have all this and keep it compatible with the browser version is to either build on browser or embed a browser in the native app. You can argue that all those things are not needed in a group chat, but Slack clearly feels otherwise. They are building a platform, some sort of groupware - not just chat. Check for example the Doodle bot demo: https://slack.com/apps/AFA5VQJKX-doodle-bot https://slack.com/apps/AFA5VQJKX-doodle-bot
- matchbok 7y ago
  Well, that's the problem. It does too much, poorly.
JustSomeNobody 7y ago
It isn't just about memory, though that's a big issue with Electron apps. It's still running probably a couple orders of magnitude more instructions per operation than an equivalent native application.
wanone 7y ago
The sheer amount of salt in the medium comments because of Electron is astounding. Never had any memory hog issues with Slack. Have been using it extensively for over 2 years now. Works fine on my 2010 laptop as well!
buboard 7y ago
So this is another javascript "native app". Why not just keep the website?
adiM 7y ago
After this update, slack stopped working on Opera. Anyone else has the same problem?

289 points by kgraves 7y ago

I already noticed that after the workspace selector looked different Slack was no longer being regularly killed by the OOM killer. Finally.

kndjckt 7y ago

Give me Grammarly and Dark Mode and then I'll stop using the browser version

dewey 7y ago
I'd rather not send my keystrokes to two companies at the same time. Not sure they changed that but this is always at the back of my mind when I see someone use Grammarly via the browser extension: https://techbeacon.com/security/grammarly-leaks-everything-youve-ever-typed-service-everything https://techbeacon.com/security/grammarly-leaks-everything-y...
- kndjckt 7y ago
  Excellent point :/ Is there a security-conscious Grammarly alternative?
  - jamesponddotco 7y ago
    I use their macOS application instead, and make sure not to type anything sensitive. Not as easy as using their browser extension, but it is safer. Been trying Language Tool as well: https://languagetool.org/ https://languagetool.org/ Not nearly as good as Grammarly, though, but it works with more languages and even has a plugin for vim.

pixelbath 7y ago

Good news for the Slack team, as this means they'll no longer be the poster child for "look how bloated Electron apps are! Slack takes up x gigabytes of RAM!" Great work, Slack team.

mac01021 7y ago
I can still say "Look how bloated Electron apps are! Slack takes up half a gig of RAM!".

steeve 7y ago

I was so happy they had finally gone native. The disappointment is strong. On a side note, SBlack, a lightweight slack client is very impressive on memory usage [1]. 1. https://www.sblack.online/ https://www.sblack.online/

btmiller 7y ago
How does this work? I thought Slack deprecated their IRC gateway; is this all API-based then?
- swalladge 7y ago
  > Sblack works exactly like a browser with small tweaks. Looks like it just wraps the website in this case. Yes there are clients that use the API. Slack offers a http rest-like api as well as a websockets realtime api. For example, wee-slack[1] (weechat plugin for slack) and slack-term[2] (curses client in golang). [1]: https://github.com/wee-slack/wee-slack https://github.com/wee-slack/wee-slack [2]: https://github.com/erroneousboat/slack-term https://github.com/erroneousboat/slack-term
- wlesieutre 7y ago
  They advertise 20 MB instead of 180 MB and not being Electron, so I would bet it's Slack's web client wrapped in macOS's built-in WKWebView, plus some custom CSS to support dark mode. >Sblack works exactly like a browser with small tweaks. We inject the dark mode style at the end of the Slack’s html, and that’s it. Another benefit of this is that Safari/WebKit does better with battery life than Chrome. I'll have to give this client a look.

pwinnski 7y ago

"We acknowledge that nobody should ever rewrite from scratch... but after five years we're rewriting from scratch because we know better."

bdcravens 7y ago
It’s an iterative rewrite, which is how you should do it. “Rewrites are bad” refers to a blank slate and reimplementing.
- pwinnski 7y ago
  I didn't choose the framing, they did. Here are the first sentences of the first two paragraphs: > Conventional wisdom holds that you should never rewrite your code from scratch, and that’s good advice. > Still, software codebases have life spans.
  - bdcravens 7y ago
    Yes, those sentences set up the rest of the article, establishing the thesis: Those two sentences are true, and not necessarily at odds with one another. The author spends the rest of the article explaining this, and how they accomplished it.

zeusly 7y ago

I wonder if they increased their efforts after seeing VS Code (also a complex Electron app) run fast and memory-efficient. Before VS Code everyone just accepted Electron's memory bloat, maybe slack even had plans to go fully native b/c no one thought it could be done properly.

doc_gunthrop 7y ago
> memory-efficient. Not how I'd describe a text editor that consumes 700MB+ of RAM at any given time.
- spookthesunset 7y ago
  Yes, because vs code is just a mere text editor.
- wgoodall01 7y ago
  Replace "text editor" with "IDE," and that 700mb figure doesn't seem so extravagant.
  - flukus 7y ago
    It does to those of use that remember upgrading to (I think) 128MB of RAM to run Visual C++ 6, it's not like a heap of new features have been added since.

mtarnovan 7y ago

How about a native client? I think it's safe to assume that Slack has the resources for this.

_bxg1 7y ago
No matter the available resources, maintaining three separate desktop apps as well as a web app would mean fewer features and more bugs across the board. And Linux would probably be left on Electron (with less support attention), if not abandoned altogether.
- sagichmal 7y ago
  Past a certain point, the downsides of Electron outweigh the downsides of native apps. We've crossed that Rubicon years ago.
  - bengale 7y ago
    If this was the case we wouldn't see so many Electron apps. You just don't perceive enough of the upsides to see why the decisions are being made.
    - wlesieutre 7y ago
      The upsides are for the companies shipping it, the downsides are for the users. So it's not a surprising outcome.
      - _bxg1 7y ago
        Tell that to people who want to use modern services on a Linux workstation
        wlesieutre 7y ago
        That's nice for them, but no matter what OS you're on the desktop client is probably crappier than loading up the webpage, with the one upside of giving you a separate icon in the dock and app switcher. Even with the performance improved, the "stuff the whole app in one web view" implementation is still showing. Clearly this isn't an Electron limitation; VS Code handles multiple windows just as well as any other text editor. Slack's desktop client is basically "It's a web browser except worse and with the URL bar hidden." Since chat requires an internet connection and it's not like Slack's desktop version launches particularly fast, I'm not sure that it does anything better than using a browser. We'll see if they support multiple instances on iOS 13. If they do, maybe we can get a Mac version based on that for something closer to native desktop behavior.

nottorp 7y ago

They say React. How is this a desktop app? It's still in a browser.

pwinnski 7y ago
Electron makes it a desktop app. That part has not changed.
- nottorp 7y ago
  Just because you don't see the browser it doesn't mean it's not still there. No, js/html "applications" are not desktop apps, they're web pages. Doesn't matter how you hide it.
  - theredbox 7y ago
    Is Sublime Text a native app or a web page?
    - bdcravens 7y ago
      Native. VS Code is a web page by this definition however.
    - guessmyname 7y ago
      Sublime Text is 100% a native desktop application written in C++ with the Skia graphics library [1][2]. However, only a tiny fraction of Skia’s functionality is actually used, just for rasterizing lines and blitting images. Font rendering is done by using the underlying platform APIs to do the glyph rasterisation. The editor also exposes an ABI/API that plugins can use via Python scripts. C++ provides the cross-platform functionality, Skia provides the cross-platform UI, custom code was written to target specific parts of the UI in macOS (using Cocoa) and Linux (using GTK). A tiny web driver is used to render a super-minimal set of HTML tags for tooltips. [1] https://news.ycombinator.com/item?id=11689481 https://news.ycombinator.com/item?id=11689481 [1] https://skia.org/ https://skia.org/
  - 7y ago

deleted 7y ago

[deleted]

_bxg1 7y ago

The most interesting details: - The first iteration was largely powered by jQuery(!) - Every workspace got its own isolated Electron process because they didn't anticipate multiple workspaces in their initial architecture Honestly it's amazing they got as far as they did with the above limitations. Sounds like this rewrite was sorely needed after their phase of rapid growth. Glad they pulled it off.

mosdl 7y ago
They switched to React, which will increase their memory usage and be slower than pure js.
- untog 7y ago
  > be slower than pure js There's no way of knowing, without knowing what they were doing previously. The whole point of React is to leverage the virtual DOM to avoid unnecessary (and very slow) DOM manipulations. Given the sheer number of things Slack has on any given page it isn't unreasonable to expect that React will make things quicker, even if it has a penalty at startup time.

dstaley 7y ago

The post doesn't say, so does anyone know if the new React version is also available on the web?

_bxg1 7y ago
There would be no reason for it not to be; it's possible it hasn't rolled out yet, though.
methyl 7y ago
I see the new interface (mainly chat input) and notification that Slack just became snappier on the web.

me551ah 7y ago

For me the gold standard of Chat applications is always going to be mIRC. It supports a ton of plugins, consumes 10-50mb of memory and little to no CPU. You could be connected to multiple servers and channels with DCC scripts running and you still wouldn't notice that it's even running. Even though Slack is using react now, they are still using electron under the hood. Which means it can never match the snappiness of a native application like mIRC.

ausjke 7y ago
mirc is windows only? there are many web-based irc these days and they worked well
- ausjke 7y ago
  interesting, so I checked out mirc and reported it's windows-only(hope to save someone sometime), and since I used irc over browser so I added some info for that. Still, obviously someone disliked this sort of comments and downvoted, I'm always surprised by downvotes like this sort, any bystander can shed some lights? Am I supposed to always write a cheerful comment for basic neutral truths?
  - dingo_bat 7y ago
    I guess down votes are because most software is windows only. Also the general topic of the thread was native clients, so expecting a web client was not very appropriate.
- AdamJacobMuller 7y ago
  Can you find me a web-based IRC client which runs in <100MB of memory?
tonyarkles 7y ago
Not mIRC, but I run x-chat and Slack side-by-side on a daily basis. Wholly different experience... I don’t think I’ve ever had to kill x-chat for pegging a CPU and killing my battery :)

oflannabhra 7y ago

This is great, but that ship long sailed for me. I still use Slack extensively, but for the past year+ exclusively in Safari tabs. Memory usage and Energy usage (I'm on a MacBook Pro) have both quartered (or more).

voicedYoda 7y ago
For over a year i was running 5+ Slacks in the Electron app, and continuously noticed how much memory was being hogged up. After some basic research, I realized that Electron is basically a wrapper of a Chrome instance. Suddenly i understood where my ram was disappearing to because so many "native" apps running in Electron were literally just spawning new chrome instances and gobbling up ram. I now do my best to keep my website apps running just in Firefox containers. Electron feels like the last rush of "write once, deploy everywhere" days of flash and Adobe air. God save us all.

Klonoar 7y ago

I will consider this benchmark vindication both for myself and the times I've had to argue as to why Electron isn't the issue, as well as the commentator from many moons ago who worked at Slack, dropped in here and explained why Electron wasn't the problem (rather, poor engineering on Slack's part was), and then was ripped to shreds over it. In fact I'm sure this comment will bring out native fanatics in force. At any rate, good for them. Seems like they reengineered themselves to a happy medium. I can definitely see myself installing it again at some point.

matchbok 7y ago
And yet, the performance is still bad. And that is only 1 of many reasons why electron is bad.
- _verandaguy 7y ago
  A hundred times this; 500-1000mb of idle memory usage by a chat client is patently silly.
  - therealdrag0 7y ago
    Sure, but on my MBP it's never been a problem. I've never had slack lag regularly or notice it impacting other programs. :shrug:
DaiPlusPlus 7y ago
I’m still skeptical. The memory usage chart from the article shows only a slight (10%?) improvement for single-workspace Slack clients, now at around 250MB. Yes, getting a 5+ workspace client down from ~800+MB to 300MB should be applauded - but the 250MB floor is still too high. I want to know what’s in the 250MB it’s still using.
- penagwin 7y ago
  In my experience at least ~100/150MB will be electron's minimum anyway, certainly impressive what they've done but I think they've basically hit bedrock unless they either improve electron itself or switch to something different.

ausjke 7y ago

so this new Desktop app will run inside a browser? or it still uses Electron underneath? It's unclear to me after reading the post. It's certainly not a native app though.

_bxg1 7y ago
You're correct about what "native" means; the article never uses the word "native", though. This is still an Electron app, just a vastly improved one.
- ausjke 7y ago
  thanks. realized the native is from a comment and just updated, so this is an improved electron slack desktop app then.

charlieegan3 7y ago

I got this update in the browser, does anyone know what happened to the subdomains? (e.g mycompany.slack.com)

k__ 7y ago

I hoped the go for Revery. Would be cool to see a native Reason app from such a big player :)

deleted 7y ago

[deleted]

bfrog 7y ago

Well there goes my last hope of ever getting a native slack client in my lifetime. I miss hipchat often. They had enough sense to make the client native.

s_y_n_t_a_x 7y ago
Not really, they could use React Native, even for desktop.
- pjmlp 7y ago
  Actually that would be much better. There is hope though, React Native for Windows team did a presentation showing how bad Electron resource usage was versus their React Native for Windows prototype. So maybe they could do some advocacy to the VSCode team and start a migration movement.
  - s_y_n_t_a_x 7y ago
    This rewrite is the first step of that, going from jQuery to React. React Native for Windows is ready for production, it powers their new Skype. It's being rewritten right now from C# to C++ for better performance in their vnext branch. You have the option to use react-native-web (Twitter's way) to run your React Native app on the web, or use ReactXP (Microsoft's way). React Native Web forks React Native. ReactXP wraps React and React Native. Two different approaches. Personally I prefer ReactXP because React Native Web will always be too far behind React Native. It's easier for ReactXP to update. Both projects have major backers and power major products.
charrondev 7y ago
Are you sure HipChat was a native client? At least on MacOS I’m pretty sure it was some web view. If not Electron, one of the others. I was very happy when we switched from HipChat to slack.
- guessmyname 7y ago
  HipChat was originally built using Adobe Air (2012) [1]. Then they switched to QT using WebView (2013) [2]. Then they created Stride using Electron (2017) [3] Finally they created a partnership with Slack (2018) [4]. [1] https://www.engadget.com/2013/02/14/hipchat-ditches-adobe-air-for-a-native-mac-client/ https://www.engadget.com/2013/02/14/hipchat-ditches-adobe-ai... [2] https://techcrunch.com/2013/02/14/with-3500-paying-customers-hipchat-launches-a-native-mac-client-to-vanquish-the-lousy-adobe-air-app/ https://techcrunch.com/2013/02/14/with-3500-paying-customers... [3] https://techcrunch.com/2017/09/07/atlassian-launches-stride-its-slack-competitor/ https://techcrunch.com/2017/09/07/atlassian-launches-stride-... [4] https://www.atlassian.com/partnerships/slack https://www.atlassian.com/partnerships/slack

deleted 7y ago

[deleted]

Despegar 7y ago

Slack is eventually going to write native apps once they realize that productivity software shouldn't be developed like an ad product from Google. It will take Teams winning because it gets included in the Office 365 subscription for several quarters before they come to the realization that they need to compete on user experience.

heavenlyblue 7y ago
Google’s Ad product always had a desktop client called Adwords Editor.
basch 7y ago
an electron app (teams) beating them will lead them to the conclusion that they shouldnt use electron? I mean, I agree, losing mass marketshare SHOULD lead to a major shakeup on trajectory, and competing on desktop user experience would be a logical next step. But... back to the first sentence of this comment.
- Despegar 7y ago
  Teams is winning because it's being bundled with Office 365. The business model and distribution lets them compete effectively with an inferior product. Slack doesn't have that luxury.
  - Guillaume86 7y ago
    Teams is so inferior I'm not sure they compete for the same market, when team chat become really important Teams is just not an acceptable option in my experience (we had to switch away from Teams last year because there was too many bugs/frustrating issues and basic features missing, like a actually usable search feature).
    - basch 7y ago
      its about momentum though too. your point in time experience is quite different than the trajectory/velocity of the product, and its rate of change.

acemarke 7y ago

I know that popular opinion in the Twitterverse is that "Redux is dead", but I note that both Twitter and Slack just released major rewrites that use Redux heavily. I talked about Redux usage stats and comparison with other alternatives in my "State of Redux" talk at Reactathon earlier this year [0], and my post "Redux - Not Dead Yet!" also addresses some of these aspects [1]. Also, quick plug for our current focus. I'm working on some tutorials for our new Redux Starter Kit package [2], and then will be working on tackling additional functionality to push it towards a 1.0 release [3]. After that, we'll get started on a major revamp of the Redux docs [4] to improve the learning flow, better organize the content, cover more real-world usage topics, and teach using Redux Starter Kit as the "default way to write Redux". [0] https://blog.isquaredsoftware.com/2019/03/presentation-state-of-redux/ https://blog.isquaredsoftware.com/2019/03/presentation-state... [1] https://blog.isquaredsoftware.com/2018/03/redux-not-dead-yet/ https://blog.isquaredsoftware.com/2018/03/redux-not-dead-yet... [2] https://redux-starter-kit.js.org/ https://redux-starter-kit.js.org/ [3] https://github.com/reduxjs/redux-starter-kit/issues/82 https://github.com/reduxjs/redux-starter-kit/issues/82 [4] https://github.com/reduxjs/redux/issues/3313#issuecomment-450601554 https://github.com/reduxjs/redux/issues/3313#issuecomment-45...

fooddood 7y ago
Isn't the common sentiment now that Redux is no longer considered a must-have for all greenfield projects? Also aren't communication apps a perfect use case for Redux due to the need to have events from multiple sources happen in a single store in a linear order?
- acemarke 7y ago
  That's part of what I was getting at, and what I talk about in the first couple links. Lots of folks have used Redux because they were _told_ they "need" to use it. That's always been overkill. And, yes, there are plenty of other viable alternatives that overlap Redux's capabilities in various ways (Apollo, MobX, React context, etc). So sure, it's not a "must-have", because you should _always_ evaluate tools and determine what's really appropriate for your use case rather than just blindly using something. But, at the same time, Redux is still very widely used (~50% of React apps), and not going away. So, there's a big difference between "not an automatic must-have" (which is true) and "dead/dying" (which is not).

ebg13 7y ago

In their side-by-side memory usage comparison, what the hell is happening on the left at 6 teams that isn't happening at 5 teams and happening at 3 teams that isn't happening at 2 teams? What the is happening on the right at 6 teams that isn't happening at 5 teams?

mh- 7y ago
They're buckets, it's 6 or more teams ("6+") not 6. The only one that doesn't make sense to me is _2 teams_. Unless they had some specific hack to reuse processes for a 2nd team, how can the incremental memory usage of that 2nd team be almost nothing? Thinking about it, though- separate teams were lazily loaded and the usage behaviors of people with different numbers of teams probably varies substantially enough to cause these artifacts. e.g. I imagine this is "3-5 teams logged in" not "3-5 teams actively loaded". (disclaimer: I don't work for Slack, just speculating.)
- ebg13 7y ago
  You're probably right, but, if "6+" means "100 teams", then "6+" is the wrong label.
zhobbs 7y ago
Also curious about the 3 vs 2 on the left. For 6, it says 6+, so maybe that is a mean that could include outliers with tons of active workspaces.

nik736 7y ago

So for people who only use one team nothing has changed?

_bxg1 7y ago
They also reworked their whole codebase to use React instead of jQuery, among other things. Please read the article before commenting.
- nik736 7y ago
  I read the article, but for me as a user it doesn't matter at all if the client is written in jQuery, plain javascript, React or some new shiny framework. Memory usage seems to be the same, as long as I don't feel any performance difference nothing has changed.
  - _bxg1 7y ago
    They also talked about a different loading strategy which will gradually request content as needed instead of doing it all up-front, dramatically decreasing time-to-first-interaction. And code quality has a huge impact on user experience in the long run. Writing it off as a non-factor is laughably ignorant.
phlyingpenguin 7y ago
The hack I used to use to inject CSS into the app for a dark theme is no longer viable. So that changed.
- jumbopapa 7y ago
  I got the dark theme to work. Would you be interested in a write up?
  - passivepinetree 7y ago
    I would! I imagine others would be as well.

mcguire 7y ago

"Conventional wisdom holds that you should never rewrite your code from scratch, and that’s good advice." Speaking as someone who has done a fair number of rewrites as well as watching rewrites fail, conventional wisdom is somewhat wrong. 1. Do a rewrite. Don't try to add features, just replace the existing functionality. Avoid a moving target. 2. Rewrite the same project. Don't redesign the database schema at the same time you are rewriting. Try to keep the friction down to a manageable level. 3. Incremental rewrites are best. Pick part of the project, rewrite and release that, then get feedback while you work on rewriting the next chunk.

tptacek 7y ago
#3 is in fact what they did, and what this post is mostly about, though their releases were apparently internal.
leeoniya 7y ago
> Don't redesign the database schema at the same time you are rewriting. 100%. rewriting all layers simultaneously is the first step to never finishing.
taeric 7y ago
I internalize this as every rewrite is a race to feature parity. Keep your races small and be prepared to call them off and devote energy elsewhere.
razemio 7y ago
Thank you! I read the first sentence and had to speak "bullshit" out loud. Sometimes rewriting something feels so good. Especially after some time has past and you are still in the process of learning. You apply all the things you have learned and your are amazed how much better it has become.
- tptacek 7y ago
  Rewriting things always "feels so good", which is why people offer up the advice not to do it.

deleted 7y ago

[deleted]

bredren 7y ago

This must have been a forgone conclusion--but was there never consideration of writing this natively for MacOS / iPadOS?

djsumdog 7y ago

So big re-engineering rewrite .. and they're still going with electron? I mean, I guess it's good they're getting memory usage down for multiple teams, but other than that, it still seems like a bad start. I realize native apps on the three big platforms is difficult, but they're not using any native components what-so-ever. It's their web interface in a window. They could have used existing toolkits like QT, Gtk or something else, themed them to look like the Slack we're familiar with, and ditched the electron bloat. I've tried to write a couple of prototypes in electron and have worked on some electron projects and I just don't see why people are flocking to it. Every tutorial is based around huge amounts of boilerplate or scaffolding, and unit testing always seems to require weird freaky hacks with modules. I mean I guess if it works for them, good on them, but I'm still not going to take this as a sign to recommend or try new projects in Electron.

fjabre 7y ago
I think Slack’s web interface is ideal. I fail to see the need for a slack desktop client.

0xDEEPFAC 7y ago

Yikes! The legacy version used up to 2 gb of memory? I guess its good they got it down to only 1 gb... For reference AIM 4.2 system requirements was 6mb of RAM and 6mb of disk space.

electronstudio 7y ago

Is it still an Electron app? The only reason for using Electron is surely because you don't have the manpower to develop a proper native app. But then how have you got the manpower for a rewrite?!

BinaryIdiot 7y ago
Yes. The biggest change here is moving away from direct DOM API usage to React and not having multiple instances of a browser window inside of electron. Considering this took _two years_ it's kinda incredible they couldn't rewrite it natively in that amount of time or less. I'm guessing the only reason this took two years is due to the incremental approach they initially took.
catacombs 7y ago
The post shows a wireframe that says it is still an Electron app, which blows my mind because the last language anyone should use to build a native app is JavaScript.

akstrfn 7y ago

Switching to ripcord on my laptop was a breath of fresh air. I always wonder why don't these companies develop proper desktop clients that dont wreck mid range laptops...

SkyMarshal 7y ago
For anyone else who didn't know about Ripcord: https://cancel.fm/ripcord/ https://cancel.fm/ripcord/ Their first marketing bullet: "It's not made from a web browser" :D
bmurphy1976 7y ago
I never heard of ripcord. I just downloaded it and gave it a try. It suffers the same problems as every single native (non-electron) chat client I've ever used. Primarily it's hideous and you can't change the UI size uniformly. As an older dev who's eye sight isn't as good as it was 30 years ago when I started, it's getting harder and harder to use native apps because the default fonts are so goddamn small. Oh sure, you can dork around in the font preferences dialog and change some things, but there is no option to scale all of the UI (UI => Scale => 120%). It ends up being a hodgepodge of unreadable small text mixed with reasonably sized by but poorly styled and colored larger text that's nearly as hard to read because of the lack of space separating elements. Of course everything gets more crowded when you increase the size, instead of doing what it should do and also increasing the space between elements to let everything breath. In an Electron app, I can Ctrl-+, Ctrl-+ and everything looks great. I have yet to find a single native app that I use regularly where this isn't an issue. The only ones that comes close (no surprise here) is Sublime Text. These problems just don't happen with Electron apps. Electron technology may be slower than native, but it sure nails UI scaling. I'll take a UI I can actually see over one that runs more efficiently any day.
- tumult 7y ago
  You can set `QT_SCALE_FACTOR=2` (or whatever) as an environment variable and the entire UI will scale. But by default, it should be trying to use your desktop scaling and DPI settings -- you might want to try changing those, first.

zerr 7y ago

Just hire proper native desktop developers (e.g. C++) and do another rewrite.

saagarjha 7y ago
Slack’s library that they share between their mobile apps is written in C++.
- zerr 7y ago
  That's great (and an obvious choice), but I mean the proper native desktop GUI app.

rob74 7y ago

Hmmm... trying to optimize their Electron app is nice, but how about a real desktop app instead of a heavyweight browser engine masquerading as one? Would be really nice, especially for an app you have to have running in the background the whole time. But the chances for that are slim, I'm afraid...

gnicholas 7y ago

I went to get the update on my Mac, and it shows a new version from July 8. The release notes say: "Slack is a little faster, thanks to a few small but important changes". Huh? This seems to be the right update (4.0.0), but on Slack's website the release notes [1] show the release date to be July 15. Is this the same version as I'd get via the Mac update? If so, what's with the press push today (Verge and others), if this has been out for weeks? Also, why is it described as "a little faster" and "a wee bit faster overall" (in the web release notes)? Is it a wee bit faster, or much faster? 1: https://slack.com/intl/en-gb/release-notes/mac?geocode=en-gb https://slack.com/intl/en-gb/release-notes/mac?geocode=en-gb

entropicdrifter 7y ago
The changes that made it faster and use fewer resources have been incremental for the last year. This is just the last of the modernization updates that has completely removed the last of the original architecture's source code
- gnicholas 7y ago
  Thanks for the additional background. So will this release improve performance much for those who have the prior update?
eridius 7y ago
Slack's app is two components. The first is the desktop app itself. The second is the web part, which can be updated separately from the desktop app. The release notes for the app are talking specifically about the desktop app component. The fact that the web part can be updated separately is why you can hit ⌘R and have new features appear in your workspace. In my case, I quit and relaunched the (same version of the) desktop app and suddenly my sidebar looked different and I had a popup telling me that Slack was now faster.

Nyashka 7y ago

Dark mode? No? Fck you.

deleted 7y ago

[deleted]

stephen82 7y ago

I guess they need to invest some time to experiment with QuickJS[1] so they can produce a binary executable and check how well it performs and how much memory it consumes on any system. I'm really curious about it! [1] https://bellard.org/quickjs/ https://bellard.org/quickjs/ P.S.: Yes, Fabrice Bellard did his thing again!

vzaliva 7y ago

I hope they will do a decent Linux port. For example, maximum font zoom was limited by 150%. It does not allow to zoom more than that. On 13" screen with 3840x2160 pixels it is not enough. Fonts are too small to read comfortably.

vasilakisfil 7y ago

With all this amount of profit and market share they should be more eco friendly and write a native client instead.

briandear 7y ago

Could someone please explain to me why a publicly traded company can’t write an actual, native Mac (or Windows/Linux) client instead of force feeding the lowest common denominator approach of React “native?” Imagine the performance and UI improvements of Slack could write a Swift app using standard Mac/iOS conventions. React “native” can be a treat approach for resource constrained organizations, but there is little excuse for a big tech company to shortcut using pseudo-native cross-platform approaches. For what Slack is, it’s still terrible when it comes to efficiency and stability. It’s lazy.

riston 7y ago

There's a lot of discussions that Slack should go for a full native application. Yes memory/CPU usage would be much smaller but then again this cross-platform maintenance hell begins. You can look at Skype's example it didn't end well, Linux version was lagging totally behind, also Mac client wasn't up to date and now Skype also released web client :D.

Sodman 7y ago

I've noticed that the browser version of slack has been crashing increasingly frequently in recent weeks, I wonder if this is because of their "Run the entire old + new systems in parallel" approach? Got the "modern-only" update today and it seems much more stable!

viraptor 7y ago

It's not clear to me from the post - did they do the same changes on the website version? Should I expect the same improvement there, or are those completely separate implementations.

brailsafe 7y ago

Gitlab is approaching rewrites in sensible way. Slowly replacing discrete components of jQuery / rails views with Vue components, but only if necessary

kup0 7y ago

I was so hoping that they had dropped Electron.. but nope. At least they’re focusing on performance, but the achilles heel will always be there. That said, as much as I dislike Electron, Microsoft has done a fine job with VSCode, so there are ways to do Electron “better”, even if the “best” Electron apps are still mediocre compared to native apps

gilgoomesh 7y ago
They're proud that they can operate in just 500MB of RAM for an app that shows scrolling lists of text. The economics of RAM has changed somewhat but 1990s me is still appalled.
- untog 7y ago
  It isn't scrolling lists of text, though. It's user profiles, rich text, colored code snippets, images, uploaders for both, reactions, contextual menus, channel lists... I'm not saying they can't do better, but the app does do quite a lot.
  - redwall_hp 7y ago
    The Textual IRC client for Mac does this with like 40-60MB of RAM, and that's still using a WebKit view for the chat pane. The rest of the UI is pure Cocoa and way nicer.
  - SquareWheel 7y ago
    Interactive embeds, notifications, inline messages, voice and video calling, an extensive app API...
- loudandskittish 7y ago
  Seriously. I'm not sure how we got to a place where 500MBs of RAM for apps that don't even have a quarter of the functionality of apps that needed 500KBs of RAM became normal and acceptable.
ComputerGuru 7y ago

jupp0r 7y ago

> Time spent rewriting something that already works is time that won’t be spent making our customers working lives simpler, more pleasant, and more productive. With that being said, can we please have dark mode now?

royge 7y ago

I am expecting that they'll rewrite it into a proper native desktop client. :( Anyway, I'll just use the browser version.

deleted 7y ago

[deleted]

jpalomaki 7y ago

Creating native Slack client with the same features as current is not trivial. Just think all the apps, their embedded UI, voice/video calls. Likely the only reasoble way to have all this and keep it compatible with the browser version is to either build on browser or embed a browser in the native app. You can argue that all those things are not needed in a group chat, but Slack clearly feels otherwise. They are building a platform, some sort of groupware - not just chat. Check for example the Doodle bot demo: https://slack.com/apps/AFA5VQJKX-doodle-bot https://slack.com/apps/AFA5VQJKX-doodle-bot

matchbok 7y ago
Well, that's the problem. It does too much, poorly.

JustSomeNobody 7y ago

It isn't just about memory, though that's a big issue with Electron apps. It's still running probably a couple orders of magnitude more instructions per operation than an equivalent native application.

wanone 7y ago

The sheer amount of salt in the medium comments because of Electron is astounding. Never had any memory hog issues with Slack. Have been using it extensively for over 2 years now. Works fine on my 2010 laptop as well!

buboard 7y ago

So this is another javascript "native app". Why not just keep the website?

adiM 7y ago

After this update, slack stopped working on Opera. Anyone else has the same problem?