views:

92

answers:

3

First, I know that Silverlight needs to be embedded in a website, usually an asp page. I understand I need a delivery boy. My question is this; What types of apps/projects are so filled with technological hurdles as to make them ridiculous to do in Silverlight versus ASP.net?

I know that with perseverance and flexibility I can probably make EVERY app in Silverlight, in some version or another, but which ones would be blatantly simple in, say ASP.net(or even WPF) but quite complicated in Silverlight?

Basically what I am asking is if there is any reason I shouldn't consider Silverlight my first stop for every problem, obvious exceptions not with standing(a service or console).

For me specifically, at this point, I am only building in house apps.

+2  A: 

What types of apps/projects are so filled with technological hurdles as to make them ridiculous to do in Silverlight versus ASP.net?

Apples and oranges. Silverlight is client side (executed in the browser), ASP.NET is server side. Code executed on the client side will seem faster to the user, and may have access to local resources. Server side code will have closer access to service resources shared amongst all users such as databases and much greater computing power.

Any modern complex web application will work with a mix of client side and server side programming, be it developed with Silverlight/ASP.NET, JavaScript/PHP, Flash/Java, or any combinations you like.

Jim Blackler
Is there something that you can think of that would HAVE to be run Server-Side? Maybe some type of multi-user app that would need to run at the server?
Refracted Paladin
business rules need to be validated on server-side.
Codism
+3  A: 

Silverlight is, for lack of a better explanation, a WPF app delivered over the web. Running in a semi-protected sandbox (I know I'll get flamed for that one :)

Generally, if it's something you'd want to do with a WPF application, you can probably do it in Silverlight. No assertions as to the pain level there...

Dave Swersky
+1  A: 

[Pro silverlight argument]

To use the Asp.Net stack, data binding etc...when building an app in Silverlight, there's no real reason for it beyond a mere shell which is a waste since Silverlight can be hosted in Html. That doesn't negate it from use, it's a really good platform for developing web applications. I could ask the same question you did about PHP. Why bother when there's Silverlight or Asp.Net? Isn't PHP the Russian version of ASP? Still, if I picked up a ball peen hammer to drive every nail in a roof I could do it. I'd rather have a roofing hammer though.

[Personal Story Diversion]

I had a salesman at a motorcycle dealership tell me I couldn't ride a bike to the limits of the machine. Nice comment for a guy trying to sell me a bike. What he meant was there are ways of doing things with it beyond its intended use and if you know the tricks (ie: are a good rider) then you can go further with it. He assumed I had no knowledge of how to ride a motorcycle really well. Good assumption, I suck at it.

The problem I have is that there are bikes designed for different purposes and "riding to its limit" is more work than riding one better suited to the task. I bet if I did it just right, if I was that good at maneuvering belching chunks of steel, I could ride a Harley up a sand dune. But why waste my time when I can get a motocross bike with a paddle tire to do it? who cares whether I can ride the Harley to its limit?

[Anti silverlight argument]

"Silverlight is client side" <-- That's what Asp.Net uses JavaScript for, it's called "AJAX". Maybe you've heard of it? It works, and there are plenty of libraries to make really cool client side stuff in Asp.Net/Html.

PLUS Side:

Silverlight has webcam/mic support. Silverlight renders vector graphics so they scale without getting pixelated. Which is good if porn ever goes vector cause that shit's gonna take off! It handles animation so you can make things move around in c#/xaml. Silverlight uses XAML so it's all "declarative". Expression Blend has a cool styled interface so you can feel like a designer sipping your starbucks in a fancy indie coffee shop while trying to figure out how to move a border 5 pixels left without fucking up the stack panel or nesting yet another frigging element in an already complicated markup file.

MINUS Side:

Silverlight handles animation so you can make things move around in c#/xaml. Has anyone EVER done ANYTHING in GDI? Silverlight is an improvement. Okay...have you EVER done ANY animation with a software package that was meant to do animation (not programming). No? I didn't think so. That's why you moron developers bought the "Expression Blend is SOOO cool" shtick hook line and sinker. At best it is a poorly implemented animation experience. Very poor. I could go on for hours about how bad it sucks to create animations in Expression Blend/Silverlight/C#/Xaml...you would never have to know so much in a real animation package to do basic stuff, LOB app stuff. Not in Blend though. OH NO!!! You have to feed the slop to the pigs then turn around and fuck the dog in the ass before you can call it a day in Blend...

XAML is a complete mess. Dump all you food in the sink and then eat it...that's XAML. Hey! I've got an idea! Let's make EVERYTHING declarative! That way it's all in one place, but you have to know the tricks to get it to do what you want. Gee...sounds familiar! Maybe if I stick a static resource up my ass I can ride XAML to its limits...

In Asp.Net you HAD to separate client side and server side. It became common to separate style vs structure and even further semantic definitions of data. All this adds up to keeping your code in categorized places. Separate code was placed in different file extensions, different folders, even the syntax was different sometimes, which made the learning curve steep but helped mentally differentiate structures. When something needs changed or is broke, I know where to fix it. I know a style problem is in the damn CSS file not inline or in a static resource later referred to in a bazillion different places. With XAML all that shit gets mashed together in a Cartman-TrapperKeeper cyborg mess of undecipherable unmaintainable code. You don't get a choice...that's how ITS DONE! Oh, but its the latest things my precious, and its (buzzword!!! DING DING DING) "declarative".

Best practice in Asp.Net beats the pants off of what's being churned out in MVVM, MVP, MVVPLXKJY MVFUCKYOU. All the Silverlight patterns do is address getting data from your BO to the UI so you can test it separately. Hooray! Not. Have we all had to debug unit test code enough yet? Have we all beat our heads against a wall long enough to finally realize that if we documented the product well enough the testing could happen in frigging QA and not in development? I guess if you're not there yet go pick up the latest build of CSLA.Net and have at it. You know the one...that was released with all the changes before the book was scheduled to be written...

But I digress, so in summary:

Sometimes I wonder why anyone would make anything in Silverlight.

Joe