Should I build an MVP using a client side framework?

Today there are two main approaches to building a new web application: (1) Process and serve the application with a server-side framework and then use jQuery/Javascript to enhance. I am going to refer to this approach as SSjQ (server side with jQuery); (2) Backend is a Service Oriented Architecture(SOA) that serves JSON to a Javascript client on the browser. I will call this 'CSF' (client-side framework).

The merits of these two approaches have been widely debated and in a recent article, author Dan Gebhardt responds to some anti-CSF sentiments within the developer community. He concedes that the CSF approach is not the optimal way to build a minimal viable product (MVP). As a freelance business consultant, this statement interested me the most, as new (or Greenfield) software projects can be a large part of the value we provide.

Most new software projects are MVPs.

Whether it is a startup wanting to disrupt an existing "space" or a Fortune 500 company desiring an internal app to help the accounting and marketing departments collaborate on shared reports, most new projects should be delivered as soon as possible and then iterated upon. Since any new project is risky, it should be released quickly with a tight feedback loop to follow. I think the conventional wisdom is that an MVP is just for startup business ideas. Rather, however, it is basically the same as 'release early and often' with perhaps some small other particularities.

Can CSFs solve the jQuery soup problem?

I have been diving deep — almost exclusively — into the CSF approach to building apps for the last month-and-a-half. I am taking a few months off from consulting to level up on some different tech, and CSFs are at the top of my list. I am curious to find out if CSFs may offer a better way to organize the usually large client-side front-ends that I have observed on my projects. To a lesser degree, but also factoring, is the potential benefits of a backend SOA architecture.

I have gone through a ton of screencasts from Peepcode, Metacasts, Railscasts and Ember 101. This includes presentations such as Jerod Santo's Angular demonstration. I have investigated many CSF samples including Dan's informative github example app. I have focused my research on what 'seems' to be the "Big 2" CSFs, Ember and Angular.

4 Reasons why you should use the SSjQ approach for your next MVP.

After all this research I am recommending that my clients aspiring to build an MVP use the SSjQ approach for the reasons listed below. If your idea or project requires "extreme" levels of interaction and must rival desktop software in this regard, it may be that CSFs are a better approach but I can't state this for certain.

1. Building an MVP with a CSF is complex and the ecosystem is immature.

Personally, I have found learning CSFs to be challenging in a way that I cannot recall with any other new technology that I have ventured to become competent with. How exactly is beyond this article's scope, but I would concur with the many others that have had the same experience. In addition, the poor tooling and general lack of maturity is a major issue considering the SSjQ juggernaut with all its sophistication and cultivation. Listen to 'seasoned' Ember devs bemoan the same things on episodes 2 and 3 on the Ember on a Hot seat podcast. At this point I am not even close to being productive in CSFs beyond the basic stuff. This wasn't the case when learning Rails. Like Hampton Catlin, I have yet to have an 'Aha!' moment as I did with Rails.

2. SSjQ is a mature, "well oiled machine".

Doing a form with a 100 plus input elements? All of the them having crucial validations associated? That are deeply integrated with eight different back-end persistence models? Need automated tests exercising the whole thing from high to low? No problem with Rails or Django. We have been doing the server-first-and-Javascript-after thing for so long, the patterns and practices are mature and app development is fast. At this point in history, CSFs can be best classified as R&D.

3. The CSF approach is interface overkill for 98% of MVP ideas.

Look, most MVP's are not going to be requiring massively high levels of interaction, such as a 'Photoshop online' kind of idea. I dare to say that a lot of MVP's don't even need any Javascript at all for the first release. I remember hearing Garrett Dimon say he had like no Javascript(paraphrasing) in Sifter's early versions. Wasn't that one of the problems with Flash and Java applets? Interface and animation overkill on the application user experience where it is not needed. Once a MVP is released with the fast and mature server side technologies you start adding jQuery to enhance user interaction of pages that are frequently used. The key phrase is 'frequently used'. The settings, maintenance, and reporting sections of the app that will not be used regularly can use good'ol Web 1.0 technology and nobody is going to complain. In fact, users have been trained now for years in the brower request-refresh-response cycle and have no problem with it. There is no argument that user experience is profoundly important, but Javascript can incrementally deliver great experience to frequently used sections of an MVP.

4. SSjQ apps are not as 'soupy' nowadays thanks to pre-processors

I too am concerned with disorganized client-side code but the state of the union for SSjQ apps is much better in 2013 due to pre-processing.

Just like CSS styling was 'saved' by pre-preprocessors like SASS and LESS, similarly, SSjQ built apps are greatly aided by pre-processors. In this way, Rails 3.1 (asset pipeline) was more important than Rails 4 with respect to SSjQ apps.

One thing that I like about CSFs is that they encourage/force the use of separate directories and files for models, controllers, and templates. This is part of their promise: do to the front-end what Rails did with the backend in forcing good practices. Aside: The jury is still out on whether CSFs can solve the front-side good practices problem, as the most mature of the CSFs, Backbone, is now panned for its inability to handle the needs of complex apps and leads to a 'Backbone soup' of sorts.

But nowadays with tools like Sprockets and Grunt it is easy to separate your Javascript into different logical directories and files. I recently worked on a Rails project in where all the developers were creating smaller Javascript files without anyone setting down a directive. The app was started in the Rails 2.x days and had the typical (of the time) large monolithic application.js file. This small distinction of creating specific and descriptive Javascript files reaped quick rewards with respect to getting the client-side code maintainable and extendible.

Lastly, Coffeescript, with its support for the classes, inheritance, and super by the class keyword makes it easy to apply the familiar class pattern present in most other languages to our client-side code, improving design and management.

When building MVP's the CSF approach could be the future.

Dan Gebhardt and the many others involved in CSFs are pioneers and we need these guys and gals to push forward with the promise of CSFs and backend API architectures. I will continue to monitor and learn from these trailblazers in an effort to provide the most value to current and new clients. That said, at the time of this writing, I recommend the SSjQ approach to be used to deliver the MVP as soon as possible followed by adding Javascript-built enhancements to the frequently used sections.