I've been tasked with figuring out if Silverlight (1.1) is something our company should invest in. I haven't found any compelling reason to say yes. We can do everything we need using AJAX and ASP.NET. We're a small dev team and don't have any designers.
So we'll never utilize the eye candy offered by Silverlight. Isn't that the only reason to use Silverlight - eye candy?
What advantage does Silverlight have over AJAX? If I need to make a call to the server, the AJAX UI is tied up but so is the Siverlight UI. Silverlight also has the same problem AJAX does with thread mashalling. I can create a background thread in Silverlight
but it doesn't really make any sense to. Since I can't update the UI thread what good does the background thread do? Just use the UI thread.
For now, I don't see how troubling users with another browser plug-in is any advantage. Please prove me wrong if you disagree and why.
If you have a technology that does EVERYTHING you need and want, then why would you change? There's nothing wrong with that. There's nothing that states that you have to move to Silverlight. It's not like MS will stop supporting ASP.NET AJAX.
However, you're argument against the usefulness of Silverlight is tailored to your specific situation and can also be made against Flash. Yet, Flash (or Flex) is used all over the place by people who are making compelling browser-based applications that
attract customers. So, just like Flash, this technology will not be for everybody, but for those who want to use it, now it is available.
Thanks. Maybe I missed something. So are you saying the main reason to use Silverlight is for the visuals? Meaning, you or someone on your team is very good at graphics design.
As for layout, there is already a lot out there to help make a visually appealing web app. Things we've been using for a while. I don't mean to be down on Silverlight. I actually like the technology. I'm just trying to cut through the market fluff and
get into real world reasons as to why a team would adopt it. So far, no one has said anything.
I, personally, think, at least for right now, the main reason for a shift to Silverlight IS the visuals. So, depending on what your application is meant to do, you may or may not receive any benefit from that shift. Sure, you can make great-looking websites
without it. This site is a good example of one. But, this site could also be more interactive by using a client-side based application. Of course, that begs the question, why? This site's not trying to sell itself or another product. It's only trying
to provide a function. If you're site, instead, is the face of your business, then the better the visuals and the more impressed the potential customer, then the greater potential of gaining that customer.
Also, there are things you CAN do with Silverlight far easier than you can in straight javascript/DHTML, such as animations. Can they be done w/o SL and Flash? Sure. But not nearly as easily. I guess what it comes down to is, how much of a priority,
for your application, is the user's experience and can the user's experience be improved by some really nice visuals?
Excellent jasonxz. I agree. Replacing all of the javascript coding with C# for example is another great reason. The visuals are then a byproduct but not the main deciding factor for going with SL.
If anyone on the forum has chosen SL for a specific solution, I'd be interested to hear why. Specifically something along these lines:
- We had this particular problem
- Our existing technologies could have done this (or couldn't have) but...
- So we went with SL because...
A template like that is usually the best way to get definitive reasons on specific scenarios SL filled a hole when nothing else good have. Or at least, SL filled it better and of course here's why.
Well I am working on a project and we are using Silverlight because they want a graphical interface and they have a staff that is familiar with .NET. I think they were more comfortable supporting a .NET app in the future as opposed to javascript or Flash
given the difficulty in finding resources who are talented in those technoligies.
In my situation, we wanted to be able to drag/drop and rotate icons, and be able to save/load the results. We also wanted it to be supported on major browsers. I felt we could have used Flash, but no one had much experience with ActionScript, and we decided
we didn't want to have an ActionScript specialist to maintain the application. So basically we went with Silverlight because it is cross platform/browser compatible and doesn't require knowledge of a specific/specialized language.
So are you saying the main reason to use Silverlight is for the visuals?
I'd say the other main reason is because you use .NET as the codebehind for your logic rather than javascript. I realize, with AJAX.NET, you still end up with a fair amount of C# codebehind but this is all run on the server rather than the client and it's
inevitable that you'll end up having to do some javascript still. And I don't know about you, but I abhor javascript, especially compared to C# (I'd probably rather do javascript than VB script however).
Additionally to say it's 'just for the visuals' is one thing but in my opinion, even with no graphical design skill, it's easier to do interfaces in XAML than HTML. This translates into being able to more rapidly develop a (good or bad looking) interface
than you previously were able to with html. This of course supposes that you are able to use some stock controls such as "buttons" and whatnot which are currently not available with the silverlight developer frameworks. Currently it feels like you get caught
up in the minutiae of recreating basic controls too readily but this will change.
Don't forget the famous "workflow" gains of being able to develop the application while a graphical designer develops the interface side by side. Even if that graphical designer is non-existant the idea of being able to separate your business logic from
your interface is first class in XAML compared to HTML. Which means if somewhere down the road you do decide to spruce up your interface it may not require developer support at all! Of course there are many features of XAML, that are not currently present
in silverlight but will be as it matures (such as triggering storyboards purely in xaml), that are required before this goal is truly achievable. Regular, desktop WPF applications are much better at this and I'd expect Silverlight to get to the same point
before it's officially released.
Another reason to go to Silverlight is scalability. One can eliminate or greatly reduce the need to generate HTML on the server side. On the server side one can manipulate XAML with business data as metadata and return that to the client and the client
browser renders it with client CPU. There will be a huge reduction in page postbacks and the need to use the ASP.NET page pipeline and create all the temporary .NET objects representing the ASP.NET page and controls and update them on a fine grained basis
with business data. Most of the interaction between the client and server will be with web services and only updated XAML or differential data to manipulate the next XAML on the client side where the various sequential XAML will be stored as resources in
a dll or cached on the client. One can have a master page and only individual panel XAMLs need to be updated or replaced after callbacks. This is not to mention the speed increase with CLR JIT compiled code compared to interpreted javascript.
Also there will be a reduction in image files downloaded as for example for special gradients in a button one can now use simple vector graphics declaration in XAML.
Dennis
The server side CPU is reserved for predominantly business logic
johncollins
Member
38 Points
34 Posts
Why use Silverlight when AJAX does everything we need?
Aug 30, 2007 04:14 PM | LINK
I've been tasked with figuring out if Silverlight (1.1) is something our company should invest in. I haven't found any compelling reason to say yes. We can do everything we need using AJAX and ASP.NET. We're a small dev team and don't have any designers. So we'll never utilize the eye candy offered by Silverlight. Isn't that the only reason to use Silverlight - eye candy?
What advantage does Silverlight have over AJAX? If I need to make a call to the server, the AJAX UI is tied up but so is the Siverlight UI. Silverlight also has the same problem AJAX does with thread mashalling. I can create a background thread in Silverlight but it doesn't really make any sense to. Since I can't update the UI thread what good does the background thread do? Just use the UI thread.
For now, I don't see how troubling users with another browser plug-in is any advantage. Please prove me wrong if you disagree and why.
Thanks,
John
jasonxz
Participant
1787 Points
557 Posts
Re: Why use Silverlight when AJAX does everything we need?
Aug 30, 2007 04:29 PM | LINK
If you have a technology that does EVERYTHING you need and want, then why would you change? There's nothing wrong with that. There's nothing that states that you have to move to Silverlight. It's not like MS will stop supporting ASP.NET AJAX.
However, you're argument against the usefulness of Silverlight is tailored to your specific situation and can also be made against Flash. Yet, Flash (or Flex) is used all over the place by people who are making compelling browser-based applications that attract customers. So, just like Flash, this technology will not be for everybody, but for those who want to use it, now it is available.
y_makram
Contributor
6952 Points
1353 Posts
Re: Why use Silverlight when AJAX does everything we need?
Aug 30, 2007 05:38 PM | LINK
Yasser Makram
Independent Consultant
http://www.silverlightrecipes.com
_____
Dont forget to click "Mark as Answer" on the post that helped you.
johncollins
Member
38 Points
34 Posts
Re: Re: Why use Silverlight when AJAX does everything we need?
Aug 30, 2007 05:52 PM | LINK
Thanks. Maybe I missed something. So are you saying the main reason to use Silverlight is for the visuals? Meaning, you or someone on your team is very good at graphics design.
As for layout, there is already a lot out there to help make a visually appealing web app. Things we've been using for a while. I don't mean to be down on Silverlight. I actually like the technology. I'm just trying to cut through the market fluff and get into real world reasons as to why a team would adopt it. So far, no one has said anything.
jasonxz
Participant
1787 Points
557 Posts
Re: Re: Why use Silverlight when AJAX does everything we need?
Aug 30, 2007 06:04 PM | LINK
I, personally, think, at least for right now, the main reason for a shift to Silverlight IS the visuals. So, depending on what your application is meant to do, you may or may not receive any benefit from that shift. Sure, you can make great-looking websites without it. This site is a good example of one. But, this site could also be more interactive by using a client-side based application. Of course, that begs the question, why? This site's not trying to sell itself or another product. It's only trying to provide a function. If you're site, instead, is the face of your business, then the better the visuals and the more impressed the potential customer, then the greater potential of gaining that customer.
Also, there are things you CAN do with Silverlight far easier than you can in straight javascript/DHTML, such as animations. Can they be done w/o SL and Flash? Sure. But not nearly as easily. I guess what it comes down to is, how much of a priority, for your application, is the user's experience and can the user's experience be improved by some really nice visuals?
johncollins
Member
38 Points
34 Posts
Re: Re: Re: Why use Silverlight when AJAX does everything we need?
Aug 30, 2007 06:12 PM | LINK
Excellent jasonxz. I agree. Replacing all of the javascript coding with C# for example is another great reason. The visuals are then a byproduct but not the main deciding factor for going with SL.
If anyone on the forum has chosen SL for a specific solution, I'd be interested to hear why. Specifically something along these lines:
- We had this particular problem
- Our existing technologies could have done this (or couldn't have) but...
- So we went with SL because...
A template like that is usually the best way to get definitive reasons on specific scenarios SL filled a hole when nothing else good have. Or at least, SL filled it better and of course here's why.
helfon
Member
48 Points
34 Posts
Re: Re: Re: Why use Silverlight when AJAX does everything we need?
Aug 30, 2007 06:31 PM | LINK
Well I am working on a project and we are using Silverlight because they want a graphical interface and they have a staff that is familiar with .NET. I think they were more comfortable supporting a .NET app in the future as opposed to javascript or Flash given the difficulty in finding resources who are talented in those technoligies.
swirlingmass
Participant
1358 Points
385 Posts
Re: Re: Re: Why use Silverlight when AJAX does everything we need?
Aug 30, 2007 06:32 PM | LINK
In my situation, we wanted to be able to drag/drop and rotate icons, and be able to save/load the results. We also wanted it to be supported on major browsers. I felt we could have used Flash, but no one had much experience with ActionScript, and we decided we didn't want to have an ActionScript specialist to maintain the application. So basically we went with Silverlight because it is cross platform/browser compatible and doesn't require knowledge of a specific/specialized language.
justncase80
Member
355 Points
148 Posts
Re: Re: Why use Silverlight when AJAX does everything we need?
Aug 31, 2007 02:18 PM | LINK
I'd say the other main reason is because you use .NET as the codebehind for your logic rather than javascript. I realize, with AJAX.NET, you still end up with a fair amount of C# codebehind but this is all run on the server rather than the client and it's inevitable that you'll end up having to do some javascript still. And I don't know about you, but I abhor javascript, especially compared to C# (I'd probably rather do javascript than VB script however).
Additionally to say it's 'just for the visuals' is one thing but in my opinion, even with no graphical design skill, it's easier to do interfaces in XAML than HTML. This translates into being able to more rapidly develop a (good or bad looking) interface than you previously were able to with html. This of course supposes that you are able to use some stock controls such as "buttons" and whatnot which are currently not available with the silverlight developer frameworks. Currently it feels like you get caught up in the minutiae of recreating basic controls too readily but this will change.
Don't forget the famous "workflow" gains of being able to develop the application while a graphical designer develops the interface side by side. Even if that graphical designer is non-existant the idea of being able to separate your business logic from your interface is first class in XAML compared to HTML. Which means if somewhere down the road you do decide to spruce up your interface it may not require developer support at all! Of course there are many features of XAML, that are not currently present in silverlight but will be as it matures (such as triggering storyboards purely in xaml), that are required before this goal is truly achievable. Regular, desktop WPF applications are much better at this and I'd expect Silverlight to get to the same point before it's officially released.
http://justinmchase.com/
~justin chase
dworthem
Member
68 Points
32 Posts
Re: Re: Why use Silverlight when AJAX does everything we need?
Aug 31, 2007 11:24 PM | LINK
Another reason to go to Silverlight is scalability. One can eliminate or greatly reduce the need to generate HTML on the server side. On the server side one can manipulate XAML with business data as metadata and return that to the client and the client browser renders it with client CPU. There will be a huge reduction in page postbacks and the need to use the ASP.NET page pipeline and create all the temporary .NET objects representing the ASP.NET page and controls and update them on a fine grained basis with business data. Most of the interaction between the client and server will be with web services and only updated XAML or differential data to manipulate the next XAML on the client side where the various sequential XAML will be stored as resources in a dll or cached on the client. One can have a master page and only individual panel XAMLs need to be updated or replaced after callbacks. This is not to mention the speed increase with CLR JIT compiled code compared to interpreted javascript.
Also there will be a reduction in image files downloaded as for example for special gradients in a button one can now use simple vector graphics declaration in XAML.
Dennis
The server side CPU is reserved for predominantly business logic