Home > Programming > JavaScript, JSON and modern web MVC

JavaScript, JSON and modern web MVC

June 2nd, 2011

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:

Current JavaScript solutions suffer from "Double MVC". You need both server and client-side MVC stacks. Conceptual complexity is very high.
@dhh
DHH

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.

  1. Anthony
    June 7th, 2011 at 09:33 | #1

    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.

  2. June 7th, 2011 at 09:37 | #2

    @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.

  3. Anthony
    June 7th, 2011 at 09:53 | #3

    @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?

  4. June 7th, 2011 at 10:46 | #4

    @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.

  5. June 19th, 2011 at 06:08 | #5

    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.

  6. June 19th, 2011 at 10:37 | #6

    @Miller Medeiros Ah, nice find on Quora! Yes, this bit especially:

    It’s the time-honoured software design principle of reducing coupling and increasing cohesion. By serving JSON, you’re letting your server be dedicated to what it’s best at: worrying about business logic, data persistence, etc.; and letting your client do what it’s best at: user interface. When you serve a block of HTML and slap it on the page, you’re blurring the distinction and creating a fragile dependence between client and server. Implication is that if you change the page design, you will probably have to change the service too.

    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.

  7. yitznewton
    July 12th, 2011 at 15:44 | #7

    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.

  8. March 4th, 2015 at 13:35 | #8

    Since these pages have a top 10 ranking, the pazges must have all the best settings. The home page should promote the product categories whilst all the internal pages should follow a clear path easily understood by bokth search engines and customers. We’ve lopoked at numerpus ways tto icrease traffic to your website using search engine optimisaqtion and website optimisation with high traffic low competition keywords.

    My page [cheap seo pricing](https://kdp.amazon.com/community/profile.jspa?userID=554581 “cheap seo pricing”)

  9. June 24th, 2015 at 10:09 | #9

    But how do you perform kegle correctly?

Comments are closed.