An article was published at JupiterJS.com (titled “JavaScript vs Silverlight”) arguing that JavaScript is better than Silverlight. Unfortunately, there is no way to post comments on that page (weird, really) so I decided I would post my answer here.
First let me state that I do not think that Silverlight is an opponent, nor a threat to JavaScript. I love both, I write both, and both are helping me to create better experiences.
Also, Silverlight has grown to be much more than “just” a web plug-in. You can write out-of-browser applications for PC and Mac, and now you can use it to write Windows Phone 7 applications. In the near future it will expand to other platforms (top boxes, etc). So opposing JavaScript to Silverlight is really shooting at the wrong target in my opinion.
That said, some (many) of the points in this article are wrong and need correction, so here goes:
- Plugin Lock-In: OK I will grant that one. The number of users according to the article is 50%, Microsoft speaks of 65% (I think, didn’t check the latest), but all in all you’re right, it is less widespread than JavaScript. The fact that it took years to JavaScript to reach that broad reach and that level of standardization is irrelevant right now, since we are in the present and not the past. This is an argument for what I have been advocating always: Use Silverlight to enhance your webpage, not to replace it completely.
- HTML5: Quoting: “HTML5 is going to provide a lot of the same goodies that Silverlight provides.” Keywords: “is going”. Where do I start… first it is really not ready yet. Let’s talk about it in 2 years or 5 years. Second, even though it is developed as an open standard, nothing says that the browser makers will implement all functionalities in the same way and in the same time frame. I have been burnt too much in the past to trust the words of corporations when it comes to implementing “standards”. On the other hand, you know exactly what you get with Silverlight.
- Group Standards: See “HTML5”.
- Competition: Since when is that a bad thing? Competition encourages innovation, and Flash/Flex have pushed Silverlight to become bigger and better in a ridiculously short timeframe. Besides, HTML5 is also a competition to Flash and Silverlight and others, so the same story applies here.
- Backend locking: First, why talk about Flex here? Was this article initially aimed at Flex? Weird… anyway, when it comes to Silverlight, nothing could be more wrong. SOAP-based services are just one option. With Linq-to-Json and Linq-to-XML, parsing JSON and XML based replies is a breeze and much easier (and faster) than in JavaScript. Believe me, I know, I did wrote a lot of parsing code for JavaScript when it was all we had.
In fact, Silverlight is so good at REST calls and networking that I would recommend using Silverlight (where available) to do that even if you do not use XAML to create a UI. Use the HTML Bridge to communicate back and forth with JavaScript, and use the speed and ease of use of Silverlight for the heavy lifting. - Development time: Visual Studio is the best development environment available, and that pretty much sums it up. Firebug is great, but I really prefer a full blown debugger. I understand it is a matter of preference to a certain point.
- Open: As someone who writes and maintains open source projects, and a rich blog, I know that there is a lot of open source projects and of documentation available online. I rarely use the Microsoft official documentation if I want to solve something, I either get an open source component to perform the task, or I find how to do it myself, with the added value of learning something in the process.
- Community: I have been active in the JavaScript community and I have been active in the Silverlight community, and I loved both. I am more active now in the Silverlight community because it is where I spend most of my time. It is a rich, vibrant and innovative community, and I love every moment I spend interacting with it.
- Scripting vs Compile: We could argue for hours about that. I love C# as a language, so I am glad I can use it in Silverlight. That said, you can also use Python, Ruby and more if you prefer. As for the fact that scripting produces less code, I am puzzled. I doubt it. Maybe if you ignore the fact that jQuery is of course code, and needs to be interpreted too. In that matter, Silverlight wins, since the .NET framework is not interpreted, but is already there and optimized, ready to be used. Also, compiled code is still faster than the fastest JavaScript, though to be honest I never really found that to be an issue when I was writing a lot of JS code.
Also, I feel that it is easier to write clean decoupled code in Silverlight than in JS. Componentizing an application with MEF or an IOC framework is super easy. .NET wins here in my book. - Testing: Silverlight has at least two unit test frameworks that I know of, the Silverlight Unit Test (part of the Silverlight toolkit, available for free and super easy to use) and NUnit. As for automated UI testing, it is also possible.
- In the box: What I usually advocate is “island of richness” made in Silverlight than communicate with the rest of the page. I am not a huge fan of full pages made in Silverlight. These island of richnesses can communicate with JavaScript (through the HTML bridge) or with other Silverlight applications running in the same page or in another page (local communication). It is as open as I need it to be. Also, Silverlight applications (in the contrary of other plugins) can blend with the HTML if needed, and you can place HTML elements in front of a Silverlight area. It does not need to be square, by the way, you can clip it to any shape. Here too, I consider the fact that I can use JavaScript (should I need it) an advantage.
- Perceived performance: As said before, it is now super easy (with MEF) to componentize a Silverlight application and load modules on demand. It is also possible to write customized splash screens, so the UX is better should the loading time be slow anyway. Oh, and I can use JavaScript to start performing tasks while waiting ;) best of both worlds.
- Mobile: iPhone, I agree. It’s funny to have to use a closed platform as an argument for openness ;) but yeah, as long as Jobs doesn’t come to his senses, Silverlight won’t make it to iPhone. This kind of things should actually make you want to sell your iPhone and choose a better phone, but this is another debate. For now, for mobility with Silverlight, I will use Windows Phone 7 and am very excited about it. There is also Silverlight on Symbian, and I wouldn’t be surprised to see it run on Android too some day.
- OS Support: As I said, the numbers cited by MSFT are higher than 50%, but since noone really knows, I will happily concede that JavaScript’s reach is larger. That said, Silverlight runs on multiple flavors of Windows (included embedded for kiosks etc), Mac, Linux (it runs pretty well there, Miguel and his team are doing a great job), plus all the other platforms to come (Windows Phone, top sets, etc). Yes JavaScript wins in terms of reach, which makes it a great fallback strategy.
- Accessibility: The accessibility story is much better in Silverlight 4 and this is an area where the team is constantly improving. Already now, it is possible to make selectable rich text boxes. If you want to display HTML content on top of Silverlight, you can. Also, this really has nothing to do with JavaScript, you’re comparing Silverlight to HTML here.
Anyway… my point still stands: Both technologies complement each other. Silverlight plays very well with JavaScript, and an SL application is really not the isolated ivory tower that the article paints. It has multiple ways to interact with the page, with JavaScript and with the web.
It is also a platform that is a lot of fun to develop for, and allows for a great user experience. It enables my designers to think out of the box and we constantly push them to try new concepts. No more square boxes, easy multitouch interactions, rich and smooth hardware accelerated animations and much more make Silverlight a really great platform to code for. So dear reader if you made it that far, do not let ill-informed articles lure you away from Silverlight, at least give it a try and if you have something that you don’t understand, ask the community, it is great!.
Oh, and if you disagree, please post a comment below (but keep it civil and constructive ;) This is what the community is about, discussing and interacting!
Cheers,
Laurent
Print | posted on Wednesday, July 14, 2010 2:49 AM