Windows Presentation Foundation (WPF) on GitHub
github.com
github.com
Prior to creating Tag That Photo, we had little experience with the WPF beyond simple demo type applications. Of course we've come a long way over the course of development but it certainly hasn't been easy. We have extensive experience with many other UI frameworks such as WinForms, Android / iOS as well as various web frameworks, and I think it's safe to say that once you wrap your head around it, the WPF has the slickest architecture. The team that designed this really knew what they were doing. It has this "peeling-the-onion" mentality to it where it's simple to implement straight-forward use-cases but if you want lower-level control of essentially every aspect of rendering, binding, input handling etc it's all exposed for you.
In case you want to see the final product: https://www.tagthatphoto.com
Its heavy use of binding, aspect oriented programming, dependency injection, cascading styling dictionaries, converters etc. are heavily leaned upon in a number of other UI frameworks. Once you understand how to organise these paradigms properly, you'll find a lot of other frameworks far easier to migrate to.
It's well worth learning, even if it's just as a transitory learning mechanism. I'm a big fan of learning frameworks that change your way of thinking and reduce the learning curve of other technologies. It's not for the feint of heart though - if you've never learned architecture to a level where you can separate your UI concerns from your logic properly and learned how to inject function into your UI from your viewmodel, there are some hard concepts to wrap your head around - especially when it comes to debugging - if you don't separate your concerns properly, it will make testing and debugging a bitch.
There are a lot of "Oh wow! I never thought about it like that!" moments of realization on the curve - rather like that moment when Scotty realizes that he never considered that it was space that was moving in his transporter algorithms.
Check out the plans page for more info on the pricing. https://tagthatphoto.com/plans/
It's that composable.
Personally think that these frameworks, like WPF and Cocoa, are still easier than working with Angular/React/Vue, but TBH that might be a reflection of my weaknesses with web development more than anything else. XAML is a bit of a mess but compares favorably to HTML+CSS, and XAML is almost as good as Interface Builder in my mind. The MVVM approach in WPF could be improved but it makes sense.
The .NET 5 doesn’t address any of these. They do a lot of good stuff for server side development but the story for desktop development is bad.
I'd throw xplat in there, but I think I'm already asking for too much.
Windows 8 is still casting a long shadow of half-baked bad ideas.
Is it different if you send your comments to /dev/null or if they do? I think it is. In one scenario you at least gave it a try.
Edit: also, nobody wants or uses native desktop apps anymore, so that's a big plus for React (either via Electron or just plain web app)
The customers I served during the last four years beg otherwise.
Like them there are plenty of European companies willing to pay for native desktop apps.
And I mean green field development, not maintenance.
Not everyone has business cases that can stuff into Web or mobile phones.
Having tried to develop a WPF app like a WinForms app, it is incredibly tedious because it's not what WPF was designed to do. Drinking the Kool-aid and working within the confines of how WPF was designed to work makes a lot of things significantly easier, but the trade off is having to explicitly set up view models, use data binding, and find alternatives to doing everything in code behind.
IMHO, the biggest challenge was dealing with the databinding ecosystem, which is incredibly powerful, but also complex, opaque, verbose, and tedious. There is practically no debugging of databinding, which is incredibly frustrating. It's hard to figure out why it doesn't work or why you don't get what you expect to get in whatever is actually being called.
Whether it was old winforms databinding or various js databinding approaches on the front end, its always been fairly straight forward to get what I needed. WPF always seems like it's jumping through hoops for things that should just work. I'm sure there's a lot of logic behind how WPF's databinding actually works for it to be able to support all the various situations that it does, but, for me, it's never been very clear, and I've wasted countless hours trying to find and debug the right databinding syntax only to have it still not work and have to resort to a less elegant/hacky way of achieving the result that I'm looking for.
While it's rich capabilities enable you to implement everything you can dream of, doesn't the same hold for JS desktop apps? (+ they are cross platform)
I don't see the use case anymore...
Maybe if Silverlight hadn't been such a deadend.
On the other hand, the layout model of WPF is a lot easier than mastering html+css.
JS desktop apps still mostly don't work without embedding a browser like electron and that ranges from annoying (e.g. for size/memory reasons) to impossible (for things like a plugin where you have a constrained environment, need to launch instantly etc).
The middle ground is desktop js using system browsers, but it's pretty painful to do too.
When WPF came out there were quite a few very cool open source projects that built on top of it because it's really easy to extend WPF and build components for it. But then every two or three years MS announced a new framework so most of these efforts died out. When you look at commercial third party suppliers like Developer Express they have the same component in three or four flavors. this must be a huge and expensive effort to maintain.
I think the various name changes have been extremely confusing and created the perception of more "resets" than actually happened at the code and API level. They dropped the ball by not bothering to have a good compatibility and migration story across WPF->Silverlight->WinUI, but since Windows 8 they've been pretty good about maintaining continuity for WinRT APIs
So Microsoft learned how lazy devs are and how ignoring such advises contributed to bad perception of GUI apps, e.g. Swing, and forced everyone to code the right way.
It is relatively easy to turn async code into sync, if really required.
MS's market was full of amateur-hour developers because their platform (WP7) was weak and lagging behind, thus incapable of attracting the top tier of devs. And then they poured gasoline on that fire with a barrage of silly incentives that were ignored by pros but attracted even more beginners. Now, to put a cherry on that fine mess, they attempted to remedy their bad business decisions with a technical solution that damaged the one asset they really had - an advanced and ahead-of-the curve app-development story. One own goal after another, really.
https://blogs.msdn.microsoft.com/windowsappdev/2012/03/20/ke...
As for the rest, I only agree it was a big mistake not to have a proper migration path.
However, WinRT was anyway the result of Synfosky's team (aka WinDev) being on the winning side, after they won over Longhorn, so not so much .NET love was going on back then.
And we had to wait for iteractive releases of Windows 10 slowly fix all those mistakes.
Whatever their reasoning was it was just plain dumb, heavy handed and unrealistic.
They don't feel like the product that would come if DevDiv did their best to produce a sane UI framework. They feel rushed, semi-overlapping, half-finished.
I imagine it should be possible to make just one more xaml framework which is cross platform, and much better than WPF (and it's derivatives), and much better than the js alternative (Because of deployment, not least).
I'm not sure if there is any incentive for ms to put their weight behind it however.
Please elaborate?
You can add a design time view model to get compile time warnings(and autocomplete) about incorrect bindings.
Thank you. I've never been able to figure out if web layout is as terrible as it seems, or if I'm just missing something.
Once you spend the 20 minutes to learn the WPF layout algorithm, you can reason about why every element is located where it is, down to the pixel. To get there with HTML/CSS, I feel like I would have to memorize and recall a huge list of ad-hoc rules, and their combinatorial interactions. Usually I just give up and accept the mysterious 3-pixel gaps that seem to crop up randomly, and I don't even attempt complex layouts.
It is brittle because XAML itself is a compiled language without the ability to step through or debug well, which means runtime errors in the object tree usually causes the entire app to crash with very abstract error messages.
it is complex because the language is supposed to be an object tree building mechanism and thus needs to be quite generic.
It is verbose because of the underlying abstracted data model. e.g dependency properties etc.
Compared to HTML, where the 'evolutionary' pressure to create a workable compromise is much higher.
I used to think XAML could be better if architected well, but the missing ecosystem and usage around it made it so, that HTML was and still is massively more productive.
This is absolutely untrue. Xaml errors can be caught like any other error, and most errors get swallowed rather than crash the application (which can cause some debugging headaches when things aren't rendering as you expect).
> I used to think XAML could be better if architected well, but the missing ecosystem and usage around it made it so, that HTML was and still is massively more productive.
I don't think html is massively more productive. I'm not even saying that WPF is so much better, but start debugging any reasonably large react application and you're just as likely to get into an unproductive quagmire.
WPF relies on Windows specific functionality.
And I really hope MS is neglecting WPF because some key insiders are looking to hand over the desktop story to some combination of Avalonia and Blazor.
.NET Core has always had platform-specific libraries that only work on a single platform or work somewhat differently on different platforms. The UI libraries (WPF and WinForms) are just the biggest examples now of platform-specific libraries on .NET Core.
edit: As pointed out below, it looks like the title refers to recent source code commits, not the creation of the repo.
Relevant links:
Edit: The roadmap https://github.com/dotnet/wpf/blob/master/roadmap.md has a list what's currently available and what's still missing. Looks like by now the main parts (PresentationCore, PresentationFramework) are open-sourced as well.
Even with Windows phone "dead" and maybe you don't need Xbox or HoloLens or Surface Hub or the best experience on ARM devices, there's still a lot of advantages to UWP for GUIs (or arguably the best, most comfortable, most adaptive experience on Desktop/Tablet). There's also a lot more opportunities for "hybrid" development to migrate Win32 applications a piece at a time (instead of needing to restart form near scratch an entire Win32 application to move towards UWP), so the birds and bees are living together better now and it's no longer a "war" between Win32 and UWP. But the implication is still that all of the energy on making better Windows UI controls and experiences (such as Fluent Design System 2.0+ work) is going into UWP controls and experiences. You can get there slowly from Win32 or start fresh with UWP. If you know UWP, it should be easy enough to use Xamarin for cross-platform UI work on mobile, even with Windows phone "dead".
And from their BUILD talk, I imagine VSCode might eventually move into it, as the team had quite a few React Native vs Electron benchmarks, and was quite keen to describe all Microsoft products that are now making use of React Native.
Kitbashing this with winelib will probably be the best way to do it.
Maybe this will be the basis of a cross platform toolkit in the future , but right now MS doesn't seem to really care....
Also why would C# and WPF do that instead of the myrriads of other languages and desktop tech? WPF alone wasn't exactly popular on Windows itself.
XAML makes it very easy to layout apps that scale well, and it's built-in states for controls and easy styling is very handy.
But my question was more towards how making WPF portable will create a renaissance for the desktop considering the market share it already can cover and that even among that market share isn't exactly popular, not how good WPF is.
Former Delphi / C++ Builder fanboy here.
But even Visual Studio XAML designer is relatively good. I used it is mostly.
And both do allow to work with live objects and mock data, as well, even if it isn't as clear as with Borland products.
The only exception was one that had to integrate with an existing Forms one.
And starting later this year, .NET Core will be re-branded to ".NET" deprecating .NET Framework (on 4.8) and merging Mono into it (see Build Conference). .NET Core 4.0 will be skipped and the next version is ".NET 5" (without the Core moniker).
And that single thing will eliminate years worth of confusion. About bloody time.
A nice byproduct is that it will finally convince everyone in my org that we have to go all in on migrating from "traditional .Net" to .Net "Core", on everything we do.
Also about bloody time :)