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

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

#381

Post by wink » Tue, Jul 23, 2019, 10:23 AM UTC

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.

Been doing that quite a few times back in PHP-land.

Partial rewrites based on Domain/Model/REST endpoint and just proxying to both webapps based on which was new already.

No breaking changes from the outside, either share the parts of the code that are still good (most of the business logic might be) or fork them (and then refactor and maybe you need to fix bugs twice) and after a while you can switch off the old part.

Works like a charm with added benefits of being in the same language to avoid wasting time. But the base idea works even if you use different languages.

It's also not for web apps, for example Apache Storm can do Bolts? (been a while) in several languages so you can also easily rewrite parts, if you can serialize your data in and out of it.

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

#382

Post by RobertKerans » Tue, Jul 23, 2019, 12:16 PM UTC

cozuya wrote: post #351

RobertKerans wrote: post #292

Earlier quoted context omitted.

Suspense for data loading seems to cover that side of things quite well in the experiments I've tried with the current API. I use Sagas as well though, and Ive found them ok...really easy to test but feel very heavyweight and clunky; personally, I don't _really_ like the loading/error state to be handled by Redux: the more years I work on React/Redux app the more I prefer for a section of an app to be mounted -> trig…

What do you do if multiple components/"pages" that aren't even remotely connected need access to the results of an API call?

The results are in the Redux store. I'm not sure I understand the question, why and how would multiple components be making the same fetch request at the same time? With what I'm describing, there is already a common state, if they just need access to that state they have access to it.

Edit: If you do need to synchronise multiple async updates to that state that happen in a very short space of time & in an unknown order in a controlled way, then yeah something like sagas is a solid choice to exert control over that. But very often the user of the UI is only going to make one request [or one batched set of requests] -- eg I am working on an RN app at the minute, and each screen does need to fetch data. So I fetch in the component, it shows loading etc, then populates the store. If the user cancels what they're doing (navigate away for example), the component used to fetch unloads and no dispatch is made.

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

#383

Post by ebg13 » Tue, Jul 23, 2019, 12:47 PM UTC

43920 wrote: post #335

ComputerGuru wrote: post #316

Earlier quoted context omitted.

> Microsoft has done a fine job with VSCode Microsoft has done a fine job with VS Code considering it is built on Electron , but it's a freaking text editor ffs! It has basically zero need for a UI. If this were 1990 and there were no cross-platform filesystem, i/o, network, async, etc. APIs available for native applications, it might make sense. But a text editor is basically the very simplest cross-platform UI you…

VS Code is a lot more than just a text editor; off the top of my head, it has: * Syntax highlighting and code folding * Autocomplete * Integrated file browser * Integrated git client * Automatic formatting * File preview * Debugger * ...and a ton more features Just looking at the screenshots from the release notes ( https://code.visualstudio.com/updates/v1_36 ), I highly doubt this is "the very simplest cross-platfor…

> VS Code is a lot more than just a text editor; off the top of my head, it has:...

And it also plays little explosion animations around my cursor while I type, which is neat.

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

#384

Post by cozuya » Tue, Jul 23, 2019, 1:30 PM UTC

RobertKerans wrote: post #382

cozuya wrote: post #351

Earlier quoted context omitted.

What do you do if multiple components/"pages" that aren't even remotely connected need access to the results of an API call?

The results are in the Redux store. I'm not sure I understand the question, why and how would multiple components be making the same fetch request at the same time? With what I'm describing, there is already a common state, if they just need access to that state they have access to it. Edit: If you do need to synchronise multiple async updates to that state that happen in a very short space of time & in an unknown or…

I meant to reply to the guy above me who advocates component level fetch as opposed to using Redux sorry.

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

#385

Post by RobertKerans » Tue, Jul 23, 2019, 1:55 PM UTC

cozuya wrote: post #384

RobertKerans wrote: post #382

Earlier quoted context omitted.

The results are in the Redux store. I'm not sure I understand the question, why and how would multiple components be making the same fetch request at the same time? With what I'm describing, there is already a common state, if they just need access to that state they have access to it. Edit: If you do need to synchronise multiple async updates to that state that happen in a very short space of time & in an unknown or…

I meant to reply to the guy above me who advocates component level fetch as opposed to using Redux sorry.

That was me! Component level fetch !== no Redux, that's not what I described; using Redux does not _mean_ you have to use one of the many libraries built to wrestle asynchronous fetching into Redux.

I've got nothing against any of them, I've used almost every major one in my jobs over the last few years. But I (and the person who replied to me) both seem to feel the same way, that in many cases just fetching in React, in the component, is all that is needed, let the Redux application deal with marshalling the resultant state (which it is very good at)

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

#386

Post by jonnycomputer » Tue, Jul 23, 2019, 1:57 PM UTC

TylerE wrote: post #345

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!

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…

I'm guessing this is because some people only think of python as being a prototyping language, for performance reasons.

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

#387

Post by eeeeeeeeeeeee » Tue, Jul 23, 2019, 2:01 PM UTC

mtarnovan wrote: post #9

How about a native client? I think it's safe to assume that Slack has the resources for this.

Why would they do it? I want a native Slack app, but they have no incentive to do so. Look at where Slack has grown with their current app and ecosystem. I’ve never heard a single company say they’re moving to Microsoft chat because of Electron, or going back to IRC.

It seems Slack has addressed the major issue with their current app with this rewrite — multiple workspaces.

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

#388

Post by eeeeeeeeeeeee » Tue, Jul 23, 2019, 2:07 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.

I like threads. Especially in busy rooms, or where you need a quick diversion of a topic that only affects some of the participants in the room.

I use it for incident updates internally too so the discussion is grouped. Much easier than paging through the channel.

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

#389

Post by phponpcp » Tue, Jul 23, 2019, 4:14 PM UTC

jrockway wrote: post #204

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.

Low end desktops come with a gig of RAM. A $35 Raspberry Pi is what "low end" really is. While 250MB is a big chunk... I think it's actually okay, even in this extreme case.

The new RPi has like 4gb of RAM tho

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

#390

Post by vonseel » Tue, Jul 23, 2019, 4:26 PM UTC

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

My only request for redux-starter-kit is more documentation on usage with TypeScript (and perhaps deeper integration with ts-not sure how well the current package integrates with a ts codebase).