Skip to content

Off-the-shelf front-end frameworks

Frameworks can be useful but it’s good to be wary of using them, especially by default. They come with a set of pros and cons.

It helps to think about the problem we’re solving by using a particular framework. Here are some important questions to consider. How light or heavy it is for our users? Will it be maintainable for our team to use? Do its values and choices match ours?


Front-end frameworks:

  • can make complex things simpler (so it frees up time for solving other problems);
  • are often well maintained and well tested (so we don’t have to test it ourselves);
  • can speed up development time in the short term (because a lot of work is already done);
    • can speed up development time in the long term (because it becomes familiar);
  • come with built-in design and development decisions (taking the responsibility for that off of us);
  • have a clear set of rules or way of doing things (which can make communication about components easier).


Front-end frameworks:

  • add a dependency to our project (meaning another external resource to worry about);
  • can be painful to upgrade, especially if we’ve made customisations (so we either have to stick with an old version, or have to update lots of our code);
  • can be overkill for the problem we are trying to solve (something smaller and lighter could work better);
  • can have a steep learning curve (we have to learn how the framework approaches solving the problems);
  • are solving someone else’s problem (which might not be the same as ours).
  • are someone else’s opinions and approach (which might not match ours now, or in a few months’ time)
  • can have a generic look and feel to it, even though most are customisable (so our site looks like others using the framework);
  • don’t always follow best practices for HTML (such as not using semantic elements, being verbose, or not baking in accessibilty);
  • don’t always follow best practices for CSS (like selectors with high specificity, using rules like !important frequently, and size of stylesheet);
  • don’t always follow best practices for JavaScript (like testing for support of features before using them, or having a no-JS version for failure cases);
  • have large CSS and JS files since they are a catch-all solution (which means that pages load slower and use more of our users’ data).
  • can be not as flexible and modular as as custom solution.


It’s best for us and our users to roll our own framework, but learn from the others. Bootstrap, Foundation, and other frameworks provide good starting points.

We need to think about the cost of using a framework against the benefits it provides, especially the cost to our users. The best way to have a tool that fits best is to write our own. We can make this small and modular so it will be fast for us to use and light for our users. Since it will match our opinions and processes, it will be more maintainable.