.NET & Funky Fresh

Syndication

News

  • <script type="text/javascript" src="http://ws.amazon.com/widgets/q?ServiceVersion=20070822&amp;MarketPlace=US&amp;ID=V20070822/US/bluspiconinc-20/8001/8b68bf4b-6724-40e7-99a5-a6decf6d8648"> </script>
The Manifold Blunders of Xaml–Part 1: Version and Platform Hell

I started work with “Xaml-based” platforms in the pre-Beta days of WPF, so I’ve been working with this technology longer than most. Back then I was utterly awed and inspired by it’s capabilities. Today I’m frustrated and sometimes outraged. As I’ve traveled to various conferences, worked with various companies and interacted with the many Caliburn.Micro users, I’ve discovered that I’m not the only one who feels this way. This blog series attempts to catalog a number of the issues, some of which have been there from the very beginning; others creeping in over time. This is an aggregate of my own observations and those of the community.

Versions

Let’s take a brief stroll through the platform timeline:

  • 2006 – WPF 3.0
  • 2007 – Silverlight 1
  • 2007– WPF 3.5
  • 2008 – Silverlight 2
  • 2008 – WPF3.5 sp1
  • 2009 – Silverlight 3
  • 2010 - Silverlight 4
  • 2010 – WP7
  • 2010 – WPF4.0
  • 2011 – Silverlight 5
  • 2011 – WP7 Mango
  • 2011 – Lakeshore1
  • 2012 – WinRT/Metro2

If we focus on the platforms and ignore their various versions, we have something like this:

  • 2006 – WPF
  • 2007 Silverlight 1.0 (no CLR)
  • 2008 – Silverlight 2.0 (CLR)
  • 2010 – WP7
  • 2011 – Lakeshore
  • 2012 – WinRT/Metro

So, it appears that Microsoft has released a new UI platform at least every two years! Let’s contrast that to the timeline for pre-Xaml UI technologies:

  • 1985?– Win16
  • 1995 – Win32
  • 2001 – WinForms
  • 2006 – WPF

Interesting. We have at least 5 – 6 years between platforms prior to Xaml, but it’s actually about 10yrs due to the fact that WinForms is just making Win32 available to managed languages. It’s just a wrapper around existing APIs. Each of the Xaml platforms is actually a different runtime altogether. So as far as platforms go, we’ve gone from one every 10yrs to one every 2 years. But that’s not all, let’s look at Xaml itself:

  • 2006 – Xaml 2006 Spec
  • 2008 – Silverlight 1 Xaml
  • 2009 – Xaml 2009 Spec
  • 2011 – Silverlight 5 Xaml
  • 2012 – WinRT/Metro Xaml

Aside from the actual platforms released, we have a parallel divergence in Xaml markup capabilities. In 2006 the first version of Xaml was released. It was formally defined and released as a spec shortly after. When Silverlight came along, Microsoft failed to create a Xaml language compatible with their own specification. In fact, even Silverlight 5 doesn’t comply with the Xaml 2006 spec. In 2009 Microsoft released a new version of Xaml that fixed several important shortcomings with the 2006 spec….but not a single platform implemented it. WP7 is still playing catch-up with Silverlight and WPF. WinRT/Metro Xaml has less Xaml features than any platform. Furthermore, it significantly changes some aspects of Xaml altogether, making it compatible with almost nothing. Furthermore, some of the changes they are making will prevent it from ever becoming compatible in the future.

When I step back and try to look at this information objectively, the most natural conclusion I can come to is that Microsoft UI technologies are, and have been for the last five years, in a state of complete instability…and it doesn’t show any signs of change (esp. with the rumors that WP8 will not use Silverlight, but some variant of WinRT). You can’t count on anything. If we forget about app developers for a moment, and think about the ecosystem, imagine the effect this has on third party products, control vendors, open source frameworks and tooling. Every time MS spits out a new platform or Xaml flavor, the entire ecosystem has to start over.

My own Experience

I first wrote Caliburn for WPF when there was no word on anything like Silverlight existing. When Silverlight was first announced, it was branded WPF/e so I thought my framework would port. Unfortunately, when SL2 was made available, there were so many differences that I had no choice but to completely re-write Caliburn. Then, when WP7 was announced, I started porting Caliburn to that, only to discover that it was not possible. So, I did another complete re-write resulting in Caliburn.Micro. Now we have WinRT/Metro. I think I can port it, albeit, with a ton of conditional code. But, I’m not 100% sure yet. If it looks like another re-write…I’m done with this game.

Maintenance and Innovation

There are lots of negative side-effects to this sort of instability. The one that hits me most is that it creates a battle between maintenance and innovation. Again, speaking of my own project, I have plenty of ideas about how to improve Caliburn.Micro. I think some of them are minor niceties, but others are more along the innovative lines. But, you will never see any of them come to fruition. Why? Because the instability of the underlying platform, the constant release of new platforms…has put my project into a state of perpetual maintenance. I can’t innovate because I’m still trying to deal with the differences in WP7.5 and I’ve got developers (who can blame them?) banging down my door wanting to know when WinRT/Metro version will be available. It’s been discussed much in recent years as to why innovation seams to happen in non-Microsoft open source and on other platforms like Mac…while very little happens in Windows software. Could it be because we are spending our time re-writing everything every two years? and don’t have time to develop anything forward thinking?

Careless and Arbitrary

Sadly, many of the API and Xaml differences were completely avoidable. I remember one particular bug I had in Caliburn. It resulted from the fact that List<T>.Remove was implemented differently between WPF and Silverlight. In a particular scenario it would work fine on one platform and crash your app on another. There are hundreds, probably thousands of such issues, from the BCL all the way up through the UI stack.  We aren’t talking about missing features here. We are talking about the same features which exhibit different behavior or have altered APIs.  Sure, Microsoft worked hard to improve this with successive releases of Silverlight. But then came WP7, which stepped us back in time. Now look at WinRT. There are a number of changes that are completely arbitrary. They serve no technical purpose and don’t improve the API. They just make more work for developers who want to port code. If you want another fine example, just try to write a cross-framework design mode check.

A Lack of Understanding

Sigh. This one perfectly ironic issue really troubles me sometimes. Through all of this, I’ve realized that Microsoft doesn’t understand their own platform. I’ve got more to say on this later, but let’s look at this from an API perspective here. Consider this: every control specific to WP7 development could have been built on top of Silverlight without a need for a modified runtime. Most controls could have been implemented simply by styling an existing control or applying a template. For example, the Pivot control can be implemented using a tab control with a custom template and some attached behaviors. In fact, wouldn’t it have been cool if you could just use a Tab control in WP7 and it just changed it’s appearance to work on the phone?! Wait, wasn’t that the idea behind templating and adaptive layout to begin with? Here’s another example: Behaviors. Perhaps you didn’t know that Microsoft built this twice? In WPF there were Triggers. In fact, in both WPF and the Blend behavior system, there is a class called TriggerBase. They have the same name! They do the same thing! But, you can’t create custom triggers or actions in WPF because the ctor is marked internal. Did it not occur to anyone that they should just remove that instead of re-inventing the wheel? As a result, we now have two methods of doing triggers, and you have to know which to use for what. It’s even true in Silverlight, which has limited support for “traditional” triggers, but does have some. Ridiculous. I could go on and on about the types of internal and cross-platform inconsistencies MS has created by not simply understanding the core capabilities of their own framework.

All of this get’s really interesting if you consider that Mac is the platform that is considered most cutting edge and innovative in terms of UX…and they’ve scarcely had any major breaking changes since 2002. Considering that their phone apps run on their tablet and they are porting a number iOS features back to OSX…it must be nice only having to worry about two platforms and knowing that the OS vendor is making a visible, tangible effort to unify those two platforms…..but I’m getting off topic now.

End of Part One

There are lots of problems with Xaml, but I chose to start this series with one of my particular pain points. Some developers neither care nor are affected (yet) by these sorts of version issues, but they have a big effect on the surrounding ecosystem and are going to be with us for the next decade. Over the next several blog posts, we’ll discuss many other problems, some technical, some not so much, but all have been singled out by multiple members of the community (read: not just me) as problems. It is my hope that Microsoft employees working on these technologies will read this and seriously consider what they can do to improve things going forward or at least not perpetuate the same mistakes again. I also hope that .NET developers will take a long, hard look at this part of the platform and make an honest valuation of its strengths and weaknesses.

Footnotes

1. Lakeshore is the name I’ve been hearing thrown around for the Xaml-runtime for XBox, which sources say is Silverlight-based, but drastically altered. I have no official word from Microsoft on this. It’s just what I heard through the grapevine, though I’m fairly confident in the accuracy of the information. Supposedly this is what is powering the “apps” in the new XBox dashboard which was released around last Thanksgiving.  EDIT: Apparently the XBox version is called Lakeview not Lakeshore.

2. I don’t actually know when WinRT/Metro will be released. I imagine that 2012 is a reasonable guess.


Posted 04-18-2012 11:43 AM by Rob Eisenberg

[Advertisement]

Comments

Joe wrote re: The Manifold Blunders of Xaml–Part 1: Version and Platform Hell
on 04-18-2012 12:06 PM

What about the XAML found in Windows Embedded?  the one that works with C++?  Yet another version I think.

In reality, XAML is just a serialized object graph.  The different XAMLs are just just a reflection of the inconsistent object model of the UI.

Euphoric wrote re: The Manifold Blunders of Xaml–Part 1: Version and Platform Hell
on 04-18-2012 12:38 PM

I tried working with WinRT a little after. And even when I never done big project in neither WPF nor Silverlight I get exactly same feeling as you.

I understand why they had to re-implement Silverlight. They had to have it running on both Windows and Mac. So it had to be simplified.

I understand why they had to re-implement it for WP7. It had to run on ARM architecture.

But I don't understand why they didn't keep it as strict subset of full WPF. And I don't understand, why they don't try to at least achive same functionality as WPF in WinRT. Especialy considering it is supposed to be UI for whole OS, not only as as a library.

And only person, who can fix this is Steve Ballmer. Only he can step between various Divisions and make it MS into working mechanism as a whole.

Martin Pilkington wrote re: The Manifold Blunders of Xaml–Part 1: Version and Platform Hell
on 04-18-2012 1:05 PM

It's worth noting that Apple hasn't always been this good. They released a lot of various toolkits that never came to anything in the 90s. In 2001 we had several different platforms on the Mac for development: Cocoa/ObjC, Cocoa/Java, Java, Carbon, Classic. Of these only Classic was classed as "old", the rest were largely seen as equal. Of course Cocoa/Java was deprecated in 10.4 and removed in 10.6, Java was removed in 10.7 and Carbon was promised as having a 64 bit version at WWDC one year and the next it was announced that Carbon was effectively deprecated, just months before Leopard shipped.

Things have got better though, now that Apple has stabilised on Cocoa and Cocoa Touch. There's also a very important part to Apple's success, which is the process frameworks go through. They start off private, only meant to be used by Apple applications. Often they might actually start as application code but are pulled out into frameworks. Then once they are happy with them in private they make them public in an OS release to give 6+ months for 3rd party devs to give their feedback. The fact that they take their time, refine them in private and (most importantly) use their own frameworks helps a lot in improving their design.

Hopefully WinRT/Metro will represent that for Microsoft given that they're strongly pushing everyone to go that route, and it's the Windows team that are doing it. Especially as Metro is the first time I, as a Mac and iOS dev, have been interested in porting my apps to Windows.

OwwMyEye wrote re: The Manifold Blunders of Xaml–Part 1: Version and Platform Hell
on 04-18-2012 1:34 PM

Didn't Steve MCConnell talk about how you can tell which teams in a software company that don't talk to each other by the differences in how each piece of software they build works by its self or together?(did not find the direct quote. my google foo is off today)

This will date me but it reminds me when visual C++ and VB 6 had different keys for stepping into and out of code.   Seems like the same deal. Only on a bigger scale.

It is obvious that each team is working on its own set of rules and then instead of building on what has come before that they are re-writing the same funtionality to work with their subset area, choices are made and beacuse of no communication the code naturally works differently in each set. Which is what we are struggling with.  (Easy for me to armchair quarterback this, but I am pretty sure this is the case here. )

I know have no basis in fact for this, but my opinion is that the politics of the workplace are playing out here.  Since there is not a driving architect pushing for a single standard with these libraries, each exists on its own and with no reason to share info or a forced standard  it is "just get the code working" and then move on to the next project.   It is much harder to standardize across divisions, groups and locations and if there is no political will in the company to do that then it is not going to happen.  

It is just like Microsoft's current communication policy, silence is a way of telling or not telling people what is going on.. really it is that no one knows where this stuff is heading.... Recent example ,

  There was a dev saying windows phones would upgrade to win 8  and now there is no retraction or sort of a retraction but there is no clarification in the retraction.  It is like the left hand does not know what the right hand is doing.  Which means it is hard to unify UI development if no one in the company has a clear picture of what that means as a whole or can communicate it to the masses.  Plus people can all have good ideas, but someone who has the clear vision has to pick.. A will break B but will make C so much easier... we will do C.  But when it is cross teams/divisions how is that decision made?  

Seems like the shift to Javascript and HTML 5 is also a way to get themselves out of their own confusing standards and push the confusion or lack of standard back on the community.  "The Browser standards are different but it is not our fault."  Find a framework to take care of your pain there...

I love Caliburn.Micro .. and I just barely learned the basics.

I will be sad to see it not continue,  but I totally understand.

What is the defintion of insanity?  Re-writing your code expecting some form of stability again and again. :)  You want to move forward not do the same thing over and over again.  

Hector wrote re: The Manifold Blunders of Xaml–Part 1: Version and Platform Hell
on 04-18-2012 1:40 PM

I think that the fact that Microsoft is fully supporting HTML/JavaScript as technologies to build Windows 8/WinRT/Metro applications is as close as Microsoft is ever going to get to publicly accept that XAML hasn't been a success story and it never will be.

For whatever reason XAML never got the traction that it needed and Microsoft has realized that supporting other well understood and popular technologies is the way forward regardless of whether they are better or not.

I don't mean to indicate that supporting HTML/JavaScript is a bad idea, I think it's a wonderful and smart idea, but I also think it highlights that Microsoft has seen the light too.

OwwMyEye is my full legal name, as it appears on my passport wrote re: The Manifold Blunders of Xaml–Part 1: Version and Platform Hell
on 04-18-2012 1:48 PM

OwwMyEye, you're thinking of Conway's Law:

...organizations which design systems ... are constrained to produce designs which are copies of the communication structures of these organizations.

en.wikipedia.org/.../Conway%27s_law

Brad wrote re: The Manifold Blunders of Xaml–Part 1: Version and Platform Hell
on 04-18-2012 2:19 PM

Great analysis.  I could not agree more.  I really wish MS had never done Silverlight and focused all that time and money on making WPF what it should have been.  

This kind of reminds me of that one South Park where they have the machine that is called "IT" ( en.wikipedia.org/.../The_Entity_(South_Park) ).  Yes all the XAML stuff is painful, but it's better than HTML+JS!

RichB wrote re: The Manifold Blunders of Xaml–Part 1: Version and Platform Hell
on 04-18-2012 5:09 PM

Your timeline conveniently misses APIs such as WFC, MFC, Forms3 (Forms cubed).

Perhaps even AFC should be included too?

I originally wrote this comment on an iPhone - but had to abandon that because your captcha is iOS-phobic

Rob Eisenberg wrote re: The Manifold Blunders of Xaml–Part 1: Version and Platform Hell
on 04-18-2012 7:35 PM

@RichB

Sorry about the iOS problem!  I'm not familiar with WFC, Forms3 or AFC, can you provide some links? My personal history mostly surrounds Win32, WinForms and Xaml, so that's what I was mostly aware of. I completely forgot MFC, which is obviously a bog one. Though, isn't it just built on top of Win32?

Craig Thompson wrote re: The Manifold Blunders of Xaml–Part 1: Version and Platform Hell
on 04-19-2012 2:15 AM

What really confuses me about Microsoft's XAML approach is why they chose to reuse the xmlns from WPF 3.0 in WinRT/Metro (i.e., "schemas.microsoft.com/.../presentation").

I get that XAML is an XML language for representing an object graph. So shouldn't the qualified name of an XML element uniquely identify the runtime object?

Apart from trivial demos to show that "you can run your Siverlight app under Metro by only changing two lines of code!!", what is gained by keeping the same xmlns, instead of explicitly changing it to indicate that this XAML will generate a *completely different* object graph (native WinRT vs managed WPF) when it's loaded?

Bill Seddon wrote re: The Manifold Blunders of Xaml–Part 1: Version and Platform Hell
on 04-19-2012 6:00 AM

Your concern is so real.  I remember the horror of having learned WPF only to find that many equivalent Silverlight functions were different for no obvious reason.  The way images are created on the two platform are different - why?

It is a shame you feel unable to continue to improve Caliburn.  It was/is innovative so its disappointing to hear you are struggling to lift your head above the maintenance parapet.  The one observation I'd make is that this scenario may arise because of your diligence.  It's laudable that you want to support developers but you're doing it for free while many will be using your efforts to  earn money.  Maybe you need to adjust the balance a little (though that does not solve the ever changing platforms problem).  Microsoft rarely repairs its broken products (security issues being the exception).  Instead they are fixed in later versions for which we must pay.

Anyway, because of similar concerns, our development is now moving to HTML/Javascript.  Back in the day, the HTML/Javascript combination was not up to the task and WPF was a great way to create slick animations. Silverlight also promised some cross-platform support.  But the emergence of libraries like JQuery, Raphael and even ExtJS makes it possible to present sophisticated UIs which are also truly cross-platform (from IE6 to the latest FF, Chrome and Safari). Great, small and embeddable web-servers mean the round-trip to the 'server' is negligible and, anyway, uses Ajax techniques so the page does not need to be replaced (ironically a Microsoft innovation for OWA and IE 5.5 back in the late 90's).

From my perspective, Microsoft is losing/has lost primacy reducing the relevance of WPF and all those new UIs.

Massimo wrote re: The Manifold Blunders of Xaml–Part 1: Version and Platform Hell
on 04-19-2012 9:30 AM

We are an ISV and in the last MS Event in Texas, where we were a sponsor, I specifically asked many other ISVs in the show, about their UI strategy, and was not surprised that just like us, every single one of them is moving to HTML/Javascript. So Microsoft has managed to push its own partners away from XAML.

But maybe that's a good thing!

RK12 wrote re: The Manifold Blunders of Xaml–Part 1: Version and Platform Hell
on 04-19-2012 9:45 AM

Isn't everything Microsoft does unstable? Don't they constantly abandon "yesterdays ?? of the future"? The only thing they seem to care about is their own software... think about the entire security system in Windows... its designed for programs that work with files the way Microsoft Word does, not the way most business software works with files.

I have been a Windows programmer for a long time, my preferred development language was abandoned a while ago, and when it quits working in Windows I'll switch to another operating system and development language, like so many companies have already done or are planning on doing and like more and more of my customers are wanting all the time. Microsoft has ruled the PC market for a long time but they are losing their grip and its because of THEM, not because of their competitors.

Jim wrote re: The Manifold Blunders of Xaml–Part 1: Version and Platform Hell
on 04-19-2012 11:00 AM

Good analysis, but the developer community screams, "ZOMG, the platform is DEAD!" when Microsoft stops iterating.

Paul wrote re: The Manifold Blunders of Xaml–Part 1: Version and Platform Hell
on 04-20-2012 4:11 AM

I've been thinking about this for a while too, very well written blog post.  In a past role I had to come up with potential platforms for a new system with pros & cons.  This was just before Win8 muddied the water further but looking for a platform that might live for 5-10 years it was impossible to recommend any microsoft desktop solution even then.  Microsoft had publicly stated that WinForms was superseded (future security patches only) and WPF was the future.  But then the Silverlight is dead, what about WPF rumours started and MS completely failed to clarify the situation (Ballmer famously making matters worse).  If MS can't clearly describe their platform strategy then that seems to speak volumes.  With the big chances of Win8 they had chance to clean up, but instead gave 'x' more ways of doing the same thing as well as the existing flavours.  If you're a "start up" you're probably doing web html/JS anyway.  If you're doing enterprise you could live with just one way of doing things as well as it had a clear roadmap, was well supported and you knew the rug wouldn't be pulled from under your feet!

Dennis Triplett wrote re: The Manifold Blunders of Xaml–Part 1: Version and Platform Hell
on 04-20-2012 5:22 PM

I'm so glad I found this blog... I've been out of the programming world for many years... i.e. Pascal days... and have decided to venture back into programming.  I know C, C++ and I'm learning C#.

I recently bought VS2010 pro and Microsoft Expression Studio 4 Professional.   I was starting to learn Xaml and WPF.  But...

Just like the poster of this blog wrote, I too have been seeing some inconsistency in WPF  and Silverlight development.   I became a little suspicious of both.  WPF looks cool and I had great hopes for it.

I stopped for awhile then started again then ran into this blog.  I'm now re-thinking my direction and will look into Javascript/HTML5 programming.

Question, should I also abandon C#?  I would like to develop web base, desktop and tablet database centric software.  Am I on the right track?

Thanks and this blog has been an eye opener for me...  Not sure which way to turn.  :o)

Dennis

Patrick van Dijk wrote re: The Manifold Blunders of Xaml–Part 1: Version and Platform Hell
on 04-23-2012 2:56 AM

I recently wrote down the many ways of developing graphics apps....

1. GDI

2. GDI+ having anti-aliasing

3. DirectX for 3D

4. Used to have DirectDraw which is deprecated now

5. Can use OpenGL

6. WPF

7. Silverlight

8. XNA

9. WinRT

Mason Wheeler wrote re: The Manifold Blunders of Xaml–Part 1: Version and Platform Hell
on 04-23-2012 12:55 PM

This shouldn't surprise anyone.  It's been obvious for at least a decade now that Microsoft's strategy is to keep developers on a treadmill.  <a href="www.joelonsoftware.com/.../fog0000000339.html">Heck, Joel Spolsky wrote a great article about it way back in 2002.</a>  Anyone still developing on a .NET stack is a fool.  The writing's been on the wall all this time, but we've ignored it.

Mason Wheeler wrote re: The Manifold Blunders of Xaml–Part 1: Version and Platform Hell
on 04-23-2012 1:03 PM

Argh, comments here don't like inline hyperlinks, and no edit function.  Can someone fix that please?

Ben wrote re: The Manifold Blunders of Xaml–Part 1: Version and Platform Hell
on 04-24-2012 1:18 AM

I don't think the above is deliberate at all.

WPF replaced WIndows Forms which is crap for doing anything fancy..

Silverlight  is basically WPF in a sandbox needed for browsers - most of the changes were driven by

1) A Sandbox

2) The lack of bandwidth , ( this has changed so later versions are closer to WPF)

Metro Apps

- We tried making the OS managed (Longhorn) , all the pinvokes to native is a pain , since we cant  make it managed we can make the types the same and have seamless C++/C#/JavaScript interop.  WinRT is fast..

- The new future is you must support ARM none of our old stuff runs well on that ( try COmpact framework)

- We tried  Midori /Singularity as a Windows replacement but we need to keep all the devs happy so we bring the ideas into WinRT. Midori would have been NO backward compatability

Anyway WInRT /Metro looks miles ahead of what apple and Linux are doing especially in terms of modularization and reuse of components.

Ben wrote re: The Manifold Blunders of Xaml–Part 1: Version and Platform Hell
on 04-24-2012 1:20 AM

I would also add on APple or Linux you have a completely different platform for hand helds as well.  Most OSX apps don't run on iphones etc so you should consider yourself lucky..

icanhasdesktopback wrote re: The Manifold Blunders of Xaml–Part 1: Version and Platform Hell
on 04-26-2012 5:40 AM

There's also xml based Media Center Markup Language, which is used to develop apps for Windows Media Center that comes with Vista and 7.

What I don't understand is, why they have created another xml based UI when WPF could be used in the first place. I guess Microsoft team that is responsible for Windows Media Center SDK suffered from the not-invented-here syndrome back then.

NIH syndrome also applies to the Metro team as well: they could have looked at how Windows Media Center is integrated into the operating system. WMC can be set as the default shell with a couple of tweaks, that is if you want to use it in a HTPC box over XBMC for some weird reason. WMC has a SDK to develop apps for it and it runs those apps in their own sandboxes. The same thing could be done for Metro in order to separate the now "classic" Windows 7 desktop and Metro interface, for people who want to keep Metro suffz out of their desktops while using Windows 8.

Rishi wrote re: The Manifold Blunders of Xaml–Part 1: Version and Platform Hell
on 06-22-2012 12:24 AM

Exactly, my sentiments 100%. I'll just add that if there was conditional compliance in xaml, a sort of #if/#else if you may, these perceptual changes would have been so much easier to, though not accept, but at least work around.

And I've said this many-a-times that Apple's success has been predicated on the work done at NEXT, which served as the  foundation for both OS X and iOS, whilst Microsoft was floundering with Longhorn, WPF, Silverlight, and now WinRT/Metro. Hopefully, WinRT would be it, if not I predict the Microsoft ecosystem will loose again.

Thanks for writing this.

Steve wrote re: The Manifold Blunders of Xaml–Part 1: Version and Platform Hell
on 06-22-2012 7:03 AM

It isn't shiny nice on the web stack either, where you have all these different browsers and their inconsistencies to deal with.  Just look at IE6, 7, 8, 9, etc...

It's a common thing in all their products, always has been.

Schneider wrote re: The Manifold Blunders of Xaml–Part 1: Version and Platform Hell
on 07-12-2012 10:34 AM

WPF/XAML has been a disaster for MSFT and almost all developers who have bought into it.

It was a framework that was invented in isolation with no real world apps using it apart from Blend. It was never properly dog-fooded. It was conceived in the hell of the Vista debacle. Big architectural ideas that could not be implemented in reality. Ironic it came from the ashes of the IE team, but now the web browser is vastly more performant than any XAML tech.

I still work with this technology so choose to remain anonymous because I dont want to put myself out of work, but I have certainly given up on all XAML related technologies now and look to the open source community to come up with a UI framework based on D3D or OpenGL that may even be cross platform. Pervasive 3d acceleration is here so it seems only a matter of time until a UI-framework arrives and MSFT will be forced to support/bundle it just like jQuery et al. That is assuming HTML doesn't take over the entire world first which it looks like it will.

john wrote re: The Manifold Blunders of Xaml–Part 1: Version and Platform Hell
on 07-12-2012 11:02 AM

complaining about pace of innovation - brilliant

Caleb wrote re: The Manifold Blunders of Xaml–Part 1: Version and Platform Hell
on 07-13-2012 2:38 AM

@john He isn't complaining about the pace of innovation, the problem is that all of the changes break things for no advantage.

About The CodeBetter.Com Blog Network
CodeBetter.Com FAQ

Our Mission

Advertisers should contact Brendan

Subscribe
Google Reader or Homepage

del.icio.us CodeBetter.com Latest Items
Add to My Yahoo!
Subscribe with Bloglines
Subscribe in NewsGator Online
Subscribe with myFeedster
Add to My AOL
Furl CodeBetter.com Latest Items
Subscribe in Rojo

Member Projects
DimeCasts.Net - Derik Whittaker

Friends of Devlicio.us
Red-Gate Tools For SQL and .NET

NDepend

SlickEdit
 
SmartInspect .NET Logging
NGEDIT: ViEmu and Codekana
LiteAccounting.Com
DevExpress
Fixx
NHibernate Profiler
Unfuddle
Balsamiq Mockups
Scrumy
JetBrains - ReSharper
Umbraco
NServiceBus
RavenDb
Web Sequence Diagrams
Ducksboard<-- NEW Friend!

 



Site Copyright © 2007 CodeBetter.Com
Content Copyright Individual Bloggers

 

Community Server (Commercial Edition)