Here's the problem: As a developer Electron (see 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 ). 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.
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)
> 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.
>This can be an issue, but it depends on the type of app you are making.
It does, but the problem is Electron is the new hotness, so every chat client that could have been a 10MB native app is now coming out as a 100MB Electron app. Instead of looking at the problem being solved and choosing Electron, people work backwards and choose Electron because that's what looks good on a resume/is easy to hire for/is popular/etc., then try and fit their problems into it.
"simply don't have an equivalent in native app development"
Really? I mean I know D3.js is just an example, but between LiveCharts, OxPlot, MS Charts, and a decades worth of charting libs there's nothing like it? The thing is native has decades of legacy, which isn't always a bad thing as much as people tend to assume it is.
Electron apps are not doing things that are extraordinarily new, I'd be shocked to find that there are popular libraries for frontend web dev that don't have alternatives on native (not to mention native has WebViews that get updated outside of your own release cadence, and offer performance that's at least good enough to embed in places where you really can't find anything as good as the Js equivalent).
>In general, Web technologies are advancing at a much faster rate than native, and native tech will find it hard to keep up.
I find that statement wonderfully ironic, I think with things like Electron, the Web just started getting to where native tech is. Web technologies "advance faster" in the sense that technology "churns faster". Look at what web apps were doing in 2006 and what web apps were doing in 2016 from a user's perspective. While from a web devs perspective React and co might have brought us forward (or sideways) lightyears, from a user perspective not that much changed. If WPF could do what that user needed in 2006, it can do what they need today, that's why there's so few "advancements".
Now we're getting stuff like WASM so we can essentially utilize native stacks on web tech, I don't know how easily I can call that "advanced tech" over native.
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.
I didn't say there are no data visualization libraries for native development. What I said is there is no equivalent to D3.js. I recommend taking a look at D3. It is not a charting library. There are charting libraries built on top of D3, but D3 is not your average charting package like MS chart control.
I disagree with that. PgAdmin is a great example of how bad performance can be when you choose to build a non-native app. I admit it's not in Electron, but the idea behind it is similar.
Performance is especially important for BI programmes. Start up time can be a bit longer, but users will heavily use the programme, so every delay to use it will be noticed much more than for a non-BI app. Navigation without using the mouse is also more important for BI apps, and typically worse in non-native apps (not that it couldn't be different).
So while the pure start up time is itself not a huge problem, non-native apps will also take more resources and time performing tasks, which is a huge deal for BI apps.
- 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".
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.
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.
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:
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.
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.
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.
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.
"Regress" would be more appropriate, it's taking away useful features. Gimping what an application is capable of should not be the solution to security.
How are you going to secure user against key loggers when there’s a “useful feature” allowing any app to listen keyboard events of the whole windows station?
Keep in mind there’re another useful features, allowing users to run an unsigned application from any source, with administrator privileges.
There are permissions for which apps can use my Mic, Camera, Contacts, Call history, etc... Microsoft could easily add one that lets me run UWP apps with a higher privilege that allows IPC with Win32 apps.
As it is right now, you can't even build a UWP app that can talk to a server app running on the same exact machine. Instead, you have to build all of your UWP apps so that they depend on some Internet server.
Permission settings only work for the minority of people who’re into that information security thing.
Look at the mobile apps.
Many apps require geolocation permission, not because they need it, but because they include some ads, and ad provider who made their ad serving control needs GPS coordinates to serve better ads.
The majority of users don’t care.
They just click “I agree” on those permission popups, so unlimited number of third-parties able to literally track their each step.
> 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.
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.
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.
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:
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.
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.
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.
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-fro...
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.