4 ms·

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.
mikewhy 8y ago
Here's a simple comparison using nativefier (electron based single-site-browsers) vs something using WKWebView: https://imgur.com/oG2Dm5y https://imgur.com/oG2Dm5y Both are playing low-quality HTML5 video. For any sites I could think of, the memory usage, thread count, CPU time, and idle wake ups were considerably smaller using WKWebView. The disk usage was also crazy smaller, as is expected. ~122MB for nativefier vs ~14MB for WKWebView (and a lot of that is due to being written in Swift).

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.

mikewhy 8y ago

Here's a simple comparison using nativefier (electron based single-site-browsers) vs something using WKWebView: https://imgur.com/oG2Dm5y https://imgur.com/oG2Dm5y Both are playing low-quality HTML5 video. For any sites I could think of, the memory usage, thread count, CPU time, and idle wake ups were considerably smaller using WKWebView. The disk usage was also crazy smaller, as is expected. ~122MB for nativefier vs ~14MB for WKWebView (and a lot of that is due to being written in Swift).