6 ms·

- Electron is big dependency, adding hundreds of MB to our app - Electron Apps haven't and won't ever 100% fit into the OS environment/theme, neither Windows,

- Electron is big dependency, adding hundreds of MB to our app - Electron Apps haven't and won't ever 100% fit into the OS environment/theme, neither Windows, macOS, or any Linux desktop - Electron takes a long time to start up - Electron eats a big amount of memory - Electron uses a lot more battrey - Many APIs of the underlying OS are not avaiable to Electron, especially those not found on competing platforms So, allow me to say this: If web technologies are more attractive to you (which is completely fine), stick to the web. But don't create Desktop programs that waste ressources and time just for the sake of having "a true cross platform app".

userbinator 10y ago
It makes me think Electron is the new Java. Trying to make things cross-platform inevitably introduces inefficiencies and lowest-common-denominator functionality. The UI may look native but the contrast in everything else is instantly noticeable. That said, these samples seem to be mostly UWP/C# stuff which I wouldn't consider "real native" i.e. Win32 --- I've been programming in Win32 for a long time and even the differences in resource usage between Win32 and .NET apps are noticeable.
- Const-me 10y ago
  That UWP thing is the new real native. On some Windows platforms, win32 API is emulated and very limited. It works fine without .NET. The API is COM-like, can be consumed from C++ and JavaScript. However, C# is much simpler than C++ for that, one reason is many APIs are asynchronous and C++ has no async-await.
  - userbinator 10y ago
    The API is COM-like I have been forced to use COM a few times, and that doesn't sound very encouraging... IMHO Win32 is simpler for a lot of things, compare for example the task of using the file selection dialog the Win32 way: https://msdn.microsoft.com/en-us/library/windows/desktop/ms646829(v=vs.85).aspx#open_file https://msdn.microsoft.com/en-us/library/windows/desktop/ms6... ...with the COM "replacement": https://msdn.microsoft.com/en-us/library/windows/desktop/bb776913(v=vs.85).aspx#basic_usage https://msdn.microsoft.com/en-us/library/windows/desktop/bb7... (There's a 10-level nested if in that code. I recall exclaiming WTF the first time I saw that.)
    - Const-me 10y ago
      > forced to use COM a few times, and that doesn't sound very encouraging I use COM a lot and I love it. The problem with COM is it’s too many things at once. It’s an excellent ABI. At the same time it’s crappy RPC and overengineered serialization framework. In addition, registration could become a point of failure. You can only use good parts and ignore the bad ones. See how MS did it with their Direct3D or MediaFoundation. > 10-level nested if in that code You can write shitty code like that with any framework and in any language. Doesn’t say anything about a framework or language. Apparently, there’s some stupid policy that prevents them from using ATL in their code samples. With CComPtr instead of raw interface pointers, you can just return the code when FAILED(), the destructor will release the objects as needed.
  - WayneBro 10y ago
    UWP is a sandbox. I wouldn't call that native. You can't even do any sort of local IPC with it if your other process is Win32. Furthermore: - You can't run a UWP as Administrator. - A UWP app has less access to the system and user data. - You can't develop a UWP app that has in-process plugins. - You can't hook into a UWP app like you can with actual native Win32 apps, to send keys, hook keys or do screen overlays. In summary, UWP is full of artificial limitations and that's why nobody is building on it. I'm looking forward to the day when Microsoft announces that UWP is either going away or being pulled out of it's sandbox. Then I'll consider using it.
    - Const-me 10y ago
      Just because you don’t have permissions to do something, doesn’t mean something is wrong with the API. Technically, you can restrict permissions in a similar way on any NT-based OS. Doesn’t mean the Win32 API is not native. Doesn’t mean those ACL permission checks everywhere are “artificial limitations”. Most of those UWP’s limitations are here to protect users. Microsoft learned their lesson about the security. I don’t want your app to be able to do local IPC or hook keys on my PC. Furthermore, you can’t have unrestricted access to the lower levels of the system, and universal apps at the same time. There’s no Win32 subsystem on the phones, or on embedded windows 10.
      - WayneBro 10y ago
        There is going to be a Win32 subsystem on phones. That's the next thing Microsoft is trying. They already showed Windows 10 running on arm with Win32 apps running on it. The things I mentioned or not permissions. They are limitations. No UWP app is permitted to do them so they might as will not exist. However those things do exist and there must be a reason why. Maybe people have needed to use them before? I think so.
        Const-me 10y ago
        > going to be a Win32 subsystem on phones Maybe, but currently there’s none. > Maybe people have needed to use them before? It’s called “progress”. Over time, better and safer APIs replace dangerous lower-level things. For example, DirectX deprecated direct access to the graphics and audio hardware. Similar way, UWP deprecates direct access to system and user data, physical display and keyboard. Apparently, Microsoft prioritized user’s safety and battery life over needs of those few software vendors who heed the functionality for legitimate reasons.
  - xorblurb 10y ago
    > On some Windows platforms, win32 API is emulated and very limited. hm, very limited, maybe. There is actually no public Win32 for the platforms you have in mind, I think, but a subset is common with UWP. However, it's not emulated... and probably nearly all of Win32 are standing right there, only you just can't use it... For ex in Win8 RT the whole (or nearly whole) Win32 was there and could even be used by a non-Windows program: Office.
    - Const-me 10y ago
      Yeah, I know there was classic Win32 environment on Windows 8 RT, just it wasn’t public. However we’re talking about UWP apps here, Windows 8 is unrelated. And there’s no Win32 environment on Windows Mobile 10, or Windows 10 IoT Core.
      - xorblurb 10y ago
        I don't think there is any emulation of Win32 either? You just have some of the functions; those that are part of UWP.
riskable 10y ago
I was with you until you mentioned how long to takes to start an electron app... It's nearly instantaneous for me. Actually, nearly all apps open instantaneously for me but maybe it's because I'm running a Linux Desktop with an SSD? Also, the battery thing is nonsense. An idle web app will use up just as much battery as an idle native app. It's the implementation and code architecture decisions that matter more for battery then the underlying APIs. Lastly, making apps cross-cross-platform is worthwhile unless the point of the app is platform-specific (e.g. an app that tunes something in the OS). You're always going to end up with a larger code base and more complexity when making things cross-platform. Using something like electron is an excellent way to avoid all that complexity.
- userbinator 10y ago
  An idle web app will use up just as much battery as an idle native app. How about when they're not idle? There's probably an order of magnitude if not more instructions being executed in Electron, which eventually reaches the same OS APIs a native app would call directly. JITs still have overhead. You're always going to end up with a larger code base and more complexity when making things cross-platform. Using something like electron is an excellent way to avoid all that complexity. All you've done is moved the complexity to where you as a developer may not see it, but your users sure do.
- AbacusAvenger 10y ago
  An idle web app will use up just as much battery as an idle native app. Idle apps can still vary in how much battery life they consume. I've seen some background apps that don't appear to be using any CPU (i.e. "0%" utilization) but actually have high-frequency timers which will wake the CPU every time they fire. Waking the CPU is bad news because it kicks it out of the low-power C-states and thus eats more battery. If you're on Windows try running 'powercfg /sleepstudy' and you might find some interesting power-hungry behavior from even "idle" apps: https://blogs.windows.com/windowsexperience/2014/06/26/sleep-study-diagnose-whats-draining-your-battery-while-the-system-sleeps/ https://blogs.windows.com/windowsexperience/2014/06/26/sleep... On Linux, you can use 'powertop' for the same purpose, though I've found powertop is more useful since it shows more raw data and makes fewer assumptions.

userbinator 10y ago

It makes me think Electron is the new Java. Trying to make things cross-platform inevitably introduces inefficiencies and lowest-common-denominator functionality. The UI may look native but the contrast in everything else is instantly noticeable. That said, these samples seem to be mostly UWP/C# stuff which I wouldn't consider "real native" i.e. Win32 --- I've been programming in Win32 for a long time and even the differences in resource usage between Win32 and .NET apps are noticeable.

Const-me 10y ago
That UWP thing is the new real native. On some Windows platforms, win32 API is emulated and very limited. It works fine without .NET. The API is COM-like, can be consumed from C++ and JavaScript. However, C# is much simpler than C++ for that, one reason is many APIs are asynchronous and C++ has no async-await.
- userbinator 10y ago
  The API is COM-like I have been forced to use COM a few times, and that doesn't sound very encouraging... IMHO Win32 is simpler for a lot of things, compare for example the task of using the file selection dialog the Win32 way: https://msdn.microsoft.com/en-us/library/windows/desktop/ms646829(v=vs.85).aspx#open_file https://msdn.microsoft.com/en-us/library/windows/desktop/ms6... ...with the COM "replacement": https://msdn.microsoft.com/en-us/library/windows/desktop/bb776913(v=vs.85).aspx#basic_usage https://msdn.microsoft.com/en-us/library/windows/desktop/bb7... (There's a 10-level nested if in that code. I recall exclaiming WTF the first time I saw that.)
  - Const-me 10y ago
    > forced to use COM a few times, and that doesn't sound very encouraging I use COM a lot and I love it. The problem with COM is it’s too many things at once. It’s an excellent ABI. At the same time it’s crappy RPC and overengineered serialization framework. In addition, registration could become a point of failure. You can only use good parts and ignore the bad ones. See how MS did it with their Direct3D or MediaFoundation. > 10-level nested if in that code You can write shitty code like that with any framework and in any language. Doesn’t say anything about a framework or language. Apparently, there’s some stupid policy that prevents them from using ATL in their code samples. With CComPtr instead of raw interface pointers, you can just return the code when FAILED(), the destructor will release the objects as needed.
- WayneBro 10y ago
  UWP is a sandbox. I wouldn't call that native. You can't even do any sort of local IPC with it if your other process is Win32. Furthermore: - You can't run a UWP as Administrator. - A UWP app has less access to the system and user data. - You can't develop a UWP app that has in-process plugins. - You can't hook into a UWP app like you can with actual native Win32 apps, to send keys, hook keys or do screen overlays. In summary, UWP is full of artificial limitations and that's why nobody is building on it. I'm looking forward to the day when Microsoft announces that UWP is either going away or being pulled out of it's sandbox. Then I'll consider using it.
  - Const-me 10y ago
    Just because you don’t have permissions to do something, doesn’t mean something is wrong with the API. Technically, you can restrict permissions in a similar way on any NT-based OS. Doesn’t mean the Win32 API is not native. Doesn’t mean those ACL permission checks everywhere are “artificial limitations”. Most of those UWP’s limitations are here to protect users. Microsoft learned their lesson about the security. I don’t want your app to be able to do local IPC or hook keys on my PC. Furthermore, you can’t have unrestricted access to the lower levels of the system, and universal apps at the same time. There’s no Win32 subsystem on the phones, or on embedded windows 10.
    - WayneBro 10y ago
      There is going to be a Win32 subsystem on phones. That's the next thing Microsoft is trying. They already showed Windows 10 running on arm with Win32 apps running on it. The things I mentioned or not permissions. They are limitations. No UWP app is permitted to do them so they might as will not exist. However those things do exist and there must be a reason why. Maybe people have needed to use them before? I think so.
      - Const-me 10y ago
        > going to be a Win32 subsystem on phones Maybe, but currently there’s none. > Maybe people have needed to use them before? It’s called “progress”. Over time, better and safer APIs replace dangerous lower-level things. For example, DirectX deprecated direct access to the graphics and audio hardware. Similar way, UWP deprecates direct access to system and user data, physical display and keyboard. Apparently, Microsoft prioritized user’s safety and battery life over needs of those few software vendors who heed the functionality for legitimate reasons.
- xorblurb 10y ago
  > On some Windows platforms, win32 API is emulated and very limited. hm, very limited, maybe. There is actually no public Win32 for the platforms you have in mind, I think, but a subset is common with UWP. However, it's not emulated... and probably nearly all of Win32 are standing right there, only you just can't use it... For ex in Win8 RT the whole (or nearly whole) Win32 was there and could even be used by a non-Windows program: Office.
  - Const-me 10y ago
    Yeah, I know there was classic Win32 environment on Windows 8 RT, just it wasn’t public. However we’re talking about UWP apps here, Windows 8 is unrelated. And there’s no Win32 environment on Windows Mobile 10, or Windows 10 IoT Core.
    - xorblurb 10y ago
      I don't think there is any emulation of Win32 either? You just have some of the functions; those that are part of UWP.

riskable 10y ago

I was with you until you mentioned how long to takes to start an electron app... It's nearly instantaneous for me. Actually, nearly all apps open instantaneously for me but maybe it's because I'm running a Linux Desktop with an SSD? Also, the battery thing is nonsense. An idle web app will use up just as much battery as an idle native app. It's the implementation and code architecture decisions that matter more for battery then the underlying APIs. Lastly, making apps cross-cross-platform is worthwhile unless the point of the app is platform-specific (e.g. an app that tunes something in the OS). You're always going to end up with a larger code base and more complexity when making things cross-platform. Using something like electron is an excellent way to avoid all that complexity.

userbinator 10y ago
An idle web app will use up just as much battery as an idle native app. How about when they're not idle? There's probably an order of magnitude if not more instructions being executed in Electron, which eventually reaches the same OS APIs a native app would call directly. JITs still have overhead. You're always going to end up with a larger code base and more complexity when making things cross-platform. Using something like electron is an excellent way to avoid all that complexity. All you've done is moved the complexity to where you as a developer may not see it, but your users sure do.
AbacusAvenger 10y ago
An idle web app will use up just as much battery as an idle native app. Idle apps can still vary in how much battery life they consume. I've seen some background apps that don't appear to be using any CPU (i.e. "0%" utilization) but actually have high-frequency timers which will wake the CPU every time they fire. Waking the CPU is bad news because it kicks it out of the low-power C-states and thus eats more battery. If you're on Windows try running 'powercfg /sleepstudy' and you might find some interesting power-hungry behavior from even "idle" apps: https://blogs.windows.com/windowsexperience/2014/06/26/sleep-study-diagnose-whats-draining-your-battery-while-the-system-sleeps/ https://blogs.windows.com/windowsexperience/2014/06/26/sleep... On Linux, you can use 'powertop' for the same purpose, though I've found powertop is more useful since it shows more raw data and makes fewer assumptions.