Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Windows Code Samples

microsoft.github.io

Post reply on HN
Print view View original

51–60 of 107 posts

Re: Windows Code Samples

#51

Post by BoorishBears »

interlocutor wrote: post #36

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…

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)

Re: Windows Code Samples

#52

Post by riskable »

Longhanks wrote: post #40
interlocutor wrote: post #36

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…

- 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, a…

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.

Re: Windows Code Samples

#53

Post by userbinator »

riskable wrote: post #52
Longhanks wrote: post #40

Earlier quoted context omitted.

- 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, a…

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 b…

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.

Re: Windows Code Samples

#54

Post by AbacusAvenger »

riskable wrote: post #52
Longhanks wrote: post #40

Earlier quoted context omitted.

- 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, a…

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 b…

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

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.

Re: Windows Code Samples

#55

Post by Const-me »

userbinator wrote: post #43
Longhanks wrote: post #40

Earlier quoted context omitted.

- 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, a…

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 di…

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.

Re: Windows Code Samples

#56

Post by Const-me »

mastax wrote: post #47
interlocutor wrote: post #36

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…

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…

They started much earlier than that, in 1999 with the release of IE5:

https://technet.microsoft.com/en-us/library/ee692768.aspx

Just tested their "get OS version" example on my Windows 10, works fine.

Re: Windows Code Samples

#57

Post by interlocutor »

BoorishBears wrote: post #51
interlocutor wrote: post #36

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…

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…

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

Re: Windows Code Samples

#58

Post by marpstar »

interlocutor wrote: post #57
BoorishBears wrote: post #51

Earlier quoted context omitted.

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…

> 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 s…

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.

Re: Windows Code Samples

#59

Post by userbinator »

Const-me wrote: post #55
userbinator wrote: post #43

Earlier quoted context omitted.

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 di…

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.

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

...with the COM "replacement":

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

Re: Windows Code Samples

#60

Post by BoorishBears »

interlocutor wrote: post #57
BoorishBears wrote: post #51

Earlier quoted context omitted.

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…

> 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 s…

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

Post reply on HN