11 ms·

This is literally what Slack moved from years ago, because it was very problematic, let me tell you why since I'm the one who did it. * Adding new APIs was a h

This is literally what Slack moved from years ago, because it was very problematic, let me tell you why since I'm the one who did it. * Adding new APIs was a huge pain in the ass, you had to write all of this ugly bridge code in Objective C, and the APIs ended up being super unnatural on the JS side. As a result, desktop integration wasn't done much since it felt like a "Black Magic" type thing. Writing new APIs in Electron is Just JavaScript, so you can make something much more natural. * We could literally do fuck-all for people running old versions of macOS - you can't upgrade Safari on old machines, you just Get What You Get. For awhile, every YouTube video on older macOS versions had a pink shade to it. Users write in, "This is clearly wrong!" "Yep, but we can't fix it. Sorry." * And big spoiler - WKWebView uses _basically_ the same amount of memory give-or-take a few MBs as Chromium. It's the content that sets the memory usage bar, not the host.

saagarjha 8y ago
> WKWebView uses _basically_ the same amount of memory give-or-take a few MBs as Chromium It really doesn’t. A “Hello, World” WKWebView is a couple of megabytes. The same in an Electron app is hundreds of megabytes.
- xpaulbettsx 8y ago
  This is a useless comparison. Once you're hosting an actual app, the content matters way more.
  - saagarjha 8y ago
    Messages uses webviews and manages to do much of what Slack does with a tenth of the memory footprint. I still have not found any evidence for your claim that Electron and WKWebView use the same amount of memory.
    - xpaulbettsx 8y ago
      You're literally comparing two completely different apps. If you want to compare Apples to Apples, host 5 teams in Slack, in both Chromium and WKWebView
      - ptx 8y ago
        What if I only have one team and a handful of channels, though? In that case I prefer starting with a lower constant memory overhead.
      - nvr219 8y ago
        calm down friend
        dang 8y ago
        No personal swipes on HN, please.
      - _wmd 8y ago
        There is of course value in comparing Messages-the-HTML-app to Slack-the-HTML-app. If they can do it in a fraction of the memory with comparable functionality, I wonder why Slack can't
      - saagarjha 8y ago
        Unfortunately, I’m in a place where I can test your argument, so the best evidence I can give you is the personal anecdote that I run Slack in Safari rather than using the Electron app for performance reasons. It’s not quite WKWebView, but I think it’s a relatively decent approximation. With that said, I still think you’re missing the point: it’s completely possible to make a messaging app that uses significantly less memory than Slack does and does basically the same things, even if you ditch native controls (which is not something I prefer people do, for reasons other than performance, but it’s something I am willing to tolerate). Loading an entire browser with its associated baggage rather than using the platform’s native web view will almost always use more resources, because you will have bloat that is not necessary for what you are doing and some features will end up being reimplemented in Electron. Just because Slack might perform poorly in both a web view and Electron (which I still believe is not equally poorly), does not mean that it could not perform well at all. There are multiple issues here.
  - giornogiovanna 8y ago
    Even if memory usage is the same, there's a world of a difference when it comes to executable size, and for most Electron apps, I doubt the content will outweigh the runtime.
    - xpaulbettsx 8y ago
      I don't find disk space worth optimizing for in 2018. For $2 you can buy a USB Thumbdrive that will hold every Electron app you'll ever use.
      - yladiz 8y ago
        It's opinions like this that cause first day downloads for new games like Red Dead Redemption 2 to be 55GBs. In the case of an Electron app disk space might not matter as much, but it's absolutely worth optimizing in 2018, at least because not everyone has high speed connections (e.g. in Germany, a lot of infrastructure is built around DSL, which obviously doesn't get great speeds).
        ianhawes 8y ago
        You’re comparing apples to oranges. 3D models vs. app code. You will be hard pressed to find any Electron app that exceeds 200 MB in disk space. Most are ~50 MB. Overall in 2018 that is not a big concern. In gaming, high definition graphics are going to result in massively larger files. That’s not going to change anytime soon and no gaming company will prioritize a small download over better graphics.
        yladiz 8y ago
        Yes I know, and the size of an Electron app versus a AAA game is sometimes 3 orders of magnitude in difference, which is why I pointed out that even a "small" app that's 100MB is still a lot to download on a limited speed connection.
        josephg 8y ago
        > You will be hard pressed to find any Electron app that exceeds 200 MB in disk space. Most are ~50 MB. Huh? Looking at my applications folder right now: Atom 1.31: 822mb Daedalus 0.8: 265mb Mist 0.9.2: 186mb Neon 0.0.7: 180mb Patchwork: 185mb Riot 0.11.4: 160mb VS Code: 193mb The electron framework alone is 117mb on MacOS. Honestly, how many copies of that do I need?
  - ynniv 8y ago
    There is a long history of sophisticated applications being written in less than a hundred megabytes, so where's the budget going? Hero images?
  - will4274 8y ago
    You made the original claim. Do you have any data to back it up?
mehrdadn 8y ago
Edit: Never mind, I misunderstood.
- etaoins 8y ago
  This quote was inside a list of negative experiences with WKWebView. It wasn’t intended to be positive.
  - mehrdadn 8y ago
    Huh, I think I got confused when reading it, thanks.
perfmode 8y ago
For what it’s worth, all of the arguments against your choices are inadequate and don’t really wrestle with the complexity of the domain. And I suspect the authors are not considering this as though they’d be the one responsible for making these decisions for a company like Slack themselves.
- saagarjha 8y ago
  Fun fact: Slack has native iOS and Android apps, with all their platform-independent logic abstracted away in a C++ library. I see no “complexity” in making a native macOS app with this.
  - jf- 8y ago
    From a cost-benefit point of view there’s nothing in it for slack. They’d have to rewrite and maintain three separate versions of the same app they already have, and what would the payoff be? It would mildly please a handful of bellyachers, who would then immediately move on to the next grievance. For the majority of users it would be wasted money and effort.
    - apple4ever 8y ago
      There sure is. They've have an app that doesn't suck for one. Which you know, would help conversions. Its not hard to write a Mac app, and its even easier to maintain it. ESPECIALLY if you already have an iOS app. There is no reason not to just make a decent Mac app. NONE.
      - jf- 8y ago
        Using caps isn’t a substitute for having a point, nor is it a refutation of the effort involved to make three separate native apps instead of one. Also you’re not supposed to use caps here. I don’t think it sucks, most users don’t think it sucks. You represent a tiny, vocal minority.
    - saagarjha 8y ago
briandear 8y ago
Why doesn’t Slack write an actual Mac app in Swift? For small companies with limited resources, I understand the attraction of “cross platform,” but it would seem that performance and uasability would be vastly improved by writing actual native applications — especially for a billion dollar company that can afford to do it and especially since Slack is one of those apps that is constantly open and performance and efficiency have a real benefit.
- TeMPOraL 8y ago
  They've cornered the market and don't have to care anymore. A lot of Slack's audience is captive - employees, contributors to open source projects that chose Slack as their social outlet, etc.
  - Despegar 8y ago
    The only way this will change is if Apple starts using more "stick" approaches. Marzipan and whatever other technologies they're working on are the "carrot".
- eschaton 8y ago
  Amen. “Cross-platform UI” has always meant “doesn’t work well.”
- jtd514 8y ago
  Yeah at this point they are basically jerks for not building something better. The reality is they dont have to care.
- ksec 8y ago
  Telegram, an Open Sources IM, has Native Clients on Mac, iOS, Windows, and Android.
pducks32 8y ago
...ugly bridging code in Objective-C. I have had a similar issue getting the Unity team at work to use native plugins but they’re inability to be comfortable with C++ is not an issue with the platform but with the programmer. Moreover, the ugliness of the code is definitely a quality of the programmer!
foobarbazetc 8y ago
We did this too, so many reasons. Lots of bugs, no printer support without using private APIs, etc etc. It’s really not an option. That and you have to rebuild everything for Win/Linux builds. Just makes no sense. Also you can’t ship your own updated WKWebView.
giobox 8y ago
It also removes pretty much the only reason to use Electron despite its shortcomings - the ability to ship and run the same code on multiple platforms. Secondly, you lose control of your application runtime environment version - need a new WKWebView version to ship a feature? Time to tell your customers to upgrade the app and their OS. I’d maybe consider this to cheaply ship a feature inside a Mac app, but this really isn’t an option for like 99% of dev teams considering Electron.
- vbezhenar 8y ago
  It’s not the only reason. First of all: you can use JS and HTML with all frameworks. Some people consider it a superior solution for GUI. Second: you can easily upgrade your app on iOS without moderation.
vijaybritto 8y ago
Do you all have any plans to test out flutter with desktop embeddings? I see that the productivity is as fast as javascript based stack. Flutter desktop seems to be consuming way less RAM than an electron app. Is there any POC ongoing at slack?

saagarjha 8y ago

> WKWebView uses _basically_ the same amount of memory give-or-take a few MBs as Chromium It really doesn’t. A “Hello, World” WKWebView is a couple of megabytes. The same in an Electron app is hundreds of megabytes.

xpaulbettsx 8y ago
This is a useless comparison. Once you're hosting an actual app, the content matters way more.
- saagarjha 8y ago
  Messages uses webviews and manages to do much of what Slack does with a tenth of the memory footprint. I still have not found any evidence for your claim that Electron and WKWebView use the same amount of memory.
  - xpaulbettsx 8y ago
    You're literally comparing two completely different apps. If you want to compare Apples to Apples, host 5 teams in Slack, in both Chromium and WKWebView
    - ptx 8y ago
      What if I only have one team and a handful of channels, though? In that case I prefer starting with a lower constant memory overhead.
    - nvr219 8y ago
      calm down friend
      - dang 8y ago
        No personal swipes on HN, please.
    - _wmd 8y ago
      There is of course value in comparing Messages-the-HTML-app to Slack-the-HTML-app. If they can do it in a fraction of the memory with comparable functionality, I wonder why Slack can't
    - saagarjha 8y ago
      Unfortunately, I’m in a place where I can test your argument, so the best evidence I can give you is the personal anecdote that I run Slack in Safari rather than using the Electron app for performance reasons. It’s not quite WKWebView, but I think it’s a relatively decent approximation. With that said, I still think you’re missing the point: it’s completely possible to make a messaging app that uses significantly less memory than Slack does and does basically the same things, even if you ditch native controls (which is not something I prefer people do, for reasons other than performance, but it’s something I am willing to tolerate). Loading an entire browser with its associated baggage rather than using the platform’s native web view will almost always use more resources, because you will have bloat that is not necessary for what you are doing and some features will end up being reimplemented in Electron. Just because Slack might perform poorly in both a web view and Electron (which I still believe is not equally poorly), does not mean that it could not perform well at all. There are multiple issues here.
- giornogiovanna 8y ago
  Even if memory usage is the same, there's a world of a difference when it comes to executable size, and for most Electron apps, I doubt the content will outweigh the runtime.
  - xpaulbettsx 8y ago
    I don't find disk space worth optimizing for in 2018. For $2 you can buy a USB Thumbdrive that will hold every Electron app you'll ever use.
    - yladiz 8y ago
      It's opinions like this that cause first day downloads for new games like Red Dead Redemption 2 to be 55GBs. In the case of an Electron app disk space might not matter as much, but it's absolutely worth optimizing in 2018, at least because not everyone has high speed connections (e.g. in Germany, a lot of infrastructure is built around DSL, which obviously doesn't get great speeds).
      - ianhawes 8y ago
        You’re comparing apples to oranges. 3D models vs. app code. You will be hard pressed to find any Electron app that exceeds 200 MB in disk space. Most are ~50 MB. Overall in 2018 that is not a big concern. In gaming, high definition graphics are going to result in massively larger files. That’s not going to change anytime soon and no gaming company will prioritize a small download over better graphics.
        yladiz 8y ago
        Yes I know, and the size of an Electron app versus a AAA game is sometimes 3 orders of magnitude in difference, which is why I pointed out that even a "small" app that's 100MB is still a lot to download on a limited speed connection.
        josephg 8y ago
        > You will be hard pressed to find any Electron app that exceeds 200 MB in disk space. Most are ~50 MB. Huh? Looking at my applications folder right now: Atom 1.31: 822mb Daedalus 0.8: 265mb Mist 0.9.2: 186mb Neon 0.0.7: 180mb Patchwork: 185mb Riot 0.11.4: 160mb VS Code: 193mb The electron framework alone is 117mb on MacOS. Honestly, how many copies of that do I need?
- ynniv 8y ago
  There is a long history of sophisticated applications being written in less than a hundred megabytes, so where's the budget going? Hero images?
- will4274 8y ago
  You made the original claim. Do you have any data to back it up?

mehrdadn 8y ago

Edit: Never mind, I misunderstood.

etaoins 8y ago
This quote was inside a list of negative experiences with WKWebView. It wasn’t intended to be positive.
- mehrdadn 8y ago
  Huh, I think I got confused when reading it, thanks.

perfmode 8y ago

For what it’s worth, all of the arguments against your choices are inadequate and don’t really wrestle with the complexity of the domain. And I suspect the authors are not considering this as though they’d be the one responsible for making these decisions for a company like Slack themselves.

saagarjha 8y ago
Fun fact: Slack has native iOS and Android apps, with all their platform-independent logic abstracted away in a C++ library. I see no “complexity” in making a native macOS app with this.
- jf- 8y ago
  From a cost-benefit point of view there’s nothing in it for slack. They’d have to rewrite and maintain three separate versions of the same app they already have, and what would the payoff be? It would mildly please a handful of bellyachers, who would then immediately move on to the next grievance. For the majority of users it would be wasted money and effort.
  - apple4ever 8y ago
    There sure is. They've have an app that doesn't suck for one. Which you know, would help conversions. Its not hard to write a Mac app, and its even easier to maintain it. ESPECIALLY if you already have an iOS app. There is no reason not to just make a decent Mac app. NONE.
    - jf- 8y ago
      Using caps isn’t a substitute for having a point, nor is it a refutation of the effort involved to make three separate native apps instead of one. Also you’re not supposed to use caps here. I don’t think it sucks, most users don’t think it sucks. You represent a tiny, vocal minority.
  - saagarjha 8y ago

briandear 8y ago

Why doesn’t Slack write an actual Mac app in Swift? For small companies with limited resources, I understand the attraction of “cross platform,” but it would seem that performance and uasability would be vastly improved by writing actual native applications — especially for a billion dollar company that can afford to do it and especially since Slack is one of those apps that is constantly open and performance and efficiency have a real benefit.

TeMPOraL 8y ago
They've cornered the market and don't have to care anymore. A lot of Slack's audience is captive - employees, contributors to open source projects that chose Slack as their social outlet, etc.
- Despegar 8y ago
  The only way this will change is if Apple starts using more "stick" approaches. Marzipan and whatever other technologies they're working on are the "carrot".
eschaton 8y ago
Amen. “Cross-platform UI” has always meant “doesn’t work well.”
jtd514 8y ago
Yeah at this point they are basically jerks for not building something better. The reality is they dont have to care.
ksec 8y ago
Telegram, an Open Sources IM, has Native Clients on Mac, iOS, Windows, and Android.

pducks32 8y ago

...ugly bridging code in Objective-C. I have had a similar issue getting the Unity team at work to use native plugins but they’re inability to be comfortable with C++ is not an issue with the platform but with the programmer. Moreover, the ugliness of the code is definitely a quality of the programmer!

foobarbazetc 8y ago

We did this too, so many reasons. Lots of bugs, no printer support without using private APIs, etc etc. It’s really not an option. That and you have to rebuild everything for Win/Linux builds. Just makes no sense. Also you can’t ship your own updated WKWebView.

giobox 8y ago

It also removes pretty much the only reason to use Electron despite its shortcomings - the ability to ship and run the same code on multiple platforms. Secondly, you lose control of your application runtime environment version - need a new WKWebView version to ship a feature? Time to tell your customers to upgrade the app and their OS. I’d maybe consider this to cheaply ship a feature inside a Mac app, but this really isn’t an option for like 99% of dev teams considering Electron.

vbezhenar 8y ago
It’s not the only reason. First of all: you can use JS and HTML with all frameworks. Some people consider it a superior solution for GUI. Second: you can easily upgrade your app on iOS without moderation.

vijaybritto 8y ago

Do you all have any plans to test out flutter with desktop embeddings? I see that the productivity is as fast as javascript based stack. Flutter desktop seems to be consuming way less RAM than an electron app. Is there any POC ongoing at slack?