Ask HN: Why is building Windows apps so complicated?
However, building Windows apps is very complicated even when you know C++ or C#.
1. I wanted to build Windows 11 apps and I had to choose between Windows Forms, WinUI3, Win32 and WPF I think. I don't really know the difference between the 3 and no one really explains that (unless Win32 which is obvious).
2. Apparently, WUP is no longer recommended. A few years they were pushing it to the max. Bummer.
3. I installed Visual Studio overnight (it comes with all the tools that building apps need). It downloaded 6GB of data and used 20GB of storage. All i want to build is a hello world app.
4. I create a project following a guide from Microsoft.
5. The app is extremely resource heavy and way too over-featured. I build the boilerplate app and Run it and it takes minutes to build (most of the time is downloading dependencies so not such a big deal).
6. I open the newly created app in Sublime Text (my editor) and I can't find a way to build the app anymore.
7. Because Visual Studio is so bloated, I download Visual Studio Code, which is far more simple but I can still not figure out how to build my app even with the various extensions VS code boasts.
8. After hours of googling, I formulate a script that can build the app from the command-line.
9. But I stil don't know how to build the app as the .exe file created does not execute.
10. I'm very disappointed.
The worst of all is that there is not even one good guide on the whole clearnet on how to do develop a Hello World windows app from scratch.
502 comments
[ 0.20 ms ] story [ 354 ms ] threadI take it you're leaning largely on this?
having worked at a company that's gone down that road, I think the jury is out whether that was a great move.
But now it's a lot better. There's more consensus on what should be used, and most frameworks seem somewhat stable. Tooling is straightforward, in part thanks to VSCode I guess. Things like ESLint, JSHint are now standard. Altogether it feels more robust.
This hasn't changed.
2. Terminal ,pick a folder, `dotnet new wpf`
3. `dotnet run` and you have an (admittedly empty) hello world app
It's telling me it took 1.5s to build the app.
Want to publish the app?
`dotnet publish -o ./publish -r win-x64` which takes a bit longer as it has to download some runtimes (60 seconds max, then cached). Zip up the resulting folder and ta-da you have an application. Just unzip and run the .exe.
If you want a single-file exe (as in completely statically compiled without self-extraction) that's a bit more advanced and requires a few properties in the csproj to configure how to handle native assemblies that expect to exist on disk. If you want it to have no runtime dependencies, add `--self-contained`
As someone who had to develop software in an airgapped enviroment, I'm sending a special "fuck you" to whoever thought this is a good idea. God forbid you have the AUDACITY to not be connected to the internet at all times for any reason whatsoever.
What if I installed the software with the intention to run it without internet, or 5, 10 or 100 years in the future?
And yes, this sucks. But if you want freedom, there are other OSes (or even other dev tools) where you can have it.
You can download all versions of Android if you want, but i doubt that you would want that.
And you can likely mention it as an explicit dependency in your csproj so that you can download it on first restore.
That's exactly what you have to do here.
I understand OC issues with the difficulties associated with using M$ tools with limited internet but wonder if the "Air Gapped" example may be a bit extreme.
Being required to work from home while still meeting an employers' secure network policies might be more common.
Also, when you write something on those environments, you know users cannot install a runtime. So you get in touch with IT teams to ensure which version of runtime they are deploying. If and only if you have to update it for proper reasons, then they can deploy newer versions to the clients. For all or for a specific user base. This is how it works.
Without an actual business case or a security concern, you don't just go from a runtime to another, let's say 4.8 to 6.0. So yes, development in airgapped environments is PITA. But it's the same with Java, Python, Perl, etc. That's not the fault of the runtime but the development environment itself.
I certainly wouldn't want to ask that the other 99% of the world's developers avoid a feature that's useful to them just to assuage my feelings of envy about the convenience they enjoy.
Nope. The exe files are supposed to do it's thing without internet and no extra effort like it was for a long time.
Contrast this with e.g. Zig for Windows is a ~60 MB zip file which contains the entire Zig/C/C++ compiler with cross-compilation support for basically everything, and also has complete Win32 headers + libraries in it. There's even DDK headers in there, though I'd expect to do some legwork to build drivers for NT with Zig.
I'm not really sure what you're complaining about here. .net core is split into tiny packages - if that is hard to handle in your very special environment, you get to use special solutions to make it work.
That being said, WinForms is also "just" a Win32 wrapper, I don't see a compelling reason why a similar wrapper wouldn't be possible in pretty much any language. .NET 4.6 is a fine choice too, especially because you're not forced to ship runtime and standard library, as Windows already has both.
We don't even require the internet for building/development. In .net land you require internet to get the dependency you're using the first time. If you want to get them all and distribute/install before you start development, you can totally do that. It's just not the default behaviour.
I get that you have opinions, but you seem to have entirely missed that the runtime is downloaded at build time and included in the bundle. And god forbid if you like doing everything by hand, you don't have to use Nuget and you can manage every last dep by hand, however you like (and you'll likely end up hacking something that is less usable than just setting up a private nuget server, but "opinions").
This does mean that certain programs just won't work, or won't work without some finagling. That's also a feature. The price of control is having to control things.
Granted, most people don't want to pay that price, and prefer convenience. That's admittedly not to my own taste - c.f.) log4j for a good example of why - but I think I'm maybe a little weird there. I certainly don't think there's anything audacious about catering to majority tastes. Maybe just vaguely disappointing.
Saying people prefer one to another hides the fact that they were not given any other option. People will choose whatever default is given and then we may say they everyone prefers that. Or just make the other option (which was normal before) complicated so that nobody wants that now.
Yes, technically easy but if their work environment is strict enough to enforce air gapped development, I imagine the bureaucratic process to accomplish such a thing to be a bit less than easy.
Do you even know what an airgapped computer is?
What I miss is the old model for installing software. Give me the yearly ISO, optionally provide a service pack or two if some huge problem went under the radar in testing.
If you don't want it to download anything then you use the `dotnet publish --no-restore` flag, which is used a lot in CI/CD pipelines. If you don't have the package dependencies cached it will then simply fail.
The internet exists, the industry has evolved, software has dependencies, and yes you have to download them (just like you had to download the SDK ISOs back in the day). But it's just one command, run it and get it over with, and after that up-front one-time pain you'll have a nice offline workflow.
For many, it is not so black and white. Internet connections are spotty, slow, or expensive. In GP’s case, there is no internet.
Like I said, you are welcome to ignore those users. But your ignorance (I don’t mean that in a derogatory way) doesn’t change their situation.
I should be able to take my computer to a remote cabin with no Internet, and use all the software on it. The only software I'd expect to not work is software whose purpose is to access data stored on the Internet, like web browsers. I don't think this is such a crazy user expectation.
That is easily doable. However users often don't want a copy of a large runtime for each and every program they use, so it often makes sense to move common things (like DLLs, runtimes, your OS) to libraries that can be shared.
You can easily make dotnet apps in either flavor to your liking. And not every developer is going to make their apps to appeal the your needs.
In days gone by we used to have truly standard libraries and runtimes, in the sense that they came with your build tools out of the box and so were available everywhere. Host platforms similarly provided basic services universally. Documentation was often excellent and also available out of the box.
In that environment, writing "Hello, world!" meant writing one line that said do that, maybe with a little boilerplate around it depending on your language. Running a single simple command from a shell then either interpreted your program immediately or compiled it to a single self-contained executable file that you could run immediately. Introducing external dependencies was something you did carefully and rarely (by today's standards) when you had a specific need and the external resource was the best way to meet that need.
Some things about software development were better in those days. Having limited functionality in standard libraries and then relying on package managers and build tools where the norm is transitively installing numerous dependencies just to implement basic and widely useful functionality is not an improvement. The need for frameworks and scaffolding tools because otherwise you can spend several hours just writing the boilerplate and setting up your infrastructure is not an improvement.
Usually you had to dig a bit and could find an "offline installer". Sometimes an "alternate downloads" link is on the initial download page, sometimes you have to good to find a deeper link on the vendor's site.
I always did that just to keep from needlessly reaching out to the internet X times when updating X machines.
And of course, make sure you're getting it from the vendor and not some sketchy download site.
In this particular scenario, my first thought was "shoulda used golang".
I hear tell that since then (1+ yrs ago) matters have improved in the realm of MS standalone apps (well, maybe just cmd line apps).
oh, and the exe is round about 65mb compared to a golang ~5 or 6mb
This is important because I support each release of the distribution for up to 10 years, and have some customers who may need to build it in an air-gapped environment.
[0] https://chiselapp.com/user/rkeene/repository/bash-drop-netwo...
Personally, I just run things in network namespaces with "ip netns exec offline|wireguard $COMMAND" to restrict net access.
I thought about using a network namespace, but that would make things more complicated since I would need to re-call my shell script to pick-up where I left off (because it requires creating a new process). I initially tried to implement this using network namespaces, but you cannot "unshare" the current process, you must spawn a new process.
With dropnet I can do
With "unshare" I would need to do more work to get to "configure()" in a new process.https://www.verizon.com/about/news/how-far-does-5g-reach
> 5G Ultra Wideband network’s signal can reach up to 1,500 feet without obstructions
> 5G can be implemented in low-band, mid-band or high-band millimeter-wave 24 GHz up to 54 GHz. Low-band 5G uses a similar frequency range to 4G cellphones, 600–900 MHz, giving download speeds a little higher than 4G: 30–250 megabits per second (Mbit/s). Low-band cell towers have a range and coverage area similar to 4G towers.
— https://en.wikipedia.org/wiki/5G#Overview
5G is _perfect_ for providing coverage in rural areas, except for the problem that 4G devices are incompatible with 5G networks. Starting 5G rollout in urban areas makes more sense because (a) 5G provides most benefit when clients are close together, and (b) because denser cells make it reasonably economical to maintain 4G coverage in parallel to 5G coverage.
Either way, if we're talking about "coverage" for low-bandwidth stuff like fitness trackers, it's the spectrum that matters more than anything. We can communicate thousands of miles on 1 or 2 watts of LF spectrum using technology that is nearly a century old. Don't need 5G for that, just need to use the right spectrum.
Syncing / uploading then happens once they have signal again. Or in the case of the Garmin I copy the FIT file off by hand when plugging it into my computer.
There are many apps that let you track your run/hike/ride without internet connection.
Personally, I think a dedicated bike computer is best, because then the phone's battery is saved for emergency uses instead of recording a ride. For long rides (8-10 hour) phones won't have enough battery to record the whole ride.
An android app is software.
Not hardware.
Hardware is cheap, network is reliable. Move fast and break things.
Neither of these assumptions are true, and we're going to have these issues by truckload, until we understand and change our mindset.
Scuba diving spots on the world are rarely well covered with internet and even if they are, still many people don't have the roaming/local SIM solution for it.
Guess where you want to use that damn app the most?
Not a great way to get new customers though as it requires missing out on logging a ride to become aware of a reason to buy.
No log in, no external services.
- Sygic,
- Topo Map+,
- 2GIS
- Starwalk - Night Sky 2
- and my fav, Genius Map
all works without WiFi, cell coverage, nor NFC/bluetooth
Even if it cost money to install, you are just paying for the privilege of being tracked by those folks instead of others.
#appsnotevenonce
At least the website works, even though it transmits the full site for every request...
Discovered this when I tried to add a WiFi password before connecting to it.
I wouldn't say the campfire was ruined, by my goodwill toward this product certainly was.
Your goodwill deterioration does not matter unless you switch a new a app[1], and a) Make sure that new app can function without internet, and b) Tell your current app developers why you are switching.
So, yeah, your goodwill is irrelevant is you're still giving them money or value. [1] I assume that it's a subscription - most things are nowadays.
Like every other dev system, connect, either download offline installers for everything (they exist), or get your system running, then you can dev offline all you like.
You don't need to "be connected to the internet at all times for any reason whatsoever". You need it once.
You can even prefetch popular libraries: https://crates.io/crates/cargo-prefetch
But to this day, nobody knows what data your system telemetries to Microsoft. Not the data they talk about in the 5-10 page license. Instead, the data mentioned in the 55 page doc about what you agree to send them, that they refer to from the MS Software License...
The end result is a Golang-like, single binary experience that runs on many platforms easily and rapidly.
Though I can master a lot of programming languages, I miss C# the most especially on async/await and LINQ. Rust is what I'm favourited in second places with a lot of similarities of C#.
[1]: https://docs.microsoft.com/en-us/dotnet/core/deploying/singl...
This. This is what's wrong. Why is single-file exe "a bit more advanced". In early 2000s Delphi could build a single file exe in seconds, and that was the default behaviour.
What changed since early 2000s that having an exe is a) advanced and b) requires manually fiddling with some unspecified properties in the abomination that is a csproj file?
I'm not sure I know any frameworks that easily support arbitrary native .dll/.so inside the application executable.
OP asked how.
The answer was, quote "If you want a single-file exe (as in completely statically compiled without self-extraction) that's a bit more advanced and requires a few properties in the csproj to configure how to handle native assemblies that expect to exist on disk. If you want it to have no runtime dependencies, add `--self-contained`"
Somehow creating an exe is "more advanced", and requires changing of unspecified parameters in the project file. wat.
I'm talking about creating a single-file application, which is just an end-user nice-to-have if you aren't using an installer or deployment system.
Don't most applications have a bunch of ancillary files? I rarely see installed applications on any platform that are a single file.
.NET Core is cross platform, it was created with ASP.Net as the driver and web development is not about exe files. "dotnet run" runs your code, on any platform, that's one of the default intended ways to run code. If you want a platform-specific executable you've done more work and made the code less general. If you also want to package the entire .Net framework into one binary on any platform, why is it unbelievably impossible to understand that this is more effort and desired by fewer people, so isn't as easy to do?
Strategic decision from Sun and Microsoft that has crippled software for 2 decades already.
Because that's how it works for very every single interpreted and bytecode compiled language?
And the thing that changed in the early 2000s was a massive shift toward using interpreted and bytecode compiled languages.
If we're specifically talking .NET, the thing that changed since the early 2000s is that creating a self-contained executable became possible in the first place. On Windows, .NET *.exe files were still run by an outside runtime, it's just that, since Microsoft owned the whole platform, it was easy for them to hide all that behind a curtain, ensure .NET is preinstalled with Windows, etc. The design constraints changed when .NET became cross-platform. OS X and Linux require a bit more (or at least different) finagling in order to achieve good user experience.
Also please dont lump interpreted languages with C#. At least with interpreted languages, once you have the runtime on your computer, you can have a single script file to work with. With C#, you STILL have to have the runtime on your computer, then after you "compile", youre left with a folder of one EXE and literally over 100 DLL.
No you don't. If you'd rather increase the download size for the user then you can turn on self-contained (include runtime) and single-file app.
The main difference is that Python installs them globally (or at least thinks it does, if you're using virtual environments), while .NET apps isolate themselves from each other.
Also, let's make a fair comparison. Is that hypothetical Rust application of yours depending on literally 100 crates? If so, what is the size of your binary?
I love Python, but I cringe whenever someone asks me why a Python program isn't running properly on their machine. Obligatory xkcd: https://xkcd.com/1987/
In fact, composer uses dependencies managed by itself in their sources. Then it gets packaged and distributed as a single file that includes all dependencies (composer.phar). That single file can be run by php as if it was any regular php file (including executing it directly and letting your system detect the required interpreter through the shebang).
https://www.php.net/manual/en/intro.phar.php
The Python people stuck in venv hell would probably think otherwise.
1. Build it runtime dependent: ( which requires the NET 6 runtime to be pre installed ) on your computer in order to be able to run: You get a single exe file.
2. Build it self contained: You get a directory with a bunch of dlls and one exe But no runtime needs to be installed on the target computer
3. Build it self contained + single exe: You a get a single exe that embeds all those dlls and unpacks them in memory ( since net 6, in net 5 it would copy them to a temp directory )
4. Build it using AOT Mode: You get a single, statically linked exe. This is probably the closest to a standard Rust (statically linked) build. However AOT mode is not yet official and requires some fiddling still, but should become stable for NET 7 next year. And you loose out on some features obviously like runtime code generation
I went ahead and searched for C# executable around 2005-2006. Guess what, this wasn't even a question then. Because, apparently, building an .exe was also the default setting for C# projects in Visual Studio.
So. What changed?
> If we're specifically talking .NET, the thing that changed since the early 2000s is that creating a self-contained executable became possible in the first place.
It was always possible.
> On Windows, .NET .exe files were still run by an outside runtime
1. We're literally in the thread to a question about Windows apps. On Windows
2. If you've ever did anything on Windows such as played a game, you'd know that you almost always need something external to run: be it msvcrt (c++ runtime) or clr.
> The design constraints changed when .NET became cross-platform.
What you mean is: it's still perfectly fine to create a standalone executable, but for some reason it's now called a "more advanced operation". The thing that's changed is that now it's hidden behind a ton of inconsistently named parameters
They were much more comparable to an "executable" Python or Perl script where the OS knows to look at the hash-bang line to figure out what interpreter to use to run it. If you try to execute one of those .NET .exes on a computer that doesn't have a suitable .NET run-time installed, you'll get more-or-less the same error as you'd get trying to run a Python script on a computer that doesn't have Python installed.
The part that was being criticized a few comments up was about how to create self-contained .NET apps with the runtime bundled in and everything. Specifically, these guys: https://docs.microsoft.com/en-us/dotnet/core/deploying/#publ... That kind of executable simply did not exist in the old Windows-only .NET Framework; it's a feature that was first introduced in .NET Core 3.0.
Just as you would try to execute a program written in C++ (and not statically linked etc.) on a computer that doesn't have a msvcrt runtime installed.
This is not a new thing. Nor is it a "more advanced".
It feels like you're getting too hung up on "exe". The important part is standalone vs. not standalone.
I for one don't want every application to include 100's of MB of standard components that every other such app also brings (such as Electron style apps). I'd much rather have an app tell the OS to fetch missing pieces once, and once only, then future apps share.
And this also mitigates a significant source of security holes. Nothing like linking everything and the kitchen sink so your system is riddled with unknown, hidden vulnerabilities in binaries.
For example, I recent worked on tools to search for such things - they are EVERYWHERE. OpenSCAD, for example, includes a ssh engine, which has known vulnerabilites, but OpenSCAD does not list them. I found thousands and thousands of embedded binary libraries in applications with known and unpatched vulnerabilities.
Too bad all those didn't use a decent package manager, allowing systemwide updates to common functionality. I suspect the future is more components, not less, for these reasons.
In other words, compare missing msvcrt.dll more to missing libc.so than to not having a JVM or whatever installed. I guess from end user perspective the end result is the same - the program won't run - but what's actually going on under the hood is very different.
Short story: developer interests unfortunately don't always align with tool builder interests.
The old Delphi-based version of Skype fell into that category. Thinking of that example, I can understand why some people think modern software is decadent.
It's really easy/simple to change an application to adjust for a different client this way.
That means that by default you can't do tree shaking, which means you would end up with enormous exes, which will probably annoy the type of people who want a single exe.
The bit more advanced is to tell the compiler which types you might want to reference by reflection so that it can shake the rest out of the tree.
Microsoft could do a much better job onboarding new developers.
Hell just recently they were trying to take away hot reload to keep that feature as a paid feature only part of VS
I only really started liking .NET when I stopped using visual studio a few years ago.
The fact this edition exists does not change my point, or really add anything of value to the conversation
The C# team says "this is the new best practice" while VS still drives you to The Old Way all the time.
https://news.ycombinator.com/item?id=28972431
There was a whole fiasco where the dotnet/C# team were forced to remove features from dotnet in order to sell more copies of Visual Studio. Later, Microsoft lied through their teeth and said it was some kind of sprint-planning scoping error, even though the development work was already done.
Full disclosure: I know what I am talking about
Except, everyone else cares about everything else .NET Framework has been used for the last 20 years.
This was quite telling on the .NET 6 release with its minimal APIs to compete against Python and JavaScript "hello world" apps. As soon as one scales beyond that, it is back to the old MVC model.
If you want an installer BTW, use "Wix".
If you are eligible for VS Community, do give it a go: https://visualstudio.microsoft.com/vs/community/ since that has the WPF designer in (the WinUI3 designer is inexcusably broken)
I just tried VS2022, and the UI designer for WinUI3 is completely non-functional? What is the recommended approach to lay out the UI pages these days?
- ignore Winui3 and do it in WPF (fewer controls, deprecated, actually works)
- do it blind in XAML, possibly with the aid of a piece of paper. Or the "live view" in VS if that works. (Live View is the suggestion given on the github issue for "designer doesn't work", fwiw)
- do it in the UWP designer, then s/Windows/Microsoft/ in the control namespaces
I hope SwiftUI and flutter will be able to make it at least a little bit better.
Isn't WPF getting phased out tho?
wpf is a stack for slow bloated apps (200mb for a hello world and 300 dlls)
even electron is lighter than this.. electron..
microsoft needs its swift + swiftui moment
Compared to what? GUI programming has always been hard on all platforms I tried.
Open VS -> New Project -> Winform/WPF -> Run
1. Open VS, wait a minute. 2. New Project 3. Run, wait 10 minutes for dependencies to download. 4. Want to use Sublime Text or VS Code, haha lol.
Why would you need 10 minutes?
>dotnet new winforms
>dotnet run
>app appears
takes a few secs
even on old .NET there was no such a thing like 10 min wait for dependencies to load
If you're used to developing on Linux where you can self-host entire repos, it's incredible how fragile and ephemeral the MS stack must feel.
>If you're used to developing on Linux where you can self-host entire repos, it's incredible how fragile and ephemeral the MS stack must feel.
I guess he's talking about restoring nuget packages, so of course you don't want to have all existing nugets in all versions on your disk.
You're playing on hard mode; try using Visual Studio for everything.
I've also found Python + Gtk (in the Python 2 and Gtk 2 days) very simple and productive.
There are a ton of problems that you have in webdev that don't neccessarily exist in a local app. Mostly from the fact that you have state everywhere, in the client, on the server, and in the database, and you have to manage it asyncronously. React helps with it a bit, but in principle a desktop app can be "100% frontend" (I mean you still have something like MVC, but you don't have a separate server or a sandbox for window js where you have to communicate).
If my memory serves, this is also how WinForms worked.
You obviously were not building apps twenty-five years ago when all this shit was figured out and super easy.
The web hit and people took it to it's logical conclusion. Twenty-five years later we are still trying to figure out the best way. Angular is highly refined but still a clusterfuck.
I build web apps professionally. It's not good and not really getting better unless better means bundling a browser with my app. Face in hands.
In today’s era, the easiest GUI tools are probably game engines, iOS and web browsers.
This! 100%! For many many years now. It's painful for all people involved (including the .NET community). Microsoft doesn't mind though, they love developing a shitload of competing frameworks, because once a framework hits version 3 or 4 where it starts to feel slightly mature then the internal incentives require the teams to dump the project and "invent" something new to stay relevant internally.
FWIW they march to their own drum, they are largely independent of Windows and Developer Division. I would not tar all of Microsoft’s efforts with the same brush.
- WPF with NET 6
- Electron
- WinUI
- Flutter
- That GUI programming is complicated
Gnome includes Gnome Builder[2] in most distributions, which makes it incredibly easy to start making Gnome/GTK apps. Developers can also leverage Flatpak and Flathub for near-universal distribution.
0. https://www.gtk.org/docs/getting-started/hello-world
1. https://doc.qt.io/archives/3.3/tutorial1-01.html
2. https://wiki.gnome.org/Apps/Builder
You copy paste a ten lines gtk or qt hello world, install a few packages (certainly not 20 GB), in a terminal go in the right dir, and type something like 'make'.
The one I used was from Microsoft.
Thankfully It‘s still a relatively straightforward process to create and compile an app with Xcode, which is the only option anyway. It‘s also a 30 GB download, but at least it‘s free.
I think Apple doesn't usually blunder around like Microsoft with these things, but actually pulls through long term strategies. We are in an awkward transition imho. AppKit/UIKit are super mature technologies, SwiftUI is the future but kinda lacking and Catalyst is either a shortcut to speed up Mac/iOS convergence or a backwards attempt to get more advanced iPad apps. It's all fine as long as SwiftUI is actually the future. If any of the others are relevant in 10 years, more than Obj-C is now vs Swift, I'll be disappointed.
I don't believe SwiftUI is technically 100% AppKit under the hood, but effectively is, for now.
One setting and you can make a fat jar. Double-click to run--everywhere.
One line of code and you can apply a modern UI theme that just works.
https://github.com/fyne-io/fyne
For example: Make a window with a vertical splitter, put some arbitrary textboxes in one half of it, and they will all have some arbitrary small minimum size. The rest of the split window remains empty. I know of no GUI framework with such an insane default positioning. Try to fix this problem with a "maximum layout" - It doesn't work! Either the controls are now overlapping (one of the rarest use cases ever), or the layout does not have any effect at all.
Another problem: On my Linux system, every third or fourth application start totally messes up the layout. Quit and start it again, and the layout is fine again. WTF?
In a nutshell, Fyne needs a bit more time to mature before it's a viable option for Go, but unfortunately it already suffers from few bad design choices regarding layout. It's also not a good idea to separate controls and layout. This may sound good on paper but in reality it just leads to tons of boilerplate code.
It's definitely huge tool, but it allows you to do a lot of kind of developments.
I think it's very decent tool if you want to do C# development, especially when you want to have reliable intellisense and strong debugging tooling
(expression evaluation at fly, changing code at fly, moving to different lines during debugging, conditional breakpoints)
https://www.electronjs.org/docs/latest/tutorial/quick-start
When we broke ground on this version Microsoft was hardcore pushing UWP. We were building for the future so we built our app within the constraints of UWP with the expectation that it would grow with Microsoft’s vision…
Fool me once, as they say. UWP is dead.
We are currently redeveloping the entire thing with a series of Win32 base classes and intend to layer on a WPF front end for now. WinUI is early and promising. But so was UWP.
Long term we’re exploring outside the box UI options like running a local server and popping a browser. C# and .NET are very powerful. But the fractured landscape for desktop development gives little hope for the future.
If your goal is to build a rich UI, then you may have to suffer through learning whichever flavor of XAML you decide to go for. But if your goal is to interact with local hardware functionality I’d probably steer clear and use WinForms, a browser interface, or a console interface.
So... basically Electron?
There are some promising developments with Blazor and .NET MAUI. But it all seems too speculative to build on at this point.
If you don't use JS, wouldn't that mean reloading the whole page for every action? Or do you still use some minimal JS to improve the experience?
https://microsoft.github.io/microsoft-ui-xaml/about.html
Why do you think UWP is dead? Please post links.
https://visualstudiomagazine.com/articles/2021/10/19/uwp-mig...
Also apparently WinUI3 won't get UWP support at all:
https://www.theregister.com/2021/07/02/uwp_microsoft_winui3/
Nobody at Microsoft is going to come out and admit that UWP is dead, but it's easy to read between the lines.
Get out of the comfort zone and use an older computer and try run an Electron app.
You can't have it both ways. As you found out, building native apps is very complicated and slow. Young devs don't have the pain tolerance of old school devs which had no alternative but to suck it up, endure the pain and march on.
But today you have a choice - be immoral and productive with Electron, or moral, slow and out-of-the-comfort-zone with the native toolkit.
The answers to all of the problems you listed are in the Microsoft online docs, but it does requires hours of reading to learn how all the pieces fit together. Native app development in C++/C# is not like "build a to-do web app in 10 minutes". Which is why very few build native apps anymore, because devs want instant gratification and native development is anything but.
You certainly can; Visual Basic and Delphi send their regards. If "modern" tools have regressed then they're deficient.
"How do I obtain Microsoft's C++ compiler and standard library (and just that)?"
https://stackoverflow.com/q/69274364/1593077
and the answer was either "You can't" or "It's complicated". I gave up and used the MSVS installer. And you _still_ need to invoke a complex script to get your environment in order.
https://github.com/ScoopInstaller/Extras/blob/master/bucket/...
Might be something via chocolaty/winget too?
https://github.com/ScoopInstaller/Scoop/wiki/Chocolatey-Comp...
Don't listen to whatever the Microsoft marketing department is hyping.
https://avaloniaui.net/
https://docs.microsoft.com/en-us/visualstudio/ide/create-a-v...
0: https://www.wikihow.com/Create-Your-First-Qt-Program-on-Ubun...
Edit: wasm as well. I just started messing around with emscripten and it blows my mind that I can run a qt GUI app in my browser.
Not to mention the whole "Windows Forms, WinUI3, Win32 and WPF" mess.
I agree, it feels clunky and bloated compared to what I’m used to (especially if multiple vs studio versions required) but it gets the job done.
I’m very curious what workflows look like for people that know what they’re doing when building c/cpp on windows.
https://docs.microsoft.com/en-us/windows/msix/desktop/deskto...
There is a way to launch packaged apps from the command line once you have registered them:
https://docs.microsoft.com/en-us/windows/uwp/xbox-apps/autom...
Everything with packaged apps is harder, so I try to avoid it.
Speaking of which, the reason your exe doesn’t open is because you’re likely building a packaged app. You can think of that like building and iOS/Android app where it comes with a bunch of extra metadata and hooks into the OS, but that means you can’t just launch the exe and it has to be installed using the new .msix installer format. Thankfully the Windows App SDK just added the ability to build unpackaged (I.e. classic win32 exe apps): https://docs.microsoft.com/en-us/windows/apps/windows-app-sd...
I have built and tested both approaches and they work well, though unpackaged apps aren’t able to use certain APIs that expect “package identity” (I.e that special metadata I mentioned above)
Most of us are building businesses apps. We just want a god damned form builder where you can double click a control and fill in the action performed code. Instead we have web tech (heaping trash fire) and several abandoned XML-based UI nightmares.
Oh, but the next XML nightmare is where it's at! ...and it will be done next year!
I tried to build an unpackaged app but it didn't work (after I click run, the app closes immediately and some errors are spewed into the console. I can't understand the error and so can't Google)
I build some simple GUIs for myself (ok, for Linux) and it was a perfect choice for that. Very stable language, relatively small, easy.
Python tkinter still went through the python2 to python3 storm and the unicode plague. So i hesitate to recommend that.
https://www.tcl.tk/software/tcltk/
But I mainly used it for creating simple register value calculator tools for helping with embedded dev.