“Silverlight” – Will it be the future of Web?
Microsoft recently released what they called “Silverlight” (nice name, btw). Microsoft claimed that Silverlight will be the future of Web with the ability to deliver compelling user experiences and rich medias such as videos and animation. If you haven’t aware about SilverLight, check out their FAQ at http://www.microsoft.com/silverlight/faq.aspx
We have been evaluating Silverlight (previously called WPF/E) since its first initial alpha release. In this post, I would like to share some thoughts about our experiences and challenges with Silverlight. There are at least 3 big challenges that we are facing before we could agree to vote on Silverlight:
- First of all, Silverlight relies on ActiveXObject. This is somewhat a big showstopper as large companies do not allow ActiveXObject in their domain group policy.
- Client requirements. Streaming videos, heavy-level animations and extensive 3D rendering means you need a very powerful PC to utilize Silverlight-based application. I think the client computer will need at least 128MB NVidia graphic card (similar to Vista requirement). Do companies ready to upgrade thousands of their computers to use Silverlight? In my opinion, not at least until 2008/2009 when Vista replaced XP (at least 85% dominance)
- Application. I was wondering what kind of business-type Web application that is suitable to use Silverlight features, such as the streaming videos and compelling animation. I agree that Silverlight is great for Webcast companies and Movies companies like Hollywood or Fox Movies (see a sample implementation for Fox Movies at http://silverlight.net/fox/). But for business-type applications like CRM or ERP?
So, will Silverlight be the future of Web – or perhaps Goldlight ? Is Silverlight just another competitor of Flash? What do you think? Post your thoughts and comments.
Regards,
Jimmy.
Seems nice.. Are there any plans with silverlight?
Hi Jimmy,
It looks like at least one company has already created a datagrid using silverlight: http://download3.xceedsoft.com/demo/gridwpf/Xceed.Wpf.DataGrid.Samples.LiveExplorer.xbap
Also, I’m going to have to disagree with most of the points you’ve made:
1) Silverlight doesn’t require you to use the ActiveXObject. It does require that you’ve installed the client libraries but that shouldn’t be a problem for most companies that want to make use of such apps.
2) The hardware requirements will only depend how you’ve made use of Silverlight since Silverlight itself doesn’t necessarily require lots of resources. If you’re making games and lots of multimedia then yes, you’ll probably need the hardware. However, if you’re making lightweight business controls (such as what Intersoft normally does), then the average computer should suffice.
3) Sure, Silverlight is Microsoft’s response to flash but that doesn’t mean that it shouldn’t be used for business apps. Many of us have always wondered why flash hasn’t been used in more business apps in the past. Even with AJAX, web apps can really only go so far until they hit a brick wall in terms of usability and performance (try creating a webgrid with 50 columns and 4000 rows sometime and you’ll see what I mean). A rich client platform such as this could do wonders to the user’s experience of such apps.
I would strongly encourage Intersoft to persue using Silverlight. Our users deserve better.
Hi Chris,
Thanks for your thought.
FYI, the Xceedsoft Grid is for WPF though, not Silverlight. Some points about your comments:
1. If you open the Silverlight.js, you will see this line “new ActiveXObject(“ag.aghost”)”. I believe you aware that many developers don’t like to rely on ActiveXObject, especially since all browsers now have native XmlHttp, including IE.
2. About Silverlight controls, our initial research shows that it is in deed a client-side technology (just like HTML, but with ability to render richer graphics). The XAML file that associated with the Silverlight need to be downloaded to client (like HTML), so if you have 4000 rows of data in the XAML, it still need to be downloaded to client side. Futhermore, the XAML markup seems like generate much more tags/codes than HTML (look at the Canvas things, the basic drawing tags, etc). It doesn’t really solve the Web bottleneck though.
Any thoughts?
Regards,
Jimmy.