skip to Main Content
4 Important Considerations For Framework Selection

4 Important Considerations for Framework Selection

When discovering a new framework, it is easy to ignore other libraries or solutions as we sit transfixed by the dazzling lights of our shiny new toy (my precious…). Sometimes one framework might trump another in all or almost all cases, but it’s important to know what kind of measuring stick to hold up against these different options. When evaluating a new framework, I usually like to focus on four considerations.

  • Speed
  • Readability
  • Flexibility
  • Community

Now, some people may be wondering why robustness is not on the list, given it is one of the factors most organizations value. The definition of robustness varies widely between most firms and firms must constantly weigh the advantages of sticking with popular, time tested framework vs exploring newer, less tested frameworks. Later in this article, I also walk through why community is a significant factor in a framework’s robustness.


The speed of a framework really has two sides. Speed of development is absolutely important, because a user doesn’t know how long it took to make something, nor should they care. If it takes an extra month or two to develop before deploying a project, that could mean tens to hundreds of thousands of dollars depending on the team size. On the other side, the end user should and will care about how quickly and smoothly the app runs. People are becoming far more impatient, so a ‘laggy’ app can lose users before they’ve even had a chance to experience its features.


Readability may seem like a strange term to describe a framework, but first think about how much time is spent reading code that someone else wrote (sometimes months if not years ago). This can be largely dependent on who is actually implementing the framework, but each framework has a fundamental organization that lends itself to making its inner workings easy to divest. Some people like the ng tags and controllers in Angular applications, and I love the way a React component can have all of its markup, functions and styling in one place, or it can be separated into a logic container and a markup component. The important thing to remember is that many people will be reading through the code in the near future. In the Book, “Clean Code”, Robert C. Martin claimed that the ratio of reading code to writing code is 10 to 1, which should illustrate just how important this aspect of a framework can be.


The level of flexibility in an application leads to either surprisingly easy fixes and feature additions or painful workarounds and overload of dependencies. If a framework already has too strong of an ideology on how an application can be built, it might not fit your current use cases, or it might not have a good way to add features you hope to implement in the future. Think of having someone lay down the foundation of a house for you, but they make all the walls out of solid steel. You may ask, ‘What about the windows’ and they just respond, ‘You shouldn’t use windows. Look out how strong it is!’ A framework can be reliable, fast and well supported, but if it doesn’t account for your desired implementation, it’s not right for your project.


Finally, communities that actively use and improve upon a framework or library are indispensable. Years ago, when I primarily used Ruby on Rails, I started sampling JavaScript frameworks like Backbone, Ember, Angular and React. At first I became frustrated at the numerous tutorials and articles that all used a Node/Express back end, but I came to accept that the people most experienced with and enthusiastic about JavaScript frameworks would obviously be JavaScript developers. Making sure that a framework or stack has an active community can save a lot of time when encountering an unusual error. Frameworks like React and Angular are especially strong in this regard, as they have huge open source communities coupled with huge tech companies backing them up. One last thing I wanted to bring up, and this is highly debatable, is that I don’t like seeing frameworks that use a lot of ‘magic’. By ‘magic’ I mean automated routes or tasks that can make work faster an easier. This doesn’t seem like it would be a problem, but it leaves me with black boxes that can sometimes be very rigid in what they will accept or do. What I mean is that it is far easier to understand what is going on and fix issues when the inner workings of an application are exposed. I used to love Ruby on Rails for its magical scaffolding that auto generated migrations, forms, models and controllers, but your application can crash and burn from nothing more than a typo in a file name, or you can spend exorbitant amounts of time tracking down the path that data from the server takes just to see what’s going on. Rails conventions make development lightning fast and reduce verbosity, but it can lead to readability issues when another developer is tracking down the source of an error. This is one of the reasons why I quickly grew to love Express.js for Node. I could very clearly see how every module related to one another and had no worries of inadvertent side effects. My final say on magic in frameworks is that it can be great, as long it is a very small team and every developer is extremely experienced with that particular framework.

Ultimately, the technologies you choose should be based upon your particular use case as well as your current and future goals. This means that you might have factors to consider other than the ones mentioned above. The most important thing is not to get blinded by unfounded bias. Ruby developers are usually going to tell you that Ruby is the best option, just as Golang developers are going to tell you that Go is superior. You can take every factor into account when deciding on a stack or framework, but that means nothing if you’re overselling the ones your most familiar with. There’s really no substitute for staying plugged in to the various communities and looking at real data.

The four selection criteria I adhere by is something that I’ve cultivated through multitudes of client engagements, but it’s important to recognize that different use cases may require additional criteria. An example would be government work that requires highly vetted frameworks with tech that is widespread enough for the internal technicians to manage. As modernization continues to be a priority for many larger organizations, framework selection will increasingly become part of the discussion. In just the last quarter, we’ve seen five larger clients request technology reviews – and for good reason. See how our approach to technology modernization is driving change for our family of clients.


Back To Top