You probably shouldn't use a JavaScript Framework

You probably shouldn’t use a JavaScript Framework. Instead, you should write modular, vanilla JavaScript. You also probably shouldn’t be considering a JavaScript MVC framework, especially if it’s going to be architected in the same way as a server rendered application (going to use site/application interchangeably). With a high performing site, you’ll likely squeak just as much perf out of a server rendered app as you would a “single page” app. Between sending less down the line to your users (reducing bandwidth and time to load), keeping their cache size small (making it more likely they’ll have something in cache next time), and reducing the memory footprint of your JavaScript (increasing perceived and on-page performance), you’re likely better off rendering on server.

If you absolutely must use a JavaScript framework (development skills across the team aren’t high enough to write vanilla JavaScript and there’s not time/money/interest in training the team and improving their skills, there is a real, not perceived, business need to support very old and outdated browsers, etc…) for server rendered applications, you should probably use jQuery. Yes, there’s Zepto and any number of other things you can use in place, but you should probably use jQuery.

If you are truly architecting an application that will benefit immensely from being rendered on the client side and you are able to keep its footprint (download and memory) down and it’s demonstrably better for the user and you therefore must build using a JavaScript MVC framework, you should absolutely not just choose one that’s cool or trendy. Be very conscious of what each framework does, it’s pros and cons. Understand that each cool feature, like a virtual DOM, has serious tradeoffs, like a large memory footprint. Be always vigilant when it comes to performance and understand that if jQuery takes as long as it does to parse and execute on mobile without anything else, imagine (scratch that, test) what it’ll be like for a full MVC framework. Don’t discard mobile devices (or old mobile devices) because of your targets; we need to build a web for everyone and client side rendering is really hard to do progressive enhancement with.

If, after all of this, you still want to use a JavaScript framework, especially a JavaScript MVC framework, you should do the following: create a proof of concept that mimics the real life use cases of your features and functionality. Todo MVC is great for narrowing down your choices, but some frameworks are better suited it than others; the only real apples to apples test you can do is with your needs. What you create should look identical with all of the frameworks and have identical functionality. Once prototyped, you should test and evaluate. What was the learning curve? What resources were available to guide and help the learning process? How long did it take to complete? How modular is the output? How readable and maintainable is the code written? Can you already see places you’d like to optimize for? How likely are the skills gained using this framework going to translate to future work when this framework no longer exists? What’s the total over the wire size? What about subsequent loads? How accessible is it? What are its performance metrics? What does its JS memory profile look like? How about across all devices, from small and low powered through big and high powered? With all of this, then you’ll have a good understanding of what framework to use. Or, you’ll find you shouldn’t.

There are other ways to reduce layout thrashing than React and it’s virtual dom. You can build encapsulated, reusable components without Angular’s directives. You can loop over elements without jQuery. I promise.