Change, or lack thereof is often an indication of how successful your technology stack is. If you are constantly swapping out core technologies then chances are you'll need to rethink your approach. If, on the other your stack remains fairly stable save a few new additions or tweaks then odds are you made the right choices at the start.
Last year, after careful consideration, I published an internal post that detailed my recommendations for the standard Microsoft Web Technology stack. Looking back on this I feel happy enough that my choices have proven themselves. But time goes on and technologies change so perhaps it's time for another look at the stack. Perhaps give it a bit of a refresh after all there has been a number of great developments in the .NET world. Do I need to refresh it? No not really – I could quite easily stick with my previous stack and truth be told the changes are fairly minimal – mostly version bumps. But I also want to look to the future, is there anything worth keeping an eye on (there is BTW), is there anything we should be avoiding (probably) etc.
Recap
Lets take a very quick run through of the recommended stack from last year.
The choice of client side technology really depended on the project requirements. Essentially I suggested most projects use jQuery and some jQueryUI stuff. If the UI required a higher degree of complexity/richness I recommended moving towards Sencha and Silverlight with Silverlight being the preferred option unless there was some project requirement that blocked the use of browser plugins. That's the general gist anyway – I can elaborate if anyone wants to hear more.
Refresh
So I'm recommending a few minor tweaks in an attempt to keep the stack up to date. After all .NET4 and Visual Studio 2010 have dropped since I last made my recommendations. Here goes
Not exactly a major overhaul and it shouldn't be. The stack is simple enough to handle many types of project and has been fairly successful since it was put forward. So I wanted to keep moving in that direction while bumping the versions up to the latest and greatest. So lets attempt to justify some of these changes.
MVC3
Look at the past posts on this blog and you will see I've spent a lot of time with MVC and, more recently MVC3 (Beta – RC – RTM). This blog doesn't cover half the MVC hacking I do on a daily basis. So MVC3 is just released and that might make some people nervous about using it as the primary basis for a web stack. I'm not - it's a quality release both in terms of features and stability. MVC3, for the most part, should be considered more as a refinement of MVC2 with a nice new shiny ViewEngine slapped on top. There really isn't much there that couldn't be done in MVC2 with a bit of custom code. But that's good it kind of hints that they were on the right path to begin with. But the enhancements it does offer make development a much cleaner experience. I already have a heap of blogs on the subject so if you want to know more about my views on MVC3 have a look at these,
- ASP.NET MVC3 Preview 1 First Look
- ASP.NET MVC3 JsonValueProvider
- Remote Validation in ASP.NET MVC3 RC1
- Unobtrusive JavaScript in MVC3
Razor View Engine
Razor is Microsoft's internally developed View Engine. It could be seen as a successor to the old clunky WebForms View Engine. I am not going to get into the syntax of Razor and how it is much cleaner than the WebForms syntax, no, if you want to digest all that have a look at one of my earlier posts – The Razor View Engine. In that post I also discuss the differences between Razor and Spark – my previous View Engine recommendation. So what has changed? Why am I recommending Razor over Spark now? Well as the previous post says it best with these lines,
[Spark is] a great engine but has suffered from a lack of tooling.
Spark, especially in comparison to Razor, has very limited tooling support in VS2010 – sure you have SparkSense but it's currently not a patch on Razor support (which is still in itself RC status) and I can't help but feel they'll always be playing catch-up with in house developed/supported stuff.
That view hasn't changed. Razor has a brighter future simply because of the in-house support being offered by Microsoft. Also there isn't an official release of Spark that works against MVC3 (still built against MVC2 dlls) – it is possible to grab a branch off Github though. It's a shame though and I wish all the best for Spark in the future – perhaps our paths will cross again?
The last thing I want to mention about view engine choice – or at least ask – is does it matter? The answer, of course, is not really. Your views should be very light and not have a lot of serverside logic built into them. So sticking with one view engine isn't going to ruin anyone's life.
jQuery/jQueryUI
OOTB integration with MVC is the most obvious reason for sticking with jQuery here. Also the fact that it has proven popular in many of our previous projects means it'll be sticking around for some time. The majority of our companies web projects can be catered for by jQuery (and sometimes including jQueryUI for some richer elements) as a decent base to write custom code. It may not be necessary in all projects of course and shouldn't be abused but that will depend on the project but I am confident enough to say 95% of our web based projects (not including mobile which I will touch on shortly) will feature jQuery and a few plugins to get the job done. All we need to do is bump the version up to the latest and we are flying.
Sencha (version 3)
OK I am still recommending Sencha/ExtJS for the small niche of projects that need a lot of richness but can't make the move to Silverlight. As before I am caveating this (or covering my ass). Sencha is a complex beast it has a steep learning curve and simply hacking away at it in a project is never going to be the best approach. It's best to avoid it but if jQueryUI doesn't cut it and Silverlight can't be deployed make sure the developers have plenty of time to get up to speed, have a capable mentor and code is checked for any bad smells early and often. Done right Sencha can produce brilliant results – but getting it right can be tricky.
Revolution
As always on the Web front things are changing fast. There new techs and new versions always round the corner. Some will be relevant, some just novelty. Obviously to stay ahead of the game we want to be keeping an eye on the technologies and applying some scientific rigour to determine if these should be brought into the recommended web stack. Here is a very quick rundown of my “ones to watch in 2011”.
Knockout.js & Backbone.js
Complex UI require a bit of structure or you'll end up with a lovely pile of spaghetti, the bad kind not the tasty good kind. jQuery and jQueryUI don't really offer anything in this area – sure you can get a collection of plugins to solve this but the best approach is a single unified lightweight framework that does one thing in a simple and consistent manner. Both Knockout and Backbone provide this but in via different routes. Knockout.js offers an MVVM framework similar to Silverlight/WPF data binding while Backbone offers a minimal MVC framework. It's hard to say at this point which is better – both have their pros and cons but that is for another post.
jQuery 1.5
Looks to be more betterness from the jQuery team (yes i know it's not a real word). So far there has been a re-architecting of the Ajax component so that you can bind callbacks at anytime (thanks the Promise pattern). This pattern is likely to make it into the public API as well so your own can make use of the promise construct. Another new feature appear to be subclassing of the jQuery object. Similar to the YUI3 sandboxing approach subclassing allows us to extend our own instance of the jQuery object without polluting the global instance. These changes combined with a number of bug fixes and performance improvements means jQuery vNext is looking good.
Ext JS 4
Ext JS 4 promises to be a big improvement over the current versions. Many things have been simplified and refactored which is good because often in version 3+ you get the feeling that things are perhaps OVER-engineered and needlessly complicated. Ext 2/3 also feels like it has massive functionality holes – there are nice widgets but the data package and application architecture always felt half baked. Not with 4 it seems. The data package is shaping up very nicely and they have their own MVC based classes built right into the framework. This could make large applications much easier to manage.
jQuery Mobile & Sencha Touch
Mobile is still an immature area among big companies. Many of them have native apps in various app stores etc. but they still don't really know how best to manage them. Good web based mobile frameworks appeal to them more as it gives them much greater control over the content – after all they own the hosting servers etc. jQuery Mobile and Sencha Touch have address different concerns – jQuery Mobile focuses on offering a consistent cross device experience while Sencha Touch aims to provide a native look and feel on WebKit based browsers (iPhone/iPad/Playbook/Android devices). I expect these frameworks to come into their own this year as they move out of immaturity and more people start experimenting.
Nuget
A nice little package manager for the .NET world offering public and locally hosted repositories. What makes it different to other is that a package could be anything – not just DLL. I like this and one of the reasons why I like it is that I can use it to distribute my JavaScript frameworks without have to maintain a big list of files needed for each one. I just click jQuery Mobile and it will pull in jQuery and the necessary CSS. I want Backbone and it will pull down Underscore for me as well. Same goes for any .NET libraries. Combine this with the ability to version packages etc. and it will make projects less of a “DLL Hell”.
WCF HTTP
The new WCF HTTP stuff is looking really really nice. One of the big issues with WCF is all the XML configuration and other blah that goes along with it. Newer WCF has given us .svc-less services generated from pure code, better configuration control and now some really nice improvements to the WCF communication channel. You can have custom Media Processors that let you control what is served to the client based on requested content types or actions (JSON, XML, Images – anything you can think of). The cleaning up of UriTemplates also mean that you can produce a very lightweight RESTful service or MVC like architecture very very easily.
Conclusion
Another long ramble that's taken me longer than expected to write up! Obviously there is plenty there to think about and hopefully it will generate some discussion. Hopefully I get a chance to flesh a lot of this out and offer more low level justification on my tech choices. 2011 is shaping up to be a great year in the tech world.