The MVC model is a very handy and very well accepted model for traditional desktop applications that let the user manipulate some kind of data. Even web-applications (mostly) fit this model nicely.
In a desktop app this normally involves three distinct parts which are like services: they need to work together, but (should) have a well-defined contract/interface. They are all written in the same main language (whichever it is the app is developed in) but the model needs to interface with some kind of permanent storage (persistence) which sometimes involves translating to another language/representation of the model – be it XML, SQL, CSV, LaTEX or whatever. The View on the other hand, will mostly want to create some kind of visual representation of the model which is sometimes described in some other language than the main. That can be HTML/XUL or XML for Qt-based GUIs – you name it. VMs like Java or .NET have their own way of describing – the more appropriate term is ‘creating’ – the interface from within the program using the same main language.
Now think of MVC as applied to web-apps. Do we get by with 3 languages? No, we need more and that makes it so much more complicated.
Server-side frameworks represent the MVC and can thus comprise 3 languages (like in desktop-apps) already. If a part of the V is to be executed on the client, we need JS in the mix. Since that JS code will mostly also need some data (part of the M) we need to translate that part into a form suitable for transfer to the client (commonly known as ‘marshalling’) with throws another language into the mix – JSON, XML or something else – for a total of 5.
What’s more is that this encompasses two distinct systems, each with their own cycles, states and debugging environments. In one word: a nightmare.