News for hackers. Stuff that matters.

A comment on Reducing Slack’s memory footprint.

Re:Reducing Slack’s memory footprint by mdekkers on Saturday March 04, 2017 @04:38AM (#13790137)
why not use the right tool for the job instead of doing Olympic-level gymnastics to use a hammer as a screwdriver?
[ Parent | on HN ]
Re:Reducing Slack’s memory footprint by jjnoakes on Saturday March 04, 2017 @09:32AM (#13791020)
Because it is faster and cheaper to get a junior JavaScript developer to bang out a cross platform GUI in electron than it is to get one or more developers together to write a proper cross-platform native application.

They cared more about cost and time to market than performance and technical prowess, and in a business context, that is often a correct trade-off.

I don't like it because I prefer small fast clean applications, but I know I'm in the minority and I accept that that's how the business world works.

[ Parent | on HN ]
Re:Reducing Slack’s memory footprint by mdekkers on Saturday March 04, 2017 @11:15AM (#13791474)
They cared more about cost and time to market than performance and technical prowess, and in a business context, that is often a correct trade-off.

Cool when you are starting up and all, but surely they must have a bit more money now, and would be able to do it right?

[ Parent | on HN ]
Re:Reducing Slack’s memory footprint by nemothekid on Saturday March 04, 2017 @12:12PM (#13791785)
When Facebook was hitting performance issues with PHP, they decided to rewrite the entire runtime instead of rewriting in a different language.

If Facebook with its billions decided it was cheaper to rewrite PHP, the cost/benefit analysis must favor optimizing current code than doing a rewrite

[ Parent | on HN ]
Re:Reducing Slack’s memory footprint by mdekkers on Saturday March 04, 2017 @12:43PM (#13791941)
Facebook is Facebook. Slack isn't Facebook, and neither is every other business besides Facebook Facebook decided to rewrite PHP because the CBA worked out for Facebook - that doesn't mean the argument holds true by default for any other situation.
[ Parent | on HN ]
Re:Reducing Slack’s memory footprint by jjnoakes on Saturday March 04, 2017 @11:36AM (#13791571)
But why spend the money to do it from scratch when you can spend less focusing on the pain points?

If your users pay you either way, the cheaper option (from a business point of view) is better.

[ Parent | on HN ]
Re:Reducing Slack’s memory footprint by coldtea on Saturday March 04, 2017 @05:56AM (#13790330)
Because Electron (or whatever they use) is web-scale.
[ Parent | on HN ]
Re:Reducing Slack’s memory footprint by mdekkers on Saturday March 04, 2017 @11:14AM (#13791472)
Because Electron (or whatever they use) is web-scale.

Web-scale? What's web scale? why does my desktop client need to be "web-scale"?

[ Parent | on HN ]
Re:Reducing Slack’s memory footprint by coldtea on Saturday March 04, 2017 @11:57AM (#13791700)
Everything needs to be web-scale:

https://www.youtube.com/watch?v=b2F-DItXtZs

[ Parent | on HN ]
Re:Reducing Slack’s memory footprint by paulddraper on Saturday March 04, 2017 @06:08PM (#13793408)
/dev/null is web-scale

http://engineering.wayfair.com/2013/04/devnull-vs-mongodb-be...

[ Parent | on HN ]
Re:Reducing Slack’s memory footprint by mdekkers on Saturday March 04, 2017 @12:50PM (#13791977)
That's hilarious
[ Parent | on HN ]
Re:Reducing Slack’s memory footprint by thunder-ltu on Saturday March 04, 2017 @07:18AM (#13790576)
This.
[ Parent | on HN ]