My passion for the past several years has been personal development. I have started to believe that in order to become a great software developer, you must become a great person first. That is my primary motivation to create a different kind of playground that will let me explore (and write about) stuff that may come a bit weird at first. So, here it goes:
Meet you there!
My previous post has gotten a lot of great feedback. Thanks everybody! I got some more important roadblocks that are worth noting. I am starting to think that having outlined the traditionally hard parts in ASP.NET development and later focusing on techniques for mastering them might turn helpful to many people. OK then, here we go.
Andy Stopford started out by bringing up ViewState. Being an easy source of many performance issues is almost a non-issue. To me, ViewState is a classic example of a leaky abstraction. It tries to make you think that your controls never get unloaded and HTTP requests do not actually exist. All you have to do is handle some events and configure controls in there. Yeah, right! That abstraction does not cover a lot of scenarios and pretty soon you find yourself thrown into the pit of lost state data, odd control behavior, and hard-to-find bugs. Like it or not, ViewState is here to stay, and going through a good book or a good article series is a must for all new developers. Going through the required reading and approaching dynamic control loading with some discipline typically deals with all ViewState-related problems.
Probably the hardest thing to do in ASP.NET is MVC. The page architecture does not help much when you want to separate your application concerns. Many people will just go with the flow and end up with that 5-KLOC code-behind class. I still think you can achieve a good level of separation of concerns and realize a nice MVC-based architecture for your app... again, with some discipline.
Mike Yeaney brought up AJAX and especially how ASP.NET has never been designed with AJAX-based apps in mind. You have to jump through hoops if you want to do better at authentication and error handling, so that they work better with XMLHttpRequest calls. Things are getting better with ASP.NET AJAX. At the very least you get support for web services, working with profile data and authentication. I strongly advise that anyone trying to create rich user interfaces starts with that.
Ruffus brought up the out-of-fashion rendering of many of the built-in controls that makes it hard to create accessible pages. Accessibility is a big requirement these days and is getting harder and harder to ignore. Nevertheless, having a truly-accessible site will require that you learn the tricks of the trade and carefully craft your rendered markup. Doing this with custom ASP.NET controls or with a home-grown framework looks like the same amount of work. Still, I'd lean towards the control-based solution.
I fully agree with Wally that you have to really know what you are doing when ditching WebForms. It is highly unlikely that you are smarter than the Microsoft guys that designed the framework and, chances are, you are better off if you stick with WebForms and invest some time into learning how to extend the framework and overcome its limitations.
Mike Yeaney's comment got me thinking here. He mentions that he and his team have ripped the entire WebForms part of ASP.NET (Pages, Controls, etc), and they are coding against custom HTTP handlers that allow them to serve their HTML, JS, CSS, etc. This is both a good and a bad thing. The good part is that you get tremendous freedom of what you can do with your web application. The best part is that your imagination and skill are the only limit. You can devise all sorts of clever ways to craft rich UI, optimize your page sizes, streamline the navigation, coax search engines into crawling your site better and faster. You have total control over your web application! The worst part, on the other hand, is that your imagination and skill are the limit. You are throwing away a good many features that have been tried and tested in many scenarios. You lose a feature-rich way to componentize your UI that allows you to easily reuse UI blocks all over your application. You have to train any new team members, so that they know how your solution works, because, chances are, they have experience with the WebForms model only.
So, what is the biggest ASP.NET WebForms roadblock that would make a person ditch the entire control-based composition model and go for creating his/her UI from scratch? I'd love to hear your reasons, but here are some of mine:
- The controls tree. It is a good way to split your page into blocks, but it requires a lot of extra effort to maintain. I can't remember how many times I've jumped through hoops to recreate the same control tree on postback, so that I am able to handle postback events originating from dynamically-created controls and of course load my ViewState.
I can go on, but right now I think those two are the biggest roadblocks to ASP.NET newcomers. They can surely be overcome (and that is what my blog will cover in the future), but that is not easy, especially for newbies. I still think there is value in learning about the framework and taking the time to overcome some of the problems, so that you can benefit from the features inside before you throw everything away. I am tremendously interested in experiences that have had people decide to do their own thing.
Hallo everyone! I am extremely pleased to be starting this blog (Joe, thanks for bringing me on board) and I would like to start with a short introduction.
I am a web developer with lots of love (and some hate) for ASP.NET and an AJAX fetish. I am a part of the Telerik team and me and my teammates are the people directly responsible for some of our most popular components in our RadControls suite for ASP.NET.
I have been permanently displeased with the state of the tools and platforms for doing web development and I am constantly looking for ways to sharpen the saw and get to the next level of "uberdeveloperness". This blog will focus on coping with the inherent difficulties in developing for the web -- that wonderful place with thousands of users and a minimum of three browser platforms to support. I strongly believe that using the right tools for the job and combining them with agile values and practices greatly increases our chances of succeeding at our current project. Or just about any project. Stay tuned for my experiences, tips, and suggestions!