Need for Light Weight View engine from Microsoft and Evil of Codebehind in ASP.net MVC.

Some how I had an impression in my mind that current version of ViewEngine was just a temporary solution until Asp.Net MVC reaches to Beta stage. It seems now that current version is going to be final at least for V1. If you are like me who do not like ViewPage, then you will have to relay on MVC Contrib for either Brail or NVelocity.

What is wrong in using current version of ViewPage?

I always thought of Web application MVC View as a light weight template engine capable of sending gestures back to controller. Current Version of ViewPage interits from Page class and includes all lifecycle events that are not necessary in MVC View. I cannot imagine my self using ViewPage in real world complex application with multiple partials.

Why do we need light weight ViewEngine from Microsoft team when similar implementation are available from MVC contrib?

Its very difficult to convince architecture committee in big companies to use the piece of software that comes from open source world, more so when alternate version from Microsoft is available with full support.

Most of the Microsoft developers will find themselves more comfortable with the ViewEngine that supports CLR languages rather then Brail or NVeloicity.

Evil of code behind in view

We continue to see lot of Asp.net MVC samples from MS team which uses code behind in View, Although in most of those cases code behind files are empty they do clutter solution with unnecessary file and gives wrong impression to developer community.

Code Behind in a View can easily promote bad design specially when most of the developers are coming from traditional asp.net development and are still learning MVC concepts. Making Code Behind file available to developer has potential risk of promoting them to write business logic or even make service call directly from Code Behind.