4 ms·

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

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-reimplementation https://code.visualstudio.com/blogs/2018/03/23/text-buffer-r...

crispinb 7y ago
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.
cjblomqvist 7y ago
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").
- royjacobs 7y ago
  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.
  - jlmb 7y ago
    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…
    - royjacobs 7y ago
      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.
      - jlmb 7y ago
        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”.
        royjacobs 7y ago
        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!
    - parliament32 7y ago
      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.

crispinb 7y ago

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.

cjblomqvist 7y ago

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

royjacobs 7y ago
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.
- jlmb 7y ago
  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…
  - royjacobs 7y ago
    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.
    - jlmb 7y ago
      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”.
      - royjacobs 7y ago
        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!
  - parliament32 7y ago
    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.