Winslop UI Direction Poll

[Belim]

🗳 Winslop Direction Poll

Winslop just got a WinUI 3 port, but the classic WinForms / .NET Framework version still exists.

Now the question is simple:

Which direction should Winslop take?

Option A: The modern Microslop road

🚀 WinUI 3 / Windows App SDK
Fancy Windows 11 UI, modern stack, more complexity.

👍 React with 👍

---

Option B: The retro power tool

🛠 WinForms / .NET Framework
Lean, fast, minimal dependencies, classic Windows utility vibes.

👍 React with 🚀

Yesterday's WinUI meltdown

🎉 So after some experiments, frustrations, and a few choice words directed at Microslop's UI stack, Winslop ultimately stays true to its roots.

I need to vent about WinUI.
I moved Winslop from .NET Framework 4.8.1 to .NET 10 first and honestly, that still felt like half a solution.
So I went straight for the next "logical" step: a WinUI conversion

Here's the thing: I'm a minimalist. I like lean code, direct control, and software that doesn't require a small religion to maintain. That's why, in the Microsoft .NET ecosystem, I still stick with WinForms. Without WinForms, I probably wouldn't even keep a second OS partition just to run Windows 11. WinForms is one of the few things in the whole stack that still feels... sane.

So, WinUI. "Modern Windows 11 UI experience", right? (Screenshot below)

After about five hours, I had a working MainWindow.xaml and a connected feature page that sort of worked. But the scope and ceremony were insane. To me it felt like migrating a classic VB6 application to VB.NET back in the day. You know, back before Microsoft also decided to slowly suffocate VB.NET for sport.

And I'm sorry, but why is everything so Microslop?
There was a time when you could build a full Windows app with a few forms and some logic. Now it feels like you need three frameworks, four patterns, and a ceremonial XAML ritual just to show a button. We managed to land humans on the moon in 1969 with computers weaker than a modern toaster — but in 2026 a simple Windows UI apparently requires half the Microsoft ecosystem and a small architectural thesis.

F*ckkkk... Like… no, seriously. I'm not doing this. WinUI is a monster. It's not "modern", it's unbounded complexity disguised as progress.
It's a stack that constantly demands more structure, more glue, more patterns, more XAML rituals until your simple little utility starts looking like a corporate enterprise app with a thousand moving parts.

Sure, I could have made it easy and let a coding agent brute-force the conversion. But what's the point?
Programming is something I genuinely enjoy. It relaxes me. But not like this. I'm not 19 anymore, chasing the Silicon Valley fantasy of a multimillion-dollar startup fueled by vibe-coding and buzzwords. I want to build software, not manage a labyrinth.

And honestly, I should have known better.

If you want to understand what WinUI is, just look at the "fancy" Windows 11 Explorer:
pretty? maybe. but sluggish, inconsistent, and occasionally bizarre. It's the perfect demo of the WinUI promise and the WinUI reality.

The slow parts are WinUI 3, and the buggy parts are Win32

Microslop in a nutshell.
No wonder 80% of Microslop apps are web apps now — even those often feel faster than WinUI.

So yeah. Sorry, folks. Winslop stays a classic WinForms app.
I'm not spending my limited time on this kind of bullshit.

---

Vote with reactions or drop a comment explaining why.

The goal is simple:
figure out what Winslop should become going forward.

[Karl-WE]

I see different reasons for Winui3.

1. You have already invested time into this migration and a learning curve, frustrating at times. Your feedback shows that it takes some time but then it's like learning a new programming language results can only get better.
2. Some people raised feedback about requiring dotnet 10 while I think this will soon become as ubiquitous as C++ redist 2015 and later.
3. I don't think Winforms will ever die, as accessible as it is and still used by Windows itself, but speaking for dotnet 4.8 is certainly on a path to deprecation. In the next Windows Server it will no longer be part of the OS and requires sideloading, as with dotnet 2/3.5 today.

So maybe it is not just about personal preferences but rather technology and things moving forward. I believe the more you learn about Winui3 the larger will the ROI become also in terms of UX and workflow improvements, that you might not consider with Winforms.

Thank you for going through all the pain, investing so much of your free time.

[Karl-WE]

Thanks for your feedback Zoltwn @Falcosoft.
Reading it I have noticed an issue in my own statement.
Coexistance is not a problem at all.
Corrected

for both x86 and x64. as x86 executables, only.

Example: Citrix Workspace, Acronis True Image.

It's not because I am pedantic, even if I understand you say so

Allow me to resonate:

1. Apps available as x86 will become a blocker for Microsoft to severely reduce file system complexity, registry, patches and image /disk usage when removing syswow64 as a future goal. Maybe for Windows 12 or 13.
2. X86 cannot be protected the same way against attacks as x64. Not an expert here.

[Falcosoft]

1. Apps available as x86 will become a blocker for Microsoft to severely reduce file system complexity, registry, patches and image /disk usage when removing syswow64 as a future goal.  Maybe for Windows 12 or 13.

2. X86 cannot be protected the same way against  attacks as x64. Not an expert here.

Hi,
The biggest (or rather only?) advantage of modern Windows compared to modern OSX/Linux/Android is binary compatibility with more than 30 years of x86 software. This compatibility is even more inportant for big businesses than for home users. Microsoft cannot drop x86 compatibility without risking an even bigger 'I will never upgrade' movement than the Windows 11 related one. The 1st thing that MS had to do with the ARM based Windows 10 was to inplement an x86 compatibility layer (before the x64 one). Even Intel dropped the X86S concept for the same reason:
https://www.intel.com/content/www/us/en/developer/articles/technical/envisioning-future-simplified-architecture.html

The cost of maintaining compatibility with the vast, existing 32-bit software ecosystem likely outweighed the benefits. The initiative was seen as creating a potential "bifurcation" (split) in the market, complicating things for developers and customers.

So ovewrall I do not think such thing can happen with the next (or the next aftet the next) Windows version since the block is software products of 30 years, not this one :)

BTW, the AMD64 architecture defeated the IA64 (Itanium) one partly because it's a very thin layer that provides native execution speed for x86 software instead of heavy emulation.
There could be so many other ways to reduce bloat, complexity, redundancy in Windows besides killing 32-bit support. But no effort can be seen toward such directions.

[Karl-WE]

I kindly disagree. Windows 11 removed native 32 bit OS installs
Windows Server 2008 R2 removed 32 bit OS installs.
Windows Server 2003 introed them. So taking this schedule as an assumption Windows Server vNext (2028) is a perfect candidate.

I believe that removing syswow64 will come soon but optional.

From many OS out there Windows always provided the largest backwards compatibility.
In the mobile space or Apple based OS 64bit only hast been around for quite a long time.

[Falcosoft]

Hi,
We are talkingg about 2 completely different things. Native x86 OS vs. x86 application compatibility. As I said above the biggest advantage of AMD64 (x86-64) is that it can provide x86 application conpatibility without sacrificing performance or adding heavy/bloaty abstraction or emulation layer.
With an x64 OS you only lose Win16 compatibility not Win32. So with an x64 OS itself you lose virtually nothing related to x86/32-bit application compatibility. But dropping 'syswow64' would result in the biggest breaking change in the whole Windows NT line history.
And as you said Windows never treated the compatibility of legacy apps the same way as other ecosystems.
I would bet that x86 compatibility will be preserved on the x86-64 Windows OS line while the underlying CPUs support it the same way.
Of course it's not impossible that in case of servers the 32-bit subsystem can be only optionally installable. There were even Windows verisons - although not too successful ones :) - that were only able to run store apps (Windows 10 S).
My bet applies to the mainstream x64 OS line.

[Falcosoft]

BTW, you can run 16-bit Win16(!) apps natively even on 32-bit Windows 10 if you enable the optional NTVDM component. That's why I argue that 32-bit Win32 apps will work until x86-128 arrives :).

[tonyberetini-burai]

Definitely modern approach

[CT-ABT]

Option B. The ‘modern’ style—the so-called ‘Fluent UI’ branch, all those rounded corners, extra-slim lines or even no lines, evilish colours, etc, are utterly disgusting. Anything up to Windows 10’s visual design was fine, but definitely no Fluent UI.

[ed-br]

The future of Windows is clearly WinUI, so you should really lean into that framework, @Belim. Its also much easier for the average user to handle. The old GUI was more of a power-user thing anyway

[Karl-WE]

I would like to bring up another aspect of this point.

Imagine a new gen user, they didn't grew up with winforms, so their first impression of the app might be either oh that UX is very practical and offers great overview OR they might have an impression like...
Wow that's looks so 90ties (before I was born), I cannot even read and use it well with my high resolution touchscreen features.

[Falcosoft]

For this hypothetical 'new gen user base' even the existence of this app is not relevant. Most likely for this hypothetical user base even the concept of real 'personal computing' where you own your hardware/software and can customize and decide what way your OS work is already a concept of the 90ties :)

[Bapf]

With the current packaging: The old version.
Because having to install an additional SDK to run something that's supposed to make Windows (c)leaner is somewhat counterproductive.

If the packaging can be change so that the windows App SDK isn't needed / included in the binary, than I'd vote for the new version.

[Belim]

good point 😄
and yeah, it’s not just the runtime the windows app sdk dlls (the ui framework itself) also weigh a ton. turns out modern ui frameworks come with a small truckload of dependencies. im looking into packaging options though, so lets see how much of that can be trimmed down

[antwnhsx]

A lot of people, myself included, naturally gravitate toward newer stacks because they promise better tooling, nicer UIs, and a more modern development experience.

Modern frameworks are powerful, but they also bring layers of architecture and dependencies. For some projects that trade-off makes perfect sense. For others, it’s just overhead.

I’m not against modern frameworks, but I see Winslop fundamentally as a tool. At the end of the day, the most valuable resource in an open-source project isn’t the framework, it’s the developer’s time.

[Mykinius]

If it's between those two screenshots, definitely the retro one. Why? Because the WinUI3 mockup in the OP here is afflicted by some of the very same UX regression paradigms that have led to win11 Explorer/Settings UIs feeling awful to use beyond the embarrassing performance hit:

• Fewer colors, worse contrast between elements: no button borders showing that labels are buttons instead of just as-is text, no green border, no light grey background behind the checkboxes to make the text field in the lower half more easily discernible, etc. Just a flat, homogeneous off-white on everything.
• Needlessly larger text and huge padding, leaving less room for buttons or list items: "Tools" has been replaced by an unlabeled ... button, and the WinUI3 version only shows only 7 items vs. the original's 18. You want to intuitively convey the options available, not hide them from easily intimidated tech-illiterate users.

These things can probably be solved in WinUI3 with further wrangling. But the current style (and what I assume are WinUI3 defaults) is functionally a big step back.

After writing all of the above, I saw the collapsed "Yesterday's WinUI meltdown" section. Definitely the right call given all that predictably BS modern framework nonsense that reflects my own previous poor experiences with WPF vs. Forms. Maybe there's a modern UI framework out there that isn't such needlessly tangled spaghetti crap, but I don't normally do UIs so don't know of one yet.

[Belim]

fair take and i agree with most of it.
this is still a very early pass, and ive only just started optimizing the actual ui. a lot of the current look is still winui3 default behavior, not the final direction
for now ill keep shipping both. the winui3 package will also include winslop.legacy for those who prefer the classic build

[KnivesTV]

Beauty is only skin-deep. Lean, clean and easy to code means you'll stay sane longer. Retro it is.

[jakemontijo95-ops]

I think the main takeaway from this poll is the almost even split between the results. Modernization will bring dissatisfaction to >50% of the users. you probably knew this already, idk, this is my nothing opinion to keep in mind.

[click-click]

Does a simple tool (set and forget) like Winslop really need to go with the flow? What's next, more crap
with WinUI 4/5/6..?

I understand it's a good idea to keep one's skills updated as a developer and I respect that, but please
keep in mind those of us that love apps with minimal impact, zero footprint and no extra baggage. I will
be using legacy until it is no longer kept up to date. What comes after that, I dunno. In this modern
day and age, KISS ("Keep It Simple, Stupid") for Microsoft no longer has much meaning.

[yamaue40-ship-it]

🚀

[Belim]

@click-click @jakemontijo95-ops @KnivesTV @Mykinius @antwnhsx @aloneguid @Karl-WE

fair point and honestly both sides have valid arguments
looking at the poll results right now (~50/50), its pretty clear that Winslop currently has two audiences. if i force a single direction, ill likely end up frustrating half the users.

Thats why my current approach is

1. winui3 build as the main experiment
2. winslop.legacy.exe for the classic winforms version
3. this way people can simply choose what fits their preference.

technically speaking, winui3 is where much of the modern windows ecosystem is heading. a lot of built-in windows 11 apps already follow that design direction, notepad, calculator, settings, and others. tools like powertoys are also built around the same modern ui stack.

like it or not, thats the visual language microsoft is pushing across the platform. and in software, just like everywhere else, appearance matters, beauty sells.
the funny part is, that winslop is still very much a set-and-forget tool. you launch it once, apply your tweaks, and youre done. so in the end the ui mostly has to look right and stay out of the way, which is exactly what these modern frameworks are trying to standardize across windows. that doesnt mean the classic approach is wrong.

in fact, winforms still excels at

• very small footprint
• minimal dependencies
• fast sartup and dense layouts
• direct, efficient ui control

winui3 on the other hand brings

• native windows 11 fluent design integration
• modern composition/rendering pipeline
• better long-term alignment with the windows app sdk ecosystem
• easier accessibility and adaptive Layouts

so for now the plan is simple:
i will ship both, gather feedback, and see what people actually end up using in practice.

but realistically speaking, at some point i will probably have to move further in the winui direction anyway, if only from a developer perspective. that's where the platform, tooling, and ecosystem are moving, whether we like it or not.

and while many of us still appreciate the efficiency and clarity of classic desktop UIs, a lot of newer users simply didnt grow up with those windows-98-style interfaces anymore. for them, the modern windows 11 look is just the normal baseline.

so for now, i will experiment, listen to feedback, and see where winslop naturally ends up.

and yes, when i started this migration i was very skeptical (and honestly pretty annoyed) about the whole thing. i even wrote a small rant about it here https://github.com/builtbybel/Winslop/blob/main/CHANGELOG.md
so this whole winui port is still very much an experiment in progress

[khaledJ-hash]

I chose The modern Microslop road, because knowing Microslop's history, they might remove ceratin frameworks etc.
I have seen this happen quite recently.

[Iscariah]

I had to install a new runtime for the new layout tool. Retro is much better; it's so much smaller and doesn't require me to install even more stuff to run. No need for fancy stuff.

[Karl-WE]

The runtime will be required for other apps too

[Karl-WE]

@Belim do you like to have the new app listed in Winget repo? What about the old one?

Since the current winget yaml supports dependencies it would fetch the runtime, the app and install when necessary.

Suggestion:

Builtbybel.winslop, moniker winslop, dependency package name for dotnet 10 runtime

Buildbybel.winslop.classic

[Iscariah]

The runtime will be required for other apps too

Well, it's definitely the first app for me that requires an installation of Windows App SDK 1.8, which actually is even more than a runtime alone, because it's an SDK (Software Development Kit)

The old tool didn't require this.

[SubZeroBR]

Definitely the Retro/Classic build. The new WinUIslop interface has needlessly large spaces and fonts, wastes space for other options to fit tidily around the app, strange kerning all around, the list goes on. It's like people lost their 20/20 vision. Rounded corners will never be a thing. I like precision-pixel arrangements, and will always prefer easy-to-see boxes, lines and frames. WinUI was a deranged direction taken to compete with other cough Apple cough systems to try to be the "new coolest kid'round the block".

[thompsi]

You know you love it despite your moans! Just think of the satisfaction of getting there. Keep up with Microsoft's changes. I'm voting for the modern way!

[aloneguid]

This is not Winslop criticism, but rather Microsoft. I don't think "modern" way is actually modern. Desktop app development mostly went downhill due to how bad the modern windows UI stack is. Name one application you use daily that is WinUI 3.

[Belim]

notepad was literally the best app microsoft ever built and somehow they still managed to “modernize” it into something worse
have some faith in me. winslop will be the first actually usable winui 3 app right next to notepad 😆

[Karl-WE]

I am still happy that they even touched it both classic notepad and store based one.
I never thought this would ever happen since there is no financial motivation.

Another nice app, maybe lesser known, is the modern version of ```
edit

[GodsBoy]

Option B, no question.

Winslop is a set-and-forget power tool. You launch it, apply your tweaks, and close it. The UI just needs to stay out of the way and do its job fast.

WinForms delivers exactly that: lean binary, zero extra dependencies, instant startup, dense layouts that show you everything at once. WinUI 3 brings rounded corners and a truckload of SDK baggage to a utility that debloats Windows. The irony is hard to ignore.

Belim's own rant in the changelog says it better than any poll comment could. The WinForms version is already the right answer. Ship it, keep it fast, keep it simple.

The community that actually uses tools like this grew up valuing efficiency over aesthetics. That audience is not going anywhere.

[KnivesTV]

What @GodsBoy said was spot on the money. I couldn't have said it better myself. This is what the project needs because this is what the project represents.

Imagine using a bloated 40MB pretty tool to unbloat Windows just because half the users want something aesthetically pleasing to look at for about 30 seconds. It serves no purpose, but at least it looks modern, and that gives you a good feeling. Now imagine using a 200KB tool that is easy to code, maintain and run, and it gets the job done just as well. We're talking about ~200x physical size difference here just to have rounded corners and a pastel colored rainbow theme.

After you use Winslop, you close it and forget about it for a while.

Tell me: Does it really matter how pretty it was? Does it create lasting memories of that time you de-slopped Windows, or is it more important that Belim puts his time and resources into making a tiny little tool even better for the rest of us without wasting time fiddling around with unnecessary complexities and bloat that WinUI 3 provides?

Really think about it. Common sense should be kicking in about now.

[Belim]

@KnivesTV i get your point, and honestly i had the same argument in my head before starting this whole thing.

but something interesting happened after the tool got “modernized”. suddenly a bunch of blogs, youtube channels and tech sites started reaching out and covering winslop. before that it apparently looked too old, spartan and power-user-ish for the broader audience. for many people it simply looked… well… ugly

so it seems the reality is: people do care about appearance. beauty sells. and judging by how many modern windows apps look today, microsoft probably knows exactly what theyre doing there 😄

that said, im still not convinced that the whole winui stack isnt a bit of a monster. technically its far more complex than it needs to be, and the migration was honestly painful.

but now that ive opened that door, i can't just walk away from it again. unfortunately im the kind of person who has to finish what he started

so in the next releases ill try to squeeze out as much efficiency as possible both in terms of size and performance while keeping the tool usable for both camps

[Falcosoft]

The goal is simple: figure out what Winslop should become going forward.

Hi,
What about an 'intermediate solution' ? That is adding a proper manifest file to the legacy executable so common controls that can be themed by the OS itself become less Win9x style. Something like this:

PS: I had to remove the included manifest resource from the executable's resource section since the included one is recognized by none of the Windows versions I tried. After removing the included one an extenal one like the attached below worked:

Winslop.exe.manifest.zip

[samcode44]

we don't mind the modern way but the size is matter here! anyway thanks in advance for your amazing work and effort.

[leftdisconnected]

The WinUI 26.03.110 release is 44 megabytes in size while the WinForms 26.3.31 version is 200 kilobytes in size. That answers our question quite succinctly and I have ZERO understanding of why someone would prefer the former.

A proper application should fit into kilobytes or maybe a couple of megabytes of code; anything larger suggests incompetence. What's the point of a .NET environment if the distributed executable is a 50MB package? How is .NET helping?

I suspect that at some point people are going to give up and let Claude write our applications in MASM. As some have noted all along, .NET was the beginning of the end for Windows; it's been downhill ever since.

MS can shove their "Fluent Design System" right up their stack.

My 2 cents obviously don't matter as I'm not the one trying to make Winslop have the highest impact to the most users, but there they are ;). I wish Belim all the best as they try to navigate the path forward on a platform that is less and less profitable, and thus less important, to Microsoft as time goes on.

Microsoft is not an OS company anymore; it's a cloud company that unfortunately still owns a legacy OS.

[Karl-WE]

I get your frustration but the new app is only that large as people don't want to install a common dependency.
So @Belim included it.

Secondly looking at winslop exe it's even more compact compared to classic.

Does it calm your legit point down a bit?

[leftdisconnected]

looking at winslop exe it's even more compact compared to classic.

Does it calm your legit point down a bit?

Yup. I should have inspected the contents before making a statement, but I was in a rush and frustrated by the obvious difference in download size. Dependencies are relevant to the package size, however, as you still have to download them if they aren't already a part of Windows. You are correct, though, as the EXEs and other program-specific files are what counts towards program size.

Thanks for correcting me.

[JohnLGalt]

@Belim

Aesthetically, WinUI3, because I'm so over XP. But to keep from driving you Postal - whatever you decide.

I'd venture that the vast majority of users are not, in fact, here for "pretty pretty graphics" - they're here to change something (or many somethings) that Micro$oft simply fucked up. Whenever that happened to be.

It's not something that's gonna be sitting in their trays that they consult every 5 minutes (aka Discord, or whatever the new thing is to replace Discord these days). Run it, set your Windows up the way you want, and then (hopefully! I must include the caveat!) you don't run it for at least a few months.

Besides - you're the one that wrote:

https://github.com/builtbybel/Winslop?tab=readme-ov-file#built-to-remove-things-not-to-impress-you

So, yeah. I don't think you'll be worried about the 3 people who stop using it if you abandon the WinUI3 version.

[mariachi444]

I actually don't have much knowledge about WinRT or UI development on Windows, but dude, you put in a great effort to redesign the app in a framework that consumed many hours of your time, and you also avoided that c*ncer they call "Vibe coding".
Personally, I congratulate you on this and think you shouldn't give a damn about the opinion of a random who hates and criticizes the new design implemented by Microsoft but still uses Windows.
We have to adapt to changes to survive.
I vote for new design.

[Belim]

yeah its been a few tough weeks tbh, i usually pick things up pretty fast but this was different. maybe i can still push winui 3 to the next level though 😃