- 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.
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:
- 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.
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.
[]At this point, we’re probably one of the oldest Ember sites in production.[]
[]There was somewhat of a brewhaha around Ember on this perf. issue a year ago; of course things have gotten better since.[]