7 ms·

Here's the problem: As a developer Electron (see http://electron.atom.io/ http://electron.atom.io/ ) is more attractive to me than Windows APIs. Take a look at

Here's the problem: As a developer Electron (see http://electron.atom.io/ http://electron.atom.io/ ) is more attractive to me than Windows APIs. Take a look at the RSS Reader ( https://github.com/Microsoft/Windows-appsample-rssreader https://github.com/Microsoft/Windows-appsample-rssreader ). I can make a desktop app that is practically indistinguishable from this app using Electron, so why would I use Windows APIs? If I use Electron then my app will run on Mac and Linux, not just Windows, and my skills will be portable too. The Flat UI of Windows is a mistake. Because of Flat UI, there is no differentiation between Web apps and native Windows apps, which makes it possible--and even desirable--to make desktop apps using Web technologies.

v0lta 10y ago
We had to redo an inhouse Electron app in WPF because we came to the point where we had to do some stuff within windows, e.g. printing or create a heavily customized MSI file. Both is possible with Electron but with the native Windows solution it's easier to fine-tune behavior. I think for UI and some web stuff Electron might really be superior. Especially if your team is already fluent with the web stack. But it has it's limits and if you reach them or have very specific requirements you might be better of with WPF or UWP apps and the initially higher effort of developing in C#/XAML might pay off. Saying this I believe the existence of Electron is a great possibility for UI devs.
Longhanks 10y ago
- 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.
Kipters 10y ago
Indistinguishable, until you look at the resources usage :/
mastax 10y ago
I don't think MS wants to discourage developing apps using web technologies. They support a number of ways [1,2,3] to turn HTML/JS apps into windows {,store} apps. They've been supportive of using web technologies to make apps before electron existed. The original "modern" app platform for Windows 8 had APIs for C#, C++/CX, and JS. I don't think the first JS push was an effort to improve portability, but portability is definitely a part of "new MS" strategy. Look at things like Xamarin and the Objective-C compiler for visual studio (whatever they're calling it). They don't care if your app isn't Windows exclusive, they're just begging you to put it in the Windows Store. [1]: https://developer.microsoft.com/en-us/windows/develop/winjs https://developer.microsoft.com/en-us/windows/develop/winjs [2]: https://www.microsoft.com/developerblog/real-life-code/2016/05/09/Electron-Windows-Store.html https://www.microsoft.com/developerblog/real-life-code/2016/... [3]: https://developer.microsoft.com/en-us/windows/bridges/hosted-web-apps https://developer.microsoft.com/en-us/windows/bridges/hosted...
- Const-me 10y ago
  They started much earlier than that, in 1999 with the release of IE5: https://technet.microsoft.com/en-us/library/ee692768.aspx https://technet.microsoft.com/en-us/library/ee692768.aspx Just tested their "get OS version" example on my Windows 10, works fine.
- amckinlay 10y ago
  > they're just begging you to put it in the Windows Store. And now their store is full of crap and no one uses it.
  - sidlls 10y ago
    The first part of that applies to Apple and Google app stores, too.
amiga-workbench 10y ago
Electron is a fine choice if you hold your users in utter disdain.
BoorishBears 10y ago
Here's the problem: As a user, Windows APIs is more attractive to me than Electron. Electron apps all have orders of magnitude higher memory usage than comparable native apps I use across the board (10s of MB vs 100s of MB). They also have a look and feel that's just "off" most of the time (there's more to the "Flat UI" than having a flat UI). They also tend to not play as well with right click. >I can make a desktop app that is practically indistinguishable from this app using Electron, so why would I use Windows APIs? Because you don't want all your users running a harder to update embedded version of Chrome with multiple separate instances. Because you realise that since the dawn of cross-platform UIs, non-native apps have always stuck out like a sore thumb once you got past the visuals. As a developer I definitely see why being able to leverage web technology everywhere is attractive, and even as an businessperson I'd see it, but let's not kid ourselves. It's being intentionally selfish. In theory you can balance that out by using your savings from going with something like Electron to improve other areas of the app, but something tells me in most cases that isn't the driving factor (after all, something like Qt can offer cross platform without the overhead of Electron, it's just Js+HTML5 is more convenient than C++ if you're only trying for easily marketable/hireable skills)
- interlocutor 10y ago
  > Electron apps all have orders of magnitude higher memory usage than comparable native apps I use across the board (10s of MB vs 100s of MB). This can be an issue, but it depends on the type of app you are making. If you are making a calculator app, you don't want it to consume 100 MB of memory and take 15 seconds to start. But if you are making a Business Intelligence app then if it takes 100 MB and 15 seconds to start your users will typically accept that. And as a developer you get to use awesome Web technologies, such as D3.js, that simply don't have an equivalent in native app development. In general, Web technologies are advancing at a much faster rate than native, and native tech will find it hard to keep up.
  - marpstar 10y ago
    I agree that web-based libraries are being released at a more frequent rate and with greater adoption than desktop APIs, but to suggest that native app development offers no data visualization libraries seems a bit naive.
felixrieseberg 10y ago
I used to be the project lead for Electron at Microsoft (now building the Slack Desktop App) and I'm super happy to say that there's been a lot of great work around interacting with native Windows APIs from Electron: https://felixrieseberg.com/using-native-windows-features-from-electron/ https://felixrieseberg.com/using-native-windows-features-fro...

v0lta 10y ago

We had to redo an inhouse Electron app in WPF because we came to the point where we had to do some stuff within windows, e.g. printing or create a heavily customized MSI file. Both is possible with Electron but with the native Windows solution it's easier to fine-tune behavior. I think for UI and some web stuff Electron might really be superior. Especially if your team is already fluent with the web stack. But it has it's limits and if you reach them or have very specific requirements you might be better of with WPF or UWP apps and the initially higher effort of developing in C#/XAML might pay off. Saying this I believe the existence of Electron is a great possibility for UI devs.

Longhanks 10y ago

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

Kipters 10y ago

Indistinguishable, until you look at the resources usage :/

mastax 10y ago

I don't think MS wants to discourage developing apps using web technologies. They support a number of ways [1,2,3] to turn HTML/JS apps into windows {,store} apps. They've been supportive of using web technologies to make apps before electron existed. The original "modern" app platform for Windows 8 had APIs for C#, C++/CX, and JS. I don't think the first JS push was an effort to improve portability, but portability is definitely a part of "new MS" strategy. Look at things like Xamarin and the Objective-C compiler for visual studio (whatever they're calling it). They don't care if your app isn't Windows exclusive, they're just begging you to put it in the Windows Store. [1]: https://developer.microsoft.com/en-us/windows/develop/winjs https://developer.microsoft.com/en-us/windows/develop/winjs [2]: https://www.microsoft.com/developerblog/real-life-code/2016/05/09/Electron-Windows-Store.html https://www.microsoft.com/developerblog/real-life-code/2016/... [3]: https://developer.microsoft.com/en-us/windows/bridges/hosted-web-apps https://developer.microsoft.com/en-us/windows/bridges/hosted...

Const-me 10y ago
They started much earlier than that, in 1999 with the release of IE5: https://technet.microsoft.com/en-us/library/ee692768.aspx https://technet.microsoft.com/en-us/library/ee692768.aspx Just tested their "get OS version" example on my Windows 10, works fine.
amckinlay 10y ago
> they're just begging you to put it in the Windows Store. And now their store is full of crap and no one uses it.
- sidlls 10y ago
  The first part of that applies to Apple and Google app stores, too.

amiga-workbench 10y ago

Electron is a fine choice if you hold your users in utter disdain.

BoorishBears 10y ago

Here's the problem: As a user, Windows APIs is more attractive to me than Electron. Electron apps all have orders of magnitude higher memory usage than comparable native apps I use across the board (10s of MB vs 100s of MB). They also have a look and feel that's just "off" most of the time (there's more to the "Flat UI" than having a flat UI). They also tend to not play as well with right click. >I can make a desktop app that is practically indistinguishable from this app using Electron, so why would I use Windows APIs? Because you don't want all your users running a harder to update embedded version of Chrome with multiple separate instances. Because you realise that since the dawn of cross-platform UIs, non-native apps have always stuck out like a sore thumb once you got past the visuals. As a developer I definitely see why being able to leverage web technology everywhere is attractive, and even as an businessperson I'd see it, but let's not kid ourselves. It's being intentionally selfish. In theory you can balance that out by using your savings from going with something like Electron to improve other areas of the app, but something tells me in most cases that isn't the driving factor (after all, something like Qt can offer cross platform without the overhead of Electron, it's just Js+HTML5 is more convenient than C++ if you're only trying for easily marketable/hireable skills)

interlocutor 10y ago
> Electron apps all have orders of magnitude higher memory usage than comparable native apps I use across the board (10s of MB vs 100s of MB). This can be an issue, but it depends on the type of app you are making. If you are making a calculator app, you don't want it to consume 100 MB of memory and take 15 seconds to start. But if you are making a Business Intelligence app then if it takes 100 MB and 15 seconds to start your users will typically accept that. And as a developer you get to use awesome Web technologies, such as D3.js, that simply don't have an equivalent in native app development. In general, Web technologies are advancing at a much faster rate than native, and native tech will find it hard to keep up.
- marpstar 10y ago
  I agree that web-based libraries are being released at a more frequent rate and with greater adoption than desktop APIs, but to suggest that native app development offers no data visualization libraries seems a bit naive.

felixrieseberg 10y ago

I used to be the project lead for Electron at Microsoft (now building the Slack Desktop App) and I'm super happy to say that there's been a lot of great work around interacting with native Windows APIs from Electron: https://felixrieseberg.com/using-native-windows-features-from-electron/ https://felixrieseberg.com/using-native-windows-features-fro...