Determining Whether Client-side MVC is for You

I’ve been meaning to write down my thoughts on Javascript MVC frameworks for a while now. Ever since we rebuilt the Square merchant website with Ember1, we’ve added major new sections to the webapp and gotten a better understanding of how an MVC app would be built and maintained with multiple engineers across multiple teams.

Currently, my thinking is that while rich Javascript MVC frameworks aren’t necessarily a silver bullet, they’re still excellent for a lot of use cases and the downsides shouldn’t preempt new projects from trying them out.

The virtues of Javascript MVC frameworks have been espoused for a few years now, but it’s worth going over some of the less-obvious benefits:

• Testing Javascript is easier when the M-V-C parts are well-defined and separated. Presuming a need for some Javascript for interactivity on the site, the added level of structure allows for unit and cross-module tests instead of having to always rely on full-blown acceptance/integration tests on the browser with Selenium et al.
• Making a JS client leads to building/reusing an API. Anecdotally, it’s pretty easy for the “VC” side of a server-side MVC framework (e.g., Rails, Django, etc.) to discreetly mingle view data for that one controller and get out of sync with the API’s data rendering. This may not be an issue when the project is new, but it quickly becomes a nuisance as a project matures and becomes the source of consistency bugs.
• Subtly, MVC frameworks dampen the discouragement from building complex pages with interdependencies between parts of the page. Having built a settings page with simple jQuery callbacks + JS objects and then turning around and doing it in Ember, the Ember version took longer up front, but allowed for new sections pretty easily afterwards. The plain version was faster to start, but was awash in hidden technical debt which had to be addressed with every update.
• For larger teams, settling on and using a MVC framework provides a common standard. Plain Javascript offers few conventions, and I (like most JS developers who tried to write structured code before these frameworks sprung up) went through a phase when I essentially set up proprietary systems in the JS + DOM. It sounds cool to roll your own, until you have to turn around and teach it to whoever needed to make updates.

Alas, there is no free lunch, and so to figure out whether it makes sense to use a client-side MVC framework, consider the some of the costs:

• Chances are, you’re giving up browser-side caching with every app update (assuming concatenation + minification). Of course, your browser is downloading and parsing a lot of Javascript code, and it can affect performance when the framework adds its bookkeeping to your code2. Performance versus developer productivity is the classic tradeoff.
• There is the added cognitive load of understanding the framework for new engineers, front-end and back-end alike. There’s still a tendency to treat client-side web code as “just Javascript”, so the complexity of the code and its conventions catch new contributors off guard.
• The engineering costs are front-loaded: it takes a lot more work to get an app up-and-running, and though the payoff will come when the site gets to a certain size and complexity, it requires substantial effort to get over that initial hump and set up the modeling logic, syncing behavior, view hierarchy, routes, etc.
• Performance and error reporting is possible, but extremely noisy given the uneven nature of Javascript interpreters across browsers. Even if you get around the problem of reading production’s minified code (via source maps), a lot of exceptions aren’t going to make much sense, seeing as Javascript runtimes do not do a good job of being specific with their errors. Outside of testing every browser during development from inception, there will likely be a class of errors that you simply let live.

All that said, I do think that current MVC frameworks fill a needed role for small-mid-sized web apps benefit from the added structure but are stable enough to not demand biweekly pivot-level rewrites.