The rise of JavaScript and it’s impact on software architecture

MVC and it’s siblings have been around for a while and developers are comfortable bathing in the warm light of their maturity and wide-spread advocation. However, a few years ago developers started doing more of their coding client-side and as a natural consequence the lines between M, V and C became blurred leaving many of us cold and uncomfortable when trying to explain where the architectural puzzle pieces belong.

I’m sure you’ve had a similar experience. Anyone who’s used jQuery, for example, has been in the uncomfortable situation where controller code now exists within view and even worse these two are tightly coupled by virtue of jQuery selectors. To make matters more complicated if you’ve ever used class-names for application state or .data() then you’re model, view and controller are now more tightly bound than the figures in a Kamasutra carving.

This is not a new problem but the solution(s) are quite new to me and so I thought I’d share my experiences.

jQuery is Great. But…

Anyone who knows me or my work is familiar with my evangelism of the framework, and it still has it’s place, but times are a-changing and we-the-developers need different tools now. jQuery is a DOM-manipulation framework, the best in the world but to be effective in the development of web applications we need new architecture tools.


MVC in a traditional sense is split across the tiers of client- and server-side infrastructure. However a number of new paradigms and tools exist that firmly embed another layer of MVC (or MVP/MVVM/etc.) within this traditional setup. Over the past few months I’ve done some investigation to determine the value of such tools and I have been blown away. Some of the frameworks that I’ve looked at are:

This is list is not exhaustive and neither are these tools exactly the same in what they deliver but the overlap is sufficiently significant to consider them the “same”.

I invite you to dig deeper into these tools yourself but in a nutshell they typically are:

  • created using JavaScript
  • use either MVC or MVVM as their architectural base
  • use object-oriented principles to represent data and controllers within JavaScript
  • are loosely coupled within their operational paradigms i.e. controller and models are independent
  • use ORM to represent data
  • serialise/deserialise the data objects to/from JSON
  • are loosely coupled with the view
  • can be combined with jQuery
By using these tools the concept of front-end and back-end applications is pronounced and the handoffs between the two are explicit as well as neatly independent.

That is all

In a later post I’ll detail the creation of an app to demonstrate the ease  and power of these new frameworks through the use of KnockoutJS. Currently I’m building applications using Knockout since it’s easy to learn, incredibly elegant and famous of being concise. For those of you that would like a sneak peek the source code is here, and there’s a demo here.

4 thoughts on “The rise of JavaScript and it’s impact on software architecture”

  1. Great post and could not agree more. These micro frameworks are needed and help propel javascript to a first class language. That includes writing structured, testable and refactorable code just like any OO language. There is just too much javascript being written without the same rigor we would apply to other languages like java, c#, ruby etc. Also, mobile platforms are no pushing us to build up our ‘lego’ pieces more succinctly versus bloat that you get from larger libraries. is a promising site that helps you bundle your framework needs.

  2. Which of these has the most “natural” implementation of models and controllers? I feel that – though you are right regarding the maturity of architectural patterns like MVC – a lot of people still get it wrong (or have less than elegant, clunky implementations). I feel this is especially an issue in Javascript where the Object Oriented syntax is not…solid, for lack of a better term. I mean I know the syntax exists, but Prototype inheritance, for example, is a slightly different animal. Plus I think dynamic languages have a lot trick up their sleeves that allow you to do something fast, but confusingly (call-back spaghetti, functions w/in functions w/in functions, etc). I don’t think I’ll be a big proponent of “the serious javascript” until browsers come together and agree to implement some more recent features of the ECMAScript standard, like Actionscript has.

    • JavaScript MVC is definitely the most mature but I quite like how Spline models objects. Backbone is the most popular but it’s a very weird implementation of MVC. I agree that the solutions aren’t perfect but they’re progressive when compared to what we had a year or two ago. Let’s hope it only get’s better…


Leave a Comment