Full-Stack frameworks vs. Non Full-Stack frameworks

This post is part of a series of posts on Client-Side Web Application Development using JavaScript.

Full-Stack, Non-Full-Stack & Macro-Framework, Micro-Frameworks

Another useful but orthogonal classification in the JavaScript Framework world is Full-Stack Frameworks and Non Full-Stack Frameworks. From here on I will be using the word framework to denote both Frameworks and Libraries.

Full-Stack Frameworks are ones that help us with the full development stack from the user interface till the data store.

Anything else is a Non Full-Stack Framework. In the Non Full-Stack frameworks if the framework / library is less than 5k in size then it is called a Micro Framework. Micro Frameworks usually do one thing and do that one thing very well.

So the choice really boils down to using a plethora of Micro-Frameworks and handling the integration issues yourselves or using a Full-Stack Framework which handles the integration itself.

Modular or a Monolith

You can further classify the Macro-Frameworks (another term or Non-Micro-Frameworks) as modular frameworks or monoliths. A monolithic framework is one where you cannot swap out the Framework’s implementation for a Feature with an alternate one. For example Rails 3 is modular whereas Rails 2 was a monolith. A lot of JavaScript Macro-Frameworks are towards the monolith side of the spectrum (Personal potentially biased subjective view – a lot of you may not agree with this). May be this will change in the future as people learn. dojo, which is the oldest JavaScript Macro-Framework is highly modular. But hey it is not cool, because it is old .

In reality it is not a binary (modular vs. monolithic). Some of the features might be hard baked, whereas some of the features may be pluggable. For what I mean by this see Steven Sanderson’s table given below in the samplings section.

 

Factors that go against Full-Stack Frameworks

• Size
• Average in what they do (A micro framework may do the same task in a better fashion).

If you are from the .NET Community think of this distinction as something akin to using Visual Studio Team Foundation Server for everything from Requirements Management, WorkItem Management & Tracking, Source Control, Build Container, Issue Management or use specialized but powerful tools and integrate them yourselves. The best example I can think of is comparing the source control system that comes with Team Foundation Server with git. They are no match. But you see the point.

Factors that go against Micro-Frameworks

• When you use multiple Micro-Frameworks some of the integration code that we write to integrate them comes from belongs in the Infrastructure space. If we had used a Full-Stack Framework that would have provided this Integration Infrastructure code for free.
• The other issue being different Micro-Frameworks may not be compatible with each other. So you as an application developer will have to make sure that they can play nice with each other.
• Quite a few of these Micro-Frameworks may not have a huge community associated with them. What if the developer gets busy with other things and is not interested in maintaining the framework anymore.

Sledgehammer for a thumbtack?

A frequent argument that leads people to choose a Micro-Framework is that we only need Feature X which is provided by this Micro-Framework. We do not need a monster of a framework that provides Feature X, Y, Z…. What if the application evolves?

 

Key Parameters

So the key parameters here are

• Is it an Enterprise Web App or a Web Site?
• If it is a Enterprise Web App then can we assume, We can afford slow load initial load times for first time visitors. Subsequent visits are going to be faster. Consider the initial load time as that of something like a installation time.
• If it is a Web Site, Are most of your users repeat users? Can we afford slow initial page load times for first time users? Is it like Twitter or Facebook which you use day in and day out or is it a one off e-Commerce website where the # of first time users are more and repeat users are less?
• Do all the pages uniformly need all the features from the Framework you have chosen?Page 1, 2, 3, …n – Feature 1,2,3, … m
• Or is it like each page is unique in terms of feature requirements?

  Page 1 – Feature 1, 2

  Page 2 – Feature 3, 4

  Page 3 – Feature 1, 5, 6, 7

  Page n – Feature k, l, m

• Is your website small and do you need only a select few features? Where will your small website evolve to in terms of feature requests?
  

   

  Sampling

A sampling again from Steven Sanderson’s blog entry

	Views	URL routing	Data storage
AngularJS	Built-in DOM-based templates (mandatory)	Built-in (optional)	Built-in system (optional)
Backbone	Choose your own (most used handlebars.js, a string-based template library)	Built-in (optional)	Built-in (overridable)
Batman	Built-in DOM-based templates (mandatory)	Built-in (mandatory)	Built-in system (mandatory)
CanJS	Built-in string-based templates (mandatory)	Built in (optional)	Built in (optional)
Ember	Built-in string-based templates (mandatory)	Built-in (mandatory)	Built-in (overridable)
Knockout	Built-in DOM-based templates (optional, can do string-based too)	Choose your own (most use sammy.js or history.js)	Choose your own (e.g., knockout.mapping or just $.ajax)
Meteor	Built-in string-based templates (mandatory)	Built-in (mandatory?)	Built-in (Mongo, mandatory)
Spine	Choose your own string-based templates	Built-in (optional)	Built-in (optional?)

Credits:

I was reading some interesting community debates on this subject, so not every sentence that I have written is patented by me. Giving the credits where it is due, these are the links that I read through (I scavenged these from my memory – Chrome bookmarks).

http://tomdale.net/2011/04/imagine-a-beowulf-cluster-of-javascript-frameworks/

http://mir.aculo.us/2011/04/11/i-for-one-welcome-our-new-micro-framework-overlords/

http://blog.stevensanderson.com/2012/08/01/rich-javascript-applications-the-seven-frameworks-throne-of-js-2012/

http://www.slideshare.net/rmurphey/the-jquery-divide-5287573