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.
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.
When a rewrite isn’t: rebuilding Slack on the desktop
251–260 of 408 posts
Re: When a rewrite isn’t: rebuilding Slack on the desktop
#252Earlier quoted context omitted.
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.
250MB floor is still too high Too high for what? Low end desktops and laptops today come with 8GB of ram. Using ~3% of that for a chat app doesn't seem like a big deal.
Re: When a rewrite isn’t: rebuilding Slack on the desktop
#253Earlier quoted context omitted.
What is the goto for web if Redux is dead? I am not super knowledgeable about all the exact architectures, but I thought mobile was just starting to adopt the redux architecture vs MVP, MVVM, etc
A lot of people are saying that the new-but-not-really-new React Context API and useReducer hooks are sufficient to cover redux. My team isn't convinced, we see immense value because we're big fans of using Redux Saga-- a model that isn't well covered using Context or hooks, although we do use those APIs as well when needed.
Something like Redux Saga, Redux Thunks, Redux Observable (my personal preference here), or what have you, are the higher order "toolsets" that Hooks alone aren't likely to replace yet. It may be the case that some of them are going to start targeting Hooks/Context more directly without "needing" an intermediary state engine like Redux, but it's also entirely possible that it will still remain a good reason to make a step change to a state engine like Redux when you find yourself needing higher-order coordination between components that libraries like Sagas, Thunks, or Observables can provide.
Re: When a rewrite isn’t: rebuilding Slack on the desktop
#254Earlier quoted context omitted.
I know, I'm a React Native developer. I'm just saying that "native client" doesn't necessarily mean separate Mac, Windows and Linux ports; furthermore, for a billion dollar company, a native client of _some_ kind isn't an unrealistic demand.
That's fair; although I'm pretty sure they wouldn't be able to have such a consistent and unique look-and-feel with React Native (you can correct me if I'm wrong). It's debatable whether that's a good tradeoff, but it's totally one that some people would make.
Re: When a rewrite isn’t: rebuilding Slack on the desktop
#255Earlier quoted context omitted.
Thanks for the articles! We've been using Redux since August of 2016 at Groove. For us, we've found that Redux makes sense when you have state that needs to be shared. If you are dealing with some specific, tightly coupled component state, it sometimes makes sense to keep that particular piece of state local to the component (at least for our use-case). The biggest issues we've run into during our time with Redux hav…
Yep. The Redux "Three Principles" docs page [0] emphasizes the "single source of truth" aspect. It's a good selling point, but has unfortunately led to a lot of folks interpreting that as "you _must_ keep _everything_ in Redux". (Doing so is a valid design decision, and I've certainly talked to folks who deliberately did that to make everything trackable and time-travel-able. But, most UI state probably doesn't need…
Rather than putting absolutely everything in the global DB, I now try to restrict that to things that are actually global, such as the user profile data and such.
Re: When a rewrite isn’t: rebuilding Slack on the desktop
#256Earlier quoted context omitted.
Thanks for the context! I was using from 2017 -> Feb 2019 when we migrated to slack. It definitely had a webview feel similar to slack. I never particularly noted any memory issues. I haven't noticed any with slack either though. For me my top memory consumers end up being: 1. Docker (web dev servers) 2. Chrome 3. Firefox 4. VSCode 5. 1Password 6. Spark 7. Sublime Text Even at the bottom of the list they are using 20…
I don't know which 1 password you are using but my 1password uses two accounts and sits at below 100mb. lower than slack/spark/vscode and many more apps.
Spark is a native app right? If it’s not they definitely nailed the look and feel of a native app.
Re: When a rewrite isn’t: rebuilding Slack on the desktop
#257Earlier quoted context omitted.
There's this classic article on the topic: https://www.joelonsoftware.com/2000/04/06/things-you-should-...
Joel's article is the famous classic, but he proved himself wrong when his company, Fog Creek, built Trello from the ground up, sharing no code with FogBugz. Trello became a huge success while FogBugz languished. https://medium.com/@herbcaudill/lessons-from-6-software-rewr... (I think this article should be the new classic.) > My takeaway from these stories is this: Once you’ve learned enough that there’s a certain d…
Re: When a rewrite isn’t: rebuilding Slack on the desktop
#258Earlier quoted context omitted.
You could do a rewrite that takes into account the bad old database schema, but doesn't repeat the wrong code design choices based on it. Then, when that's ready and stable and working with the existing schema, it's way easier to do a refactor and adapt to the new schema too.
"Show me your flowcharts and conceal your tables, and I shall continue to be mystified. Show me your tables, and I won’t usually need your flowcharts; they’ll be obvious. " -- Fred Brooks, The Mythical Man-Month Attempting a design re-write without changing the data structures will just result in the same design. And you can't change the data design without then having to change the code to match.
Re: When a rewrite isn’t: rebuilding Slack on the desktop
#259Earlier quoted context omitted.
Those memory-bloat apps are never, never only memory hogs. They always come with an outsize hit to general system responsiveness, always have UI lag, and so on. These days almost all of them are webtech junk. I still have a few Java programs with that problem —I've been reading "it's in your head, here's a proof that it can't be as bad as you say" for like 20 years now and those folks continue to be wrong in practice…
I've been using Slack on the desktop daily since the alpha version. I've never found it to have UI lag. I honestly think that most people us use phrases like "webtech junk" are offended on principle and not because of any measurable difference that matters to regular users.
Try telegram on desktop and compare the UI performance. Slack definitely has UI lag. Not nearly as bad as Teams though.
Re: When a rewrite isn’t: rebuilding Slack on the desktop
#260Earlier quoted context omitted.
Ripcord [1] is a (native) desktop chat client for Slack and Discord written in C++ and QT. It was posted a few months ago [2] and I’ve been using it since then, it works great. [1] https://cancel.fm/ripcord/ [2] https://news.ycombinator.com/item?id=19617699
Thanks, I'll take a look. I tried https://volt-app.com a while ago but it had some bugs that made it unusable (for me) with Slack. I'm also a bit concerned of using a closed-source client with Slack.