Live data from Hacker News

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

medium.com

251–260 of 408 posts

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

#251
post #60

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.

It was a webview with Qt at one point and used ~25-50mb of ram typically

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

#252
post #135

Earlier 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.

That memory is for IntelliJ, Docker images, Photoshop, Final Cut, Blender, etc.

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

#253

Earlier 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.

Hooks are definitely going to reduce a lot of greenfield project needs for a state library, which should be great for React ease of starting new projects.

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

#254
post #62

Earlier 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.

Twitter has a super custom look and feel and I think that’s mostly react-native and react-native-web. I could be wrong about that though.

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

#255
post #76

Earlier 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…

I recently came to the conclusion that I’ve been going a bit overboard with this in ClojureScript's (let’s call it equivalent) version of Redux, re-frame.

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

#256
post #202

Earlier 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.

I’m using 1Password 7 for Mac with 6 vaults. Seems to hover around 300Mb.

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

#257

Earlier 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…

Wow. This article you linked seems worthy of its own HN submission. Thanks for sharing it!

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

#258

Earlier 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.

I've done several huge rewrites over my sordid career, and a strategy that works well is to abstract your bad data design behind a good one. This involves some kind of transformer layer between your bad data design spec and your abstracted better one. There's of course performance hits of some kind no matter what, but the hope is that they're worth the benefits of the cleaner code/architecture that the better data design spec affords. It's difficult I'll grant, much harder than abstracting simply bad code, but it's possible, and also makes it that much easier to replace the actual data design at some point in the future, and remove the transformer layer. Hope that makes sense!

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

#259
post #175
post #169

Earlier 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.

> I've been using Slack on the desktop daily since the alpha version. I've never found it to have UI lag.

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

#260

Earlier 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.

The Volt app actually looks in your browser files to steal its Slack login session cookie: https://github.com/voltapp/volt/issues/143.
Post reply on HN