4 ms·

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

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.

kitsunesoba 4y ago
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?
criddell 4y ago
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 4y ago
  > 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.
  - bluedino 4y ago
    >> 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
  - vxNsr 4y ago
    > 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.
    - Falkon1313 4y ago
      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 4y ago
        > OCX, DCOM, CORBA, OWL, I didn't even know these existed.
    - com2kid 4y ago
      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.
WA 4y ago
> 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 4y ago
  >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.

kitsunesoba 4y ago

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?

criddell 4y ago

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 4y ago
> 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.
- bluedino 4y ago
  >> 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
- vxNsr 4y ago
  > 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.
  - Falkon1313 4y ago
    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 4y ago
      > OCX, DCOM, CORBA, OWL, I didn't even know these existed.
  - com2kid 4y ago
    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.

WA 4y ago

> 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 4y ago
>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.