[whywhywhywhy]

It makes perfect sense for the user but developers will always argue for Electron so that they only have to test one browser engine.

I can’t even gets web devs to test on anything but Chrome and when something they code does break I have to listen to the Safari whine even though they all use iPhones so are part of the reason it’s relevant. Dread to think how an argument for supporting 3+ web engines for a “native” app would go.

[criddell]

A lot of developers are not fans of Electron. Generally, it's a quality vs quantity tradeoff. Are you willing to make a crappier thing if it means more people can use it?

For companies like Microsoft making something like Teams, I think it sucks. They have the resources to make native apps and when you have tens of millions of users, adding support for another platform would cost them pennies per user.

[com2kid]

> For companies like Microsoft making something like Teams, I think it sucks. They have the resources to make native apps and when you have tens of millions of users, adding support for another platform would cost them pennies per user.

Back when I worked at Microsoft, 2014 or so, we had serious problems finding Win32 developers. We essentially had to train people up. While I am sure the Windows org had lots of them, put out a job req and even internally not very many people are going to have native Windows development on their resume.

Nearly had to draw straws to see who had to get "stuck" learning Windows stuff.

I imagine native MacOS developers are similarly rare as a % of the overall developer pool.

Android and iPhone developers, easy peasy.

Likewise, Web developers, not a problem.

The other thing is, Electron has tons of momentum behind it, which means more and more people jump onboard to learn it, which makes hiring easy. Tutorials and learning resources get made, making developing for it even easier.

IIRC we ended up dropping the native C++ Windows app and just used C# and one of the UI toolkits, I forget which one.

[vxNsr]

> Back when I worked at Microsoft, 2014 or so, we had serious problems finding Win32 developers. We essentially had to train people up.

Microsoft only has itself to blame for this. They charge an arm and a leg for their dev environment setting it up is a pain no matter what, the stuff you get “free” when you pay for the dev environment is not nearly enough to create anything worthwhile. So why should any CS department bother with win32 circa 2005. As much as Balmer liked to chant about the importance of developers he sure liked to milk them dry.

[com2kid]

For decades MS had the best development environments, best training, and best documentation.

MS fucked it up with the wpf->silver light->winrt transitions.

Win32 is a horrible API but it was stable and there was a time Win32 developers were everywhere.

Visual Studio is still one of the best real IDEs out there. The tooling for modern languages is a sad joke compared to what we had in 2005. And modern documentation is so bad it is absurd. People don't realize how much $$$ MS used to spend on sample code (MSDN samples were large fleshed out sample products!) and on documentation teams.

Comparison point, last time I tried to use Google cloud, I had to use the way back machine to look at an old version of the docs because the embedded sample code had gotten broken during an update 2 years prior and no one ever fixed it.

[pjmlp]

You forgot another two major fuck ups, killing .NET Native and C++/CX, without a proper migration path to a GUI framewokr that is anyway WIP and will take a couple of years to even reach some kind of parity with WPF.

I still mostly use Microsoft technologies, but that was a big middle finger to everyone that was willing to go through all WinRT rewrites since Windows 8, advocating for the technology.

[Falkon1313]

It may be more the myriad of technologies and the fact that they change them out almost as often as their underwear. Same problem we have with javascript frameworks.

What is it that we need 10 years experience in this week? Win32, OCX, DCOM, CORBA, OWL, ActiveX, WinForms, WPF, ASP, SliverLight, .Net, XNA (etc. etc.)?

Kind of amusing that so many people turned to web tech to escape that treadmill and then just totally recreated it in javascript.

[vxNsr]

> OCX, DCOM, CORBA, OWL,

I didn't even know these existed.

[bluedino]

>> I imagine native MacOS developers are similarly rare as a % of the overall developer pool

Which is a shame, because as bad as Xcode is, developing native apps on the Mac is almost pleasurable compared to Windows or Linux

[pjmlp]

When WinDev keeps pushing for stuff like COM, with tooling that already felt primitive when Visual C++ 6.0 was around, it is no wonder that they have such hard times.

Eventually even those of us that know Win32 quite well don't want to deal with it.

[kitsunesoba]

What seems even crazier is not even wanting to test against different builds of Chromium to help keep pace with Electron updates. At that point isn't one's code just too brittle?

[WA]

> Dread to think how an argument for supporting 3+ web engines for a “native” app would go.

Well, on mobile, it's slightly different. If you use Capacitor, it uses the OS' native WebView, which is either Chrome (Android) or Safari (iOS). You gotta test for two web engines, but fortunately, they're relatively close.

I think a solution like this for desktop would make sense. Modern browser engines don't have that many differences and it would make the runtime a lot smaller (thin wrapper around the already installed browser engine).

Sure, it has its downsides, but mobile apps have been written like that forever (via PhoneGap before and now Capacitor) and have come a long way since.

[whywhywhywhy]

>but fortunately, they're relatively close.

I mean I wish I worked with people with that opinion but somehow the 60+ devs I've worked with over the past 5 years manage to code things that work in Chrome but with many parts broken in Safari and an attitude that it's Safari's fault.

I have little patience for this attitude because the period of time I worked as a dev I had to support IE5.5, IE6, IE7, Safari, Firefox and Chrome. But it is the prevailing attitude.