Framework choices for developers

The world of frontend development today is an intimidating one. With so many frameworks and libraries, it can be quite difficult to figure out the best choice. We keep seeing beginners working on website templates asking the question: which framework should I learn? The answer is almost always: it depends. You have to pick the right tools that fit the constraints of each project or mockup.

Big frameworks

It can be tempting to go with a full-featured framework that claims to have solved all the hard problems for you. However, it will only be a good choice when you are indeed facing the problems these frameworks are designed to solve.

Are you building a fully-fledged single-page application that requires client-side routing, hundreds of components and multiple teams working on different features in parallel? If the answer is no, big frame- works are probably not for you.

In trying to deal with the complexities of large-scale applications, frameworks introduce complexities of their own in the form of extra layers of abstractions and tooling requirements. You have to first conquer a steep learning curve before becoming productive. While for a large project this is probably a wise price to pay, it's total overkill for simpler scenarios.


Many developers advocate for the idea of building your own stack with micro-libraries. This approach gives you the utmost flexibility: you can ignore the things you don't need and you get to decide every part of your stack. This is great for simple projects where all you need is a few micro- libraries that solve specific problems.

However, if you extend this strategy to larger projects, you'll find yourself having to make so many choices in order to build a suitable stack that it leads to decision fatigue. Moreover, the wiring and plumbing required to make sure everything works well together can quickly become overwhelming. It takes a lot of experience to get it right, and if you aren't a seasoned developer, your code may end up much less maintainable than desired.

View layer-centric

There is a third category on the library-framework spectrum: the view layer-centric libraries. The common trait in this category is that libraries provide a standalone, ready-to-use view layer for efficiently rendering dynamic content and handling user interactions. This is often sufficient for simple projects.

It's possible to create a framework that offers the best of both worlds

At the same time, they can tap into their ecosystems of tools, libraries and conventions to handle more demanding scenarios. The aim here is incremental complexity: don't over-engineer it if the size of the project doesn't justify the overhead.

React is a great example in this category. Its core library is just a view layer, but its community has created tools and libraries to fill in the gaps. The only issue is that contributors have such diverse opinions that the ecosystem has a very high churn rate and there is no single 'best' stack. Again, this can lead to decision fatigue.


It's possible to create a framework that offers the best of both worlds: simplicity for small projects and a full-featured stack for larger ones. The key is that the user can scale up the framework's complexity incrementally, when the project demands.

To achieve that, the framework must be divided into incrementally applicable parts. Start with the view layer as the core. Then add routing, data persistence, build tools and higher-level architecture. These parts should work well together, but they should also be decoupled: so the user is free to use them one at a time or all together, or even swap some out for custom solutions.

This is what I call a 'progressive frame-work', and I believe Vue.js qualifies as one. For the simplest use case, you can pull it down from a CDN and get the benefits of reactive, declarative data bindings with no set-up at all.

For really ambitious projects, you can use the official command tool to scaffold a recommended stack with the best-in-class development experience. There are also official libraries to deal with common needs such as client-side routing, Ajax data fetching and touch gesture handling. If you think the idea of a progressive framework is plausible, check it out at

This article was originally published in net magazine issue 279. Buy it here.

Thank you for reading 5 articles this month* Join now for unlimited access

Enjoy your first month for just £1 / $1 / €1

*Read 5 free articles per month without a subscription

Join now for unlimited access

Try first month for just £1 / $1 / €1

Designer and frontend engineer Evan You is the author and maintainer of Vue.js, and a core developer at Meteor.