Hacker News Reader

Comment by royjacobs | Hacker News Reader

So, on the one hand we've had this discussion here a ton of times: People are using Electron because it means faster shipping, easier cross-platform development, and so on. But on the other hand, the amount of hackery in Slack[1] that needs to happen just to get a level of performance and memory usage that comes within the ballpark of a native application is so high that it begs the question: At what point does the amount of work needed to get basic levels of performance negate the initial gains of building the application using a tool like Electron?

I'm not trying to troll and say "Electron bad" btw, I'm genuinely curious.

[1] See also: Optimizing VSCode, for instance: https://code.visualstudio.com/blogs/2018/03/23/text-buffer-r...

View on HN

Albeit there are most likely a lot of "hackery" needed due to using Electron/web tech to get the optimal performance, this article is about architecture and how they originally did not build an architecture to support this and how they now needed to re-think that in order to get the startup performance they now desire - a situation you probably (likely?) could end up in using other technologies than Electron/web.

The high velocity web tech landscape and a startup (velocity) mentality are more likely the reasons why this was not made originally (most likely a good trade off, in particular the startup velocity argument). I'm a little surprised a community like HN don't see this, and rather bash Electron being the devil of all things (as some comments seem to imply). We should rather commend Slack for (obviously) making a decent tech choice (using a perspective where what really matters to them; rapid growth, is/was the first priority above all else, including "technical excellence").

It seems to me that the reason this architecture is needed is because the original choice of technology necessitates it.

I mean, it's not that a C++ application wouldn't need a rearchitecting for startup performance, but it would likely not be needed for an application as simple as Slack.

I’m curious: why would you consider Slack to be “simple”?

I see Slack as an incredibly full-featured app. As always, many people might not use all the features, but that doesn't mean that nobody does…

I'm comparing it to applications that may have somewhat more reasons for slow startup times, like mentioned below in the thread (think: Photoshop, Maya, Unreal Engine, etc). Not a chat application.

I'm not saying Slack is not full-featured, but it's definitely not on the same scale as some of these other applications.

Maybe, but I would actually argue with the assumption that an image editor is somehow inherently (allowed to be) “more complicated and/or slow” than a productivity app.

Or, more simply: Slack (and other similar products) are not just “chat applications”.

No, they're certainly not just chat applications, but if you think that Photoshop is an image editor that is somehow at the same level of complexity as Slack I'm not sure what to tell you. We'll have to agree to disagree!

Because very very little happens in the client itself. Basically any button that does something is just an api call out to their servers and an update to the view. You can see this yourself when you're working on a higher-latency network connection -- damn near every click gets you a spinner or a pause of some sort before things happen.

>rapid growth, is/was the first priority above all else, including "technical excellence"

That's the modus operandi of many unpleasant things like bacteria or cancer cells, why should it be commendable on its own?

One possibility is that the timing is usefully different with Electron - the products were out and getting traction (and presumably in Slack's case revenue) long before the performance hacks were conjured.

I don't know if the total amount of work over time sums to approach that of a portfolio of native apps, but even if that's the case, there's a world of difference between spending extra time improving a product that's already out in the world and developing the first cut.

Reply on news.ycombinator.com