This blogpost and one of our senior developers at work believe that web development has come full circle with ASP.net MVC. Its not really a question about VB script vs VB9/10 or whatever is the latest. Besides routing engine, helper classes and methods. What are some strong arguments you can make to say
ASP.net MVC != Classic ASP + .net BCL
The View component of the new ASP.NET MVC support syntax which looks like ASP 3.0.
In fact, this syntax (<% %>) was always available in ASP.NET WebForms.
You can still use ASP.NET controls ( < asp:control > ) in MVC or you can use the new syntax (which is odd IMHO) or use other frameworks like NVelocity.
This range of available techniques cannot be considered as a old ASP over .NET BCL.
In ASP the "View" receives the request. In ASP.NET-MVC a controller receives the request, subsequently it may choose from a number of different views to create the response.
This seperation of the Request handling from the Response handling is very different from ASP.
The blog post is not based on a very complete understanding of the MVC framework. MVC promotes a good separation of concerns, the code that is contained within the View files should be very basic; All of the actual coding happens within the controllers. The blog post author says that the true strength of ASP.Net was the controls, I would argue that the strength was the event driven model and the presentation of a stateful environment overtop a nearly stateless environment. MVC maintains this strength while also promoting an even further separation from the actual UI.
That argument works under the assumption that all there are in MVC is Views.
The reality is that the view is one small piece of the puzzle, and thinking it is the whole thing shows a profound lack of understanding of both the pattern and the framework. You cannot make an argument without first educating the person, and in the act of educating the argument will become irrelivent.
To address the blog post itself, yes, you do lose alot of functionality by giving up rich controls, especially if you are talking about controls you bought from a third party vendor. However, nowadays there are full suites of javascript widgets out there that are as good if not better then anything available for asp, and they are free. Not only that, but using ASP.net means buying into an extraordinarily complex framework that works about 90% of the time. The problem with this is that 90% is never enough for anything non trivial, and working around the framework for that extra 10% can be living hell. The other thing is that the performance that comes with buying into that complexity is absolutely abysmal.
Comparisons between MVC and ASP.net need to be between widgets vs good archetecture, flexible straight forward markup, and good performance. If you need those widgets, then stick with ASP.net, Lord knows it isn't going away any time soon. If you are comfortable with web technologies like html, javascript, and CSS, losing those out of the box widgets will suck, but what you get will vastly outweigh what you lose.
There are significant, fundamental design differences between classic ASP and ASP.NET MVC. The most significant difference is the separation of business logic from display logic. In classic ASP both types of logic were, for the most part, mixed in the mark up. In ASP.NET MVC -- used properly -- the only code in the view component is that required to render the page. The business logic, the selection of the data to appear on the page and the logic to interpret and handle inputs, is found in the controllers and model.
Because of this difference, ASP.NET MVC significantly increases the testability of the code over both classic ASP and WebForms. All of the business logic is found in classes that are decoupled from the rendering engine and can thus be (more) easily tested via unit tests. In classic ASP and WebForms, to one extent or another, much of this logic is found on the page or in code-behind, which is more difficult to test.
Plus, in my opinion it would be harder to maintain the application once you have the classic ASP like code floating in the HTML of the page.
I can agree that maintaining a page with spaghetti code can be harder.
But ASP.NET MVC Views are still compiled like ASP.NET WebForms are - this is big difference over ASP 3 and you have IntelliSense available in .aspx.
The overall application maintenance with MVC is in fact much simpler. It is much easier to create unit tests for you code which can create a nice net for catching bug (and also increse developers' confidence that code really works).
It is very easy to create a page in Web Forms but many times it is harder to test the code behind the page.
I am the original author of that blog post and here are my views on it:
ASP.NET MVC is a different framework targeted for different audience and purposes. The main purpose ASP.NET MVC serves is separation of concerns and testability. The view code and HTML mix code does create spaghetti code but you should always keep your views as small components. This will make it easier to debug the application and find problems instead of keeping all the views on the same page and creating a mess.
ASP.NET MVC had to give up many powerful ASP.NET controls. But luckily many JavaScript libraries came out with new cool controls to be plugged into ASP.NET MVC.
Software is all about trade offs. You are trading ASP.NET powerful controls, ViewState management, Postbacks etc with complete control over the request/response cycle. If you are comfortable with ViewState, Postback issues and not interested in unit testing then maybe ASP.NET MVC is not for you.
Also with IronRuby in progress I see ASP.NET MVC as a very powerful framework.