It's not clear to me from the post - did they do the same changes on the website version? Should I expect the same improvement there, or are those completely separate implementations.
When a rewrite isn’t: rebuilding Slack on the desktop
261–270 of 408 posts
Re: When a rewrite isn’t: rebuilding Slack on the desktop
#262Earlier 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…
I've done the transformation layer in the small to keep components running during a re-write/refactor. Create a new structure and write some code (in the DB or otherwise) to make the new structure look like the old structure long enough to eventually replace that old code.
I can't imagine doing that as an independent step towards a rewrite.
Re: When a rewrite isn’t: rebuilding Slack on the desktop
#263I will consider this benchmark vindication both for myself and the times I've had to argue as to why Electron isn't the issue, as well as the commentator from many moons ago who worked at Slack, dropped in here and explained why Electron wasn't the problem (rather, poor engineering on Slack's part was), and then was ripped to shreds over it. In fact I'm sure this comment will bring out native fanatics in force. At an…
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.
I checked in Firefox and a given Slack uses 200+MB at load and then optimizes down to 140MB at runtime for a given Slack, of which ~60MB is JavaScript and ~80MB is page elements. So if those numbers carry over to Electron-Chromium, then it's 100MB of "I'm a browser" and 140MB of "I'm a webpage full of dynamic and objects". They certainly will not carry over precisely equally, but it puts some scope on it to consider.
(Gmail uses 250MB at runtime in the same Firefox instance, for comparison; I didn't test it in an Electron-like container.)
Re: When a rewrite isn’t: rebuilding Slack on the desktop
#264Earlier quoted context omitted.
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 m…
If someone is running so much stuff that an app (or a few apps) using ~250MB of ram instead of ~100MB (or whatever) of ram is a huge problem they can easily spend $200 or so for an extra 8GB of ram. Ram is cheap. Usage at this scale just doesn't matter to the vast majority of users.
Yeah, yeesh. So I'm in the market for an ultrabook and eventhough I had 8 GB of ram in my desktop over a frigging decade ago there still exist laptops with less than 16 GB today. Not only that, the cheapest 16 GB model is over a $1000 more expensive because now I must have an i7 and everything else.
And no, not even with 16GB will I tolerate what slack uses even with their new version.
Yes, I do consider upgrading the ram myself by replacing the soldered ram-chips. And do not for a second imagine I'm doing that so that I can send text messages@!
Re: When a rewrite isn’t: rebuilding Slack on the desktop
#265Earlier quoted context omitted.
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.
Low-latency UIs that respect user input are amazing. They're just quite rare these days. I guarantee the difference is noticeable and makes a difference—look at how everyone liked (and still likes) the UI smoothness and low UI latency of iOS, for example, and iOS, though probably the current front runner on this front for popular operating systems, is just so-so at it. I guess if my principle is that I like my comput…
Google Docs on what device? Their iOS apps are famously bad on slower iPads (like the original Air) but the website with a correctly configured browser on a reasonably-specced laptop or desktop is very responsive, once it loads. Of course, I'm not a fan of it myself, but the input lag isn't the reason.
Re: When a rewrite isn’t: rebuilding Slack on the desktop
#266Earlier quoted context omitted.
Your third point is arguing against the premise. A "partial rewrite" isn't a rewrite. That's the entire point.
At some point a partial rewrite might become a complete rewrite. It depends. Ship of Theseus[1], etc. 1: https://en.wikipedia.org/wiki/Ship_of_Theseus
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
- reap tax benefits in your 99.9% new house.
Re: When a rewrite isn’t: rebuilding Slack on the desktop
#267" 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.
"refactor"
Re: When a rewrite isn’t: rebuilding Slack on the desktop
#268Earlier 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?
Extra features aren't the reason why Slack is so huge.
Re: When a rewrite isn’t: rebuilding Slack on the desktop
#269Gitlab is approaching rewrites in sensible way. Slowly replacing discrete components of jQuery / rails views with Vue components, but only if necessary
Re: When a rewrite isn’t: rebuilding Slack on the desktop
#270Earlier quoted context omitted.
If people cared about looks or features, Slack certainly wouldn’t come out on top. No, what people care about are primarily network effects. They'll use whatever someone in the company decided to use (frequently Slack because it’s always been Slack since someone back in 2013 decided it was the hip choice, before it even had a desktop client), and they’ll put up with whatever dogshit client they’re served, because it’…
In the last two companies I worked in it was us low level employees which were begging IT for Slack, until they reluctantly accepted (because of costs and of fears about hosting confidential chats on 3rd parties). Nobody was begging for LimeChat or IRC. And what about Discord? It's almost exclusively used by people in their homes, there is no company pushing it down their throats.
There are network effects outside of companies "pushing [software] down [employees'] throats." Consider, for instance, that large groups of gamers already use Discord?