[coldtea]

>250mb of RAM for a chat app that can display 4k assets, renders every known written language under the sun side-by-side in multiple fonts, supports a stupid number of emoji, has an inline image viewer, realtime sockets kept open for notifications, includes syntax highlighting for a bunch of languages, a wysiwyg-ish editor for posts, one-on-one audio chat, and can work effortlessly with hundreds of people in a single channel

Not of what you wrote is even remotely difficult to be achieved, even in a 50MB-using native app.

In fact most of those things come for free with the OS and relevant native libs are already loaded into memory:

"renders every known written language under the sun side-by-side in multiple fonts", "supports a stupid number of emoji" (the OS font-renderer can give all that to all apps for nearly free)

"can display 4k assets", "has an inline image viewer" (I can do that in a trivial app that's 1MB or less).

"includes syntax highlighting for a bunch of languages" ...

Really, none of these features, and neither all of them combined, warrant 250mb of RAM.

[Klathmon]

But again, would it really make any significant difference in the vast majority of users?

If slack had taken the time to devote another team to developing another application (because they still need to support the web), possibly multiple applications for each platform, would they be where they are today?

Would that time and money pay off in any way? I really believe it wouldn't. To save a few hundred mb of RAM, you are looking at triple or quadruple your development and maintenance costs, not to mention making it that much more costly to add new features. That doesn't seem like a good payoff.

Obviously in places where it did make a difference (mobile platforms) they went completely native, and it shows in both the positive and the negative. Their mobile apps look and feel native, and work quite well, but they lag behind the "web based" clients in features. (most notably the new voice chat options are not in the mobile versions)

In a perfect world every application would be custom developed for each and every platform, and no expense would be paid to ensure that there are 0 wasted resources, but we are far from a perfect world.

Having a slack app that runs on any desktop platform, feels the same between all of them, and allows Slack as a company to exist is a win in my book, even if it uses a few hundred mb more than it should (which again, for me it only uses 100mb of ram, that's 1/320th of my total ram on this machine, and only like 40mb more than the tab that i'm writing this comment on is taking).

[coldtea]

>Would that time and money pay off in any way? I really believe it wouldn't. To save a few hundred mb of RAM, you are looking at triple or quadruple your development and maintenance costs, not to mention making it that much more costly to add new features. That doesn't seem like a good payoff.

I don't think writing native apps is so much more difficult that a web app like Slack. If anything, it's probably the opposite.

There are cross-platform (native) apps with custom UIs, like DAWs and NLEs that are an order of magnitude more complex in both their UI and their logic code, and yet are done with teams and by companies that have an order of magnitude less funding than a company like Slack.

[Klathmon]

It might not be more difficult, hell it is probably easier for each individual platform, but even if each one is 20% quicker than a web based one, all together you would end up spending 240% as much.

Plus then there is ongoing maintence costs, probably a ton more documentation costs (unless they all look and act the same), more coordination needed with new features to ensure parity, and more bugs and security issue surface area.

That's not a trade-off I'd want to make unless it was required for some other reasons.

[ralmeida]

I'm not particularly familiar with the relative costs of native vs Electron, but it should be noted that: a) many DAWs are single-platform; b) DAWs don't have backends, which is at least a significant portion (if not the majority) of what a service like Spotify or Slack spends development time on.