9 ms·

With all this Electron and PWA focused development a cannot shake a feeling that we add an extra layer of a "runtime" on top of an operating system, that could

With all this Electron and PWA focused development a cannot shake a feeling that we add an extra layer of a "runtime" on top of an operating system, that could be avoided. An extra layer which occupies RAM space and processor time which feels unnecessary but it is where we are headed. I wonder if the reason is simple, that we (myself included) have not provided anything better or the reason is that big corporations who control most of the market have pushed this technology forward. I hope we can learn from this and bring back some of this lost performance while keeping the productivity and security gains.

whywhywhywhy 4y ago
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.
- 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.
trap_goes_hot 4y ago
That ship seems to have sailed with the (over?)use of VMs a long time ago.
gw99 4y ago
This. I encountered hell the other day. I saw a corporate Citrix deployment that had 45 users running three electron apps on an underprovisioned server with the CPU, disk and memory rammed at 100% lagging out. That’s 135 separate browser stacks basically. Microsoft are moving office to this stack as well. Ugh. Of course I was there trying to work out why our simple old fashioned web app was running slowly in a chrome tab…
- bluedino 4y ago
  Our hospital system uses Citrix and the application patients have to sign in with runs on some web framework instead of being a native Windows app. Such a frustrating experience using the on-screen keyboard to enter your name to sign in.
loudmax 4y ago
The bottom line is that Electron is portable. Unless native apps become as portable as Electron there will be a need for this layer. The optimistic scenario is that WASM becomes the single target that everyone settles on, and that the performance penalty is minimized while the security sandbox is strengthened.
- _gabe_ 4y ago
  I see this all the time, and I honestly do not get it. As someone that has ported a game written in C++ for Windows to Linux... its not that hard. It took me 2 days, about 4 hours of work total, and most of the ports I had to make were because I'm an obstinate developer and didn't use the std lib functions that would handle the OS wrapping for me. Now, I've never ported an app to mobile, and that may be entirely different. However, and this may be an unpopular opinion, I don't want developers building an app that's meant to be used on a mobile device and a desktop. They're 2 separate ways of using a computer and they should be treated as such. When I think of desktop apps like Photoshop, Outlook, Word, Chrome, and Da Vinci Resolve, they all look and behave very differently than their mobile counterparts (if they have one). If you want to develop for mobile and desktop, then you need to invest the time to make it a good experience on both. I hate desktop apps that have been mobile-ified to support mobile-first design. Design a proper UI and UX for the platform you're targeting. Otherwise don't bother "supporting" a platform you never test, intend to test, or design specifically for.
  - mkoubaa 4y ago
    Porting a large-scale windows desktop app to linux takes engineer years.
    - deleted 4y ago
      [deleted]
    - anthk 4y ago
      Not with QT and C++.
  - 4y ago
amadeuspagel 4y ago
The obvious solution to this is to remove the bottom layer so that the browser is not a layer on top of the OS, but is the OS.
- sanroot99 4y ago
  Hypervisor based os is future ,for eg qubes os
  - hulitu 4y ago
    TBH, it doesn't matter how many levels of abstraction you have when the programs are crap.
- kllrnohj 4y ago
  That won't meaningfully change performance at all. Browsers aren't slow because they have to make slow syscalls - they mostly don't. They are slow because web technologies themselves are slow, sometimes by design, sometimes because of security/abuse concerns, but often just because HTML & CSS are absolutely crap platform for interactive UIs, something they were never intended to be and retrofitting that doesn't result in a very efficiency stack.
  - robocat 4y ago
    > HTML & CSS are absolutely crap platform for interactive UIs I mostly disagree. HTML is great for plain forms, that seamlessly work at different form-factors (from mobile to desktop) with very little work. Browsers are also good at graphical outputs. Browsers can fall down when you need rich, complex, or custom inputs: because virtual keyboards are very different from real keyboards (iOS especially poor), and touch is very different from mouse, and game consoles are something else again! But we go where the users are, which is usually a wide variety of devices which makes browser based deployment the default choice, so you work within the limitations of browsers.
    - kllrnohj 4y ago
323 4y ago
Do you think Microsoft loves it that people are building Windows apps with Google tech? But this ship has sailed a long time ago.
- criddell 4y ago
  I think they do love it! I'm pretty sure they chose Chromium for Edge because they see Electron or something like it as the future.
RunSet 4y ago
When you see decades of Windows version after Windows version, each billing itself as "the fastest Windows ever!" and each having higher minimum system requirements than its predecessor, two conclusions are inescapable: 1. The Redmond wizards have devised a method to make software run faster and all it requires is faster hardware. 2. Microsoft is in bed with hardware manufacturers.
- currenciessfe 4y ago
  What are you talking about? I'm running Windows 10 on a 2009 computer - one which was low-mid end back then. Only upgrade is an SSD.
  - opan 4y ago
    The system requirements are something they put out on paper, parent isn't necessarily saying you need a better PC, just saying Microsoft themselves say that, which you can verify yourself.
- Night_Thastus 4y ago
  Modern Windows PCs feel very noticeably snappier and more responsive than older ones. For all my complaints about Windows, that certainly isn't one. I've had to go back and work on old XP boxes, and that is not a pleasant experience. Admittedly a good chunk of that is SSDs, and better hardware plays a role. But hardware was going to get better anyways regardless of Windows - at least they didn't use the better hardware to make the effects fancier/get sloppy and end up at square 1 like so much of other software.
  - hulitu 4y ago
    > Modern Windows PCs feel very noticeably snappier and more responsive than older ones If you run the same version of windows on both PCs, yes.
gernb 4y ago
I choose it for portability. I can ship to my users today, work on new features for all users, or I can spend 3-4-5-6 months dealing with differences in platforms, differences in tooling, build environments, deployment, etc.... I also it choose is because as a programmer it's far easier IMO to make a web tech app look good than a native app. CSS, Unicode text, emoji, images, video, canvas, webgl, it's all easy, portable, and batteries included, vs the various platform specific ways of providing those features.
binkHN 4y ago
> With all this ... PWA focused development a cannot shake a feeling that we add an extra layer of a "runtime" on top of an operating system... Is this not ChromeOS? A little OS, a lot of browser and little else?
luvs2code 4y ago
I'm gradually starting to see X11/Xlib as a solution for cross platform desktop apps. It is the native GUI API for most UNIX operating systems. Ports exist for Windows(win11) and Mac which makes X11 technically portable to them as well. Its not exactly an elegant solution I have to admit. But the licensing problems with QT make a lot of people nervous, GTK seems to be pretty polarizing, and for whatever reason WxWidgets and FLTK never really got much adoption/didn't progress very far. [0] https://learn.microsoft.com/en-us/windows/wsl/tutorials/gui-apps https://learn.microsoft.com/en-us/windows/wsl/tutorials/gui-...
- ColonelPhantom 4y ago
  I think wxWidgets was pretty big in the 2000's, with quite some programs using it. To name one example, the Code::Blocks IDE uses it. FLTK has never seen adoption even to the level of wxWidgets I think, but to be honest it is also quite simply hideous. I have not found a proper looking theme for it either, since I was mildly interested in using it to add a simple GUI to a Rust tool.
  - luvs2code 4y ago
    I don't know why WxWidgets seems to be less popular now than it was back then. I remember it being somewhat popular. Now people hardly seem to know about it. FLTK looks horrible next to most modern applications. But FLTK 2.0, which has been abandoned for 10 years, actually looks pretty modern and the API is actually pretty elegant. There was some kind of split in the community about FLTK 2.0 breaking backward compatibility and I guess the 1.0 people won in the end.
- hulitu 4y ago
  They saw it's good so are now deprecating it.

whywhywhywhy 4y ago

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

trap_goes_hot 4y ago

That ship seems to have sailed with the (over?)use of VMs a long time ago.

gw99 4y ago

This. I encountered hell the other day. I saw a corporate Citrix deployment that had 45 users running three electron apps on an underprovisioned server with the CPU, disk and memory rammed at 100% lagging out. That’s 135 separate browser stacks basically. Microsoft are moving office to this stack as well. Ugh. Of course I was there trying to work out why our simple old fashioned web app was running slowly in a chrome tab…

bluedino 4y ago
Our hospital system uses Citrix and the application patients have to sign in with runs on some web framework instead of being a native Windows app. Such a frustrating experience using the on-screen keyboard to enter your name to sign in.

loudmax 4y ago

The bottom line is that Electron is portable. Unless native apps become as portable as Electron there will be a need for this layer. The optimistic scenario is that WASM becomes the single target that everyone settles on, and that the performance penalty is minimized while the security sandbox is strengthened.

_gabe_ 4y ago
I see this all the time, and I honestly do not get it. As someone that has ported a game written in C++ for Windows to Linux... its not that hard. It took me 2 days, about 4 hours of work total, and most of the ports I had to make were because I'm an obstinate developer and didn't use the std lib functions that would handle the OS wrapping for me. Now, I've never ported an app to mobile, and that may be entirely different. However, and this may be an unpopular opinion, I don't want developers building an app that's meant to be used on a mobile device and a desktop. They're 2 separate ways of using a computer and they should be treated as such. When I think of desktop apps like Photoshop, Outlook, Word, Chrome, and Da Vinci Resolve, they all look and behave very differently than their mobile counterparts (if they have one). If you want to develop for mobile and desktop, then you need to invest the time to make it a good experience on both. I hate desktop apps that have been mobile-ified to support mobile-first design. Design a proper UI and UX for the platform you're targeting. Otherwise don't bother "supporting" a platform you never test, intend to test, or design specifically for.
- mkoubaa 4y ago
  Porting a large-scale windows desktop app to linux takes engineer years.
  - deleted 4y ago
    [deleted]
  - anthk 4y ago
    Not with QT and C++.
- 4y ago

amadeuspagel 4y ago

The obvious solution to this is to remove the bottom layer so that the browser is not a layer on top of the OS, but is the OS.

sanroot99 4y ago
Hypervisor based os is future ,for eg qubes os
- hulitu 4y ago
  TBH, it doesn't matter how many levels of abstraction you have when the programs are crap.
kllrnohj 4y ago
That won't meaningfully change performance at all. Browsers aren't slow because they have to make slow syscalls - they mostly don't. They are slow because web technologies themselves are slow, sometimes by design, sometimes because of security/abuse concerns, but often just because HTML & CSS are absolutely crap platform for interactive UIs, something they were never intended to be and retrofitting that doesn't result in a very efficiency stack.
- robocat 4y ago
  > HTML & CSS are absolutely crap platform for interactive UIs I mostly disagree. HTML is great for plain forms, that seamlessly work at different form-factors (from mobile to desktop) with very little work. Browsers are also good at graphical outputs. Browsers can fall down when you need rich, complex, or custom inputs: because virtual keyboards are very different from real keyboards (iOS especially poor), and touch is very different from mouse, and game consoles are something else again! But we go where the users are, which is usually a wide variety of devices which makes browser based deployment the default choice, so you work within the limitations of browsers.
  - kllrnohj 4y ago

323 4y ago

Do you think Microsoft loves it that people are building Windows apps with Google tech? But this ship has sailed a long time ago.

criddell 4y ago
I think they do love it! I'm pretty sure they chose Chromium for Edge because they see Electron or something like it as the future.

RunSet 4y ago

When you see decades of Windows version after Windows version, each billing itself as "the fastest Windows ever!" and each having higher minimum system requirements than its predecessor, two conclusions are inescapable: 1. The Redmond wizards have devised a method to make software run faster and all it requires is faster hardware. 2. Microsoft is in bed with hardware manufacturers.

currenciessfe 4y ago
What are you talking about? I'm running Windows 10 on a 2009 computer - one which was low-mid end back then. Only upgrade is an SSD.
- opan 4y ago
  The system requirements are something they put out on paper, parent isn't necessarily saying you need a better PC, just saying Microsoft themselves say that, which you can verify yourself.
Night_Thastus 4y ago
Modern Windows PCs feel very noticeably snappier and more responsive than older ones. For all my complaints about Windows, that certainly isn't one. I've had to go back and work on old XP boxes, and that is not a pleasant experience. Admittedly a good chunk of that is SSDs, and better hardware plays a role. But hardware was going to get better anyways regardless of Windows - at least they didn't use the better hardware to make the effects fancier/get sloppy and end up at square 1 like so much of other software.
- hulitu 4y ago
  > Modern Windows PCs feel very noticeably snappier and more responsive than older ones If you run the same version of windows on both PCs, yes.

gernb 4y ago

I choose it for portability. I can ship to my users today, work on new features for all users, or I can spend 3-4-5-6 months dealing with differences in platforms, differences in tooling, build environments, deployment, etc.... I also it choose is because as a programmer it's far easier IMO to make a web tech app look good than a native app. CSS, Unicode text, emoji, images, video, canvas, webgl, it's all easy, portable, and batteries included, vs the various platform specific ways of providing those features.

binkHN 4y ago

> With all this ... PWA focused development a cannot shake a feeling that we add an extra layer of a "runtime" on top of an operating system... Is this not ChromeOS? A little OS, a lot of browser and little else?

luvs2code 4y ago

I'm gradually starting to see X11/Xlib as a solution for cross platform desktop apps. It is the native GUI API for most UNIX operating systems. Ports exist for Windows(win11) and Mac which makes X11 technically portable to them as well. Its not exactly an elegant solution I have to admit. But the licensing problems with QT make a lot of people nervous, GTK seems to be pretty polarizing, and for whatever reason WxWidgets and FLTK never really got much adoption/didn't progress very far. [0] https://learn.microsoft.com/en-us/windows/wsl/tutorials/gui-apps https://learn.microsoft.com/en-us/windows/wsl/tutorials/gui-...

ColonelPhantom 4y ago
I think wxWidgets was pretty big in the 2000's, with quite some programs using it. To name one example, the Code::Blocks IDE uses it. FLTK has never seen adoption even to the level of wxWidgets I think, but to be honest it is also quite simply hideous. I have not found a proper looking theme for it either, since I was mildly interested in using it to add a simple GUI to a Rust tool.
- luvs2code 4y ago
  I don't know why WxWidgets seems to be less popular now than it was back then. I remember it being somewhat popular. Now people hardly seem to know about it. FLTK looks horrible next to most modern applications. But FLTK 2.0, which has been abandoned for 10 years, actually looks pretty modern and the API is actually pretty elegant. There was some kind of split in the community about FLTK 2.0 breaking backward compatibility and I guess the 1.0 people won in the end.
hulitu 4y ago
They saw it's good so are now deprecating it.