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.
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.
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.