Engineering for Slow Internet

How do you use WhatsApp over BitTorrent? And how do you update your macOS over BitTorrent?

The author clearly says that downloaders elaborate enough to deal with slow connections (e.g. "download in a browser") were fine. The problem is that modern apps don't let you download the file the way you want, they just expect you to have a fast internet connection.

I've not so much good vs not so bad vs bad. It's more necessary vs unnecessary. There's also "just because you can, doesn't mean you should."

Amen to this. And give them a mobile cell plan with 1GB of data per month.

I've seen some web sites with 250MB payloads on the home page due to ads and pre-loading videos.

I work with parolees who get free government cell phones and then burn through the 3GB/mo of data within three days. Then they can't apply for jobs, get bus times, rent a bike, top up their subway card, get directions.

Some of these web apps are from very profitable or big companies and that drives me insane because they have more than enough funding to do things right.

Take Home Depot for example. Loading their website in a mobile browser is soooooooooo slow. The rendering is atrocious, with elements jumping all over the place. You click on one thing and it ends up activating a completely different element, then you have to wait for whatever you just clicked to load and jump all over the place again. Very frustrating! Inside their stores is even worse! I asked for help locating an item from one of their workers one day and they pull up their in-store app. That too was slower than molasses and janky, so we ended up standing there for several minutes just chatting waiting for it to load.

That's a good question. I just launched Slack and took a look. Basically: it's doing everything. There's no specialization whatsoever. It's like a desktop app you redownload on every "boot".

You talk about minification. The JS isn't minified much. Variable names are single letter, but property names and more aren't renamed, formatting isn't removed. I guess the minifier can't touch property names because it doesn't know what might get turned into JSON or not.

There's plenty of logging and span tracing strings as well. Lots of code like this:

            _n.meta = {
                name: "createThunk",
                key: "createThunkaddEphemeralMessageSideEffectHandler",
                description: "addEphemeralMessageSideEffect side effect handler"
            };

The JS is completely generic. In many places there are if statements that branch on all languages Slack was translated into. I see checks in there for whether localStorage exists, even though the browser told the server what version it is when the page was loaded. There are many checks and branches for experiments, whether the company is in trial mode, whether the code is executing in Electron, whether this is GovSlack. These combinations could have been compiled server side to a more minimal set of modules but perhaps it's too hard to do that with their JS setup.

Everything appears compiled using a coroutines framework, which adds some bloat. Not sure why they aren't using native async/await but maybe it's related to not being specialized based on execution environment.

Shooting from the hip, the learnings I'd take from this are:

1. There's a ton of low hanging fruit. A language toolchain that was more static and had more insight into what was being done where could minify much more aggressively.

2. Frameworks that could compile and optimize with way more server-side constants would strip away a lot of stuff.

3. Encoding logs/span labels as message numbers+interpolated strings would help a lot. Of course the code has to be debuggable but hopefully, not on every single user's computer.

4. Demand loading of features could surely be more aggressive.

But Slack is very popular and successful without all that, so they're probably right not to over-focus on this stuff. Especially for corporate users on corporate networks does anyone really care? Their competition is Teams after all.