02.27.165:13 pm
Back

MVC vs. MVVM: Pros and Cons of Single-Page Applications

By: Irina Abramson

There’s been a ton of writing on the subject, so while I can’t say anything unique, I’d like to post this for a discussion, both internally and with our clients.

Historically, we’ve been going with MVC most of the time, especially for MVPs, where time to market and low cost is of an essence.  However, MVVM presents a few advantages when you are building for years to come.

I like MVVM better than MVC in a form of complete isolation of FE from BE: run a RESTful API server with whatever back end platform there is (Ruby on Rails, Node.js, Java, .NET or Django) and a completely separate JavaScript application (Backbone.js, AngularJS or React) running off its own Grunt or Gulp build system. Here’s why:

  • Ease of setup for a UI engineer: no need to mess with VMs or any other complicated local configuration.  This is especially handy for Mac-loving UI engineers having to work with .NET back ends.
  • Ease of resource allocation: we can swap or add new UI engineers if we have to, without any ramp up time for server-side setup.
  • Front end can run anywhere: same server as a back end, independently on a static server (think scalability), or locally.
  • Back end can run anywhere: on an office server, in the cloud, or locally. Even better, you can simulate one with static JSON files.
  • Better long-term performance: once you download all the assets (HTML/CSS/JS/images), your only HTTP traffic is data.
  • With this architecture, API server is already in place if you want to build a mobile app down the road.

Unfortunately, SPAs are not without disadvantages:

  • More effort to build: you have to duplicate some of the business logic both on the server and client side. You have to have a budget, which makes it less appealing for MVPs.
  • Longer initial page load time: you have to download all the front end application code upfront (JavaScript libraries, HTML for hidden modules, etc.)
  • Automated testing is more complicated: you have to take server response times into account. 

Conclusion: If you are building a large project that will be around for years to come and requires both front-end and server-side developers to build and support, with the possibility of a mobile app addition, consider MVVM. If you are building an MVP where the focus is low cost and quick time to market, go with MVC.

What do you think?