Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

medium.com

Post reply on HN
Print view View original

341–350 of 408 posts

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

#341

Post by nwienert »

mcguire wrote: post #151
jt2190 wrote: post #119

Earlier quoted context omitted.

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.

Take a typical CRUD app. It'll have, say, something for inserting data, editing data, viewing data, and reporting. Pick one of those chunks (reporting is good; it's usually easy and gives insight into the data) and rewrite that. Release it (if it's a web application, modify the old app to redirect reporting requests to the new app). Lather, rinse, repeat until you have a completely rewritten app. It is more along the…

That’s exactly what they are doing, it says it in the article.

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

#342

Post by Groxx »

somethingnot wrote: post #101
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…

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

Sure, but there are multiple "OpenGL on Metal/Vulkan" projects. Because it's possible to do so without all that much of a performance loss.

OpenGL effectively should die... but it's not going to be in favor of raw Metal/Vulkan, except in rare cases. Most people already use engines that abstract most of that away, and Metal/Vulkan are in basically every way better for those engines.

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

#343

Post by flukus »

wgoodall01 wrote: post #327
doc_gunthrop wrote: post #127

Earlier quoted context omitted.

> memory-efficient. Not how I'd describe a text editor that consumes 700MB+ of RAM at any given time.

Replace "text editor" with "IDE," and that 700mb figure doesn't seem so extravagant.

It does to those of use that remember upgrading to (I think) 128MB of RAM to run Visual C++ 6, it's not like a heap of new features have been added since.

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

#344

Post by xedrac »

TylerE wrote: post #330
kbenson wrote: post #231

Earlier quoted context omitted.

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 company I work for actually did this with our main product. Gradually re-written from Java (JBOSS) to Python over about 10 years. Basically the Python side knew what URLs it could handle and proxied the rest over to Javaland. We ended up shutting down the last Java bits early last year.

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

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

#345

Post by TylerE »

xedrac wrote: post #344
TylerE wrote: post #330

Earlier quoted context omitted.

The company I work for actually did this with our main product. Gradually re-written from Java (JBOSS) to Python over about 10 years. Basically the Python side knew what URLs it could handle and proxied the rest over to Javaland. We ended up shutting down the last Java bits early last year.

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 really think there was a better option at the time.

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

#346

Post by yjftsjthsd-h »

harryh wrote: post #305
paulddraper wrote: post #283

Earlier quoted context omitted.

> Too high for what? Too high for an app that runs continuously.

Nearly all users continuously run web browsers these days and they all consumer a lot more ram than slack.

Yes, and that's a problem. Additionally, if the OS and browser are both always running, then there is even less memory left for your app! So this is a stronger argument to use less, not an excuse.

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

#347

Post by untog »

xedrac wrote: post #344
TylerE wrote: post #330

Earlier quoted context omitted.

The company I work for actually did this with our main product. Gradually re-written from Java (JBOSS) to Python over about 10 years. Basically the Python side knew what URLs it could handle and proxied the rest over to Javaland. We ended up shutting down the last Java bits early last year.

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

Why not?

I would argue that if you already have a lot of in-house knowledge with Java then you might as well stick with it (and just not make whatever mistakes you made last time around) but Python seems like a reasonable alternative to me.

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

#348

Post by TylerE »

untog wrote: post #347
xedrac wrote: post #344

Earlier quoted context omitted.

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

Why not? I would argue that if you already have a lot of in-house knowledge with Java then you might as well stick with it (and just not make whatever mistakes you made last time around) but Python seems like a reasonable alternative to me.

At the time there was a strong internal directive that it not only not be Java, but not anything that even looked a bit like Java if you squinted at it (e.g. dotnet) - plus we've always been an "anything but Windows" shop anyway

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

#349

Post by untog »

gilgoomesh wrote: post #308
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

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.

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

#350

Post by untog »

mosdl wrote: post #326
_bxg1 wrote: post #17

The most interesting details: - The first iteration was largely powered by jQuery(!) - Every workspace got its own isolated Electron process because they didn't anticipate multiple workspaces in their initial architecture Honestly it's amazing they got as far as they did with the above limitations. Sounds like this rewrite was sorely needed after their phase of rapid growth. Glad they pulled it off.

They switched to React, which will increase their memory usage and be slower than pure js.

> be slower than pure js

There's no way of knowing, without knowing what they were doing previously. The whole point of React is to leverage the virtual DOM to avoid unnecessary (and very slow) DOM manipulations. Given the sheer number of things Slack has on any given page it isn't unreasonable to expect that React will make things quicker, even if it has a penalty at startup time.

Post reply on HN