Skip to content

Aquent | DEV6

Generic selectors
Exact matches only
Search in title
Search in content
Search in posts
Search in pages

Don’t Burn Yourself, Use a Framework

Written by: Chad Upton

Try to think of building an application more like baking an application. The word “building” emphasizes the complexity of the process. Baking simplifies something that is actually rather complex. After all, baking is chemistry and chemistry is complex; yet baking was mastered centuries before we understood modern chemistry. Most bakers don’t have chemistry degrees and they can still bake wonderful things on the first try every single day.

That’s because:

  1. They follow the recipes of those who came before them.
  2. They make so many mistakes that they invent new recipes or return to trusted ones.

Recipes are important and getting a recipe right is much more than mixing the right ingredients — it’s also how those ingredients are combined and the volume in which they’re used. If the baker gets it wrong, they may create a foul smell or even start a fire.

The same is true for building successful applications. The easiest way to make high quality applications on the first try is by following recipes that others have slaved over. We often call these recipes “frameworks”.

Why use frameworks? There are always people who don’t want to use frameworks because they think they can do the same thing with less overhead or with cleaner code. In some cases they’re right and when they’re right let’s hope they distribute their work (dare we call it a “framework”) for the rest of us. When they’re wrong, lets hope they migrate to get the benefits of a JavaScript framework, otherwise they and their clients may be stuck with code that is bug prone, difficult to update and difficult to understand.

From taking on many projects, in various states of launch or repair, it has become obvious that the most valuable time to spend on code is by writing no code at all. Some developers and managers get anxious when no code is being written; when no bugs are being fixed; and when no commits are being made. That’s understandable, until they see first hand what it is like to work with a framework and a team that evaluates the most elegant way to solve each problem. If they haven’t experienced that, it sounds expensive and slow. But, this approach makes quality a habit, not a goal. Preventing bugs and making it faster to implement new features translates into saving money, which shortens the return on investment to days. 

When we rush to “work” by skipping the recipe, we dramatically increase the risk of burning ourselves (or our cookies). When a baker burns a batch of cookies they have to make them over again — that means they will take twice as much time and double the production cost.

Again, why use a JavaScript framework? Because following a good recipe gives us a more predictable result, in less time, with fewer fires and that improves overall quality and makes everyone happier.

It is also important to note that frameworks alone don’t solve every problem; we also need people who understand how to implement those frameworks and fill the gaps those frameworks leave open for interpretation. That is who DEV6 is — we are the people who follow recipes, fill gaps and understand problems so that we can make great applications every single day.