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.

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

Here's a simple comparison using nativefier (electron based single-site-browsers) vs something using WKWebView:

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

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.

calm down friend

No personal swipes on HN, please.