Before I continue with the rest of this post, I first need to make a disclaimer. I'm in no way an expert on all things Microsoft has to offer in the web realm and have yet to complete a full-fledged ASP.NET MVC & JQuery project.
However, I see myself as someone who quickly grasps the potential and limitations of emerging technologies and tools, not only by actively reading blog posts and Twitter discussions, but also by talking a lot with community experts and experimenting myself. Since the inception of the .NET Framework, I've been designing and building enterprise-class business applications in Windows Forms, Compact Framework, ASP.NET WebForms with AJAX, WPF and Silverlight. Although I love things like NHibernate, Silverlight and the practices of Scrum and XP, I don't believe in silver bullets and will always try to choose the right tools for the right job.
So, now that we got that clear and before I share my conclusion, lets see some of the advantages and disadvantages of using the different web technologies for building greenfield business applications.
ASP.NET AJAX Web Forms
Advantages
- Easy to learn the basics
- User control model allows for simple reuse
- Abstracts the complexities of web applications behind an object-oriented API
- Feels quite natural for Windows Forms developers
- Loads of experienced developers available
Disadvantages
- Not designed for rich and interactive user interfaces
- Has many pitfalls that most developers don't think about properly (e.g. ViewState, SessionState)
- ASP.NET Page Life Cycle will hit you in the face whenever you try to do something dynamic
- Does not force you to use JavaScript and JQuery for interaction and promotes misuse of AJAX UpdatePanels which can seriously degrade performance
- Not designed for testing, even with patterns like Model-View-Presenter or Presentation Model
- Compile and startup time significantly increases when the application grows in size and complexity. This seriously hampers productivity.
- User interface design is limited to what you can do with CSS and pictures
- I'm not sure how long Microsoft is going to continue investing in WebForms
ASP.NET MVC with JQuery
Advantages
- Designed for testability
- Forces you to use JavaScript making it easier to build a responsive, very interactive UI, without unnecessary postbacks.
- No page-life cycle to worry about
- Quick startup time, regardless of the size of the application
- Microsoft is investing heavily in it
Disadvantages
- Requires a considerable amount of time to get up to speed.
- Completely different mindset compared to ASP.NET WebForms. Expect for the HTML/CSS part, you to have to learn everything from scratch.
- Relies heavily on JavaScript and JQuery for anything that requires more than static content. Since JavaScript is a dynamic language, expect long painfull sessions in the Visual Studio debugger.
- No automatic state management (although the data binding mechanism is quite nice)
- Limited Intellisense in JavaScript (but that will change in the future)
- Not possible to reuse parts of a page as an encapsulated control with logic
- User interface design is limited to what you can do with CSS and pictures
Silverlight
Advantages
- Great for internal applications or Internet-facing apps that have a controlled user-base
- Unlimited possibilities for user interface design and providing a rich experience
- Only requires knowledge on XAML and C#
- Allows to treat an application as a compositation of object-oriented controls, with all benefits
- No page life-cycle issues
- Styling the application in XAML is much easier than using CSS, especially with Expression Blend
- Separation between XAML and C# code allows for clear separation of concerns
- Offloads the load on application servers by moving some of the load to the browser
Disadvantages
- Requires users to install a browser plug-in under administrative priveleges
- Deployment within an enterprise requires some planning
- Only runs on Windows and MacOS
- Asynchronous programming might take some time to get used to
- The Visual Studio design-time experience sucks, but Expression Blend makes up for that big-time.
- Debugging Silverlight control bindings is non-trivial, but will be improved in Silverlight 5
- Multiple overlapping, but conflicting data access frameworks
- Building custom controls requires you to learning about peculiar concepts like Attached and Dependency Properties
- You have to account for the security risks of the availability of all client assemblies in the browser.
But, that's not all, since a while we have two dedicated tools that, though mistreated as being for hobbyist and amateurs, provide serious opportunities.
Microsoft WebMatrix
Advantages
- Rapid Application Development
- Uses the MVC / Razor engine, IIS Express and SQL Server Compact
- Allows you to start small and painlessly move to full Visual Studio & SQL Server
- Built-in SEO support
- Many open source web site templates that can be used as a quick-start
- Built-in Web App Gallery where you can download all kinds of add-ins such as CMS projects, blog engines, etc.
Disadvantages
- Fixed architecture
- Is designed for external hosting, and deployment with a local IIS is non-trivial
Visual Studio LightSwitch
Advantages
- Great for CRUD applications
- Very extensible scaffolding engine (custom XAML controls, custom data types, etc)
- Build-in and customizable templates for various types of data entry forms
- Design can be fully customized
- Relies on WCF RIA Services, allowing you to connect a LightSwitch app to different data sources or existing service-oriented architectures
- Uses Entity Framework and SQL Server out-of-the-box. Support for other vendors is possible using commercial EF providers.
Disadvantages
- Fixed architecture
- Not very scalable
- Engine-based, so you don't get access to XAML views
- There's no migration to Visual Studio
- Not many people know the exact limitations of LightSwitch
Conclusion
As I said before, silver bullets don't exist - at least, not within our profession - and you always have to make a trade-off when choosing one technology over the other. But even though there are usually many more factors involved than those mentioned here, the table below list the first choice.
| Users / Nature | Static Content | Data Entry / CRUD | Rich Experience |
| Intranet | WebMatrix / ASP.NET MVC | LightSwitch | Silverlight |
| Controlled group of internet users | WebMatrix / ASP.NET MVC | LightSwitch | Silverlight |
| Internet | WebMatrix / ASP.NET MVC | WebMatrix / ASP.NET MVC | ASP.NET MVC |
Regarding Microsoft WebMatrix, I have not found much that refer to any serious drawbacks. And indeed, it does seem pretty impressive. If you don't think WebMatrix is for you, then I would suggest replacing it with ASP.NET MVC. It's scaffolding features are not bad at all.
I would never advice any company to invest in WebForms anymore. The only scenario where I might consider it, is when the team has no experience in ASP.NET MVC or Silverlight and the project is too short to deal with the learning curve. And don't think the switch from ASP.NET WebForms to MVC is trivial, because it's not. And I can only talk for myself, but I wouldn't be surprised if learning Silverlight takes less time than MVC and JQuery. It sure will give you a higher productivity.
I'd really like to hear about your own experiences. Do you agree or disagree? Have you run into the limitations of WebMatrix or LightSwitch yet?
PS. You can also reach me through my Twitter account @ddoomen.
8 comments:
I can only talk for myself, (I’m not an expert in Silverlight by any stretch of imagination), but I think that Silverlight/WPF has a huge learning curve and is probably the most difficult technology in this list to master.
It’s such a paradigm shift from everything else currently being done.
Even simple concepts suchs as:
1. Markup extensions, (used in binding for example or… x:NullExtension)
2. Attached Properties
3. Dependency Properties
Require the developer to have a deep sense of what’s happening under the hood.
Even the way the API was designed, (so that XAML could take advantage of it).
I’m not even considering all the intricacies that writing Silverlight/WPF require, understanding concepts like, ActualHeight, RenderSize, DesiredSize, the way different control honor this concepts.
I don’t actually have anything against this technology but from all of the above… IMO this is the one that requires the most specialized developers.
Compared to the latter, MVC is a child’s play. ;-)
In the other hand MVC, having all of its “peculiarities” it’s very “web like”.
And like it or not we are moving more and more into the web.
The sooner we embrace and acquire skills in the web “realm” the better.
My Best Regards, Ricardo
Hi Ricardo,
Thanks for your feedback.
Obviously, this post is highly opinionated, but after having completed a big Silverlight project in the 2nd half of Silverlight, I can not be anything but thrilled. I don agree that creating your own Attached or Dependency Properties requires a bit of thinking, but in that project I never had to. The controls provided by the Silverlight Control Toolkit are more than enough.
Maybe if you're a die-hard control developer you might have to deal with that (and those peculaliar properties you mention), but compared to JavaScript it still sounds much easier. I would never call MVC child's play. Yes, the Razor stuff and the concepts of controllers and models are quite nice, but as soon as you need dynamic behavior, you need to dive deep into JavaScript. I love JQuery, and call me lazy, but working without proper IntelliSense and a static compiler sounds like my first C++ endaveours 20 years ago.
However, I wonder how I would feel about this post if I would have been a very experienced JavaScript developer.
Hi Dennis,
I really like the article, I have one comment on Silverlight. You have "Offloads the load on application servers by moving some of the load to the browser" as an advantage, and I agree, but a disadvantage that is tied directly to this is in security of your business logic. With SL, all of the libraries needed for display/processing are downloaded directly to the client in a XAP file, which is just a renamed ZIP file with your DLL's, resources and a manifest. The user can then open this file and have access to all of your business logic (if you're not using obfuscation) by opening them with a tool like Reflector. So you have to be extremely mindful of where you place that logic: 1) in the actual SL app, or 2) in the web services you use for server call back.
I make a point of doing this with every SL app I run across, just out of curiosity, and I am appalled at the lack of this mindset. If you want to give away your hard work, just write it in SL.
IMHO, Silverlight is WAY to easy to compromise to be considered for critical applications. I think it is best reserved for trivial, internal LOB apps. I think you are much better suited jumping on the HTML5/CSS3/JScript wagon to create compelling UI in a serious web app.
Regards,
Karl
You are right about the potential security risk, but most of the time I don't care if somebody would analyze the client-side assembly. They can't replace them, because signing of the assemlbies and the XAP should prevent that. Additionally, I never trust what the client app is doing. If you look at my reference architecture on www.silverlightcookbook.com you'll find that every action on my domain model is explicitly validated.
Very good, and I love your advice about my favorite, Silverlight.
Just keep Silverlight off of the internet, except for administrative functions, and you're fine.
Also, it's next to impossible to get Silverlight into the government because they aren't allowed to install ANYTHING!
We've had to move to Flash or plain html for that reason alone on some projects.
LightSwitch is actually more scalable than most technologies. It hits the server LESS because it doesn't have to refresh the entire screen.
LightSwitch IS ALREADY in Visual Studio. Switch to file mode and you will see that it is just normal code that you can change.
LightSwitch is just EF/WCF RIA/Silverlight. These are old technologies.
Well done. One disadvantage I would add with LightSwitch is it's relative immaturity, particularly with performance and extensibility.
LightSwitch beats them all, especially for me coming from the angle of a designer.
Post a Comment