UWP apps tend to be pretty big, especially when compared to Win32/whatever Explorer is written in. That has very little to do with the author and much to do with the framework.

It's a little dispiriting to see this as the top HN comment on a high schooler's project .

And 55 MB for a native app is paltry. Even the 'Google' app on Android is 285 MB, the Gallery app of OnePlus is 70 MB.

7-zip for 64-bit windows: 1.4 MiB

Winamp 5.8: 7.8 MiB

mpc-hc: 13.5 MiB (open source media player with many built-in codecs)

irfan-view: 3.4 MiB (image viewer/utility)

uTorrent: 2.3 MiB

Sysinternals Process Monitor: 1 MiB

For a truly native application, which doesn't pack a huge run-time or dependency tree, that's the expected size range. Now, it's true, it seems no one does that anymore ...

So many people just don't understand the scale of these things.

I stopped using LviewPro probably 8, or 10 years ago, but always wished I knew of a replacement that was so efficient. I see that IrfanView also does quite a bit more. I think I have a new favorite!

Now, if you'll pardon me, I need to drop the author a kind note. :)

I mention this because Delphi and Lazarus are quite high level environments to work with with rich frameworks and libraries yet you can create very lightweight applications with them (the executables will be a bit fat compared to what you can do with pure C/C++ or even pure Free Pascal, especially with Lazarus, but resource consumption is still low).

You do not need to use C/C++ with pure Win32 API to create lightweight applications and even if you use those there are frameworks that allow for easier development (e.g. WTL, Win++ or libui to mention some).

Windows could be so better with their old Windows 2000 style, without all those design jumps around.

[1]: https://en.wikipedia.org/wiki/C%2B%2B/WinRT

[2]: https://docs.microsoft.com/en-us/windows/apps/desktop/modern...

[3]: https://docs.microsoft.com/en-us/windows/apps/desktop/modern...

And IMO WinAPI not being hardware accelerated (although i think some parts of it, like filling and blitting, are hardware accelerated) isn't really a big issue - if anything, requiring hardware acceleration from you UI might be a hint that you are making it a bit too flashy. But that might be me preferring plain and compact UIs like those made with Win32 as opposed to website/mobile-like stuff.

I see this argument brought up in demoscene discussions ("your .exe is 4KB but it uses several GB of system libraries and device drivers!") and the rebuttal is the same: I'm assuming this UWP one itself makes use of other system DLLs too, like any other Windows application will, so the comparison is between 5MB + shared and 55MB + shared.

Even the 'Google' app on Android is 285 MB

Android is a whole other story altogether. The bloat is endemic there, and emulating that is not at all something to be proud of. Windows applications can be far more efficient, as Windows' own explorer.exe shows (and even that is probably not anywhere close to "perfection", but the difference is already enormous.)

That said, the bloat is real.

And with that it is still only 4.27MB+6.81MB = 11.08MB on my system. So yeah, the bloat is real no matter how you look at it.

For a native app of Windows Explorer kind that doesn't pack massive resources, 5-10 Megs is a reasonable size.

Heck, you are forgetting than something like 3D Studio MAX originially fit on a set of floppies and I can assure you it could do FAR more than "the Gallery app" whatever the heck that poor thing is.

no, had to build a few apps where this was requested only for branding purposes.

And these applications are not using "numerous DLLs" - just two files: app.exe and sciter.dll (and that one can be linked statically into executable).

So "yes", 50 Mb for an Explorer thing is too much.

Sadly, I have seen 'senior' engineers write much worse code than this...

I’ve run into a related behavior on iOS where I really dig some color palette while viewing in inverse colors and want to take a screenshot to capture it. The screenshot is “helpfully” stored as not-inverted color thereby stymying my efforts.

Optimizing for size may be less of a priority when a developer is focused on creating a positive user experience and adding useful features. Obsessive optimization of factors that users don't care about can lead to crappy applications — see quite a few open source GUI applications as an example.

This isn't production code published by Microsoft, it's an "enthusiast's take" written by a student learning to code. Most of my college colleagues couldn't make it through FizzBuzz.

Hopefully a bright new programmer doesn't get discouraged by getting smacked down in the top comment on hacker news.

The author is given a very clear indication that this is not a good direction, and hopefully changes direction quickly. He actually replied to another comment I made where I gave some advice (https://news.ycombinator.com/item?id=20130696), and said he continued working on it because of "overwhelmingly-positive community feedback", despite already being aware of the limitations of UWP. Maybe if he encountered a bunch of "UWP sucks, go Win32!" comments back then, he might've come up with something far more interesting and useful.

In other words, you can blame this idiotic "positivity culture" every time you see something half-assed, bloated, or just plain broken, or when huge mistakes are made because everyone was all smiles and happiness, and no one said NO until it was too late...

I was able to get a workable demo app going in just a few minutes using their Win32 approach. Seems very promising to me for purposes of building native-levels of performance into windows apps using managed C#. The performance statistics published on the repository seem fantastical, but I can believe it now that I've played around with a few of their demos.

Ah, The Perils of JavaSchools right there.

I agree with your comment. That code is beyond horrible, and it keeps on and on. Take a look at the other trending project on HN, Open Source Electronics Lab for $30. It has some nasty surprises on it's own, code-wise.

  // silly hack to get the tab control into a good state.
  // it gets confused when ...
  // and this seems to fix it.

Having said that, the code is still quite bad but maybe it was auto generated by a ui builder or refactoring tool.