MVC doesn't have anywhere in it for a client-server relationship. This is because MVC is actually a
desktop app model, designed for things like CAD programs. Client-server connections are
too important to gloss over, because you can't gloss over the Fallacies of Distributed Computing:
http://www.rgoarchitects.com/Files/fallacies.pdf And your architecture must actually handle those issues, which means it's not going to be MVC.
MVC makes sense for a pure Javascript app that uses the server only as a DB server (if that). It can at least be jammed into a classic old-style pure server application. But if your app actually spans the two, you haven't got MVC anymore... or you've got an app scoring 8 out of 8 on the network fallacies, probably by virtue of trying to wrap all network access behind an "RPC" interface, which tries to represent network interaction as local function calls, which one of the easiest ways to score an 8 out of 8 on the fallacies list.
Because of the way MVC tends to afford glossing over the network fallacies, I tend to consider it an inferior design for almost any web application. It's a lot of code busywork to try to sort of kind of (probably not actually, assuming the MVC one is starting with is even MVC in the first place and not just "vaguely MVCish in name only") conform to a particular architecture, requiring at least three moving pieces to do anything (one in each letter of the acronym, in practice, often a view on the server and on the client) mandating that your application be flung out all over the place, and it gives you... hardly anything in return, really. Certainly nothing that a direct application of DRY couldn't have given you. It isn't necessary for most web apps and it's a terrible default for a new web framework to impose on its users.
While I'm not a fan of the "hexagon" name (the number "six" doesn't seem to have any meaning, except this guy once drew a diagram in a hexagon), it's a much better way of looking at things. I tend to think of it as a celluar design; there are the cell innards, then surrounding it is a cell membrane that is responsible for cleaning up the innard's view of the outside world, and exposing well-defined capabilities to the outside world. (The metaphor is not perfect; biology is messy, and there's no compelling reason to copy that aspect. But the general idea of cells, or hexagons, is quite powerful.)
One of the interesting aspects of Haskell is that it tends to enable the creation of a lot of very fine-grained cells, where the type system is helping you build a very strong and very well-defined membrane; it allows you to see even things as simple as "map" as fitting in to this model, at the smallest level.