I am full of frustration at this point. 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. Feel free to leave a comment if you disagree.
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 own opinion based on my personal experience:
1. High learning curve Even though you might have a strong knowledge of C# and understand principles of the MVVM paradigm it doesn't help you to get fluent with Silverlight quickly due to the reasons stated below.
2. Wire-up code that is hard-to-read and follow
By this I mostly mean the game rules dictated by frameworks which are defacto parts of Silverlight platform and you just have to deal with them: Unity and MEF. It is a whole different story what benefits you would get using them, but there is a big room for headache and frustration here. In few words:
Both of them are runtime evaluation frameworks, which leave you guessing if your code will break when you try to navigate to another view.
Both of them are declarative in nature. So there is no straight way to see how each particular situation is going to be resolved if will be at all.
Poor troubleshooting means. Obscure error messages with little-to-no details. For example this is what would you get in the trace window if you forgot to add the
Exportattribute to yourShellclass:A first chance exception of type 'System.ComponentModel.Composition.ImportCardinalityMismatchException' occurred in System.ComponentModel.Composition. The exception itself is swallowed by the MEF internals.There is no way to switch these frameworks to a manual mode for delicate situations. Sometimes you wish these frameworks didn't exist at all.
3. Lots of bugs and inconsistencies
Silverlight is a mess. The codebase is full of bugs and weird things that are there to stay for the sake of not breaking what's been already built based on them.
- How do you like this: http://msdn.microsoft.com/en-us/library/system.windows.controls.textbox.watermark(v=vs.95).aspx ? The TextBox.Watermark property was forgotten to be implemented. Please correct me if I am wrong, but a TextBox is a basic brick of any UI and has to work perfectly anywhere. Watermark (placeholder attribute in HTML) feature has been around for years now and still hasn't found its way to Silverlight. This example is very illustrative showing Microsoft's attitude to their creation. It cost me 2 hours to try solutions from the other developers to find out that non of the works, and then about 1 hour writing my own, that turned to be not working either. All in all 3 hours for nothing.
The officially recommended way of using Silverlight is to follow the principles of the MVVM paradigm. The PRISM framework is based on these principles. The most important thing here is the concept of binding which connects your view to the view model without necessarily knowing any details about the later at the compile time. Well, I would say your MVVM framework is as good as versatile and flexible you binding mechanisms are. Unfortunately the bindings in Silverlight are so halfway-baked and stiff that you either give up on using them or have to become an expert in Silverlight internals and write them yourself tailored for your needs. Out of the box you cannot bind to anything but a property. You cannot use events without employing additional libraries from Blend. You have to learn the notion of a behavior and wrap you methods into commands just to get things connected. This is a shame! It makes you waste hours fighting the framework rather than spending them on your business problem!
4. Poor documentation
It is a problem of MSDN in general. The first time you look at something you haven used you need some clear input and a few examples to get a grasp of it. If you are lucky you will find few basic examples and a link to an article that has more information, but for the most documents on MSDN it's just a quick remark what the method does spelled in terms that are not defined leaving you guessing what it really does.
How would you do template selection based on a data context?
Where is it said that the Setter.Value property cannot take binding values in Silverlight 4, but can do it in Silverlight 5?
Another annoying thing is that the Silverlight is a sub-set of WPF which has more features and documented way better. So when you find something that looks like what you've been looking for hold your breath, chances are it's for WPF only. Sometimes it makes sense to exclude WPF from the search query (-WFP).
A good advise would be to study the examples and the source code if available which stand aside and don't have links from the reference documents. This takes time however and doesn't work for questions that need immediate answers.
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 :) Let me ask you a simpler question: Where can you download the Silverlight plugin of version 4?
6. Breaking changes and abandoned techniques
Here is an official list to start with. Here are few of my observations:
- The client proxy for a WCF service used to utilize the Async pattern back in a day. Now there is no such option. All you can do is to rewrite your code using the event-based approach. Another thing that is how you go about the Dispatcher object to make sure your calls are executed in the UI thread. It used to be a big deal and the Internet is full of articles on how to do it the right way. Nothing of it makes sense anymore. All these articles turned into trash and now can just mislead you.
7. Error prone
Lots of headache caused by bindings and all sorts of run-time evaluations.
- For god sake, why does the XamlParseException have only the line and column of a problematic piece XAML in the first document in a chain of nested documents where the real problem is in the last one? In order to troubleshoot this problem you have to unwrap all these XAMLs to the deepest one which takes lots of time. A related page from MSDN wishes you luck.
8. Cumbersome stiff and verbose XAML syntax
You have to write requires tons of markup for expressing simple things:
- Have you tried to restyle a validation tooltip of a textbox? Say, you want its border to be orange instead of red. Here is how you can do this. All you need is to copy THE-ENTIRE-XAML-THAT-COMPLETELY-DEFINES-A-TEXTBOX and then just change one property.
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
- 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 comments:
Post a Comment
Send us your comment related to the topic mentioned on the blog