Wouldn't the best solution be write it in C and have the entire app take 20MB of ram?

I think Slack is focusing on code reuse, eg. using the same HTML/CSS/JS codebase across all platforms - hence it would be preferrable to avoid having to compile for every platform.

I don't think compliation is the issue, it's supporting the diverse platform APIs and UI toolkits.

They use like 5 widgets (styled text, textfield, buttons, radios, etc). They could create their own UI toolkit with 1/10 the resources they have.

If this is true, then why are even bigger players with more resources like Facebook and Microsoft building on top of Electron instead of building natively?

I surmise that you are not alone in believing that Slack would be better built as a native app. But if it's such a bad direction why are so many going down this road and what are they missing?

>If this is true, then why are even bigger players with more resources like Facebook and Microsoft building on top of Electron instead of building natively?

Because software is a pop culture, and the latest fad always prevails at most shops. Also companies care more about cutting corners and shipping sooner than about the long haul.

That said, it's not like Facebook particularly enjoyed web based apps: "Mark Zuckerberg: Our Biggest Mistake Was Betting Too Much On HTML5"

https://techcrunch.com/2012/09/11/mark-zuckerberg-our-bigges...

The mistake there was one of timing and approach and they learned from it. The promise of cross-platform, web-based technology is still there, that's why they created React Native.

React Native is not web-based. It just uses Javascript.

The technology originated from web. It uses javascript, React, babel, flexbox, etc.

> ....Facebook and Microsoft building on top of Electron instead of building natively?

JavaScript devs are usually cheaper to hire than C++, Java, Objective-C, Swift, .NET ones.

I think VSCode by Microsoft is a good example of Electron done well.

In their case, I don't think it's because their web technology devs are cheaper. I wouldn't be surprised if that team knew multiple platforms and languages. I think it's all about finding the balance between dev costs, making a great product, and getting it out fast on multiple platforms.

On their case, they want to get a few notches up in the SV popchart culture, top of the pops.

Being cool in SV is only so valuable.

Apparently for the web dev generation, writing modular native code across OSes is a lost art, attained by us old druids not worth listening to.

Yeah, and it's especially puzzling since they've given up one of the major hassles of going natively cross-platform anyway: having to support a native look and feel.

Which makes creating a similar (uniform looking across platforms) native UI lib even easier than catering to the intricacies of each platform.

Yes, it is incredible the amount of gimmicks web devs do instead of using the right tools for native development.

Could you elaborate on what you think the elaborate on what the "right" tools would be?

Write in native languages, common to all platforms, using the OS specific APIs in each platform with the help on an abstraction layer.

Lets pick C++ as an example of native language.

Design the application architecture with the abstract ideas of what should be available across all platforms, but keeping in mind the native idioms.

For each of such concepts, provide an interface (pure abstract classes in C++ speak) with an implementation for each OS.

The actual cpp files are selected during the build process according to the OS being compiled, without any kind of #ifdefs.

Then showing a notification to the user using this architecture is as simple as.

    auto notification = NotificationService.instance();
    notification->show("New email available!");

Or opening a file, using the platform specific file dialogs:

    auto filePicker = Pickers.file_instance()
    auto filename = filePicker->open_file();

This are just two basic examples, the idea is not to replicate Qt, wxWidgets, JUCE,... rather pick just the concepts required for the application, not to build a full blown framework.

This is the approach taken by quite a few companies.

Of course, there is also the shortcut of using something like Qt, but then you need to live with the problem that the widgets aren't native, rather emulated.

On the other hand, still outperforms any browser based application.

The craziness with Electron based apps isn't nothing new to us oldies.

Since the early days of the web, OSes have supported web widgets like MSHTML on Windows, Windows packaged Web Applications introduced on Windows Active Desktop, Mozilla's XUL and many others.

They were never a match to native UI/UX.