The whole idea behind using JavaScript for web pages, would be to enable a clear MVC separation on the client side: HTML for data, CSS for view, JavaScript for the control.

If I've already got MVC on the server so, why do I need any client MVC?

Well, it's all due to bandwidth usage and having smart clients vs. dumb clients (meaning the programs).

In a "web application" we would have the following:

1. Server
   1. Modelo - MySQL/PostgreSQL/Oracle
   2. Control - PHP/Java
   3. View - PHP/templates
2. Client
   1. Model - HTML/XML
   2. Control - JavaScript
   3. View - CSS

It's worth to note that the whole Client is the "view" of the server application. This means it's actually good for it to be easy to write -in ECMAScript- and that choosing the same language for Flash is no wrongdoing (which itself also represents the "view" of the server application).

On the other side, if the question was what amount of business logic should be displaced onto the client, you would have the following choices:

1. Reduced - HTML+CSS+JavaScript / Flash
2. Medium - Java applet
3. High - specific client

The difference between JavaScript en Flash would lie in how important it is to show the data at any cost, even though it might not get rendered the same way everywhere. If we value more the data reaching the user, we should place them in HTML/XML and thus use JavaScript. But if what's more important is the actual view, the right way would be to use Flash... hoping perhaps for a better integration between SVG and the major browsers, and an improvement in JavaScript engines.

From this point of view, the availability of the data, some badly applied AJAX, that would "get possession" of the page (so that it would degrade cleanly) would indeed be a dangerous beast; a crossover between awarding the most value to the data, while completely disregarding any compatibility with browsers that might not support it.