We recently had to evaluate some development proposals on behalf of a client for a web project of moderate scope. Reviewing the proposals and considering them in the relation to project priorities, we found ourselves weighing the matter of microframeworks vs. more comprehensive (what I will call “fat”) frameworks. I wanted to share some of our thoughts in hopes that they might help others in a similar place.

Standards and conventions

Microframeworks, arguably by definition, prescribe fewer conventions for achieving a given functionality. Advocates often consider this freedom a virtue, however strong conventions make it much easier for any other developer to understand and become a productive contributor to your codebase.

Mitigating dependency risk

When using a fat framework, you generally end up relying on fewer libraries. Every dependency is a liability: you never know when something might fall out of maintenance, or when a maintainer might choose to drop compatibility with your framework version or some of your other dependencies. In practice, you end up having one major dependency to keep up with (the fat framework itself), but this is much easier to keep on top of than dozens or hundreds of third-party dependencies.

Fat frameworks like Ruby on Rails also provide mature and well-documented faculties for many peripheral application needs (think things like previewing emails, securely managing credentials, seeding the database). Every peripheral need of this sort would, with a microframework, end up necessitating either some fully custom solution or the integration of a library/tool that would be yet another dependency to document for present and future collaborators. There are also more core application requirements like caching and background job processing that have excellent first-class solutions in most fat frameworks but that you might be left to sort out for yourself if working with a microframework.

Deployment, hosting and tooling

One of the great things about building with a fat framework is that infrastructure dependencies are usually relatively homogenous and known. This means that many PaaS providers have great out-of-the-box solutions for hosting your application. You should also have a reasonably easy time sourcing human experts who can help in this area if that is what you want.

Insurance against abandonment

If you, as a non-developer, have a relatively conventional application in a fat framework like Ruby on Rails, Django or Laravel and your developer decides to disappear into the ether, you likely won’t have too hard a time finding somebody who is able to take over the project and be productive quickly. This is much less likely to be the case with a microframework. While you will certainly be able to find developers familiar with Flask or Gin or Sinatra, whatever templating libraries and whatever frontend libraries and tools might have been used to construct your app, any new developer will likely have a much higher burden to take over the codebase and become productive. They may even push for a rewrite.

These are things I generally keep in mind when selecting a framework. It is not at all to say that microframeworks don’t have a place. They certainly do – for instance in narrowly-scoped services and narrowling-scoped applications exposing simple interfaces. There are also circumstances where performance, memory requirements or niche needs like the ability to hold open tens of thousands or millions of connections on minimally-specced hardware recommend microframeworks. For typical web applications with teams of 1-100 developers, however, I think the case for fat frameworks is strong.