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.

Which Is the Best Front-end Framework?

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:

  Angular 2 React Ember Vue
Stars on GitHub 26,924 73,530 18,154 63,438
Contributors on GitHub 495 1044 679 122
Tagged questions on StackOverflow 66,152 54,158 21,651 8,598

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:

Angular 2 React Ember Vue
View/Templating
Router
Form processing    
Form validation      
HTTP communication    

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

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.

About the author

Giorgi Bakradze, Georgia
member since May 20, 2016
Since the age of 13, coding has been Giorgi's passion. Obsessed with technical details and technologies, he always tries to find better ways of doing things. Perseverance has been the key for honing his skills as a full-stack developer. He has worked on over 15 projects from small landing pages to eCommerces as a freelancer or as a full-time employee [click to continue...]
Hiring? Meet the Top 10 Freelance JavaScript Developers for Hire in November 2017

Comments

Jasterrr
Like always there is a huge market for all of these frameworks to exist and be successful. It's so hard to make this kind of articles useful actually, you said it yourself, people need to try all of them and see what do they like more. In the end it doesn't matter that much, neither of them is truly better than the other. What matters is your application, final project that needs to have value to users. And when you're deciding what to use for your next project I always try to choose better pick and that is "what I'm most familiar with" (be it specifically or conceptually).
Noelia Lopez
Hey I really like you article! I think it would be good if we consider some other statistics such as: - How many issues has the frameworks on Github - What is the approximate time to solve an issue Because how many contributors has the framework is very important but if we have more issues than contributors and the time to solve an issue is too long is important too.
Dario Cangialosi
Two hints follow. First hint: Remember it all started with Templating, then Syncing and Componentization. Second hint: do a favor to many and carefully consider whether to use or discard Ractive.js (https://ractive.js.org/) but make well informed choices and propaganda, or nothing.
Tomislav Mihaljević
I prefer custom jQuery scripts over this overcomplicated frameworks. It seems that those frameworks are designed to waste your time while trying to do something simple. They remind me of one Drupal 7 project I had to work on, it was most annoying CMS ever.
Jen Weber
Ember has many community resources beyond the official documentation. There are videos of conference talks and meetups from all around the world. In terms of tutorials, there's codeschool, Udemy, Ember Map, Ember Screencasts, Ember Watch, EmberGrep, Ember, Rock & Roll with EmberJS, EmberSchool, Discover Ember... just to name a few ;) You give some really solid advice on the types of things to look for in each framework! Thanks for writing!
Manish Shrestha
Nice article. Well written. Must read!
John Robie
I personally prefer Vue, but I can say from experience that it's easier to find jobs in React (certainly higher paid jobs), the community is more vibrant (I think Vue's internationalism creates communication hurdles), and rolls out innovations faster (Next.js, React Native, etc.). Even with all that, I prefer Vue, and champion it when I can. It is fundamentally better than React, IMO. My fear is that Vue is Betamax to React's VHS...
Giorgi Bakradze
Yeah that's true, you're going to choose the framework you are most familiar with, but if you want to change the framework (get bored, want to try something new, or for any other reason), then those points become relevant
Giorgi Bakradze
Absolutely, that is the good indication of community responsiveness/involvement in framework development, but that's a little tricky to calculate though
Giorgi Bakradze
I personally find Vue more appealing too, especially templating is really awesome
Giorgi Bakradze
Thanks!
Giorgi Bakradze
Ember has very solid core user base, which is really nice, I've personally used it in several projects and researching was really easy. Emberobserver is really awesome, I think every framework should have it's own [framework name]-observer.
Giorgi Bakradze
It depends on the scope of the project and size also. If you're going to build something that takes at least 3+ months for development then you should consider using some framework, because you need some structure and guidelines to maintain your own code. If you don't use one you'll end up creating your own framework, or you'll end up with messy architecture. Now the question is, why not use framework from the beginning ?
Tomislav Mihaljević
Because those frameworks have unclear purpose, and you must be super javascript guru and read a lot of docs to find out which is good for your specific project. And that could be a waste of time
Jen Weber
Agreed, Ember observer is awesome! I'm curious why you say that "there are few resources books, video courses, or other materials" though. What do you think could be done better, or what's missing? I'm interested in writing/building things that help. To me, it seems like there are a ton of resources, but most of my serious work has been limited to Ember and Node. I'd love to hear your cross-framework thoughts.
Giorgi Bakradze
I meant few in comparison to Angular or React, my fault not to mention that. Obviously there are resources out there, documentation alone is second to none. When I was learning about ember, documentation proved to be very useful, which is not the case for other frameworks.
Jen Weber
Ah, that makes sense. Thanks for sharing :)
Jacks Bag
Outsourcing companies in India, and a good percentage of developers under a H1B visa, prefer Angular JS. Given that more and more companies are hiring H1B folks (either directly or by contracting), and if you are trying to find a job, you better stick to favorites: Angular JS, Node.js, C#, .Net, etc.
Dunnedev
Big fan of Hyperapp.js's minimal approach to frontend. You use what you need basically. I wrote a post about it here. http://jsdiaries.com/2017/09/26/introduction-to-hyperapp-js/
Daljeet Arora
great Info. Well described. Must read! Thanks & regards <a href ="http://www.pccwebworld.com/software-development.php"> Software Development Company in India</a>
Giorgi Bakradze
Thanks
Giorgi Bakradze
Never tried that out, I'll check that
Orban Botond
Nice article :)
comments powered by Disqus
Subscribe
The #1 Blog for Engineers
Get the latest content first.
No spam. Just great engineering posts.
The #1 Blog for Engineers
Get the latest content first.
Thank you for subscribing!
Check your inbox to confirm subscription. You'll start receiving posts after you confirm.
Trending articles
Relevant Technologies
About the author
Giorgi Bakradze
JavaScript Developer
Since the age of 13, coding has been Giorgi's passion. Obsessed with technical details and technologies, he always tries to find better ways of doing things. Perseverance has been the key for honing his skills as a full-stack developer. He has worked on over 15 projects from small landing pages to eCommerces as a freelancer or as a full-time employee