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

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

#171

Post by qudat » Mon, Jul 22, 2019, 7:33 PM UTC

bendixso wrote: post #55

throwaway66666 wrote: post #23

Earlier quoted context omitted.

Nobody has the resources for that. Some companies make OSes, and some companies send rockets to space. Those feats are also powered by thin wrappers over electron. /s People seem to forget that C++ and opengl is cross-platform. And there are projects far bigger than slack, like ffmpeg and OpenCV that have existed for decades, always had very fast development cycles, with only a subset of the funding and money that Sl…

It is telling that the person arguing in favor of native C/C++ has to use a throwaway account for fear of going against the dominant force of opinion in our industry. We should be able to have these conversations openly without wondering if it makes us less employable.

Please. This is literally the same argument I read over and over again on HN. This IS the bastion for this kind of argument.

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

#172

Post by harryh » Mon, Jul 22, 2019, 7:33 PM UTC

msbarnett wrote: post #155

harryh wrote: post #135

Earlier quoted context omitted.

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

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

#173

Post by ckuhl » Mon, Jul 22, 2019, 7:33 PM UTC

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

I think it definitely depends on your use-case. Like you wrote, if everything else you have open also churns through battery life, it's unlikely having Slack open will make a difference.

However, if your other applications are a terminal, other efficient text editor (e.g. Sublime), and other generally respectful apps, I've found having Slack open is the difference between having enough battery life to work all day, and not.

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

#174

Post by fjabre » Mon, Jul 22, 2019, 7:34 PM UTC

djsumdog wrote: post #141

So big re-engineering rewrite .. and they're still going with electron? I mean, I guess it's good they're getting memory usage down for multiple teams, but other than that, it still seems like a bad start. I realize native apps on the three big platforms is difficult, but they're not using any native components what-so-ever. It's their web interface in a window. They could have used existing toolkits like QT, Gtk or…

I think Slack’s web interface is ideal.

I fail to see the need for a slack desktop client.

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

#175

Post by harryh » Mon, Jul 22, 2019, 7:35 PM UTC

asark wrote: post #169

harryh wrote: post #135

Earlier quoted context omitted.

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.

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.

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

#176

Post by zerr » Mon, Jul 22, 2019, 7:36 PM UTC

saagarjha wrote: post #165

zerr wrote: post #159

Just hire proper native desktop developers (e.g. C++) and do another rewrite.

Slack’s library that they share between their mobile apps is written in C++.

That's great (and an obvious choice), but I mean the proper native desktop GUI app.

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

#177

Post by SkyMarshal » Mon, Jul 22, 2019, 7:38 PM UTC

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

For anyone else who didn't know about Ripcord:

https://cancel.fm/ripcord/

Their first marketing bullet: "It's not made from a web browser" :D

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

#178

Post by jumbopapa » Mon, Jul 22, 2019, 7:38 PM UTC

passivepinetree wrote: post #132

jumbopapa wrote: post #125

Earlier quoted context omitted.

I got the dark theme to work. Would you be interested in a write up?

I would! I imagine others would be as well.

Directions for adding in Dark Mode/Theme into Slack 4.0 using Windows (It should work mostly the same on other OS's, but you'll need to tweak it a little):

1. You'll first need the ability to open .asar archives. This can be done with 7-zip along with the following package: Asar7z (http://www.tc4shell.com/en/7zip/asar/). Follow the installation instructions on the site and keep in mind you need administrative privileges to copy files to Program Files.

2. Completely close down Slack via Task Manager → End Task (Simply closing the application is not enough, you must kill it in task manager)

3. Navigate to the following file in your user app data C:\Users\{usernamePlaceHolder}\AppData\Local\slack\app-4.0.0\resources\

4. Find app.asar and first create a backup

5. Right-click app.asar and select 7-zip→Open Archive

6. Navigate down to the dist folder, right-click the ssb-interop.js file, and select Edit:

7. Scroll to the bottom of the large block of unreadable javascript (it's minified) and paste the code snippet to the bottom of the file.

    document.addEventListener('DOMContentLoaded', function() {
     $.ajax({
       // Note: change the URL to whatever css file you want. This one works well enough for me. I have it locked to a commit to prevent XSS
       url: 'https://raw.githubusercontent.com/laCour/slack-night-mode/5e3b2ba1303cf98775c386994730d9f87e8e8218/css/raw/black.css',
       success: function(css) {
         $("").appendTo('head').html(css);
       }
     });
    });

8. Save the file and close the archive in 7-zip. Reboot Slack.

Note: that you'll have to reapply this fix every time Slack pushes an updated

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

#179

Post by ebiester » Mon, Jul 22, 2019, 7:38 PM UTC

sagichmal wrote: post #24

dewey wrote: post #14

Earlier quoted context omitted.

As much as I'd love a native app, for a fast moving company with rolling releases it's probably very hard to keep three platforms at the same level especially if you want to do experiments too or roll out features to a small subset.

> for a fast moving company with rolling releases Name three major feature improvements to Slack in the last three years. I can think of one, threads, which are a fucking usability disaster and should have been killed immediately. I can't think of a single other major feature.

It's not perfect, but we've used it extensively.

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

#180

Post by gnicholas » Mon, Jul 22, 2019, 7:40 PM UTC

I went to get the update on my Mac, and it shows a new version from July 8. The release notes say: "Slack is a little faster, thanks to a few small but important changes". Huh?

This seems to be the right update (4.0.0), but on Slack's website the release notes [1] show the release date to be July 15. Is this the same version as I'd get via the Mac update? If so, what's with the press push today (Verge and others), if this has been out for weeks? Also, why is it described as "a little faster" and "a wee bit faster overall" (in the web release notes)? Is it a wee bit faster, or much faster?

1: https://slack.com/intl/en-gb/release-notes/mac?geocode=en-gb