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

151–160 of 408 posts

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

#151

Post by mcguire »

jt2190 wrote: post #119
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…

Point 3 seems to redefine “rewrite” as “partial rewrite”, which is essentially in the spirit of “never rewrite the [whole] code[base] from scratch”. Am I missing something? Edit: Clarified quote of original rule.

Take a typical CRUD app. It'll have, say, something for inserting data, editing data, viewing data, and reporting. Pick one of those chunks (reporting is good; it's usually easy and gives insight into the data) and rewrite that. Release it (if it's a web application, modify the old app to redirect reporting requests to the new app). Lather, rinse, repeat until you have a completely rewritten app.

It is more along the line of "don't try to do a big-bang release of everything" when you are initially writing an app.

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

#152

Post by driverdan »

anchpop wrote: post #136
driverdan wrote: post #133

Earlier quoted context omitted.

Their comment had nothing to do with IRC. It was comparing two chat clients and how Slack's Electron version is much worse than a native version.

The native client they were referring to was mIRC, which does much less than Slack does. A better comparison might be Discord, which performs much better than Slack and is also written in Electron. VSCode, written in Electron, performs much better for me than Visual Studio (a native app), but I wouldn't use that as proof that Electron is faster than native apps because Visual Studio does so much more

The major differences I can think of off the top of my head are threading, reactions, voice chat, and history. Voice chat is the only one that should use significantly more resources than mIRC.

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

#154

Post by charrondev »

guessmyname wrote: post #96
charrondev wrote: post #92

Earlier quoted context omitted.

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.

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-ai... [2] https://techcrunch.com/2013/02/14/with-3500-paying-customers... [3] https://techcrunch.com/2017/09/07/atlassian-launches-stride-...…

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 200-300 MBs. Spark, 1Password, & Sublime Text are all "native" apps so I really don't understand what the whole fuss is about.

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

#155

Post by msbarnett »

harryh wrote: post #135
DaiPlusPlus wrote: post #74

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.

Too high compared to similarly featured (or even more full featured) programs built on other technologies.

3% on an Electron chat app here, 5% on an Electron text editor there, and pretty soon you’ve managed to replace what could’ve been several apps with small memory footprints plus several gigs of efficient file caching in a users’ RAM with just a few bloated programs crowding out the cache, and made their entire machine considerably less responsive.

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

#156

Post by dictum »

_bxg1 wrote: post #75
bengale wrote: post #44

Earlier quoted context omitted.

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.

What I've noticed is that much of the distaste with Electron apps has more to do with the idea of waste than with the actual practical implications. Programmers like things to be efficient and optimized. Electron sacrifices those traits in a couple of ways, in favor of actual productivity. So "the downsides of Electron outweigh the downsides of native apps" when you're someone who patrols the task manager looking for…

32GB workstations are the exception, not the norm. I'd wager most people are using Slack from computers with 8GB RAM (e.g. every 13 inch Macbook Pro that isn't built to order) and at least one browser open at all times.

(I'm not against web APIs as a platform for desktop apps, but I'm happier using Webkit wrappers and I think this would be improved, cross-platform, if Chrome could effectively host the apps that currently ship with their own instance of Electron or CEF)

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

#157

Post by 0xDEEPFAC »

pwinnski wrote: post #13
nottorp wrote: post #10

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

Electron makes it a desktop app. That part has not changed.

Yea.. I would say Slack is an electron "client" or something like that - just like I would say Java programs are "clients" of the JVM.

Both are only "native desktop applications" if you squint your eyes.

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

#158

Post by BinaryIdiot »

electronstudio wrote: post #148

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?!

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.

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

#160

Post by qudat »

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.

Shameless plug: https://github.com/neurosnap/use-cofx

Under the hood it uses [cofx](https://github.com/neurosnap/cofx) which is a library I wrote to solve the need to write declarative side-effects without redux.

Post reply on HN