You could also request the http info and simply show that to a person on a page. In rails it would be as simple as calling 'request.user_agent' and printing that value on screen.
Needed a branded version? This is when you're talking to clients that can't tell the difference between one browser and another? These clients can't tell the difference between a big blue e, a fox or a colourful circle? Yet you needed a branded version?
I'm just pulling your leg, I understand that you needed a branded version and that wasn't influenced by your clients inability to distinguish between core brands in the online space.
How can it be a good thing to follow the MVC framework on both the client side and the server side, as it says in it's philosophy, when the client side is the V in MVC?
Good question. In hexagonal.js approach client side is full app - so there's model part (use case is part of model), glue ~ controller and views are GUI and other adapters.
Thanks for letting me know. I'll not be rushing out to add hexagonal.js to my Rails app, but if one of my friends who likes js wants to try building their own full app I'll mention this as a possibility.
To be honest most of project I developed with hexagonal.js have Rails as a backend and it's really powerful with sprockets on board. So give it a try, maybe in toy project.
Why can't MVC be compositional? The model of the client can come from the server's view. For example, a server could follow MVC, where the view is responsible for forming the data (such as in JSON or XML). In turn, that could form the model for the client's use of MVC.
Because then it's not really MVC anymore. It's something else, perhaps inspired by MVC, but not MVC.
The web world really needs to get over its juvenile idea that MVC is the One True Architecture and if something isn't MVC it isn't good and therefore if we want to present a new library with a new design it is Mandatory to explain how "No, really, it's MVC! Even though it isn't, here's how it is!". It's not MVC. That's fine. It's probably better. Many designs are. MVC is fine in its niche but that niche doesn't cover Every Web Application Ever very well.
I agree with your latter point. MVC isn't the last word in architectural patterns.
However...
> Because then it's not really MVC anymore. It's something else, perhaps inspired by MVC, but not MVC.
I fail to see why the example I gave does not follow MVC. You have MVC on the server (as people have been familiar with for a very long time. Nothing new here). In turn, that data produced by the view on the server (could be HTML, XML, JSON, whatever) can form the model of a second MVC architecture on the client side.
What exactly isn't MVC in either the client or server? The only thing I can thing you might take issue with is consuming the model from the data sent from the server, but I couldn't explain why. This is still in keeping with the MVC pattern, which in no way prescribes that the data has to come directly from a database (or whatever else the server's model's state is formed by).
Or is the problem with the server's view not generating output that is necessarily HTML to be looked at, but data to be further consumed? Again I don't see how that doesn't fit in with the MVC framework.
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.
