Everything Is Bloated, Nothing Is Good

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.

33 Replies to “Everything Is Bloated, Nothing Is Good”

  1. Or in other words, think before you speak, particularly when dismissing someone else’s work… :)

    Great thoughts Tom. Perhaps the better question to ask is whether the project is focused. I think that many of the software projects that I think of as bloated probably lack focus. They’re trying to cater to solve too many disparate problems.

    1. They’re trying to cater to solve too many disparate problems.

      This is true and it’s something that’s very, very common.

      Case in point: think about a word processor in an office suite and all of the features it has. Most of those features are added because a customer wanted them. When that feature is added, it becomes bloat for those who don’t need it, and a great addition to those that do.

  2. I think context matters here. I’ve seen the rise in bloat claims myself and I’ve also been part of it, but I don’t think it has anything to do with the code itself. I think it has more to do with choosing a solution to solve a problem. Maybe bloat isn’t the right word, but it all makes perfect sense to me.

    Take a gun, for example. At 150ft from a small target, you may have the option to shoot a shotgun or a rifle. Choosing the shotgun is probably not the best decision based on how shells work. I don’t think that’s a shot (all pun intended) at the shotgun designer or those who choose to use a shotgun for [other] specific purposes. But I most definitely believe that one option is more bloated [in this context] than the other.

    That’s what I believe the discussion is about. On the lowest level of frameworks, ones made for WordPress, that’s exactly how I’m starting to see it. The more I learn about how to be intentional in theme building, the more I believe frameworks are the bloated solution for most users. I don’t think that fits into a natural cycle of hatred and blogging. I think it’s simply about knowledge and understanding.

    The bar to entry into the framework world is typically lower than it is for the DIY world, and rightfully so. But just because it’s a handy tool that more people can use doesn’t make it any less “extra.”

    Though I have no data to back it up, I feel like the majority of [WordPress] framework users have no idea how to roll their own theme. In fact, I’ve had framework experts tell me on their own that they don’t know how to build a standalone WordPress theme. The discussion of bloat, to me, is not a shot at the code or the developer who created it. It’s more about the chosen solution for solving a problem… and I think many folks end up with a bloated solution.

    1. Sean, your last comment rings so true with my experience as well.

      “Though I have no data to back it up, I feel like the majority of [WordPress] framework users have no idea how to roll their own theme. In fact, I’ve had framework experts tell me on their own that they don’t know how to build a standalone WordPress theme. The discussion of bloat, to me, is not a shot at the code or the developer who created it. It’s more about the chosen solution for solving a problem… and I think many folks end up with a bloated solution.”

      When you count on a framework to do “everything” for you (and most everyone else) you cannot avoid bloat! If you could use (or build) a theme that addressed your needs then you could avoid a lot of that overhead. Not the framework makers fault, or anyones fault – just the way I see it.

    2. I think context matters here. I’ve seen the rise in bloat claims myself and I’ve also been part of it, but I don’t think it has anything to do with the code itself. I think it has more to do with choosing a solution to solve a problem. Maybe bloat isn’t the right word, but it all makes perfect sense to me.

      Same – I’ve made claims about things in the past and I’ve worked to cut back on it mainly because of reasons I’ve mentioned (that is, just because it doesn’t fit my needs means its bloated).

      But you’re right – it’s about if the solution is overkill for what you’re trying to do. Do you need Pages or Microsoft Word to write a markdown-based document?

      The bar to entry into the framework world is typically lower than it is for the DIY world, and rightfully so. But just because it’s a handy tool that more people can use doesn’t make it any less “extra.”

      Right on.

      In fact, I’ve had framework experts tell me on their own that they don’t know how to build a standalone WordPress theme.

      :(

  3. Nothing seems to last the test of time. It’s becoming truly disheartening and tiresome spending so much time researching the latest and greatest, plugging your nose and taking the plunge, and then coming up for air just to see that everyone is moving on to the next pool.

    1. Haha, this reminds me of the Simpsons.

      “Martin’s swimming pool breaks after being full with too many children, and everyone abandons him, although Nelson takes the time to steal his bathing suit first, leaving him standing naked in the wreckage of the pool.”

      Replace “pool” with “framework,” especially of the open source variety, and I think that metaphor is apt. Too many cooks spoil the broth. The next thing starts from the previous. More copy pasta, this time from Darkness at Noon by by Arthur Koestler:

      “This process might be compared to the lifting of a ship through a lock with several chambers. When it first enters a lock chamber, the ship is on a low level relative to the capacity of the chamber; it is slowly lifted up until the water-level reaches its highest point. But this grandeur is illusory, the next lock chamber is higher still, the levelling process has to start again. […] It would be meaningless to measure the latter as an absolute height above sea-level; what counts is the relative height of the level in the lock chamber.”

  4. I think most people (who aren’t designers) have yet to realize that more flexibility often comes at the expense of complexity. There is a limit to how lean you can make a product before it starts becoming more complex, and more difficult to use. Especially if you don’t want it to start making wrong assumptions and alienate certain use cases.

  5. There are utilities etc. that are slimmed down, in the case of themes we say they are “light”. Then there are utilities that are more than a bit overweight. The Windows OS is one that comes to mind. Its a case of, coding expands to fit the memory available.

    In the case of WP themes I have the following suggestion; When somebody creates a theme, say a stripped down 2014, it be known as 2014 light. When the child theme is a bulked up child of 2014 it become known as 2014 obese.

    1. The Windows OS is one that comes to mind. Its a case of, coding expands to fit the memory available.

      I think you could argue that every OS is bloated because no one will always use the exact same tool for the job that’s provided by the OS (and sometimes we install apps that duplicate functionality that already exist :)

      In the case of WP themes I have the following suggestion; When somebody creates a theme, say a stripped down 2014, it be known as 2014 light. When the child theme is a bulked up child of 2014 it become known as 2014 obese.

      Point taken (and funny!) but no one would download obese themes or light themes because ‘light’ is associated with ‘diet’ and ‘obese’ is associated with too large.

      In both cases, some dislike the terminology. It’s hard to find something neutral but that also explicates what the product does.

  6. Bloat is very subjective as well ! Yes, as others have said it is dependent on complexity you cannot have an all singing and dancing framework in a few hundred lines of code. However, this really isnt a new argument – when I first started programming more than (ahem) 30 years ago, if your program was more than a few Kb in size it was bloated ! Complexity, and therefore size of code, always pushes (or fills) available capacity.

  7. Nothing is bloated. Everything is great.

    There is not a single thing who can resolve or explain this behavior. It’s human nature. It’s product reaching critical mass. It’s product going mainstream. It’s elitism. It’s paradox of choice. It’s many things.

    Everything is great until it’s not. For some at least.

    What matters the most is where the product is heading. What the ultimate goal is. How many happy users there are.

  8. Major issue is the learning curve of bloggers/business owners themselves.

    Most frameworks provide ton of features that are not useful on day 1 but as the blogger matures and wants to do additional things, ease of doing them through such a framework makes them love it more.

    Also, ease of use of software is the first thing that matters – bloated or not!!!

    PS: I am not a purist!

  9. Three decades ago, I remember a friend complaining how frivolous all the “improvements” were in MultiScribe GS over the existing Apple II version. The more things change, the more they stay the same…

  10. People describe things as “bloated” when those things add code to solve problems that the person doing the describing doesn’t have.

    We all see our own problems first, and only rarely think about the problems of others.

  11. Arguments about popular products being “bloated” seem to miss one important observation: that these products are being used (successfully) by millions of people every day to browse websites, purchase products, and accomplish tasks online. Perhaps “bloat” is only an issue if it prevents something from being used successfully which, in the case of very popular frameworks, it does not. So where is the problem?

    1. Arguments about popular products being “bloated” seem to miss one important observation: that these products are being used (successfully) by millions of people every day to browse websites, purchase products, and accomplish tasks online.

      You bring up a valid point, but the fact that bloated software is being used successfully isn’t necessarily the same thing as meaning the software is high quality.

      The way that Microsoft Office came to be in the state that it’s in is because of its growing customer base constantly requesting new features many of which were not applicable to other client’s.

      But in the context of software, I think that developers often want to have the leanest set of tools and libraries available. Fortunately, many tools have custom builders that allow us to pick only the components that we need.

      Above all else, though, I agree with you that “Perhaps “bloat” is only an issue if it prevents something from being used successfully” and I still stand by the idea that we’ve just gotten in this vicious cycle of love it-use it-hate it-blog it-move on-repeat :).

  12. Good points. When I first looked at WordPress I too thought it was bloated. Sometimes a client wants a standard responsive website but still have the convenience of the wysiwyg interface for updating and stress they want it built in WordPress.
    Now I know WP is a blogging framework and not really ideal for non blog sites (standard websites) but this does not mean the client is wrong to want the above scenario. This adds complexity to building the sites by hobbling WP.
    Bootstrap too is bloated if you do not need some of the stuff, but it too can be massaged to to suit your needs.
    Bloat is inevitable if time is to be saved (more often than not) and this is where both WP and Bootstrap are good.
    Most bloggers are not web coding experts and can be dangerous near WP or Bootstrap even with the wysiwyg interface. That will not stop them trying.
    The difficulty for developer/client relations is building a site that is easy to maintain and update without the need to call on coders . Alas, there does not seem to be a happy medium here. A drag & drop interface that the client can easily update as and when they need would be ideal but this requires (dare I say) a framework to be built/used…

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.