Should I build an MVP using a client side framework?
Regards ♨ – Minimul
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".
3. The CSF approach is interface overkill for 98% of MVP ideas.
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.
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.