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 !!!
RE: ASP.NET MVC – Is WebForms the VisiCalc of Web Development?
Pingback from ASP.NET MVC – Is WebForms the VisiCalc of Web Development? : Misfit Geek
RE: ASP.NET MVC – Is WebForms the VisiCalc of Web Development?
Pingback from ASP.NET MVC – Is WebForms the VisiCalc of Web Development? | I love .NET!
I kind of dislike the impression many people have of WebForms: because of the drag and drop functionalities of Visual Studio (which, until at LEAST VS2008, were less than stellar, really), and all of the people who learnt "the web" with drag & drop in VS2003, it gives off the impression that it is an easy, VB6-style RAD tool…
I have to definately disagree with that. WebForms are much, much more complex, and much, much harder than something like MVC, as can be seen by the amount of questions that come back over and over on forums: "How do I dynamically generate controls", "my databinding doesn’t work!", "how do I separate my UI from my business logic?!". In WebForm, this is very complex. In MVC, not so.
Why? The way I’ve always seen it, WebForm is a composite application framework. When coupled with the Model-View-PRESENTER pattern to build extremely large, dynamic, composite applications (see: SharePoint), they help solve one of the greatest challenges of computer science: its easy to reuse codes. Its hard to reuse business components. WebForms help a lot with this. MVC, not so much.
The way i work, it is almost painfully obvious which of the two I’ll be using: standard web sites or web applications of all kinds: MVC (include very avanced, but not composite, apps). For anything that can be brought down to components, with large amounts of repetitive parts that appear everywhere, or can be managed by a end user: WebForm.
That is totally opposite to the general vision: WebForms, IMO, suck at RAD (with the exception of prototyping). They excel at complex composite apps. MVC is great for whats between prototyping and composites.
Wow! What a walk down memory lane. I absolutely LOVED Turbo Pascal back in the 80′s. DBase II was great, and DBase IV was such a great improvement. I worked with PowerBuilder some alongwide Visual Basic, but I found PB to be very "confining". For some reason I always felt locked in, and never really enjoyed using it.
Some people STILL don’t understand the web paradigm, and code like it’s either a desktop application or worse, a mainframe app. I’m stilling running into those old Classic ASP code bases that were done SO badly… It wasn’t all Classic ASP’s fault. It was a great alternative, but still had a long way to go.
MVC definitely has its place, but that place is not everywhere, every time. The large development team can certainly benefit, especially with a well established waterfall SDLC. (I have managed a team that maintained an MVC desktop application.) They *must* have the controls in place that MVC provides so that they can maintain order. (It will take some time for everyone to learn how to properly use it, of course. I have horror stories to tell of all kinds of code ending up in all the wrong places, and the software review did nothing to stop it.)
As you said, web forms still have their place, and I feel that that place is in rapid application development, where time is of the essence, and maintainability less important. Web forms have a lot more functional offerings, available components, etc. Over time MVC will catch up on the components, but I’m not convinced it will ever completely match web forms in terms of development speed. I suppose a lot of that depends on how familiar you get with working with the technology, though.
Another difficulty with MVC is studying existing applications. The learning curve for figuring out how an existing MVC application works is much higher than with a web forms app. Often, you can’t just open up the code and see what it does, unless the designer was careful to make that possible. The code paths can get very confusing in large apps unless standards (like naming) are strictly followed.
So, I am familiarizing myself with ASP.NET MVC, but holding in reserve how much I will use it. Most of what I am doing right now is single-developer stuff, no large team stuff. I need to see that code comprehension is not going to be a problem for the person taking over the maintenance of whatever I create.
@Francois -
Wait until you see how confused some users will get over MVC… They will end up sticking code all over the place… Been there, seen that, burned the t-shirt.
All webforms ever did was add a layers of complexity to the HTTP protocol. It has hidden developers from the stateless problem of HTTP by introducing more complex and more subtle errors. From the very first moment I used it, I could sense the horrible bastardization of web development that was ASP.Net.
ASP.Net is exactly what’s needed for people who want to be Web Developers but don’t want to learn what the Web entails, which is an whole other rant altogether.
There are good abstractions and there are bad abstractions. Abstracting something to make it easier to deal with and understand is one thing (ex. nHibernate. you still deal with the idea of persistence and relationships, you just don’t write a bunch of SQL) but to abstract it to work in ways that it was never meant to work (statefulness and WebForms) you’re just complicating the subject and it leads to all the issues we’ve seen with WebForms. Webforms is shielding them from realities that they should _really_ grasp and have an understanding of.
So since I’m one of those (I thought seemingly few) developers that likes digging into the details, and knowing exactly what’s going on under the covers, it seems like I need to push look into / learn ASP.NET MVC into position #1.
*Thank you* for clarifying this for me.
I had to smile at the phrase:
"Well, the point is, developer needs evolve. Perhaps faster than any other profession."
If you want fast, try becoming a molecular biologist, I became a developer because by the time a program appeared to analyse my data either the data was redundant or current methods produce more the new program could consume. I once wrote a program that analysed 10,000 ‘SNP’ data points, a year later it was upgraded to work with 100,000 SNPs and two years after that it became 1,000,000 SNPs. The thing is now, the technique that we use to do this work will probably be replaced by next generation sequencing or 6,000,000,000 data points.
That’s a bit faster than “Moore’s law” and why I am reading blogs on software development!
RE: ASP.NET MVC – Is WebForms the VisiCalc of Web Development?
Pingback from ASP.NET MVC – Is WebForms the VisiCalc of Web Development …
I was doing MVC web development over a decade ago. Snooze… MVC as a pattern has been known for decades.
It’s the flavour of the day for .NET developers. You’ll have the exact same questions that you attribute to WebForms be asked about MVC once MVC becomes popular enough.
Also, can you fix your form so that the tab order is correct?
Actually, it will turn out that ASP.Net is the Visicalc of web development. Silverlight is the future!
+1 to mendicant post. Dead on 100%
Well, I’m used to webform, it brings us a lot of sucessful cases, e.g. New Egg, DNN…
MVC is a good pattern, however I don’t think it’s better/strong than webform, from my own points.
There’s a few good points that I’d like to chime in on. Joe mentions that:
"ASP.NET/Web Forms was a perfect match for the skill set of the day (2001/2002)"
while I agree that Web Forms is a great way to get a page up and running quickly, it most often fails when modifications or enhancements need to be made. These people coming out during 2001-02 were in high demand to get things done as quickly as possible. Companies were adding more and more low to medium skilled people to projects to get their promises out the door. This combination is horrible. The RAD that Web Forms provides also takes away the extensibility that is needed with online web applications. Especially when inexperienced developers are working on them.
By no means am I saying that Web Forms developers are inexperienced web developers, I’m merely stating that during the boom, the talent pool was diluted quite a bit.
This brings up another point he made:
"No need to know anything about HTTP, HTML, DHTML, JavaScript, etc."
If I can code in VB.Net or C# very well, why should I need to know about web markup and client side scripting languages? Apparantly, this is all done for me. Whereas some of it may be done through out-of-the-box code generation, I’ve never come across a solution where out-of-the-box is the perfect fit for the product’s needs. Once you drag-and-drop your controls out there, are you done? Likely not. Wouldn’t it be nice to be able to control that "unimportant" JavaScript and HTML so your web app works as you want it? If anybody out there uses Web Forms and thinks the markup that it creates is "ok", you obviously don’t understand the web. Web Forms markup is crap and needing to use <%= control.ClientID %> is proof.
The last point I’d like to mention is when Joe stated that Web Forms has a:
"huge base of well factored libraries"
I think "well factored" is a gross misrepresentation of the entire ASP.NET framework. Many of the classes are difficult if not impossible to duplicate in a test environment without actually running the project. There are far too many sealed classes and not nearly enough interfaces to work with. This makes for a testing nightmare. ASP.NET MVC has solved many (but not all) of these problems.
I feel that I’m very lucky to never really "get" Web Forms. The whole page lifecycle is ridiculous when it comes to a stateless machine that is the web. I really hope it goes away before I do.
RE: ASP.NET MVC – Is WebForms the VisiCalc of Web Development?
Pingback from Twitter Trackbacks for ASP.NET MVC – Is WebForms the VisiCalc of Web Development? : Misfit Geek [msjoe.com] on Topsy.com
Hi Joe,
A lot of the tools you mention on this post, I’ve also worked on, and it’s nice to take a trip down memory lane. My first Web development was with Delphi’s WebBroker, developing ISAPI/CGI’s and then moving on to working ON Intraweb (now known as VCL For the Web), so I’ve been on both sides of the fence (consumer of web application frameworks and developer of them) and used both types of approaches to web development.
The primary issue I see with ASP.NET WebForms (and to a certain extent Intraweb) is that it is abstracting the essense of what the web is as a platform. I’m not talking about not having to deal with HTML or CSS or Javascript, in the end those are just languages. I’m talking about HTTP as a stateless protocol and the fact that we’re no longer on one machine per user.
Developers that used their existing knowledge of WebForms/VCL Forms, moved to the web by trying to develop web applications in the same way they would desktop or client-server. They didn’t undestand what stateless meant or what resource sharing was about. They were given this tool and told to "leverage their existing knowledge" and this led to a whole array of problems such as sharing violations, scalability, incorrect resource management, state management etc.
Why? Because developers forgot that it was no longer one machine per user. It was one machine per 1000 users, there was threading, there were all sorts of problems going on. Developers didn’t know how to manage state because they never had to manage state in desktop applications, it was managed for them. It was inherent.
To summarize, in my humble opinion, MVC isn’t necessarily about getting back down to the metal, but more about understanding the inherent nature of the platform. HTML, Javascript and CSS can be abstracted if desired, but hiding the architecture is what causes the problems.
Evolution isn’t necessarily always abstraction, and abstraction isn’t necesarily always bad. We just have to find the right way to do it.
RE: ASP.NET MVC – Is WebForms the VisiCalc of Web Development?
Pingback from ASP.NET MVC – Is WebForms the VisiCalc of Web Development? | rapid-DEV.net
Funny I’m just starting my blog digithistory.com with the story of Visicalc
digithistory.com/…/visicalc-histor I have a very personal relational story with Visicalc.
RE: ASP.NET MVC – Is WebForms the VisiCalc of Web Development?
Pingback from Dew Drop – August 27, 2009 | Alvin Ashcraft’s Morning Dew
RE: ASP.NET MVC – Is WebForms the VisiCalc of Web Development?
One sentence I’d never thought I’d see describing WebForms is: It was perfect, and it’s acceptance was
Some of your guys are missing the point.
WebForms wasn’t the "evolution" it was the tool we needed while our skills caught up to the web. It let us get applications built without knowing about the web plumbing.
Now that we are inevitability learning about the plumbing, we don’t need the abstraction.
The evolution (for those of us that WNAT to get to the details) is the move AWAY from the abstraction
Why did we need it? Couldn’t we have learned and embraced the web in the first place? Didn’t you have to learn about viewstate, page lifecycle and many pesky details and gotchas in webforms?
some have commented on how terrible asp.net is.
asp.net != webforms.
asp.net is a framework for servicing request/response. there are plenty of hooks and extension points throughout the framework which make it a great platform for .net developers.
webforms is an html engine. it is tightly coupled with very few, if any, extension points. the developer has very little control over the html produced.
I run into this all the time. "web developers" are using asp.net. what they really mean is webforms. if asp.net was webforms then MS MVC and Castle Monorail would not be possible.
Joe, I think we’re seeing the same phenomenon that happened in GUI design with the appearance of RAD tools. If you recall Turbo Pascal you’ll certainly recall the menu generation tools that first emerged back when we were still doing DOS applications. It was one of my first experiences with object oriented programming and back around ’93 and ’94. You had to write everything by hand, but it certainly was an improvement over what we had before that.
Then came Windows 95, but you still needed to do a lot of hand coding and positioning. Then came the RAD tools with the ability drag and drop buttons, labels, lists and of course components. We had database access components and serial port components and what not. This lead to rapid development of strongly coupled applications. But it was so great we really didn’t care.
An MVC design could very well have been applied there too. After all MVC isn’t limited to web applications. But it was so easy to just put everything together and code stuff.
In a way the same thing happened in web apps and now we’re seeing the impact of bad design patterns. The impact of cutting corners and doing it quickly rather than modular. MVC forces you to be more modular (hence the name MVC).
I don’t think its an issue of state control or not. Inevitably it will move to manage state. That is an indispensable aspect of an application. Even if HTTP is stateless one’s application isn’t and we need to preserve state. The more successful frameworks I’ve seen manage state for the developer. It’s a must because forward and backward buttons are inevitable aspects of the web. Page reloading too. So it is best to use something that encapsulates that in a well tested tool rather than develop your own.
So I see two things. An MVC framework to better separate functions into real model view and controller. Keeping applications well structured and maintainable. And the application state management which can be handled by a specially crafted controller which can be extended or configured to provide application flow control.
RE: ASP.NET MVC – Is WebForms the VisiCalc of Web Development?
Pingback from ASP.NET MVC – Is WebForms the VisiCalc of Web Development … « Web Development
RE: ASP.NET MVC – Is WebForms the VisiCalc of Web Development?
Pingback from ASP.NET MVC – Is WebForms the VisiCalc of Web Development … Match Web
Thanks for the entry, Joe…I’ve been on the WebDev track since 1995 and appreciate the comments from that perspective. Having coded CGI, IDC/HTX, ASP/DHTML/XML DataIslands (remember that one?!) apps, I jumped at the chance to use WebForms. The 80/20 rule was about right; most of the dev time was spent on the plumbing, protocal handling and persistence issues. WebForms flipped the ratio to about 40/60, which has been a huge plus. We’re delivering solid and more complex apps to our users faster than before.
MVC?…Yes, absolutely! (where State and persistence is not the primary focus). WebForms….Yes! (When it makes sense to leverage the built-in state management) In short, I’ll use one or the other (or maybe something completely different) based on the needs of my clients and the toolset that delivers solid results in the shortest time.
I need some help in designing the application.
I need some help regarding designing the architeture for my project.
Below is the requirement
1) Designer team will create HTML page with DIV Tags on page.They will create template
2) Developer then add controls or html markup on that DEV tags.That means there will be component inside DIV tags.
3) Component can have multiple zones
4) Each Zones can have subcomponent.
5) Each Subcomponent can have different properties.
Please suggest me some kind of architecture for creating such kind of project.
Dipesh, you might want to look into MasterPages
http://www.asp.net/…/video-7024.aspx
Looks like the type of thing you’re needing.
RE: ASP.NET MVC – Is WebForms the VisiCalc of Web Development?
Pingback from ASP.NET MVC Archived Blog Posts, Page 1
http://www.joelonsoftware.com/…/LeakyAbstractio
Webforms is the epitome of the leaky abstraction. When it works, it works great. When it fails it fails dramatically. For simple forms over data web apps (at which VB6 and hence webforms both excel), you’re in good hands. Once your app grows in complexity, you will find that you are shackled by the abstracted view of web development and have to fight tooth and nail to do tasks that are dead simple in other platforms (ever try multiple forms on a page?).
You may have some kind of nostalgic memory of your experiences with webforms, but it’s quite possibly from lack of exposure. Yeah jim beam is great until you’ve had a 14 year single malt scotch.
It was a great tool to get people used to the VB6 Client/Server model productive on the web quickly. But compared to other frameworks around at the same time (PHP, JSP and even Classic ASP) it ws a step back.
RE: ASP.NET MVC – Is WebForms the VisiCalc of Web Development?
The new VisiCalc