How to choose the right JavaScript framework?

JavaScript frameworks may not be the first thing that come to our mind when we think about developing the next web project. There are hundreds of functional things that we can devote our time on. Nevertheless, the topic of client-side application framework would pop, sooner or later.

Building large scale web applications is a complex undertaking and choosing the right application framework to support this endevor is particularly critical. If you’ve been following web development over the past few years, you must have noticed that JavaScript frameworks are an increasingly popular way to build new age web applications. Add to the mix the ever changing landscape of language standards, and you can imagine the reason for the existence of multiple flavors and versions of these frameworks.

Know that Frameworks are not Libraries

In order to be more precise with our decision making we must understand the basic difference between frameworks and libraries, as the term ‘framework’ is loosely used in different contexts. As an example, search ‘javascript frameworks 2016’ on Google and chances are that you will find React in several framework comparison resources - even though it is officially a library.

At a very basic level, the key difference between a library and a framework is Inversion of Control. When your code calls a method from a library, your code is in control. But with a framework, the control is inverted, i.e., the framework code calls your code.

Libraries typically focus on a narrow scope so their APIs are smaller and require fewer dependencies. A framework on the other hand tends to be wider in scope and include everything necessary to get your application up-and-running with multiple interdependencies.

In nut shell, a library is an answer to a ‘what’ and a framework is to a ‘how’. Exclude all libraries from your list.

Identify your needs

It might seem obvious, but sitting down and noting exactly how you are envisioning your application will help you understand what to look for in the framework. For example, you would want to pen down your thoughts on what type of user interface you want, what level of business workflows you are expecting, do you see a need to communicate with external systems, are you expecting any inward integrations, data storage options, APIs, versioning, tenant-specific responses …you got that. On with your thinking hat then?

Now when you have these thoughts listed, do a round of abstraction on them by putting some keywords on each item - Services, Adapters, Workflows, Queues, Two-way data binding, Templates, Multi-tenant, Multi-lingual, Cache, etc.

This keyword list will be very handy as you go window shopping for frameworks before you seal the deal.

Window shopping

To narrow down your search, find answers to three questions under each of the following five categories.

1. Industry Adoption and Support

• Who’s throwing money behind it, i.e., when and who is on-boarding, and for what type of projects?
• What is the maturity of official documentation and support?
• What are the sentiments in various technical forums?

2. Developer Experience and Productivity

• What is the learning curve for developers?
• Is it too opinionated and based on some convoluted yet-to-evolve standards?
• What type of Continuous Integration, Development and Tests tooling is supported?

3. Feature Richness and Configurability

• What percentage of the keywords you created above are catered to in one or another?
• Are features optional and can be excluded to reduce the amount of code you ship?
• How many options are available to configure native flows, to fine-tune for the required context?

4. Code Complexity and Dependencies

• Open those .js files, randomly read up the code to see how it is written. Find out if you can you tweak this code for any special scenarios (although this is generally not recommended and may breach some license clause as well).
• Browse the published API documentation, read up the embedded developer notes in code, to understand if all this plumbing is making sense.
• While scanning the code and documentation, look for a published list of external dependencies and presence of any embedded dependent libraries in the code itself. The lesser the better.

5. Future Roadmap and Extensibility

• Getting to know the would-be state is very important. There is always so much that remains undone when you write a framework. Look for a published roadmap if one exists, and any marked 'To Dos' under the hood.
• Think about scenarios where you might need to incorporate specialized libraries such as maps integration, captcha, device communication, packaging with Cordova type shells, etc.
• As technology changes fast, a framework that is not capable of evolving and incorporating newer goodies without breaking old ones would not be a safe bet. Look for extensibility hooks in the overall execution pipeline of the framework - the more the better.

The Final Call

Evaluating on these 5 categories, will help you zero-in to a few that fit the bill on almost all parameters. Now what? Which one do you choose? Here comes a bonus one to the rescue.

Flexibility

As you start hitting the boundaries and go beyond what any chosen framework was meant for, you will need the magic called flexibility. Flexibility in terms of replacing individual framework components, would go a long way. Give Flexibility a showstopper weightage in making your final selection and you will never regret your decision.