Nothing really, if you use it for simple personal projects. Once you start building web applications that are a bit more complex, you start running into all kinds of problems.

What kind of problems am I talking about?

• Building web sites in multiple languages is a major pain in the butt. Once you have 2 or more languages to support, and a few hundred pages, maintaining the resource files is hell. Especially when you are using a version management system (as you should) and have people dedicated to translating stuff.
• The event model Microsoft magically weaved in ASP.NET is not suited for web applications. HTTP wasn't meant for a user interface framework based on events. Period.
• Performance of the ASP.NET page rendering system is extremely slow. There are caching techniques, but these are hard to use and even harder to maintain.
• ViewState ! Anyone who has done some serious work using ASP.NET will know exactly what I'm talking about.
• Building standards-based websites (using CSS) is extremely hard (there are CSS "adapters" available, but they are hardly easy to use)
• The Microsoft Ajax framework is a monster (both in size and usability)

When building web applications, I only use the first steps in the ASP.NET pipeline: Http Handlers and Http Modules. Page rendering is done using a multi-language template engine combined with a logging framework for page/session/visitor/cookie tracking.

Of course, when you don't use the ASP.NET page model, you have to know a little bit about HTTP and HTML/CSS, but I wouldn't call this a bad thing. Many web developers these days know nothing about "low level" web technology, meaning they get into trouble when something "special" or "low-level" needs to be done. I prefer to have control over the whole process: gets, posts, urls, parameters, form variables, etc.

A presentation of the framework I built will follow in my next post.