One of the things that’s becoming more and more common place regarding front end frameworks, utilities, or applications is the use of the phrase “it’s bloated” followed by an argument as to why we should dismiss it.

No, this isn’t something that’s new, but it’s something that’s becoming appears to be becoming more mainstream – at least as far as I can tell – in how people describe the tools, apps, frameworks, libraries, and other tools that they work with today, or have worked with at some point in the past.

Obviously, this isn’t to say that nothing is bloated – I mean, I’ve written enough articles on the idea on “decisions, not options” and on how things should be more focused on a single niche – but sometimes I think that we often write off certain utilities as being “bloated” when that’s not exactly the case.

Just because something has a number of features that you don’t use doesn’t make it bloated.

Everything Is Bloated

Before actually determining if something is bloated or not, it’s helpful to actually know what the term means, right? One such definition is:

excessive in size or amount.

If that’s the benchmark by which we’re evaluating software, then that’s a tough call.

  • How big should a front-end framework be?
  • In terms of kilobytes or megabytes, how big should an application be?
  • …and other tedious questions

But when it comes to bloat, I think that there are a number of definitions by which developers use – subjectively, even – to determine if something is bloated:

  • File size
  • Featureset
  • Size of API
  • Options
  • …and more

And when you start writing about whether or not something is bloated without really defining how you’re using the term, it’s hard to judge exactly what you mean. That is, I – and we – need to do a better job of qualifying what we mean by the word whenever we’re using it.

Nothing Is Good

Don’t get me wrong: there are plenty of apps, tools, libraries, frameworks, and so on (all of which will be referred to as “utilities” for the sake of length in the rest of this post :) that are bloated, but that doesn’t mean that everything that’s available is bloated.

At some point, I’ve seen many of the most popular utilities an applications referred to as bloated at some point in time. This includes things like Prototype, jQuery, Rails, WordPress, Bootstrap, Foundation, and so on.

But come on: If you think everything is bloated, then maybe you’re not thinking through the decisions that went into creating the product.

That is, don’t be so quick to write off something as being bloated simply because it doesn’t align with whatever philosophy, vision, or decision that you personally have for a project. Just because something includes an option (or set of options) that you don’t use doesn’t mean it’s generally bloated.

Being overkill for your needs is not the same as thing as being bloated.

Maybe I’m being a bit of an optimist here (and that’s rare for me), but I’d like to think that a number of the most popular utilities that people love to hate aren’t so much bloated as they are as lean as they can be while still offering features that are useful to the majority of the users.

Like Your Favorite Band

Developers are not the average user. This isn’t to say we are above average or below average – perhaps just next to average :). On a more serious note, the whole “bloat” argument that comes from a developer community is becoming a little bit trite.

Hipster Han Solo


It’s almost becoming the hip thing to do.

  • A new utility is released
  • We begin to discover it and use it and love it
  • More and more people discover it and begin using it
  • The project matures
  • It becomes bloated
  • We stop using it and hate it
  • We blog about it

And it’s the same cycle over and over. Isn’t this somewhat analogous to how we were in high school when someone else discovered a band that we thought we were the only people listening to them?

Now everyone knows them so they aren’t cool anymore. They’re sellouts.

And why is that? Is it because they’ve achieved a level of a fame or notoriety, have gone mainstream, or suddenly have the money to create records that don’t sound as if they’ve been created with a cheap set of microphones in a garage?

Perhaps this isn’t a fair example. I dunno.

Regardless, everyone has their reasons – some of which are objectively valid, some of which are a bit more subjective.

And the Point Is…?

The primary point that I’m trying to make is that I don’t believe that every utility that’s out there is bloated, and using that as a reason for why you want to avoid it is become a bit cliché.

First, I think it’s helpful to take a step back and examine how a given project reached the state that it’s in. If it’s an open source project, following along with milestones, roadmaps, and issues can be really enlightening because it helps you peek in at some of the decisions that go into why things were added, changed, or removed.

Secondly, I think it’s worth considering who the target audience is for a given utility. Sometimes, utilities that seem to fit nicely within our tool belt work great for us. For others, they may fall short (or they may be bloated). But whatever the case, there’s more to an audience for a utility than just ourselves.

Finally, many of the most popular utilities – at this point – have the ability to create custom build packages. That is, you can download only the components that you need so that the final release is tailored to your project.

At any rate, there’s nothing wrong with having a critical eye for the various things that are out there and evaluating them to see if they’re a good fit or not, but writing them off as being bloated because it doesn’t fit whatever handful of use cases you have isn’t so great.

Instead, think about the context of the wider audience, the mission and the vision of the project, and whether or not perhaps it’s just overkill for your needs.

Some things definitely are bloated. Others are just overkill for our own needs. There’s a different between the two, and we – as developers – need to do a better job at distinguishing between the two.