English |  Español |  Français |  Italiano |  Português |  Русский |  Shqip

Choosing a JavaScript Framework

Conclusion

Choice paralysis” is a very real obstacle for the contemporary JavaScript team. With new libraries coming out seemingly every day (check out the /r/javascript reddit for some evidence), how do we make choices?

By doing the due diligence on the front-end (no pun intended) of a project to understand what exactly you need, you’ll be better able to rule out what you don’t. If I take a moment just to extend this book’s realty analogy a little further: when searching for a house or apartment, you’d hopefully have a list of wants, dislikes, and deal-breakers (central air as a must, for example).

After you have a better idea of what you want, it’s time to face the possibilities. You can range from a loose structure to help you get started (Backbone), to a more fleshed-out toolkit (Angular), to a fuller framework with its own set of standard practices (Ember).

However, if you’ve learned anything to watch from the up and coming frameworks, I’d say watch for web components. Web components will revolutionize the way we approach experiences on the front-end. Up until now, it seems as if frameworks have been solving the problem for which web components are the solution (see Knockout’s view model pattern, or Angular directives, or Ember components). Expect a lot of interesting things to happen as this standard becomes more widespread and the subject of further experimentation.

It’s my hope that this book has given you a chance to think about your process and a peek at how the various frameworks work in action, as well as a peek at the latest in frameworks. While no book can tell you what’s the right framework to make your bets on, I hope you’ve learned something to take with you to your teams and your projects.

There has been error in communication with Booktype server. Not sure right now where is the problem.

You should refresh this page.