3 ms·

XAML was never dead. It was the preferred .net UI system for windows 8 apps. Meanwhile they said...building a .net desktop but need a rich UI? Use WPF. The idea

XAML was never dead. It was the preferred .net UI system for windows 8 apps. Meanwhile they said...building a .net desktop but need a rich UI? Use WPF. The idea that they are a small team just fixing bugs really isn't the case. You could say the same thing about MFC. If you are butt hurt that WPF didn't set the world on fire the way html did...you just weren't paying attention. Evry developer should know html and js...whether you like it or not. I would say the same thing about C...but html and js are the thing that everyone should know something about

Maarten88 11y ago
The screw-up is that they introduced many variations of XAML, each one incompatible with the one that came before. Vista brought WPF, then came Silverlight to 'counter' Flash, then came Windows Phone 7 Silverlight, then Windows 8 came with WinRT, while Windows Phone 8 had yet another dialect not compatible with Windows 8. And now Windows 8.1 and Windows 10 are trying to bring it together again. Add some rebranding efforts to this, and you have what we have now: XAML is a very good idea, but the implementation of it is a royal mess. As long as they keep changing it all the time, developers will keep getting burned and turned off. An interesting angle to this story is the recent introduction of Xamarin Forms, which is also a form of XAML, even more universal in that it targets iOS, Android and Windows.
- ygra 11y ago
  Do note that XAML is merely a way of describing nested objects in XML. It's just a markup language and it never was incompatible to itself. Heck, if you wanted to, you could use XAML to describe Swing GUIs for Java; you just need a parser that turns the markup into objects. The implementations of the objects referenced by XAML may differ and have incompatibilities, but that's not a XAML problem. Xamarin.Forms uses completely different ones, for example, while still keeping the same markup.
- sudioStudio64 11y ago
  They screwed up a lot of things during those years...i don't know if WPF even makes the list of screw up's. Maybe I look at it differently, but I don't expect things like consistency from API's. They are what they are. You find out what you need to do to solve a problem. It's not like there is something out there that is magically better. Just varying degrees of inconsistent.
  - Maarten88 11y ago
    > I don't expect things like consistency from API's But you do not expect an API/object model to arbitrarily change for existing features. Which is what happened. A Win32 C app from 20 yrs back still compiles with no problems in Windows 10, but where do you go with a big enterprise app that was built 7 yrs back in then-state-of-the-art Silverlight? Any migration will be a big investment and comes with uncertainties and limitations.
    - sudioStudio64 11y ago
      Silverlight and WPF were different...they said that from the start.

Maarten88 11y ago

The screw-up is that they introduced many variations of XAML, each one incompatible with the one that came before. Vista brought WPF, then came Silverlight to 'counter' Flash, then came Windows Phone 7 Silverlight, then Windows 8 came with WinRT, while Windows Phone 8 had yet another dialect not compatible with Windows 8. And now Windows 8.1 and Windows 10 are trying to bring it together again. Add some rebranding efforts to this, and you have what we have now: XAML is a very good idea, but the implementation of it is a royal mess. As long as they keep changing it all the time, developers will keep getting burned and turned off. An interesting angle to this story is the recent introduction of Xamarin Forms, which is also a form of XAML, even more universal in that it targets iOS, Android and Windows.

ygra 11y ago
Do note that XAML is merely a way of describing nested objects in XML. It's just a markup language and it never was incompatible to itself. Heck, if you wanted to, you could use XAML to describe Swing GUIs for Java; you just need a parser that turns the markup into objects. The implementations of the objects referenced by XAML may differ and have incompatibilities, but that's not a XAML problem. Xamarin.Forms uses completely different ones, for example, while still keeping the same markup.
sudioStudio64 11y ago
They screwed up a lot of things during those years...i don't know if WPF even makes the list of screw up's. Maybe I look at it differently, but I don't expect things like consistency from API's. They are what they are. You find out what you need to do to solve a problem. It's not like there is something out there that is magically better. Just varying degrees of inconsistent.
- Maarten88 11y ago
  > I don't expect things like consistency from API's But you do not expect an API/object model to arbitrarily change for existing features. Which is what happened. A Win32 C app from 20 yrs back still compiles with no problems in Windows 10, but where do you go with a big enterprise app that was built 7 yrs back in then-state-of-the-art Silverlight? Any migration will be a big investment and comes with uncertainties and limitations.
  - sudioStudio64 11y ago
    Silverlight and WPF were different...they said that from the start.