How to Choose the Best Front-end Framework

The JavaScript world is a rich environment with dozens of tools, libraries, and frameworks. But, with lots of options comes a lot of confusion. It really is a double-edged sword.

While you get lots of space for creativity and experimentation, sometimes you are unsure about what library or framework to choose.

The front-end framework you choose can make or break your project on the long run.

In this article, we will look at some of the most popular JavaScript frameworks, and how they fare against each other. We’ll examine five different perspectives of these frameworks, which generally eases the process of making a decision about your next JavaScript framework.

Whether you are choosing from one of these popular JavaScript frameworks, or from something more esoteric, you should take each of these aspects into consideration.

Availability of Learning Resources可用的學習資源

This one is obvious but oftentimes overlooked. While the fancy home page of some framework might catch your eye, you still need some additional courses, books, tutorials, and articles besides boring and dry documentation to help you get started.

Creating an awesome framework is one thing and communicating the core ideas behind it is different. In fact, there are many professional developers out there who specialize in coaching. A well-crafted learning resource will dramatically cut your learning curve.

Go look for resources from trustworthy authors you have previous experience with—it will be worth your time in the end. If you struggle to find something useful, be cautious: The framework you are trying to learn might be new, or not well adopted yet by the community.

Although I mentioned that documentation alone is not enough, there are exceptions to this. EmberJS, for example, has great documentation. Core features and use cases are nicely described with generic examples here and there. Unfortunately, besides the documentation, we are left with few resources books, video courses, or other materials.

On the other hand, there is an abundance of resources for Angular and React. Almost any front-end oriented educational website will have an article or two about them, maybe even full video course or book.

Vue kind of hits the middle ground: It has good documentation and there are a few nice courses you can choose from.

Aurelia, for example, has almost zero resources; the only hope for you is documentation and luck.

I prefer having choices.

Even if you read a great book or course, there is a chance you’ll learn something new by exposing yourself to different resources. If you are familiar with the subject, oftentimes you can skim through and seek possible areas that are not quite clear yet.

Unfortunately, this strategy won’t work if you are limited with your options, which lead us to the next point.

Popularity 流行的

You might take pride in learning something exotic, but if you look at this from a business perspective, it is not the same. Your company or client probably prefers a battle-tested toolset to be used.

There are several reasons for this. If a framework is not so popular, it means there are a few developers who specialize in it. What happens if you abandon the project or find a new job? Your employer ends up being stuck in searching for a developer who knows the framework you used.

This process might become a real burden for a company. The same thing holds true even if you stick with the project and it grows. Now the employer needs more developers to accelerate the development.

There are some other personal reasons why you might opt for a popular, widely-used framework. What happens if you find yourself stuck with some problem and there are isn’t really a community that you can ask for help? Since you are on your own with documentation, chances are you’ll waste a lot of time.

Besides that, you want to think about future, more appealing opportunities in your career. If you specialize in something popular and get really good at it, there will be a lot of projects out there for you.

Obvious leaders here are Angular and React.

Most front-end related job listings out there require one or the other. They are backed by Google and Facebook respectively, and therefore employers feel “safe” about their choice.

Sometimes, the choice of framework for your company or client is not up to you; maybe it was made by a previous employee or some other person on the team. Chances are it will be Angular or React. Now there are other options out there like Ember and Vue. But, you’ve got to deliberately seek out companies using them.

You can determine the popularity of a framework by quickly looking at how well the project is doing on GitHub and other places. Here are some statistics collected as of writing this article:

Although these libraries have existed for long enough to prove themselves as popular options, if you are trying something really new, similar statistics for them may help you make the choice.

Learning only Angular or React will only get you so far in your career. Of course, you’ll have plenty of opportunities, but there is a reason other frameworks exist out there. Try to learn about them in your spare time and occasionally do some experiments. Even if you never use them in real projects, you’ll gain valuable insights that help you in your day to day development work.

Core Features 核心特性

Let’s get a little bit technical now.

At the beginning, you want to briefly overview the core features of the framework to have an adequate expectation when you’ll start coding. For that purpose scan through the documentation. You need to get a sense of what this framework is about in general. Is it a view layer only, fully fledged, or something in between?

If you have rich previous experience with other frameworks, this process is easy and quick. Look for the following topics in the documentation: templating, state management, HTTP communication, form processing and validation, and routing. Those are everyday things you do as a developer. Not all of these may be presented in the core framework, or there might be some different approach to a particular problem.

Let’s touch on popular options briefly.

We’ll start with React and Vue. They are not really frameworks; they only represent the view layer of your application. It means all the other parts—HTTP communication, form validation, etc.—are up to you.

As I’ve mentioned earlier, it might be a double-edged sword. Eventually, you’ll end up building your own custom framework. Both of them have their ecosystem of libraries to provide solutions for the most common problems, but the overall structure will vary from project to project.

React’s JSX always made me cringe. I had to get used to it. However Vue’s templating is really nice, especially if you are coming from Angular.

On the other hand, Ember has almost everything. Surprisingly enough, Ember’s core doesn’t provide advanced form processing. It just has some input helpers and that’s it. It is very opinionated and even has its own data layer. Everything has to be done “the Ember way.”

If you have a background in other frameworks or JavaScript in general, you might get frustrated because Ember uses its own object model. Standard ES2015 classes aren’t widely used, as their documentation states. You might find yourself assigning the value directly to a property and Ember complaining about it.

Another significantly different thing from other frameworks is Ember Data. It is a data layer for Ember applications. You can think about it like some kind of ORM for the front-end. You create models and map the relationships between them.

Now, if your server uses JSON API (it is a specification for implementing JSON APIs), you are in a good place with Ember, but unfortunately, most servers don’t. So you have to write custom adapters and serializers. However, if you do things the Ember way, it might be really productive. It just has a steep learning curve.

Angular 2 is a feature-rich framework. It ships with a lot of modules like Ember, so you have a ton of tools at your disposal out of the box. However as Angular is intended for large applications, it promotes TypeScript, which might trigger some resistance before you give it a go.

Another notable thing is the heavy use of observables from the Rx library, which is really nice. You can represent almost anything as an observable and apply high-level operations like map, filter, etc. If you have used Lodash or Underscore, Rx is kind of same but on steroids.

Here is a summary of the core features of the four frameworks we are discussing in this article:

All those features we briefly overviewed are worthless if you need to burn the candle at both ends to use them effectively—which is the next point.

Usability 可用性

If at this point you still have enthusiasm for your chosen framework, the next step is to get your hands dirty.

Maybe the framework is a good fit for you because of your background. Maybe it is a little bit different and challenges you in some ways. You don’t know yet, and no amount of reading or watching tutorials will help until you try it yourself.

The best way to get a feel for a framework is to use it in some mini project. This gives you an opportunity to solve everyday problems mentioned above with a given framework.

While working on a project, take your time and reflect on whether or not you are being productive. How easy is it to achieve the desired result? Do you have to look for external libraries? Maybe you need some plugins from the community. Is there any conventional structure or guidelines within the context of the framework? Maybe there is a CLI to accelerate the development process. At this step, you are gathering basic experience so you can think what would it be like if you use this framework for upcoming projects or even transition existing ones.

Ember is considered to be a very productive framework, at least for its core users. It comes with a CLI, which really helps. You can generate routes, controllers, components, and models with their own test suites. Doing all of that manually is a tedious task. Generating a new project is also possible. It will create the basic folder structure, install necessary packages, build tools, testing environment, etc. If you’ve never used a CLI to such an extent, you’ll be very pleased. But, as I mentioned earlier, Ember is very opinionated; despite all of that goodness, you might find yourself frustrated while trying to accomplish common tasks.

Now for React and Vue, they have some kind of CLI, create-react-app and vue-cli. But besides generating an initial project with some options, they don’t offer that much compared to Ember or Angular. It is understandable as they both represent a view layer. If you like customized workflows, experimentation, or different structures on a project to project basis, then you are in a good place. For some developers, flexibility is the key which inherently comes with using React or Vue.

Angular 4 comes with a CLI like Ember does. You can generate components, directives, services, etc. It also generates the initial structure for an application, so you only need to worry about the product. The testing environment is really nice as, with every generated piece of app, the test suite lives near to it (literally). Besides that, TypeScript might provide a real productivity boost. Here’s why:

How many times have you encountered the code with lines like this…

function doSomething(someData) {
    // do something
}

…and wondered what on earth someData is, what properties it should have, what functions it should provide, and what their behavior is? With TypeScript, you define the type and expect the appropriate data. It can go further if you use some IDE with TypeScript support. You can explore different parts of the app in a breeze.

We haven’t touched on IDEs but, for most of the popular frameworks, there are some plugins out there, which make development really easy. WebStorm, for example, ships with built-in support for Angular, React, and Vue.

Ease of Integration (with Other Libraries) 易於整合（和其他庫）

Last but not least, this could be considered as part of the usability, but it’s so important that it merits its own section.

No matter how feature-rich your selected framework is, chances are you will face problems where additional tools are necessary. There are great libraries out there focusing on one problem, be it DOM manipulation, data processing, time formatting, rich text editing, etc. If you try to integrate one of those and spend hours on it every time, maybe that’s not the optimal choice.

Testing this is very easy. You can quickly come up with some imaginary scenario where you need a certain library. Look at your past projects; what tools have you been using and in what scenarios? Chances are you’ll run into same situations again and you want to be prepared for that, or at least have an expectation.

Not all libraries out there support TypeScript. As Angular heavily uses it, some of the TypeScript goodness might disappear while using such a library. Of course, you can find a workaround, but it’s a little bit more of a hassle. Because of the Angular popularity, you might integrate instructions on the page of the library itself.

For Vue and React, you are responsible for almost everything, and using other libraries is not an exception. If you are using Webpack or a similar build tool, you can directly refer to libraries installed using NPM. I’ve found it to be a little bit of a hassle for Vue to use community plugins, especially when they contain user interface logic as well.

Ember has EmberObserver, which is a website of community plugins. Each of them has a score on a scale from zero to ten. It is a really great place to look for something you need. If you type the name of your favorite libraries, like Lodash, Rx, or Ramda, you’ll find the related plugins from simple wrappers to complete rewrites. Of course, there are Awesome React and Awesome Vue repositories which gather related resources, including libraries, but I found EmberObserver to be especially useful.

Committing to a JavaScript Framework 致力於JavaScript框架

Choosing the right JavaScript framework is one of the most important steps towards making your web project a success. Whether you are working on a small project or a large one, whether you are working solo or in a team, each of these details play a crucial role in determining which framework is the best for your project (and less of which framework you may prefer).

As for core features and usability, I have listed the points that will affect developers’ productivity in various degrees. Usability is especially tricky because it heavily depends on your experience and background as well as on company or organization you are working in.

Over time, the frameworks that we have discussed in this article may evolve, their popularities may change, and the projects they are suitable for may change, but this article should give you a general sense of where each of these frameworks may work the best.