Sobering listening to this and seeing the images.  Look back at everything he said......yeah.  We are giving this country away.

Whenever I tell other .NET developers I prefer VB over C# (which wasn't the case until this past February), user controls are glorified server-side include files, and migrating a classic ASP site to .NET can be done with less pain than everyone wants you to believe, I get a dirty look or two.  ; Sure, things have changed in regards to best practices and performance, but most of the performance issues are myths.  Yanghaifeng's blog entry cites discusses these myths Rob Howard presented in his 10 Tips for Writing High-Performance Web Applications article on MSDN.

One of the most common myths  is that C# code is faster than Visual Basic code. There is a grain of truth in this, as it is possible to take several performance-hindering actions in Visual Basic that are not possible to accomplish in C#, such as not explicitly declaring types. But if good programming practices are followed, there is no reason why Visual Basic and C# code cannot execute with nearly identical performance. To put it more succinctly, similar code produces similar results.

Note: in fact, both C# and VB.NET will be converted to IL and executed on CLR environment, it's totally the same.

Another myth is that code-behind is faster than inline, which is absolutely false. It doesn't matter where your code for your ASP.NET application lives, whether in a code-behind file or inline with the ASP.NET page. Sometimes I prefer to use inline code as changes don't incur the same update costs as code-behind. For example, with code-behind you have to update the entire code-behind DLL, which can be a scary proposition.

Note: both inline code and code behind code will be compiled to one page class and executed in HTTPModule.

Myth number three is that components are faster than pages. This was true in Classic ASP when compiled COM servers were much faster than VBScript. With ASP.NET, however, both pages and components are classes. Whether your code is inline in a page, within a code-behind, or in a separate component makes little performance difference. Organizationally, it is better to group functionality logically this way, but again it makes no difference with regard to performance.

 

Rick Strahl brings up some interesting issues facing ASP .NET and the community.  It's currently my favorite blog article of the year, and if you are an open minded .NET Developer it's a must read.

But the problem is one of perception: Micro$oft is by default associated with big dollar signs, and "Microsoft is always after your money". Certainly that's not my experience either for myself or for the customers I've worked with costs very clearly delineated.

But I can certainly attest to the hesitancy of many developers and companies to trust Microsoft, always feeling that in the end Microsoft is out to screw them. It's un-rational to the biggest extent but it's a very real issue that plagues Microsoft in general in my opinion.

 

Sure to bore most of my friends & family to death, I'll be doing more in-depth technical blog entries within the coming year.  These are my goals, and realistically I'll be pushing one of these out every two months:

• Writing Characterization Tests With NUnit and RhinoMocks (C# and VB) - I feel like I need to put my spin on things, and this probably isn't discussed enough anyway.

• Putting Existing Code In A Test Harness (VB) - This isn't discussed enough, especially in Visual Basic.

• Building Your Data Access Layer With A Decoupled Provider Model Pattern (C# and VB) - The current Provider Model Pattern irks me because of it's use of configuration files.  Outside of the sensitive connection string, I'm totally on-board with "convention over configuration", so I'll explain how I use this pattern complete with my alternative database cache invalidating system.

• Using libPurple In .NET Applications - This should be a great learning experience for me as I have visions of using Pidgin as an enterprise communications facilitator.

• Building A Developer Team Portal In ASP .NET (VB) - Includes modules involving internal communication, bug tracking, project management, and SVN source control.

This should keep me fairly busy in the upcoming year.   I'll also post my opinions on articles that cover subjects that matter to me:  Linux, SharePoint, Prototype, Script.aculo.us, Facebook.NET, SDL.NET, Subversion, and ASP .NET in general.