When a rewrite isn’t: rebuilding Slack on the desktop • Hacker News Board

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

#331

Post by msbarnett » Tue, Jul 23, 2019, 1:52 AM UTC

harryh wrote: post #247

msbarnett wrote: post #207

Earlier quoted context omitted.

Aside from the obvious issue that a ton of devices don’t have user upgradable RAM, are we really this comfortable with feeding constant consumerist abandonment of old devices through our own sheer laziness as developers? “It only uses 8% of 8GB of RAM. If that’s an issue consumers can buy more RAM or throw away their devices and buy new ones” is soon phrased as “It only uses 8% of 16GB of RAM. If that’s an issue cons…

If there has been no real gain in functionality, then why is Slack hugely popular while IRC is used by almost no one? Perhaps you aren't giving credit to functionality that is important to people other than yourself?

> If there has been no real gain in functionality, then why is Slack hugely popular while IRC is used by almost no one?

The main, really only, features that Slack has that IRC doesn’t is easy account onboarding and (crucially, for business) offboarding, and persistent messaging. This has been discussed to death, publicly, by organizations like Mozilla. They were also smart enough to offer themselves for free to startups, which largely undermined hipchat, which had the same basic value proposition over IRC, and allowed them to build a hip reputation and network effects in the startup crowd.

Are we really going to pretend that those features are why the Slack client consumes tons of RAM and a fuckload of CPU cycles? They’re entirely server side, for christ’s sake.

ICQ could do all of the above on a 32 Meg Mac 20 years ago. The bloat isn’t related to the reasons it “won”, or why it continues to be popular. Network effects, the fact that if your company mandates it you have no alternative, simply insulates them from suffering many ill-effects of their bloated, laggy client software.

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

#332

Post by foobarian » Tue, Jul 23, 2019, 1:55 AM UTC

dougk16 wrote: post #258

wvenable wrote: post #249

Earlier quoted context omitted.

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

Something similar I've seen is a bad data design that is embedded into a giant monolith, and has dependency tendrils everywhere. In that case it's worthwhile to factor out the logic (which includes cutting the dependencies) even leaving the schema intact. Once the problem layer is sequestered e.g. into its own microservice it is hopefully possible to release it on its own cycle much faster than the monolith, paving the way to improving the schema next.

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

#333

Post by harryh » Tue, Jul 23, 2019, 1:56 AM UTC

msbarnett wrote: post #331

harryh wrote: post #247

Earlier quoted context omitted.

If there has been no real gain in functionality, then why is Slack hugely popular while IRC is used by almost no one? Perhaps you aren't giving credit to functionality that is important to people other than yourself?

> If there has been no real gain in functionality, then why is Slack hugely popular while IRC is used by almost no one? The main, really only, features that Slack has that IRC doesn’t is easy account onboarding and (crucially, for business) offboarding, and persistent messaging. This has been discussed to death, publicly, by organizations like Mozilla. They were also smart enough to offer themselves for free to start…

Lots of different chat software had easy onboarding & offboarding as well as persistent messaging before Slack and none of it was successful in the same way.

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

#334

Post by PopeDotNinja » Tue, Jul 23, 2019, 2:03 AM UTC

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…

4. If the version X team is writing version X + 1, that knowledge is gonna help a whole lot.

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

#335

Post by 43920 » Tue, Jul 23, 2019, 2:05 AM UTC

ComputerGuru wrote: post #316

kup0 wrote: post #302

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

> Microsoft has done a fine job with VSCode Microsoft has done a fine job with VS Code considering it is built on Electron , but it's a freaking text editor ffs! It has basically zero need for a UI. If this were 1990 and there were no cross-platform filesystem, i/o, network, async, etc. APIs available for native applications, it might make sense. But a text editor is basically the very simplest cross-platform UI you…

VS Code is a lot more than just a text editor; off the top of my head, it has:

* Syntax highlighting and code folding * Autocomplete * Integrated file browser * Integrated git client * Automatic formatting * File preview * Debugger * ...and a ton more features

Just looking at the screenshots from the release notes (https://code.visualstudio.com/updates/v1_36), I highly doubt this is "the very simplest cross-platform UI you could ever need to design".

Also, as far as I know, the vast majority of the editor is still HTML/CSS/JS, with only a few exceptions (the integrated terminal and project-wide search I think?)

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

#336

Post by jancsika » Tue, Jul 23, 2019, 2:06 AM UTC

bmurphy1976 wrote: post #222

tumult wrote: post #213

Earlier quoted context omitted.

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.

I'm using a mac. QT_SCALE_FACTOR doesn't really help, and most of Apple's native apps are actually sized appropriately. It's everything else that's a problem. Honestly, I think it's an accessibility issue. Most devs are simply used to the small GUIs, so that's what they build. They don't give it any real thought or put any actual design effort into it. It's the same with accessibility, it's not my problem so it's not…

> Honestly, I think it's an accessibility issue.

Even just focusing on the usability of zooming in a browser-- I wonder how much even the best Linux desktop environment (or even OSX) trails behind browsers. Off the top of my head:

* the obvious keybindings (even across browsers?) that are the same for tabs/windows regardless of the content inside them

* in FF the zoom percentage animates itself into existence when you go below or above 100%, then remains viewable and clickable to return to normal

* most of the popular web pages are designed for zooming so that text reflows in a readable manner when zoomed

* when zooming, fonts remain readable without the user fudging around with DPI or rendering settings that no mortal ought to understand

* zoom level and scroll position is remembered in case I click the back button

Well, the desktop doesn't even have a notion of the back button so I'd say we're already at least a few years ahead of the desktop.

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

#337

Post by msbarnett » Tue, Jul 23, 2019, 2:07 AM UTC

harryh wrote: post #333

msbarnett wrote: post #331

Earlier quoted context omitted.

> If there has been no real gain in functionality, then why is Slack hugely popular while IRC is used by almost no one? The main, really only, features that Slack has that IRC doesn’t is easy account onboarding and (crucially, for business) offboarding, and persistent messaging. This has been discussed to death, publicly, by organizations like Mozilla. They were also smart enough to offer themselves for free to start…

Lots of different chat software had easy onboarding & offboarding as well as persistent messaging before Slack and none of it was successful in the same way.

Like I said, networking effects and currying a hip reputation are a huge part of why I think they got big. In large part nothing about what makes them big strikes me as technical in nature.

But sure, ok, so let’s hear your theory on why they got big and how it requires all of this client side RAM usage. So what is it?

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

#338

Post by comex » Tue, Jul 23, 2019, 2:08 AM UTC

sansnomme wrote: post #319

comex wrote: post #80

Earlier quoted context omitted.

> 4. A few good, Open Source native ports already exist, and people are just unaware of them. Native GUI clients: - Ripcord: https://cancel.fm/ripcord/ - Wey: https://github.com/yue/wey ("written in Node.js with native UI powered by the Yue library") - Volt: https://volt-app.com IRC bridges (allow using Slack from native IRC clients): - wee-slack: https://github.com/wee-slack/wee-slack - irc-slack: https://github.com…

To be fair, if you want it to be that pretty you will have to either reinvent two-thirds of a browser or half a game engine. There's a reason "rich UI"s are a pain to build compared to native GUIs (MSFT Xaml is more similar to a web browser than traditional winforms-style UI). The best compromise right now is to aggressively build pretty, heavily themed prebaked designs. Think Material Design, Cupertino etc. so nativ…

Maybe on some platforms. I'm a Mac user, so speaking for that platform, AppKit has had built-in animation support for over a decade (and now with Catalyst you can also use UIKit if you want). Drag-and-drop in particular has animations out of the box when using certain built-in widgets – e.g. when you're dragging an item into an NSOutlineView, the existing item at the cursor will slide down to make room for it. (But what in Slack is even draggable? I can't seem to drag to rearrange channels, for instance.)

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

#339

Post by kickopotomus » Tue, Jul 23, 2019, 2:10 AM UTC

bin0 wrote: post #321

m463 wrote: post #266

Earlier quoted context omitted.

The easy way to fund a new military plane is: - remove one bolt and raise in the air - slide out rev 30 "parts" from beneath bolt - slide in rev 40 "upgrade parts" (fuselage, wings, engines, etc) underneath the bolt - fly "upgraded plane" without a lot of pesky 'new plane" studies Additionally, in parts of california, how to build a house: - find existing house - pick a wall - remodel everything except for that wall…

That's sometimes a good strategy, but breaks when you do too much at once. See boeing's recent fiasco where they did basically just that with parts and a fuselage that weren't really compatible. Metaphor extends: try to replace too much in part and something will break.

I would say the Boeing incident more so favors the counterpoint. Boeing tried to keep adding features to an airframe (code base) that could not support it.

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

#340

Post by Klonoar » Tue, Jul 23, 2019, 2:13 AM UTC

candiodari wrote: post #245

Klonoar wrote: post #206

Earlier quoted context omitted.

His point is, actually, quite valid. By the time you stop and rebuild all the image caching/media pieces, you'll end up with a hefty amount of memory usage too - Telegram (not the Qt one, the Cocoa one) will regularly climb up to 200ish MB if I have a media-heavy chat going. People have skewed ideas of what's doable in memory constraints in 2019 for the feature sets that customers tend to expect.

You're comparing absolute minimum of slack with a very heavily used Telegram instance. This is, given the similarity of the apps, not fair. Compare a "media-heavy" slack with that Telegram, or compare with Telegram minimum.

No, I'm comparing the baseline: Slack's feature set.

To support that, you'd need far more than a "Hello World" stack.