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

391–400 of 408 posts

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

#391

Post by y4mi »

cs02rm0 wrote: post #367
TylerE wrote: post #345

Earlier quoted context omitted.

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?

It wouldve been Java 5.

do you actually know what that would mean?

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

#392

Post by pmarreck »

dang wrote: post #241
pmarreck wrote: post #71

Earlier quoted context omitted.

can't comment on the original comment you made here https://news.ycombinator.com/item?id=20500181 because it's now flagged, so commenting here to state: There is a deafening irony in deplatforming a post arguing against deplatforming as a valid tactic. I hope it is not lost on the HN mods. ;)

Bringing ideological battle into completely unrelated threads is definitely not ok. Please don't do this again. We want less ideological battle on HN, not more. https://news.ycombinator.com/newsguidelines.html

It's not an "ideological battle" if it's empirical (based on evidence and rational discourse).

The only "ideological battles" are religious in nature. I'm fine with keeping religion off HN, but you can't just call a contentious topic "ideological", especially if there is evidence and/or rational debate to be had. The fact that an insufficient number of people opt-in to discussing some topic in that way does not make it "ideological". Would you also consider conversation about climate change "ideological" and thus unworthy of HN?

In any event, the original post (interestingly) got unflagged, so this was superfluous anyway.

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

#393

Post by nik736 »

_bxg1 wrote: post #102
nik736 wrote: post #98

So for people who only use one team nothing has changed?

They also reworked their whole codebase to use React instead of jQuery, among other things. Please read the article before commenting.

I read the article, but for me as a user it doesn't matter at all if the client is written in jQuery, plain javascript, React or some new shiny framework. Memory usage seems to be the same, as long as I don't feel any performance difference nothing has changed.

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

#394

Post by BerislavLopac »

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

I prefer the concept of Trigger's broom. ;)

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

#395

Post by _bxg1 »

nik736 wrote: post #393
_bxg1 wrote: post #102

Earlier quoted context omitted.

They also reworked their whole codebase to use React instead of jQuery, among other things. Please read the article before commenting.

I read the article, but for me as a user it doesn't matter at all if the client is written in jQuery, plain javascript, React or some new shiny framework. Memory usage seems to be the same, as long as I don't feel any performance difference nothing has changed.

They also talked about a different loading strategy which will gradually request content as needed instead of doing it all up-front, dramatically decreasing time-to-first-interaction.

And code quality has a huge impact on user experience in the long run. Writing it off as a non-factor is laughably ignorant.

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

#396

Post by mcguire »

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.

How stable has Python (and its ecosystem) been over that time?

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

#397

Post by acemarke »

vonseel wrote: post #390
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).

RSK should be fairly usable with TS. As I understand it, it can't be as magically strict as `typesafe-actions` is or infer quite as much automatically, because of how we're generating the action types from the reducer names as strings. But, it should definitely generate correctly typed action creator functions for you.

And yes, agree on needing more documentation:

https://github.com/reduxjs/redux-starter-kit/issues/59

I've got an example app I put together using RSK, our new React-Redux hooks, and TS, and I'm planning to turn that into a tutorial soon:

https://github.com/markerikson/rsk-github-issues-experiment

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

#398

Post by kochthesecond »

RobertKerans wrote: post #385
cozuya wrote: post #384

Earlier quoted context omitted.

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…

I have preferred this method myself when dealing with simple calls (calls that need no further external information). jumping through 7 files just to find the API request that gets shipped is slightly insane.

but how do you put the result back in the store? how about displaying a default failure screen?

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

#399

Post by floatingatoll »

bhl wrote: post #301
floatingatoll wrote: post #263

Earlier quoted context omitted.

I checked in Firefox and a given Slack uses 200+MB at load and then optimizes down to 140MB at runtime for a given Slack, of which ~60MB is JavaScript and ~80MB is page elements. So if those numbers carry over to Electron-Chromium, then it's 100MB of "I'm a browser" and 140MB of "I'm a webpage full of dynamic and objects". They certainly will not carry over precisely equally, but it puts some scope on it to consider.…

Why does slack and gmail use so much memory? It feels like it shouldn’t be an intensive process to display messages. Sidenote I don’t have much front end development besides basic web pages.

You can browse their memory usage in rather explicit detail about Firefox about:memory, but that assumes a rather high level of preexisting knowledge.

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

#400

Post by therealdrag0 »

_verandaguy wrote: post #129
matchbok wrote: post #48

Earlier quoted context omitted.

And yet, the performance is still bad. And that is only 1 of many reasons why electron is bad.

A hundred times this; 500-1000mb of idle memory usage by a chat client is patently silly.

Sure, but on my MBP it's never been a problem. I've never had slack lag regularly or notice it impacting other programs. :shrug:
Post reply on HN