Hacker News Reader

Comment by smackeyacky | Hacker News Reader

I'm going to pile in too late and sing the virtues of .NET core or whatever its called now. Deployment of web apps to containers is a breeze, the language is modern feeling. Roslyn is about the most awesome thing I have played with. Razor pages are a breeze compared to the giant piles of dependency hell that client side SPAs or node have become. It feels lean and mean and I can be sitting at a debian box or a windows laptop and the experience in VSCode is identical including deploying code to production on AWS.

But like everybody has said, the desktop UI story is garbage. Fingers crossed Maui turns out to be useful because winforms and UWP are hot garbage. Such a shame from the guys who revolutionised gui development with Visual Basic.

View on HN

All upcoming UI frameworks by MS are still hung up on XAML. I get that their existing userbase is heavily invested in XAML, but in my experience XAML doesn't add much value, just unnecessarily layer of complexity, that lacks expressiveness of a programming language and makes interoperability between UI and code more convoluted.

There is some "experimental" support for code based UI composition in MAUI, but since XAML is it's primary focus, XAML probably leads design decisions.

You have never been required to use XAML, however. XAML is just a tool to allow you to describe UI API calls using XML in a way that flows well for both humans and external tooling. If you don't like XAML, just call the same exact API with C#.

I don't even understand why you say "hung up on", XAML is probably the only compiles-to-code UI API I've ever used that actually does what it says it does; I've used similar tools for other UI toolkits (Glade comes to mind), and they're trainwrecks, and I'd rather just use the API straight.

UI development tools aren't for programmers, they're for UI designers: UI designers are generally are bad programmers but good designers, but need to program somehow as part of their job, and UI design tools allow them to be part of the team without having to feel like they're second-class citizens.

You know what happens when we don't have working UI toolsets? UI designers do insane stuff like slap together some HTML, CSS, and JS, and don't care that the usability of that from either the end-user perspective or the programming perspective is absolutely awful.

Would you rather use Electron or would you rather use XAML? At least with XAML, it works, and when it doesn't work, it can be made to work. Electron is eternally unfixable.

When I was using it, all documentation samples (and nearly all other resources) were for XAML which made it unnecessarily hard to use API in pure C#.

IMO, UI development tools are often not good for anybody. Designers are much more productive using specialized UI design applications like Sketch, Figma, Adobe XD etc. Who is responsible implementing the design depends on the company/workflow.

> XAML is just a tool to allow you to describe UI API calls using XML in a way that flows well for both humans and external tooling.

Not in my experience. XML feels very unnatural to me. XML being natural for humans was a hype from twenty years ago that was never particularly true in practice. XML feels less natural (to me) than using a normal programming language to make same API calls. XML based UI development tools are also often very unreliable and clumsy.

Not the biggest fan of XML either. My primary objections against "simple" XML is repeating element names in open and close tags, the noise of <>, and (in the context of a UI tree) confusion over whether to put element modifiers as XML attributes (strings only) or nested elements (verbose, looks like an object rather than an attribute). And when you bring in namespaces, it gets more verbose and unreadable.

I've actually managed to make "UI in code" somewhat manageable by laying out my UI code in a tree mirroring the widget tree. One issue is waiting for rebuilds, another is difficulty navigating the "big picture" of my code, mapping between on-screen UI and code mentally or through an Inspect Element equivalent.

What do you think about QML?

To manage mental mapping of what is being drawn, I keep methods that create widget trees short. My rule of thumb is that whole method has to comfortably fit the screen at once. For each section of the main tree I create a static function that returns a branch of the tree. These functions have descriptive names that help you visualize what element each function builds. If a tree inside a function is long, it is broken down in the same way.

There are some fluent extensions (for Xamarin.Forms and probably future MAUI) that help you build UI in declarative fashion with C#. Same extensions could be created for other frameworks.

https://devblogs.microsoft.com/xamarin/c-sharp-markup-for-xa...

https://github.com/VincentH-Net/CSharpForMarkup

For reusable custom widgets that can't be done with a static function, I create new classes with their own widget trees. Try to keep widgets composable and avoid inheritance if possible.

Hot reload is coming in .NET 6, so waiting for rebuild will soon be history.

I have no experience with QML so I can't really comment on that.

>specialized UI design applications

Like Blend?

What's wrong with XAML and what could have replace it?

Maybe HTML?

There's nothing "wrong" with XAML, at least nothing "more" wrong than what folks are _really_ comparing it to, which is HTML/CSS/Javascript concoctions.

I like it because it's relatively easy to make half-decent-looking UI's that have excellent functionality. If you need bigger guns, there's some powerful libraries you can use for more polished UI's or you can roll your own with a lot of effort and a long learning curve. For corporate in-house apps, it's hard to beat WPF/XAML.

The same is simply NOT true for anything web-based. I see it is getting better with CSS grid. At least layout is becoming sane-r than the days of tables, flex-box, and bootstrap-everything. But you still have house-of-cards javascript library dependencies on a boat-load of complexity. I realize that the folks who do web-apps day-in-day-out see it differently.

I also remember the winform days when people could make ridiculously elaborate high-function UI's with breath-taking speed. These would look ugly and dated by today's standards (especially on today's high-resolution monitors), but that development speed, the ability to just execute what you want quickly, is sadly missing today. WPF/XAML comes close but that winforms speed is just gone. Unless you want to do winforms-- which you CAN if you really want to, along with wearing double-knit polyester pants with bell-bottoms.

C# with hot reload.

Issues with XAML:

- verbose

- static (not good fit for dynamic UIs)

- templating is unnecessarily complex

- contains code-like constructs (behaviors, convertors)

- being a separate language forces constant mental context switching when developing, which is bad for productivity. Tooling is more complex and breaks more often (like Intellisense issues)

The only good thing that XAML does is separates UI from the model, but you really don't need a separate language to do that.

What would you say are the benefits of XAML that warrant using another language for UI?

>What would you say are the benefits of XAML that warrant using another language for UI?

I think the main reason is they wanted a declarative language along side their imperative language. You don't necessarily need to recompile anything to get a layout drawn in an editor with XAML.

I haven't used it that much, but from my experience it was incredibly difficult/verbose to create any custom designs, compared to HTML/CSS. It put me off so much that I just picked another language to develop my applications in.

Coming from Windows development since Windows 3.0, I have the exact opposite opinion.

With XAML I can make my ideas fly, with Web, despite doing Web since 1998, I rather let our designer do their magic with HTML, CSS, JavaScript, turning <div> into animated drop downs.

I would question how invested the existing customers are in XAML. I have worked at about 6 companies that all use .Net exclusively and I don't think we used XAML once except for maybe an experiment or PoC.

I think the XAML stuff relates more to trying to make things move between devices more easily by using generic ideas like stretching, grid layouts, flows etc. I guess MS are still holding onto the write-once use anywhere ideal which has never made it particularly well in any stack.

So they write their WPF applications in pure C# and VB.NET code?

XAML has always just been an option, for both Xamarin and MAUI. I've always done UI in code and not had any issues.

Maui is built on top of UWP, in what concerns Windows backend.

Have to agree with the desktop development chaos, look like not wanting to take an hard decision.

Forms and WPF continue, because they are the golden eggs, the ones that most .NET desktop devs actually care about.

WinUI looks like last attempt to rescue UWP, while at the same time in typical Microsoft fashion ignoring the tooling issues surrounding .NET Native and C++/WinRT.

MAUI, well they have to do something with Xamarin, and .NET still lacks an official cross platform so Xamarin be it. On macOS they are basing the backend on Catalyst, what I find completely insane, as most iOS devs know Catalyst apps don't feel at home in macOS.

I think React has shown how UIs can be done in a better way. That's why we have Flutter, Jetpack Compose and SwiftUI now.

React is UI fashion, uses lots of memory, stresses the GC in managed languages and it was already present in Haskell, it just lacked JavaScript way of pushing frameworks.

JetPack Compose was created by React devs, and Swift UI still pales in capabilities to AppKit. Listen to this week rant on Apple's UI Frameworks at ATP podcast.

> Maui is built on top of UWP, in what concerns Windows backend.

No it is not, how is that going to work on Mac? It is it's own thing, and on Windows it will use WinUI not UWP.

Learn before commenting.

WinUI is UWP stack, that is what Reunion is all about, merging both worlds with WinUI on top.

Plenty of blog posts where to find such information.

How about before being a condescending person YOU do some reading?

https://microsoft.github.io/microsoft-ui-xaml/about.html

"WinUI 3 works with any app supported by the Windows App SDK. WinUI 3 can be used DIRECTLY as the UI layer for desktop apps, or starting next year, it can be used to modernize a Win32 app's UI gradually, using XAML Islands to mix and match with the following technologies:

WPF WinForms MFC ComCtl32"

Or here: https://www.thurrott.com/dev/206351/microsoft-confirms-uwp-i...

Oh and look here: http://allaboutwindowsphone.com/flow/item/24274_WindowsUWPde...

And finally from the last link: "You can use WinUI 3 as the entire UI layer for your desktop app, replacing your current main UI framework."

You are probably thinking of XAML which is common to all.

Please do your own research before shitting on someone.

My dear, if you read throughout the mess that was UWP marketing, UWP is basically IInspectable + .NET Metada instead of TLB + App identity.

I advise you to read about the low level WinRT and COM programming, instead of articles like those from Thurrot.

How much COM and WinRT programming, including XAML Islands have you done?

Start with the BUILD sessions from 2019, to see how everything fits together.

Learn how WinRT types get exposed to WinUI via XAML Islands, to split APIs from underlying OS version, all written in COM using the same WinRT types.

Hybrid Blazor apps are the solution to the desktop story. It's already happening, it's ready to go. It'll take a while to make it official though, too many faces in need of saving.

Avalonia is also a very compelling secondary solution.

Hybrid blazor sounds like something I need to investigate. Thanks for the heads up.

It's somewhat early days, but workable. The search term you probably want is "Blazor Desktop". It's basically Blazor Server but served to a local webview instead of a remote client.

.NET 6 will have some convenient ways to do this in WinForms, WPF, and MAUI. But if you're willing to go off the beaten path a bit, it's not too hard to assemble the bits on your own (serve up Blazor on a background thread, consume it in your web view control of choice).

> sing the virtues of .NET core or whatever its called now

I think this is the only criticisms I can level at Microsoft, their branding is just a complete mess!

Core has been dropped from .NET naming but we still have ASP.NET Core MVC (I think?) and we still have EF Core.

"ASP.NET Core MVC" is such a mouthful.

> But like everybody has said, the desktop UI story is garbage.

Strange, I find WinForms very similar to Visual Basic 6.

The UI designers are very similar. The API is very similar. C# is just a much better language than VB 6.

I personally really like WinForms, but I haven't done anything in it in about a decade.

Microsoft should either use Flutter or make a C# version of something like Flutter. Its simple to understand and doesn't have any magic xaml tag to make things work.

Isn't this just .NET MAUI?

Flutter is somewhat similar to UWP, it includes a cross-platform rendering engine.

MAUI is similar to old Xamarin, it exposes whatever native controls are available on the platform.

Useless for me because I sometimes develop GUI for embedded platforms which don’t have any native controls at all.

Even ignoring the embedded use case, I believe that’s not the right approach overall. Native controls are too different across platforms. Commercial success of Electron demonstrates people don’t give a crap about native controls, they want good UX identical across the platforms, in large part because it saves development costs for cross-platform stuff.

I've been in and around platform development in the .NET space for over a decade (not as a developer, I stopped programming for the web in like 2002 because I couldn't stand the the entire front end paradigm).

My biggest issue with .NET has always been how slow it is compared to <insert any popular server side scripting language here>.

Is there hope?

lol

I've always found that someone complaining that XXX is slow is just writing very bad code.

C# is blazing fast, but there's plenty of ways to write boneheaded-slow code.

It has always out performed Python and Ruby. While it usually falls behind Java in general performance. It seems to win in startup time which is important for scripts.

Reply on news.ycombinator.com