Please accept the following terms and conditions before reading this article…!
- By “best” I mean “the most popular general-purpose projects”. All are free/open source but the list may not include your favorites.
- Discontinued projects such as YUI are not included even though they may still have high use across the web.
- Only client-side projects are referenced. Some can work server-side but the list does not include pure server-based frameworks such as Express.js or Hapi.
- Information about each project is intentionally brief to provide an overview for further research.
- Each project provides a usage popularity indicator but statistics are notoriously difficult to collate and can be misleading.
- I’m biased. You’re biased. Everyone else is biased! I haven’t tried every tool here and will declare my favorites but you should make your own assessment based on your requirements.
- Neither I nor SitePoint are liable for any disastrous decisions you make!
The terms “framework”, “library” and “tool” can mean different things to different people at different times depending on the context. The general definitions used here:
A library is an organized collection of useful functionality. A typical library could include functions to handle strings, dates, HTML DOM elements, events, cookies, animations, network requests, and more. Each function returns values to the calling application which can be implemented however you choose. Think of it like a selection of car components: you’re free to use any to help construct a working vehicle but you must build the engine yourself.
Libraries normally provide a higher level of abstraction which smooths over implementation details and inconsistencies. For example, Ajax normally relies on the XMLHttpRequest API but this requires several lines of code and there are subtle differences across browsers. A library may provide a simpler
ajax() function so you’re free to concentrate on higher-level business logic.
A library could cut development time by 20% because you don’t have to worry about the finer details. The downsides:
- a bug within a library can be difficult to locate and fix
- there’s no guarantee the development team will release a patch quickly
- a patch could change the API and incur significant changes to your code.
A framework is an application skeleton. It requires you to approach software design in a specific way and insert your own logic at certain points. Functionality such as events, storage, and data binding are normally provided for you. Using the car analogy, a framework provides a working chassis, body, and engine. You can add, remove or tinker with some components presuming the vehicle remains operational.
A framework normally provides a higher level of abstraction than a library and will help you rapidly build the first 80% of your project. The downsides:
- the last 20% can be tough going if your application moves beyond the confines of the framework
- framework updates can be difficult – if not impossible
- core framework code and concepts rarely age well. Developers will always discover a better way to do the same thing.
A tool aids development but is not an integral part of your project. Tools include build systems, compilers, transpilers, code minifiers, image compressors, deployment mechanisms and more.
Tools should provide an easier development process. For example, many coders prefer Sass to CSS because it provides code separation, nesting, render-time variables, loops, and functions. Browsers do not understand Sass/SCSS syntax so the code must be compiled to CSS using an appropriate tool before testing and deployment.
Don’t Label Me!
The distinction between libraries, frameworks, and tools is rarely clear. A framework could include a library. A library may implement framework-like methods. Tools could be essential for either. I’ve attempted to label each project but the scope can vary.
Projects in order of popularity…
|launch date||August 2006|
|typical size||30kb min|
|typical use||general purpose|
|usage||72.4% of all websites|
- small distribution size
- shallow learning curve, considerable online help
- concise syntax
- easy to extend
- adds a speed overhead to native APIs
- less essential now that browser compatibility has improved
- usage has flat-lined
- some industry backlash against unnecessary use.
|developer||Facebook and contributors|
|launch date||March 2013|
|typical size||21kb min|
|typical use||single-page applications|
React usage appears low in statistics perhaps because it’s used in applications rather than websites. Almost 38% of developers claim to be using the library.
- small, efficient, fast and flexible
- simple component model
- good documentation and online resources
- server-side rendering is possible
- currently popular and experiencing rapid growth
- new concepts and syntaxes to learn
- build tools are essential
- can require other libraries or frameworks to provide the model and controller aspects
- can be incompatible with code and other libraries which modify the DOM
Learn more about React with our Premium course, React the ES6 Way