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

321–330 of 408 posts

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

#321

Post by bin0 »

m463 wrote: post #266
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 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…

That's sometimes a good strategy, but breaks when you do too much at once. See boeing's recent fiasco where they did basically just that with parts and a fuselage that weren't really compatible. Metaphor extends: try to replace too much in part and something will break.

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

#322

Post by illuminati1911 »

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.

When you are in hackers news your new gods are: shoehorning JS everywhere, Go and complaining how women get discriminated in the tech industry. Disagree -> dv.

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

#323

Post by illuminati1911 »

harryh wrote: post #135
DaiPlusPlus wrote: post #74

Earlier quoted context omitted.

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.

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.

This is self-deception. While technically you are right, you don't actually have full 8GB to allocate to JS bloat apps. After the OS and all the other necessary stuff what you will always have running in the background like browser etc. you'll be left with 4-6GB.

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

#324

Post by illuminati1911 »

harryh wrote: post #247
msbarnett wrote: post #207

Earlier 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?

You could make a pile of shit popular if you had similar access to Silicon Valley funding and marketing machines.

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

#325

Post by weq »

acemarke wrote: post #67

I know that popular opinion in the Twitterverse is that "Redux is dead", but I note that both Twitter and Slack just released major rewrites that use Redux heavily. I talked about Redux usage stats and comparison with other alternatives in my "State of Redux" talk at Reactathon earlier this year [0], and my post "Redux - Not Dead Yet!" also addresses some of these aspects [1]. Also, quick plug for our current focus.…

"Redux" Event Sourcing for the JS hype-machine.

Nothing is dead about event sourcing, other then the mob has moved forward in the hype cycle.

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

#326

Post by mosdl »

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

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

#327

Post by wgoodall01 »

doc_gunthrop wrote: post #127
zeusly wrote: post #8

I wonder if they increased their efforts after seeing VS Code (also a complex Electron app) run fast and memory-efficient. Before VS Code everyone just accepted Electron's memory bloat, maybe slack even had plans to go fully native b/c no one thought it could be done properly.

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

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

#328

Post by dingo_bat »

ausjke wrote: post #126
ausjke wrote: post #41

Earlier quoted context omitted.

mirc is windows only? there are many web-based irc these days and they worked well

interesting, so I checked out mirc and reported it's windows-only(hope to save someone sometime), and since I used irc over browser so I added some info for that. Still, obviously someone disliked this sort of comments and downvoted, I'm always surprised by downvotes like this sort, any bystander can shed some lights? Am I supposed to always write a cheerful comment for basic neutral truths?

I guess down votes are because most software is windows only. Also the general topic of the thread was native clients, so expecting a web client was not very appropriate.

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

#329

Post by flukus »

mcguire wrote: post #103

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

#1 and #2 ignore why a rewrite is happening in the first place. No one rewrites a system for fun, they're rewritten because the current codebase has major failings that prevent new features or make the current codebase unworkable. These should be the first things added to a rewrite to prove that it's not a wasted effort.

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

#330

Post by TylerE »

kbenson wrote: post #231
paxys wrote: 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

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.

Post reply on HN