Saturday, December 8, 2012

Why is choosing Silverlight over HTML5/CSS/JavaScript a bad idea? [closed]

Why is choosing Silverlight over HTML5/CSS/JavaScript a bad idea? [closed]

I realize that I am about to make a statement some of you won't agree with. I really want to believe I am wrong, but my experience tells me otherwise. Please don't be too quick to judge until you finish reading.

I am a consulter with a ASP.NET/MVC/CSS/HTML/AJAX background working for a client who happened to approve Silverlight (v.4) as a platform for their enterprise web-application about 2 years ago. The application itself is somewhat standard web-app with tons of forms and few charts. There is nothing worth employing those rich presentation capabilities Silverlight is known for. I wasn't there when that choice was made. The platform was recommended by an offshore team who has done the most of work and managed to make it to beta. At the time the choice was done Silverlight was on the rise and looked like yet immature but promising fashionable technology that doesn't have a rival and was thought to stay.

Now I am assigned to work on some bugfixing and implementing small features and it's getting more and more obvious that Silverlight was a poor choice. Let me explain. Even though the Silverlight platform is capable enough to provide all necassery means for solving the business problem it has some serious flaws (the following is solely my opinion based on my personal experience):

  • high learning curve

  • boilerplate code that is hard-to-read and follow yet necessary to wire things up (PRISM, IoC frameworks), so that the app was in a minimal setup that you could run

3. Lots of bugs and inconsistencies

Silverlight is a mess. The codebase is full of weird things and bugs that are there to stay for the sake of not breaking what's been already built based on them.

4. Poor documentation

  • How would you do template selection based on a data context?

  • Where is it said in the documentation that the Setter.Value property cannot take binding values in Silverlight 4, but can do it in Silverlight 5?

5. Complete mess with versions, SDK's, tools, toolkits, runtimes, developer runtimes, etc.

  • Have you tried to set up a Silverlight 4 project when the official latest and greatest version is 5? Good luck :)

6. Breaking changes and abandoned techniques

  • WCF client proxy with the Async pattern and event approaches

7. Error prone

Lots of headache caused by bindings and all sorts of run-time evaluations.

8. Cumbersome stiff and verbose XAML syntax

You have to write requires tons of markup for expressing simple things:

9. Slow even on modern computers

  • Due to the fact that nobody is following the best practices which are hard-to-find-the-latest-one and inconsistent with one another.

This is my firm belief. All in all I think Silverligh is very high in maintenance while doesn't show a noticeable difference (compared to let's say AJAX/HTML) in return on investment.

I am convinced that even though the project is in a wrapping up stage now, all further development should be diverged into a parallel project based on HTML5 with a modern MVVM/MVC client framework (AngularJS, Backbone). I already had a quick talk about this to my client, but I wasn't ready to support my point with real facts and numbe So this is what I am working right now: I am building some ground, looking for evidences and case-studies that show that Silverlight is a poor choice taking into account all of the above considerations.

The problem is that the most information I've managed to find comes from blogs and forums. I am looking for some official studies / authoritative opinions / research documents / accepted articles that break down the reason why HTML5/AJAX/CSS3 is a better platform for building an enterprise applications than Silverlight.

I would appreciate if you pointed out at some resources that could support my point. Thank you.

UPDATE

  1. An author of a MVVM faramework on Silverlight probelms: http://devlicio.us/blogs/rob_eisenberg/archive/2012/04/18/the-manifold-blunders-of-xaml-part-1-version-and-platform-hell.aspx

No Answer and comments so far




No comments:

Post a Comment

Send us your comment related to the topic mentioned on the blog