If you’re an “old geek” like me, you remember a number of software products that “changed the world”.

VisiCalc was THE spreadsheet of the day !  It might have done 2% of what Excel 2010 does, but when it was released it was an AMAZING innovation.

And how about DBase II (first released for CP/M) ?

It wasn’t the first database in the world, nor was it the first programming language, but it was an amazing innovation for the developer of the day that has evolved into forms that the original dBase creators probably never envisioned !

And then there was Turbo Pascal !!!!

When I got my first copy of Turbo Pascal it was pure genius. I think I paid $80 for it for my Televideo 802 CP/M machine. Up until then I was coding in assembly. The “C” compiler at the time was about $1,900 and the ADA compiler was like 5 GRAND !

The Turbo Pascal IDE (Editor) Debugger, Libraries etc. were state of the art back in the day, the best the world had ever seen. But it bore little resemblance to the Delphi products available today.

So what does this have to do with ASP.NET and WebForms?

Well, the point is, developer needs evolve. Perhaps faster than any other profession.

When ASP.NET was first designed, the majority of business application created were not web applications and the world was full of “Client / Server” developers.

We did Visual Basic, PowerBuilder, and Delphi. We built workgroup applications in Microsoft Access, FoxPro, dBase, Paradox, Notes, Excel, etc.

All these approaches to software development use the same “paradigm”. Forms, Events, and code that manipulates them.

Enter the World Wide Web.

My first web applications were CGI applications written in “C” and running on “Heavy Metal Unix”. 

My code had to do EVERYTHING – MY CODE needed to handle all the HTTP gook as well as generate the HTML to be returned to the client.

Later, when JavaScript came along, that same “C” code had to generate and embed JavaScript.

Now, we got it done, but 90% of our time was spent on plumbing.

Worse yet, doing this kind of web development required pretty detailed understanding of HTTP, HTML, Cookies, JavaScript, etc.

This took time to learn, and time to write – a lot of time. Meanwhile the world wide web EXPLODED in popularity.

All the technology players scrambled to meet the needs of developers who were moving to the web and needed to do it in a hurry.

Microsoft did a short lived effort IDC/HTX and then Classic ASP, Netscape did Live Wire.

Classic ASP was super and enjoyed great popularity, but only because it was less bad than all the other options 🙂

Enter ASP.NET and Web Forms.

ASP.NET/Web Forms was a perfect match for the skill set of the day (2001/2002) and was exactly what the industry needed at the time.

It delivered a developer “paradigm” that was very closely aligned with what developers were using. (VB, Delphi, PowerBuilder, Access, FoxPro, dBase, etc.)

— Forms, Events, Handlers, Libraries.

No need to know anything about HTTP, HTML, DHTML, JavaScript, etc.)

All the tough plumbing stuff was accessible in a huge base of well factored libraries, handled by the runtime, or done for you by Visual Studio.

It was perfect, and it’s acceptance was meteoric !

Then about 8 years later, Microsoft started showing ASP.NET MVC.

The “uber-geeks” and ALT.NETers were all over it and condemned Web Forms to a quick demise.

Some even suggested that Microsoft was conceding than WebForms was a mistake.

NOT !!!!!!

Web Forms was EXACTLY what we needed at the time, and it was massively successful in helping companies around the world take thousands of applications to the Web.

And then the Web, along with it’s users, matured, and they did it in “internet time” where a year is three months long. That’s a lot of evolution.

Today, more and more applications NEED access to the HTTP stack, they NEED to contain features and behaviors that can only be implemented in custom JavaScript (or Silverlight or Flash)

Like all development scenarios, developers get started doing meaningful work with the tools at hand and then inevitably start to “get under the covers”.

ASP.NET MVC does NOT hide you from the plumbing of the web. It doesn’t, for example, add state to HTTP’s innately stateless nature. To the contrary, in embraces it.

From my perspective, this makes product development from ASP.NET Web Forms to ASP.NET MVC a natural platform progression.

The ASP.NET Team is continuing to evolve Web Forms because many, many developers will continue  building great applications using Web Forms, and may never crack open MVC. There are new features in Web Forms 4.0 and there will be in 5.0 as well.

The ASP.NET team is also continuing it’s work on ASP.NET MVC. This is not to the EXCLUSION of Web Forms, but is an answer to the natural evolutionary needs of web developers.

Some developers will love the ASP.NET MVC way, other hate how much of the detail they need to code themselves when ASP.NET Web Forms just “gives it to them”.

And…. Some folks love working in the classic GOF MVC pattern. Others don’t like feeling “constrained” by a specific implementation structure.

I spent last week on campus (Microsoft headquarters where the ASP.NET is built!)  and spent much of my time meeting about the products and features the ASP.NET team will be delivering AFTER ASP.NET 4.0

More evolution – but don’t panic !

The new stuff will very cool and compatible (if you’re going to PDC or MIX you may see sneak peeks) – but most of all SIMPLE and POWERFUL !

Everyone always wants to talk about innovation, but clever evolution is every bit as exciting to me (and the lines between the two are grey anyway)

As for me, I’ll still be doing Web Forms, but I’ll be learning MVC and I’ll be chomping at the bit waiting until I can start showing you the V.after_4 stuff !

After a week looking at some longer term plans for ASP.NET – I’M PUMPED to be on the best train for web developers !!!


Technorati Tags: Microsoft ASP.NET MVC Future