Dec 24, 2014

Some thoughts on choosing JavaScript Framework

If you are reading this post, I don't have to tell you, you already know there are tons of JavaScript frameworks out there. Some of the popular ones are shown down here. You may be overwhelmed by so many choices, and you want to choose a "best" framework for you killer app.

But the first question to ask is why you need a JavaScript framework? There are thoughts like No more JS frameworks. Some of these points might be valid. But what we need is to write our front-end code in a productive way, so that our application is testable, extensible, maintainable, scalable and performant. But unlike other platforms, this browser O/S does not have a base library, it does not have conventions and does not provide the facilities to do that. You may agree with "No more JavaScript framework", but you still need to achieve these goals, and most likely you will create your own JavaScript framework, convention, structure or whatever you want to call it.

Although the platform does not have the facilities you want, yet it is very open and encourages you to create your framework. It turns out, creating your JavaScript framework is fun and relatively easier, as I personally created one. But if you don't like the idea for whatever reason, you need to pick one from others.

How to pick a JavaScript framework is affected by your role and your competence of JavaScript. Are you a CTO, development manager, architect, or front-end developer, back-end developer (yeah, so cool that back-end controls front-end, who doesn't like inversion of inversion of control)? Are you a JavaScript Ninja or beginner or somewhere in between. Have you created a JavaScript( or any kind of) framework? Do you just like standing on the shoulders of giants and purely consuming other people's work?

If you don't know JavaScript...

...but are in a position to approve or reject a framework, I suggest that you don't do that. But if you really want to or even don't want get your hands on any code, you may do the following.

  1. Google which is the best javascript framework, follow the top 20 links and read them
  2. Go to the frameworks' home page and find their success cases and count their number, for example Backbone.js's success cases, AnguarJs's success cases, Ember.js's success cases. If some of these success cases appeal to you, don't jump to the conclusion to use that framework, because very likely at the time you are reading the post, the company might have already switched to use another framework. People tend to brag about their success but not failures. If people are doing something that seems to be the right choice in the beginning, and they tell you immediately, but later when they found that it is a wrong choice, they will not tell you. Five years ago, I was asked to join a company to develop an Silverlight application. This year, I was asked by them to rewrite their app based on the web platform. Two years ago, a company asked me to join them develop their killer app using b.js, and this is the same company that asked me to them to migrate their app from b.js to a.js.
  3. Use Google trend to find out their popularity. A popular framework does not mean that it is a good framework, but since if you don't know JavaScript, you should trust that a popular framework is not a bad framework if it is not the best.
  4. Since most JavaScript frameworks are Open Source projects, go to their source website. Check the number of watch count, star count, fork count, contributors, and commits. You can get the sense of how the project is running. Is it actively developed or updated only for bug fixing. If a project does not have new updates, it does not mean that it is bad, maybe it means it is so perfect that no new feature needs to be added, instead you can create your framework or extension on top of it.
  5. Find out who are the people behind the framework. If you think the people behind a framework are better than the people of another one in terms of ability, then that framework may be better (not necessarily). Sometimes, the competition is not between frameworks, but the people behind. A few years ago, I liked more Steve Jobs more than Steve Ballmer, so I just bought Apple stock, but not Microsoft. Since Steve Jobs is gone, I don't buy Apple stocks anymore.

If you have some competence in JavaScript

You should choose a framework purely based on the technical aspect. You should forget about everything from above, just like the judge tells jury that their decision should not be influenced by the media. You can do the following.

  1. Go to http://todomvc.com/, download their source code at https://github.com/tastejs/todomvc , read the source to see how they implemented the same use cases, and see if it makes sense to you. Narrow down at least three choices. Then use the three choices to you implement the the same todomvc application by yourself. You can of course refer to original source code.
  2. Go to their document website and read their documents.
  3. Implement several of the most important use cases of your project with your three shortlisted frameworks. Getting your hands dirty is very important, and your effort in evaluating the frameworks that you will end out not choosing will not be wasted. Instead, it will help your to understand your domain problem, and the technical advantage of chosen framework. Most of these frameworks or libraries require you to write your application by following a convention, which is understandable, because convention means reusability, readability, and maintainability. The framework calls your code instead of you calling the framework. While you are implementing, answer questions such as: Does the convention have a deep learning curve? Does the convention require me to write lots of boilerplate code?( You want to write code fast.) Does this convention provide extensibility and does it have too much encapsulation which prevents you from achieving some "special" but really important use case? Is it easy to test my application code? Does it provide unit test support, or am I on my own to create my test infrastructure.

If you are JavaScript Ninja or framework developer

Besides the works above, you should read their source code and have a feeling of their code quality. Read their test case, if it exists. Normally, source code with test cases has higher quality. If you have a question on a feature of your framework, you can read their documents, you can go to forums asking for help, you can read books, but the best way is to find answers in their source code and the code of the unit tests. You can even fix bugs for the framework. I find that a few popular frameworks are all created by very smart people and they have very good quality code base. Just reading them can be the easiest way to boost your JavaScript skills even if you don't choose the framework.

The end

After going through all the process above, and you feel that, let's say, a.js is your choice, it is important that you know how to take advantage the best feature of it. Equally important is to its problems, gotchas, inefficiencies and solutions to overcome them. If you know both sides of a framework, and you feel the benefits outweigh its costs to develop your application, then it is a good choice.

But this is not the end. You need to invest a significant amount of time to study your chosen framework. If you don't study enough, you might feel that framework was a wrong choice after some time down the road. The reason could be that you are not using it in its best practice. Be patient. Learn from their community, read their source code. Some frameworks are "long term efficient, short term inefficient."

If you still don't like the framework or maybe there are better frameworks coming up, you need to have the courage to admit it was your mistake and switch gears, as even Mark Zuckerberg can admit a mistake. But don't blame the frameworks. Their creators unselfishly provided them for free, and their work should be respected.

I hope you choose a your JavaScript framework that works for your projects both in short term and long term.