Live data from Hacker News

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

medium.com

361–370 of 408 posts

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

#361

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

The reason to avoid rewrites is because they generally get cancelled, or they build the wrong thing. In the first case, you have a system that mostly does what you want, but it has architectural issues that make it hard to change. You plan a rewrite. You get buy in from management. But the problem is that the business still needs those changes. If your rewrite takes more than a few months, then you're still going to…

"incremental rewrites are best, but only if you can get the business to actually use the greenfield project. "

That completely fits my experience. If the new code is being used early and can grow iteratively while being relevant and useful, its gonna work out fine.

Having the codebases running side by side somehow is the best choice all around, if it can be managed.

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

#362

Earlier quoted context omitted.

Yeah, and a Rolls Royce is little more than a Honda with worse miles per gallon.

You say this like I should prefer a Rolls Royce to a Honda.

Yeah, I'd take a Civic Type R over any other contemporary car.

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

#363
post #349

Earlier quoted context omitted.

They're proud that they can operate in just 500MB of RAM for an app that shows scrolling lists of text. The economics of RAM has changed somewhat but 1990s me is still appalled .

It isn't scrolling lists of text, though. It's user profiles, rich text, colored code snippets, images, uploaders for both, reactions, contextual menus, channel lists... I'm not saying they can't do better, but the app does do quite a lot.

The Textual IRC client for Mac does this with like 40-60MB of RAM, and that's still using a WebKit view for the chat pane. The rest of the UI is pure Cocoa and way nicer.

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

#364
post #134

Earlier 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

But the alternative to a rewrite is gradual refactoring, i.e. Ship of Theseus, i.e. not a rewrite.

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

#365

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…

> People seem to forget that C++ and opengl is cross-platform OpenGL is dying. It's already deprecated on MacOS. https://appleinsider.com/articles/18/06/04/opengl-opencl-dep...

Apple deprecates lots of things that are still alive and well (see also: headphone jacks). I wouldn't read too much into that.

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

#367
post #345
post #344

Earlier quoted context omitted.

Something that takes 10 years to rewrite (even gradually) has no business being written in Python. Yikes!

What would you write it in? At the time the re-write started, Django hadn't yet seen a public release, Rails barely existed (and had zero traction, and Ruby-the-runtime was horrible), dotnet was barely a thing, Clojure and Go didn't exist yet, dotnet barely existed. 2005 was a weird time. Realistically the only options at the time were Python, PHP (4, not 5), or Perl. I didn't come in until much later, but I don't re…

Java?

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

#368
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

They're proud that they can operate in just 500MB of RAM for an app that shows scrolling lists of text. The economics of RAM has changed somewhat but 1990s me is still appalled .

Seriously. I'm not sure how we got to a place where 500MBs of RAM for apps that don't even have a quarter of the functionality of apps that needed 500KBs of RAM became normal and acceptable.

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

#369
post #20

For me the gold standard of Chat applications is always going to be mIRC. It supports a ton of plugins, consumes 10-50mb of memory and little to no CPU. You could be connected to multiple servers and channels with DCC scripts running and you still wouldn't notice that it's even running. Even though Slack is using react now, they are still using electron under the hood. Which means it can never match the snappiness of…

I don't really understand the hacker love for IRC. It's always been hard to figure out what level of encryption you can expect, what plugins are supported on what clients, using it from multiple devices was never a good experience, you miss any messages sent while your pc was off, very poor support for searching server history for messages with certain text, sending files can be confusing, etc. Having a snappy client…

I'm not really comparing the slack of today with mIRC which was first released in 1995. In early 2000s back when IRC was still very popular, mIRC was a breeze to use on computers which existed. It hasn't seen much development over the past decade and it shows, but it's commendable that lightness was a priority for developers who built it.

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

#370
post #277
post #273

Earlier quoted context omitted.

The difference between an 8GB macbook air and a 16GB maxbook air is $200, not $1000. Lot's more options in PCs obviously, but 2 minutes of googling found a 16GB XPS13 $580 more than the 8GB version. Again, not $1000. I'm sure with slightly more searching there are cheaper options as well.

Yeah, as said the problem isn't just the ram price it's whatever else you might need to buy to get it. But 580 is also pretty darn depressing for 8GB. For reference I bought 64GB for my workstation for less than $400 a few years ago. And that's with 25% sales tax.

This isn’t a fair comparison.

Desktop memory is cheaper, laptop manufacturers are rent seeking with upgrades normally, and with soldered memory they have free reign.

It’s true that often the upgrades are bundled, ie; can’t get 16GiB without an i7. But I think that’s fairly rare at least.

As for 16GiB, there’s a hard limit there for LPDDR3, and intel CPUs do not support LPDDR4 yet.

Oh, and another thing regarding cost, there were some issues a long time ago with the factories producing them, which is why the price is still high, maybe artificially.

https://www.vice.com/en_us/article/wnxb35/the-year-that-the-...

Post reply on HN