Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

medium.com

Post reply on HN
Print view View original

291–300 of 408 posts

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

#291

Post by bmurphy1976 »

saagarjha wrote: post #284
bmurphy1976 wrote: post #217

Earlier quoted context omitted.

That's a terrible solution. I chose my monitor specifically because it's HIDPI, not high resolution. It's easier on my eyes to read smoothly rendered text in HIDPI than jaggedly rendered text all day long. Changing the resolution subverts that.

If you're using macOS, have you tried changing the screen resolution? On HiDPI monitors it doesn't produce "jaggedly rendered text" at all (in fact, Apple ships a number of laptops with this as the default configuration…)

Yes, and it makes the apps that are sized appropriately for the default Mac resolution too big.

It's an accessibility problem, not a resolution problem. Electron apps don't have this issue because you can resize each app individually to match your needs/screen settings. You can't do this with most native apps.

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

#292

Post by RobertKerans »

api_or_ipa wrote: post #143
wootie512 wrote: post #131

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.

Suspense for data loading seems to cover that side of things quite well in the experiments I've tried with the current API.

I use Sagas as well though, and Ive found them ok...really easy to test but feel very heavyweight and clunky; personally, I don't _really_ like the loading/error state to be handled by Redux: the more years I work on React/Redux app the more I prefer for a section of an app to be mounted -> triggering a fetch -> loading, show local loading UI -> {fails, show local UI|succeeds, dispatch success}. So Redux becomes a serializable normalized data cache that acts to store the results of disparate API calls and doesn't care at all much about the UI.

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

#293

Post by Androider »

api_or_ipa wrote: post #143
wootie512 wrote: post #131

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.

We started a greenfield project a few months ago and decided not use Redux and try the context API instead. In retrospect, that was a bad idea. Context is fine for a small app, but small apps tend not to stay small... and then you're stuck with the Yugo when you what you really need is a truck.

In our main app we also use advanced features like what Slack is describing in their post, like having multiple Redux stores. We also combine stores from multiple sources (e.g. appStore = [...store1, ...store2, ...storeFromALibrary]. It's incredibly flexible.

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

#294

Post by beachy »

zepolen wrote: post #246
mcguire wrote: post #103

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

Jesus NO at no.2 Rewrites are ALL about the schema. Look, over time, your initial requirements will change. The initial schema will 100% not be what is ideal. On a long enough time scale EVERYTHING becomes many to many. I've found any rewrite of software without restructuring the schema has always been a waste of time.

Yep, I've never seen a system that was a) so bad that it requires rewriting and b) had a great schema that rewrite could be done on top of.

Usually a quick glance at the schema will shine a bright light on top of all sorts of badness - denormalizations, excessive metadata-driven-ness etc. Rewriting code on top of crud like that would be epensive, and result in a lot of ugly code, which would need to be rewritten again.

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

#295

Post by rvz »

akstrfn wrote: post #153

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

So Ripcord is created by one person in his spare time and it performs blazingly-fast and supports Slack whilst Slack's own client is maintained by tens if not hundreds of engineers and it still performs slower when joining more teams, consumes significant amounts of RAM and they create this blog-post about performance improvements whilst still using Electron.

Understanding on why Slack is unable to create a performant desktop-client for their users is beyond me. I also wasn't able to use Slack and Discord at the same time on my MacBook without it swapping on the SSD. So Ripcord seems to be a good lightweight alternative for me.

I just wish it supported Keybase Chat so I can ditch that Electron garbage too.

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

#296

Post by hoorayimhelping »

harryh wrote: post #175
asark wrote: 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.

Easy way to demonstrate the jank: switch tabs quickly on desktop Slack. The new views take a nonzero amount of time to render. Do the same thing on Sublime Text 3. Even big files with lots of syntax highlighting load nearly instantly, or at the least, much much faster.

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

#297

Post by ben509 »

bmurphy1976 wrote: post #208
akstrfn wrote: post #153

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

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

That's an interesting point. I think I'm 10 years behind you and I've definitely found myself bumping the font size in Emacs and generally avoiding many squinty apps without really thinking about it. The solutions for UI element size tend to be aimed at good eye-sight or nearly blind with little in between.

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

#298

Post by coldtea »

wvenable wrote: post #249
coldtea wrote: post #244

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.

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

Sure you can. You decouple your data structures from your schema with an abstraction layer, facade, etc.

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

#299

Post by rvz »

cat199 wrote: post #64
guessmyname wrote: post #42

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

interesting - they mention: "Slack connectivity is now available for testing. It's still pretty rough and missing a lot of features." any further insights here? could just try it myself, but slack is our key communication so getting more input would be great

I just tried Ripcord with an old Slack account and it seemed to be working fine. I've not encountered any issues on my end so far.

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

#300

Post by voicedYoda »

oflannabhra wrote: post #25

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

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.

Post reply on HN