Choosing a JavaScript Framework

The post argues that picking a JavaScript framework becomes easier when you first list what you actually need, because features you do not need become cruft. It then says to weigh maturity, documentation, support, and funding, and to judge how quickly your team can learn the framework’s patterns.

Reading notes

#

• Start with a clear list of needed features so the framework choice can be narrowed by removing unnecessary parts.
• Avoid frameworks that force unwanted dependencies or bundled UI pieces if those are not part of the plan.
• Prefer modular frameworks when you want to pay only for the pieces you use.
• Check maturity, documentation, support, funding, and whether vulnerabilities get patched.
• Small libraries can still make sense if they do one thing well and are realistic to maintain.
• Twitter Flight is presented as lightweight, backed by Twitter, and dependent on jQuery and ES5-shim.
• Team background matters because familiar patterns can reduce ramp-up time.
• Ember routes and Backbone routes are shown as examples of different styles, with Ember feeling closer to Rails and Backbone closer to plain JavaScript.
• AngularJS is described as fast, well funded, and innovative, but its patterns can be harder to learn if the team cannot adapt quickly.