JavaScript, JSON and modern web MVC
As web developers we’re working through a transitionary period. New technologies are becoming widespread enough to be usable in real web apps – not just toys. After years of stagnation in JavaScript engines, Google Chrome started an arms race in speed, with all the major browser makers competing to make the fastest JavaScript interpreter. These changes are opening up a new world of web app development that hasn’t been fully explored yet, but this means we may have to rethink some of the best practices we’ve been following for the past decade.
MVC today
In a modern web application framework, MVC is well defined: requests get routed to a controller, which requests data from the model (which is probably using an ORM) and instantiates a templated view with this data. This view is sent as HTML to the browser which creates a DOM from the HTML, and renders the DOM (with CSS and images) as a web page.
JavaScript then operates on the DOM, adding a layer of interactivity to the page. As things advance, the JavaScript layer has taken on more importance, reducing the number of page reloads by selectively reloading parts of the page with Ajax.
As the complexity of JavaScript on the client has increased, it’s been easy to end up with unstructured spaghetti code based around the jQuery model of “find something, do something with it”. As more state has moved to the browser, MVC frameworks for JavaScript have stepped in to add structure to the code. The problem is, now we have two MVC stacks:
MVC of the future
MVCMVC or MMVVCC aren’t just un-catchy, they’re a rubbish idea. If we’re going to make rich apps that rely on JavaScript (and as I said previously, I think we should), we need to lose some redundancy.
The model will usually be accessing some shared database, so in most cases it makes sense for this component to be on the server (authentication usually lives here as well). The view is the DOM, and the controller is the JavaScript. There’ll also need to be model code in the JavaScript – the extent to which the model logic is split between client and server depends on the application.
All the server needs to do is provide JSON responses when the client asks for more data, ideally using simple RESTful resources.
One benefit of the server being a simple JSON store is that it enables us to
easily add redundancy to our apps – if server1 fails to deliver a response,
fall back to server2.
No more HTML
The DOM is the means by which we display our app to the user. The browser thinks in terms of the DOM. HTML is just a serialisation of the DOM. Modern web app developers shouldn’t be thinking in terms of HTML. HTML is the assembly language of the web, and we should be working at a higher level of abstraction if we want to get stuff done. Most of the time we should be thinking in terms of layouts, widgets and dialogs, like grown-up UI designers.
The problem at the moment is that HTML is being used as a combined data and presentation format, and it should be obvious that this is a Bad ThingTM.
Of course at some point we’ll need to go down to the level of the HTML, and at that point we should be using templates. jQuery.tmpl is one (see my slides and presentation on the subject), but there are many others too. One interesting development (thanks to James Pearce for putting me onto this) is Model-driven Views (MDV).
MDV links JavaScript objects to the DOM in such a way that any changes to the object are automatically reflected in the DOM, and likewise, any user changes to the DOM are automatically reflected in the model objects. Hopefully this will become standard in modern browsers, as it provides a clean and easy way to keep the DOM up-to-date with the model objects without endless wiring, which again helps to insulate us from having to deal with too much HTML.
I’m not suggesting that HTML will go away, or that developers won’t need to learn it – just that most of the time, most developers won’t need to be worrying about it, just like most of the time, most C developers don’t need to worry about assembly code.
Conclusion
Most web-apps are currently halfway there in terms of moving functionality to the client. The problem is that we have ended up in the worst of both worlds as app developers. Our serverside MVC framework provides a nice template-based abstraction over the HTML, which we then break apart on the client. We’re forced to work at too many different levels of abstraction simultaneously, which is never a good thing.
Things were simple when everything happened on the server. Things will be simple again when everything happens on the client. Over time new tools and best practices will emerge to encourage this new way of working. In the meantime, it’s going to take a bit of extra effort, but it’ll be worth it.
Great article thanks for that. Sounds like an idea – I’ve wondered for a while what the next step would be for web development.
However, as an avid NoScript user, I can’t help but feel most people would end up writing MVC twice anyway, unless there was something that produced client-side MVC-javascript based on what it finds on the server. This would have the added benefit of enforcing a stricter adherence MVC pattern on the server.
@Anthony Thanks. I don’t think it’s at all straightforward to transfer server-side MVC to client-side MVC – they’re doing very different things and working at different levels.
As for NoScript, I can understand why you wouldn’t want JavaScript to be required on websites, but I think for rich apps you’re not going to have much choice – it’s the way things are going, and I think it’s going to make the user experience so much better.
@Skilldrick Thanks for the reply – I don’t know anything about client-side MVC. You’ve definitely given me something to read up on.
I still can’t see how V&C would leave the server completely. Unless the purpose of MDV (and the ‘proxies’ that that Google Code page mentions) is to move away from static client/request entirely, surely the server would need to control the HTTP request in some way, and would need to use a view (or at least a render method) on the model to turn it into JSON?
@Anthony What the server would be is a web service that receives a REST request (e.g.
/photos/248) and returns a JSON response with the requested information. You don’t need an MVC stack for that, IMHO.I wrote something similar about HTML being a distraction, and I believe that a lot of projects will be way more front-end driven from now on as well.
This answer on Quora about JSON responses and the server working as an API is a nice complement to this post.
Cheers.
@Miller Medeiros Ah, nice find on Quora! Yes, this bit especially:
That’s exactly what I was trying to say!
I agree about HTML being a distraction as well – it’s all too easy to let HTML be the core of the application structure if you’re not careful.
Non-redundant: that’s very nice, but what about accessibility? AIUI the state of accessible browsers means we are going to be stuck with dual stacks for the time being. Some places are legally bound to provide accessible sites.