Engineering

Frameworks, Frameworks, Everywhere

Whether you are a developer staying up-to-date with the latest trends, or a product manager looking to make sure that your app is built atop a stable and future-facing foundation, your starting point for research is “The Framework.” Backend frameworks, frontend frameworks, data frameworks—there are frameworks for everything, but unfortunately, the landscape has become so muddled with misguided buzzwords and misnomers that you might as well expunge “framework” from your technology vocabulary.

Understanding the stack

Developers like to break down software into different layers (“The Stack”) because it’s good for organization, allows software components to focus on one thing (and do it really well), and it encourages easier swapping of different components to suit the given project. Some developers prefer a unified “full-stack” approach where a few large components address every layer of the application. Others prefer more lightweight layer components that can be swapped in and out and can be “glued” together to produce a complete stack.

While the stack is critical for producing modular and consistently-structured applications, it is also the reason for confusion about frameworks. All frameworks tackle the stack differently, yet typically condense their mission statements down to one or two uselessly vague (or incorrectly applied) phrases. Backend framework. Frontend framework. These phrases are typically meaningless, and only give you a hint at what the software actually does:

  • “Frontend framework”: Is it a theming framework like Bootstrap that gives you a set of standardized CSS classes to use? Or is it a full presentation layer that actually renders all of the visual components?
  • “Backend framework”: Is it a wrapper around a database that makes it easier to execute queries? Is it an ORM? Is it an API server? Is it a content management system?

Incomplete stacks shortchange you with poor abstraction

Since inconsistent use of the word “framework” obscures what a software component actually does, it leads to developers relying on components that aren’t the best tools for the job at hand.

Imagine you are trying to build a website with forms for managing a few types of e-commerce records: customers, products, orders. Now consider using a scaffolding-centric “web application framework” like Rails, ASP.NET, Zend, CakePHP, etc. You might think to yourself: I’m using a framework! I’m good-to-go! You scaffold your code, start wiring up your data model, and everything is working well.

But now imagine that you now need to add additional record types: shipments, returns, feedback, discounts, vendors, catalogs, etc. Let’s say you have 50 new types of documents to manage. Or imagine that you’ve already written the code for 50 kinds of CRUD forms, but you decide that you want to change your view-layer implementation. Hopefully you didn’t make any enhancement to your scaffolded code, because you’re going to have to regenerate all of it.


Every new feature you wire up with your ill-suited framework incurs an additional linear cost as you toil with CRUD forms and MVC boilerplate code.


Scaffolding and coding conventions may make it easy to add/modify one data type, or even 20, but now you’re playing the game of diminishing returns—every new feature you wire up with your ill-suited framework incurs an additional linear cost as you toil with CRUD forms and MVC boilerplate code.

Your framework, it turns out, is not really covering the entire application stack that you ultimately needed. Your sample application has components of an e-commerce system and a content management system, yet you are stuck with generic web application MVC frameworks that offer you no useful higher-level structuring. You are “recreating the wheel” with every new feature that you add.

The key piece here is “abstraction”—the representation of complex functionality through simpler directives. Abstraction is important because it allows you to distill complicated—and often repetitive—code from your workflow. Many frameworks pitch “convention over configuration” as the end-all solution for efficiency in developing new features, but that “convention” often means merely scaffolding, with no attention paid to abstraction. This kind of meticulous code generation leaves you stuck maintaining boilerplate code. Naïve conventions simply do not scale well as a function of a programmer’s time.


“Framework”: I do not think it means what you think it means

It’s often called a… But it’s more like a…
AngularJS Web application framework Model-view binding, routing and templating engine
Backbone.js Web application framework Model-view binding, routing and templating engine
Bootstrap Front-end framework CSS/JS styling and layout framework
Express Web application framework Lightweight HTTP server with routing and middleware
Knockout Web application framework Model-view binding and templating library
jQuery Front-end framework JS frontend utility library
Node.js Web application framework Web application runtime environment and platform
React Front-end framework View flow/rendering engine
Ruby on Rails Web application framework Web-application MVC scaffolder, routing and middleware framework


It takes a community

The motivation for this post is the growing number of nonsensical “top framework comparison” articles that pit, e.g., jQuery vs. AngularJS, AngularJS vs. Wordpress, or Wordpress vs. Node.js. These comparisons make no sense, provide no insight into the purpose of each piece of software, and often imply false mutual exclusivity. Sometimes it’s okay to compare apples and oranges (if you’re talking about your favorite fruit)—but in the case of these frameworks, there is no such common ground if they are targeting different parts of the stack.

It’s up to the community of developers at large to stop with the framework madness and stake a specific claim about which part of the stack their software applies to. It is counterproductive to boil Bootstrap down to a “frontend framework,” so it is the responsibility of all developers to make sure that they are describing their projects clearly and precisely.

Getting back on track

The first and easiest solution is to throw out the phrases that are uselessly vague—the obvious primary candidates being, of course, “backend framework” and “frontend framework” (with “application framework” close behind.)

Next, developers should use more focused language when describing what their products do. Some simple examples:

  • A “frontend” framework that is actually focusing on styling and layouts is better described as a “presentation” framework.
  • A “backend framework” should clarify whether it is tied to one database or is agnostic, whether or not it exposes an API, whether it has a web interface, etc.
  • An “application” framework that really just offers MVC scaffolding, should cut to the chase and acknowledge itself as an “MVC scaffolding framework.”
  • A “framework” that offers no logical or organizational structure for an application is most likely not a framework at all, but a library.

That is not to say that there is one official set of layers for web application stacks, or one interpretation of whether a given software package fully covers one layer or another. The end-goal is simply to eliminate ambiguity and discourage false comparisons between sets of software that are not actually targeting the same parts of the stack.

Choose your stack wisely!

The confusion around frameworks highlights the importance of understanding the stack components that you or your developer has chosen, and whether the software foundation is able to abstract everything that you are trying to do. Consider: automating repetitive tasks is good, but consolidating (mostly) identical tasks into one is even better.

Depending on the scope of your project, using an incomplete stack—and then resorting to custom code hacks to get you the rest of the way—will often be the deciding factor in whether your product is able to grow past its proof-of-concept.