Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
Our team is divided on this and I wanted to get some third-party opinions.
We are building an application and cannot decide if we want to use .Net WPF Desktop Application with a WCF server, or ASP.Net web app using jQuery. I thought I'd ask the question here, with some specs, and see what the pros/cons of using either side would be. I have my own favorite and feel I am biased.
Ideally we want to build the initial release of the software as fast as we can, then slow down and take time to build in the additional features/components we want later on. Above all we want the software to be fast. Users go through records all day long and delays in loading records or refreshing screens kills their productivity.
Application Details:
I'm estimating around 100 different screens for initial version, with plans for a lot of additional screens being added on later after the initial release.
We are looking to use two-way communication for reminder and event systems
Currently has to support around 100 users, although we've been told to allow for growth up to 500 users
We have multiple locations
Items to consider (maybe not initially in some cases but in future releases):
Room for additional components to be added after initial release (there are a lot of of these... perhaps work here than the initial application)
Keyboard navigation
Performance is a must
Production Speed to initial version
Low maintenance overhead
Future support
Softphone/Scanner integration
Our Developers:
We have 1 programmer who has been learning WPF the past few months and was the one who suggested we use WPF for this.
We have a 2nd programmer who is familiar with ASP.Net and who may help with the project in the future, although he will not be working on it much up until the initial release since his time is spent maintaining our current software.
There is me, who has worked with both and am comfortable in either
We have an outside company doing the project management, and they are an ASP.Net company.
We plan on hiring 1-2 others, however we need to know what direction we are going in first
Environment:
General users are on Windows 2003 server with Terminal Services. They connect using WYSE thin-clients over an RDP connection. Admin staff has their own PCs with XP or higher. Users are allowed to specify their own resolution although they are limited to using IE as the web browser.
Other locations connects to our network over a MPLS connection
Based on that, what would you choose and why?
I am especially interested in hearing from developers who have experience with both ASP.Net and WPf.
Reasons to choose WPF:
Much faster and easier development than ASP.NET and jQuery
Much easier to implement quick incremental background loading of data
Much easier to implement client-side caching of commonly used data (important for remote offices)
More efficient data transfer from server (can use advanced WCF features unavailable to web browser)
Keyboard navigation better, since you can easily define shortcuts, etc, and not be limited by browser
Maintenance overhead much better using MVVM pattern
Softphone integration easy
Reasons to choose ASP.NET and jQuery:
None that I can see
In your scenario I would definitely choose WPF.
First of all, I would sit down and write the business requirements and specifications. It really doesn't matter what tech you use - proper planning will affect your project timeline more than technology choice. This is especially true for an in-house custom built app.
As far as development, I would take the requirements and lay out the backend functionality. I would actually implement the backend in WCF, regardless of the client technology - that way you could use best of both worlds if needed (for example for phone integration you could write a stand-alone WPF app). ASP.NET with jQuery can easily use WCF services (JSON or XML version) together with desktop client.
As far as development of the client forms, this highly depends on developers experience and your future plans. I am not going to go into advantages/disadvantages of developing web software here - there are a ton of articles in the last 10 years about cloud/web based software (for example salesforce). I would rather concentrate on deliverables - what is your team most comfortable with today and in the future. There's a huge difference between WPF and web development, from development standpoint, and it requires completely different experience.
Why not consider a hybrid solution - Silverlight
With Silverlight you get most of the goodness and statefullness of WPF (with almost exactly the same XAML and code), plus you get the deployment characteristics of ASP.NET
Many people consider Silverlight the next step after ASP.NET/AJAX, and it would definitely deliver all of the benefits of WPF relevant to your scenario.
WPF is the way to go, without a doubt. I agree with all that #Ray Burns has said.
Because:
You will get a richer, slicker, faster application.
It will be easier to build1.
Softphone/Scanner (i.e. hardware) integration is going to require browser plugins etc. and this can be a nightmare with a browser based application.
Keyboard navigation is still better with native applications.
IME Maintenance is easier with WPF applications.
Definitely use WCF to provide the backend via The Entity Framework, see The Entity Framework In Layered Architectures. You can do have a better integration with the backend in a native application because it can be called inline - no need for callbacks or ajax. I've built components for WPF that are linked via EF to the business logic to provide aware controls for simple stuff like validation. It's stunningly good to drop a customer name field onto a form and it just works.
To add additional components you need to build it with a proper well thought out plugin architecture. This is the same in both environments. I've got some thoughts on this I jotted down in my journal entitled Designing a plugin architecture for an application
When building a WPF application you will be writing in one language (e.g. C#) + markup (XAML). When building asp.net you endup with two languages + markup, as you always have to code some Javascript.
So, based on your requirements it has be to WPF / WCF (EF). A web based application will be a lot more work, more complexity, and not be as nice.
About 12 months ago I was fortunate enough to be given a free hand to choose the technology for a new application. I spent almost a month evaluating all of the options and came to the conclusion that it had to be C#, WPF, Entity Framework. After writing the application I can confirm that it was the right choice...
1. It will still be easier even if your programmers have to learn WPF first. WPF is much better thought out, great and lovely. very lovely. It just works right.
Hi
I think The question at issue is Windows-application or Web application(WPF for win-app VS asp for web-app), Which one is better for you and your project?. In this case your platform is network and your program must work on the net. so for this usage Web-app is better but there are a lot points existing which can make decisions hard. Network platform has great challenge.(according to my personal experience)
Working with web-app by asp.net is nearly hard. you must try to handle many thing's for web-app(request time, session management, even poor UI in comparison to WPF, j-query, etc ). Remember this is not as easy as simple web site.
But win-app is good for network with this condition: "local network"(mpls is almost the same). Absolutely developing win-app is easier than web-app ("At least number of users expert in net-program developing"). for this case WPF has many good things(UI , command, etc) also has many challenging point(like multi-threading and lack of expert developer in this field ) . I'm rather with wpf than asp but decisions is yours
And chalk point to good thing Silverlight but if you want to use this you must look at prism framework : http://compositewpf.codeplex.com/
I have recently developed a project separately with asp and silverlight(prism framework). developing silver-light version is too hard and takes more time than asp.net version but at the end SL-ver have great look nothing else!
Burns pointed to good issues about wpf. also consider Artemiy's post. your environment conditions is same for both of them. WPF/ASP can work with scanner and soft-phone cuz the base of both is on C# and .net library
Finally what ever your decisions is you must hire advance developer at least develop one business-app for the network platform.
Is your app a desktop app or web app.
If Desktop wpf is best.
If web based asp.net is best.
Don't front load your development with your get it up quick scenario. That never works well and results in a sloppy deployment. Take your time, cover all the steps (Business Requirements, System Design, Program Design, Code, TEST and TEST some more, Deployment)
Some points to be made for ASP.NET:
The pool of ASP.NET developers is much larger then the pool of WPF developers.
Which means you can probably find qualified ASP.NET developers easier.
ASP.NET is probably more future proof, chances of WPF getting large changes and being hard to port to later versions is probably larger.
Also keep in mind that the focus of MS seems to be on Silverlight so there might be a consolidation down the road which makes WPF obsolete.
More mature eco system of ASP.NET makes for more out of the box solutions to use to solve problems.
With multiple locations you might be able to skip a few layers and go directly to a website?
Related
I am after recommendations for a framework (or project template) for rapid application development using C# on the back-end. It must support the following:
User login/authentication
SPA
Responsive client
Easy to understand client and server (not a steep learning curve like AngularJS)
Clean/uncluttered project structure (both client and server). Some OOTB ASP.Net project templates are very cluttered (eg the the VS2012/2013 SPA MVC/Knockout/BackBone template) - maybe I could be convinced, but just looking at a new project it puts me off instantly.
Easy DB access.
Flexibility on the client (for custom functionality eg adding maps and other UI libraries like D3) - don't want a client framework that you have to wrangle to paint outside the lines.
Would appreciate any/all suggestions/opinions.
Thanks
Tim
Like anything in software, there are so many ways to do this. You are essentially asking for a complete system architecture. You could try to be more specific, but your question is going gather opinionated answers and this will probably end up getting closed.
But I'm bored and will throwin a couple of pennies before that happens:
C# most likely means you'll be going .NET on IIS (though maybe its docker on linux?? refer back to my first line above)
User login/authentication
If its IIS, you could be running Windows Auth, or if in an enterprise, Kerberos or Federation. Or if its going against social sites, maybe OAuth? This one depends on what authentication your users need and is really separate of the other areas below.
SPA / Responsive client / Easy to understand...
You listed some very popular frameworks (Angular/Knockout) used in modern SPAs. You may not like them but these are becoming industry standards. Responsive web is pretty much bootstrap or foundation. Though, angular material seems to be gaining popularity too.
Easy DB access.
Whats your definition of easy? Looking for an ORM? If so, Entity Framework is popular in .net apps. Or if you are more of an SQL person, maybe LINQ is easier. Many options here too.
Flexibility on the client ...
Though you may not like some of them, using popular frameworks means you get a lot of developer support behind it - and a lot more answers here on SO if you have problems. One man's sunset is another man's sunrise. What you consider difficult might be viewed as easy by another. Hard to say whats most flexible but going popular means you got more help.
We have a large code base in MFC and VB. A few applications are in .NET. All these applications interoperate with each other on the user's machine and also connect with Unix servers via sockets.
Recently we have started discussing a re-write of our applications and possibility of moving a lot of these desktop applications to web (they would run in intranet). A straight forward way is rewritting them in one of the .NET technologies. But a suggestion about using Google Web tookit has popped up and the argument is that it would help creating applications that would run in a browser on both desktop and mobile devices.
One of the key problem that I see is that GWT is a large abstraction over Javascript. This will require the team to learn GWT, Javascript, IDEs etc as their experience has been primarily Microsoft technologies and not Java. It would be easier for them to learn .NET technologies instead of GWT.
I do not have a depth of GWT and its drawback pittfalls and do not know about a parallel Microsoft Technology that I should investigate.
So I would appreciate if people here can share their views or experiences using GWT or equivalent Microsoft technology.
Questions like this are subjective, so you wont get one straight answer. Are you rewriting the unix/socket backend as well? Or do you intend to put a web service wrapper in front of the sockets because without this I cant see a web / internet solution working.
For my money if you are a .net/microsoft house then a MS technology is the way to go. MS is currently backing jQuery which is a client side javascript framework, but there are others like extjs. If you stick with MS and a server side solution then ASP.NET MVC is currently gaining a lot of traction. MVC and jQuery work well together imho.
If you set up a REST based web service layer for your backend it means you can even get away with flat html front ends powered by any javascript framework without needed a server side web rendering technology at all. For REST you can look at .NET WCF if you stick with MS tech.
Given that you've been working with MFC and VB, .NET is going to be a new world to you as well. At least with Microsoft you'll have strong development tools and learning resources that you'll need. Not so sure that will be the case with GWT.
But also, if one of your developers wins the lottery and leaves the company, you'll have fewer problems finding another MS developer to replace him.
Given you guys are a Microsoft development shop, I'd stick with the Microsoft stack (unless your developers really want to learn something new - in my experience that's rarely the case).
Anyway, I thought I'd bring up that Microsoft had an "embraced and extended" version of GWT called Volta that they release 2-3 years ago. The idea is that it takes C# as its source file, and compiles that to Javascript.
I suspect the project is dead (I can't seem to find a whole lot of information about it), but you may want to verify that. I brought it up because you guys seemed like a Microsoft shop who's interested in GWT.
Based on your provided information I think it is better to use fromMicrosoft Technologies instead of Google Technologies.
This will reduce Cost (include Time to learn and also the budget and etc)
on the other hand, Silverlight goes on the windows phone mobiles with (WinMo7) so your application will run as the same in Cellphones too. So my sugesstion is to use Microsofts Technologies.
Let's say you have an intranet development team where it is in your best interest for each developer to be happy with their work - one person leaving will negatively impact the others. Some developers wish to embrace the Web (i.e. ASP.NET MVC). Others wish to work in a stateful environment where Web is merely the medium for delivery (i.e. SilverLight).
I don't want to argue the merits of either (I have my opinion). Rather I want suggestions for legitimate arrangements such that we can have our cake and eat it too. Is it possible for some members of the team to work with SilverLight while others work with ASP.NET MVC without ending up in pandemonium?
I'm thinking that MAYBE we could have ASP.NET MVC for the majority of our applications and then have the SilverLight people develop components that can be used in the UI? But according to this question that didn't turn out so well.
I'm just looking for a scenario that would allow the team to effectively use SilverLight and/or ASP.NET MVC in their work (not necessarily in the same app) without imploding.
Any links to articles with information pertaining to how well a given scenario works would also be appreciated.
Unfortunately you can't make all of the people happy all of the time.
...which is what it sounds to me like you're trying to do. You have to pick the best technology that suits your application and roll with it. Trying to mix and match technologies just to keep people that want to use one or the other is going to fail.
If your application has legitimate uses for both ASP.NET MVC and Silverlight, then by all means give the Silverlight development to the people that want to do it and let the ASP.NET MVC people handle the rest. Just don't introduce Silverlight to give the developers who want it something to make them happy.
We have a mixture of Silverlight and regular ASP.Net on my team. It's a pretty big application but about 50% of it is Silverlight apps. People who want to work on Silverlight do that and the rest of us do web development. There is one big .sln that has all the projects and a bunch of smaller ones that have projects related to specific functional areas in the app. We have a build process that compiles everything and puts it all together.
Which parts of the application are SL and which parts of the app are HTML depends on a combination of business requirements and end user capabilities -- NOT whether the dev just want's to do SL or HTML.
If you want both do co-exist in your environment, you will need a process and it should revolve around business requirements and not just what fun toy a dev wants to use.
I think you should re-examine your assumptions. In particular:
One need not develop with MVC to embrace the Web; Web forms + Ajax works great in many scenarios.
Silverlight apps don't need to be stateful. In fact, Silverlight apps don't even require a UI.
IMO, the best approach is to start with a detailed architectural design for your site, and to look carefully at where each technology might be best applied. With an architecture in-hand, you can begin design and agile development, and let developers choose which areas they would prefer to be involved with, subject to overall project management constraints. But the key is to have the architecture drive the technology choices, not the other way around.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
I'm starting a new web project and I am considering two presentation frameworks. I am thinking either about ASP.NET MVC or Silverlight. I would tend toward Silverlight since I'm quite experienced .NET developer while I have just a basic knowledge of ASP.NET controls.
It is mainly going to be an iternal
product so browsers are not an issue.
You still have not written a proper description about the nature of your application. It is difficult to assess which technology is a good fit without first knowing well enough the domain the application is being applied to, and the problems it is designed to solve.
In general, Microsoft is positioning these array of presentation technologies on the "Reach vs Rich" continuum. You have "plain old" HTML and Javascript on one end, acceptable by the most number of client machines out there, and the ultimate full-blown WPF on the other side where limited number of machines can handle. You did mention this to be an internal app, so WPF via XBAP or ClickOnce are also possible.
So the scale would align this way: (reach) ASP.NET, AJAX, Silverlight, WPF (rich).
So the question is just how rich you want/need it to be for the users until it hurts the deployment base? Frankly if all you fetch are forms and tabular data and statistics then regular ASP.NET web forms are just fine. If you want on-the-fly resizable graphs and client-side interactive with back-end WCF web services Silverlight can do that. If you want even more powerful graphical rendering than WPF via the remote deployment options is your bet.
Silverlight 3 with RIA seems to be very powerful. I hadn't programmed for 6 years after working on VB6. I about a months time, here I am developing a web applicaton that uses SL3, WCF and entity framework and I feel very comfortable.
The silverlight forum and stackoverflow ofcourse are very active and for some of the problems that i've had had, I have been able to get a solution easily.
The one thing I'm not sure of yet is performance.
Both personally and professionally, I write C# daily for Windows forms apps and Windows services. Even after years of this, I find it FAR faster to whip out a web app with PHP or Python than to do it with .NET. Maybe things have changed with Silverlight, but to me the learning curve on ASP.NET is ridiculous compared to the payback.
Edit: The above was written a year or so before I tried ASP.NET MVC. I find ASP.NET MVC wonderfully intuitive and clean.
Don't forget Silverlight is going to require a plug-in to use, and to my knowledge it has not been "natively" added to IE, let alone the rest of the browsers. So there could be tons of maintenance/support issues with that alone. PDF files are considered "ubiquitous" by now, but you still run into a user or two that doesn't have Adobe Reader on their computer and it often occurs at a bad time and then you're scurrying around to get an installer.
At a fundamental level, this is what has kept me from doing Silverlight for my web apps. I think the technology behind it is good, but considering nowadays you could get equal visibility/functionality with a nice Webforms/MVC/AJAX/jQuery combination (mix and match to your liking), I'd say stick with ASP.NET.
IMO you may be better off with ASP.Net. While you would have a slight learning curve, you'd be developing on a proven, reliable, scalable model rather than something thats in beta and will likely change before RTM.
Also, with AJAX these days its possible to get a pretty slick user experience out of ASP.Net.
I would recommend ASP.NET, no additional download is needed.
I used Silverlight but a lot of companies are not allowing users to install anything also home users are not happy to install browser plugins, Silverlight is not so known as Flash player.
For beginners and advanced programmers you can find video tutorials at.
http://www.asp.net/mvc
It's hard to recommend one over the other without knowing what your application is. Whatever you do decide, make sure you keep your target audience in mind; not everyone is going to have Silverlight installed on their computers.
Personally, unless I was designing an incredibly interactive and beautiful web app, I would go with ASP.NET (with or without the MVC framework) if only for the fact that there is a ton of reference material for it while Silverlight is still relatively new territory.
It is mainly going to be an iternal product so browsers are not an issue. It's more about the price of development. Is it easier to learn Silverlight model or ASP.NET model? I expect that Silverlight is based on WebServices and so it might clearly divide my application code into a business logic (service) and presentation (silverlight application).
Given your background in .NET but limited Asp .net experience... I assume you are more of a service/client guy. Which will mean your javascript is probably just as limited... If this is the case, I'd go with Silverlight. It will ease you into WPF, which you may be likely to use in the future.
But more importantly working with Silverlight 2.0 feels more like building a sandboxed desktop application. More than a web application. You will be more at home with Silverlight if your prior experience is with client apps.
If you want to break into building web sites/applications go with ASP .NET MVC.
Either way knowledge of the typical ASP .NET controls will not go far, since they are for WebForms.
I would say - unless you need flash-like animation and interaction capabilities - go for ASP.NET. It's simpler to program against and doesn't require extra downloads for the users.
I think Silverlight is only required when you want to create applications like Flash. These applications are combined into a single executable which are downloaded once on the client machine. They can communicate with the server if they need any data or any functionality which resides on the server. The end user needs to install the Silverlight environment add-on to help run these applications.
Whereas if you create an asp.net application, its code resides and executes on the server itself and hence a simple internet browser can execute it. But the downside is that for user-interactive applications, there need to be separate calls made between the server and client machine when the code requires.
We need to build an administration portal website to support our client/server application. Since we're a .Net shop the obvious traditional way would be to do that in ASP.Net. But Silverlight 2 will be coming out of beta a good while before our release date. Should we consider building the whole website in silverlight instead, with a supporting WCF backend?
The main function of the portal will be: users, groups and permissions configuration; user profile settings configuration; file upload and download for files needed to support the application.
I think the main reason for taking this approach would be that we have good experience with WPF and WCF, but little experience in ASP.Net. Either way we would have to learn ASP.Net or Silverlight, and learning Silverlight seems a more natural extension of our current skills.
Are there any big no-nos from the experience of StackOverflowers? What are the big positives?
I would recommend against building a pure Silverlight site.
Silverlight suffers from the same issues as Flash does: Unintuitive Bookmarking, issues with printing, accessibility issues, not working back buttons and so on.
Also, you would require your users to have Silverlight installed or at least to have the ability to install it.
In controlled environements (eg. in large companies or health care) or on mobile devices, this might not be the case.
I would definitely go for a full Silverlight application, specially if you have good experience from WPF. You will be able to reuse your knowledge from WPF, and should be able to pick up Silverlight fairly quickly. I've been working with Silverlight since Beta 1, and the current Beta 2 is of solid quality. I guess it's safe to assume that a RTW version is just around the corner.
Pilf has some valid point, specially around printing. For that I would probably use SQL Reporting Services, or some other reporting framework, on the server side, and then pop up a new window with printable reports. For linking and bookmarking the issues are no different than any other AJAX application. I did a blog post today about how to provide deep linking and back-forward navigation in Silverlight.
Silverlight also has all the hooks needed for great accessibility support, as the UI Automation API from WPF is brought into Silverlight. I don't know if the screen reader vendors have caught up yet. The styling/template support in Silverlight makes it easy to provide high-contrast skins for visual impaired users if that is a concern.
Depends on your goals. If administration portal is part of application and will only be used from computers where your application is installed, there are plenty of advantages of going fully Silverlight - or even WPF.
But if you can see a scenario where it will be used either from random PC or by random person, fully functional HTML/Javascript version is absolutely necessary.
Some reasons are:
Most people don't have silverlight and you'll earn a good load of swearing if they have to download and install it. Some people who have it installed keep it disabled (together with flash and sometimes even images) to avoid distractions and speed up browsing.
When HTML site fails, user gets error page and reloads. When silverlight fails, it can hang or crash.
HTML is what is expected - both by users and web browsers: back and refresh buttons work as they should, hyperlinks and forms work as expected.
Slow internet is still very common, both in remote areas and mobile devices.
I agree with what everyone had said so far and I think this Flow Chart, which is aimed at Flash, also applies to Silverlight.
Source of Image
It sounds like your problem is that you need a rich-client admin application. Why not use click-once?
On the topic of remote andministrators, another poster stated that was an argument in favor of HTML if the admins were on a slow connection. I would argue that depending on the type of information, it may be more efficient to use Silverlight. If you have an ASP.NET datagrid populated with server side data binding, you can be downloading a ton of markup and viewstate data. Even if you're using an alrternative to DataGrid that's lighter on the ViewState, you will still have a lot of HTML to download.
In Silverlight, once you get the XAP down, which is probably going to be smaller than the corresponding HTML, the XAP is cached and so you shouldn't have that cost every time, and you'll just be retrieving the data itself.
For another example, let's say you have a bunch of dropdown lists on one of your forms which all have the same values in the list. In Silverlight, you can get these values once and bind them to all of the dorpdowns, in HTML you will have to repeat them each time.
This will get better with client side data binding in ASP.NET, which follows a very similar model to Silverlight and WPF for data binding.
Overall, I would also think that you would need to write less code for the Silverlight implementation which can increase productivity and reduce maintenace costs.
ASP all the way. You should only use silverlight/flash etc when text can't do what you want it to do - e.g. display video.
Using a plugin for your website makes it slow, and requires the user to have the plugin installed. Silverlight for instance rules out all Linux user. Also, since Silverlight is pretty new, there is no telling how committed Microsoft will be to keep the platform alive if it doesn't pick up soon.
I'd stick to plain old HTML with server side scripting.
Also, for public websites: Flash and Silverlight can't be indexed by any search engine, so good luck with writing tons of metadata if you want any visitors at all.
Silverlight is a good choice for an internal-facing portal, just as it would be for a public-facing portal if you've already evaluated your project and have decided to go forward with a web portal. You are free to integrate Silverlight components within an existing ASP.NET application (i.e. the "islands of richness") approach, but if you have the ability to build a new project from scratch, don't discount a completely Silverlight solution as a valid choice where you would have went with a traditional ASP.NET portal. Silverlight is RTW now, so if this decision is still on the table, you know you won't have to deal with breaking changes going forward.
There are some downsides with developing a site completely in Flash / Silverlight, but if those downsides won't matter to you or won't have an impact then there is nothing stopping you. Choose whatever tool you think meets your needs more fully. I wouldn't be put off creating a site purely in Silverlight based on the downsides, because it brings a lot more positives to the user experience.
The previous comments have dealt with most of the downsides of using Silverlight for a site like this and I agree. If you're determined to have rich-client style development and your audience is small (for admins only) then I'd probably recommend WPF over Silverlight as it currently provides a richer set of tools and controls.
If you stick with ASP.NET have you looked at Dynamic Data - it's ideal for building backend management sites with little effort.
I've seen "Silverlight only" websites at Microsoft and they are pretty impressive. But again, the demos were there to exploit the full potential of what Silverlight can do. The moment you need something different you may be out of luck. I don't see Silverlight like Flash except in the way they are installed/seen. But the Flash/ActionScript backend is really bad compared to what Visual Studio can offer with .NET
Ask yourself why would you like to use Silverlight? Fancy effects or programming model?