Choosing a Framework, and what is a Framework Anyway?
A Bit of History
I might as well at this point digress to a bit of history which might better explain what a Framework is. In the beginning of the world wide web, what Tim Berners Lee created was basically the ability to create a static page (i.e. unchanging, every time it was viewed it was the same) with links on it, kind of a computerized Choose Your Own Adventure. Very quickly after its introduction, however, it was quickly realized that people wanted dynamic content, or content that could change depending upon user input. So web servers changed from programs that displayed static content, to programs that could run scripts, in the early nineties this was CGI (or Common Gateway Interface) written in C. This would allow a user to see a different page depending on input from the previous page (for example, when you went to Lycos in 1994, you could enter a search term and find web pages that contained that search word). Eventually most developers switched from writing in C to more productive languages like Perl, PHP, Java, and whatnot. These CGI programs running on a web server are what we call server side languages, and for a majority of the lifetime of the web this was were the majority of the work was done that allowed showing of web pages.
Ajax Changes Everything
JQuery changes everything
Angular and the Rise of Frameworks
Back to the Present
What to consider when choosing a framework.
The obvious first thing when considering a framework is longevity, will the framework be maintained in the future. While popularity is a good sign of longevity, it may not guarantee it (the above example of Angular - probably the most popular framework - switch to a completely incompatible version 2 is a lesson that should be heeded). You might wonder why it is important to maintain a Framework, after all if it works now, won’t it work forever? Unfortunately, while it continue to work forever, it may use features of the browser that are deprecated or changed over time. It will not take advantage of features that are added to browsers, and eventually you will end up with an application that looks dated and xdoesn’t hold up against its contemporaries.
The next thing to consider when looking at a framework is popularity itself, if a framework is popular it will be much easier to hire talent to work on it, as well as for the talent that is working to get assistance when issues come up. There is a saying in computer science that all abstractions are leaky, and what that generally means is that a Framework (which is an abstraction) frequently runs into issues that the designers of the Framework didn’t think about. If you don’t run into one of these issues, consider yourself very lucky, but I find that almost all frameworks run into issues of some kind. If you are one of only a few people working with a Framework you will not be able to easily find solutions these problems as you might be the one of the few people having this particular problem, however if a lot of people have the same problem because there are a ton of people using the framework it is more likely there will be blog posts, StackOverflow questions, or some answers or at least clues to answers on the internet.
One thing that I also like to consider, is the size and complexity of the Framework. If a framework is small and relatively simple it becomes a lot easier to debug when things don’t work the way you expect, whereas a giant framework that requires a PHD in computer science to understand how it works becomes more of a Black Box where you have to just trust that it behaves the way it is documented.
How long a framework has been around plays both to strengths and weaknesses. Angular 1 has been around for a long time (and even though it has been superseded by Angular 2) it is still probably the most popular framework with the most developers using it, the most StackOverflow questions, etc. However, it uses a technique to determine if the page has to be updated called dirty-checking, which causes a lot overhead and has been superseded in modern frameworks by a technique that is orders of magnitude faster generally called Virtual-DOM. This may or may not be noticeable by your users, depending upon what your are doing, but it is a consideration you might want to weigh when determining your framework.
While there are always new Frameworks coming along, but here are a list of what I consider viable Frameworks, their advantages and potential disadvantages. I am going to use the number of StackOverFlow questions as a general guide for how popular a language is (there are other metrics, like number Google Results, Github Stars, and it also points to past popularity rather than current popularity.
Advantages: Probably still the most popular framework, and certainly the most popular historically (240,000 SO questions). Lots of developers are familiar with it, and there are hundreds of plugins and libraries that work with it.
Disadvantages: While still maintained, no new features are coming to the framework. Slower for updating than more modern frameworks. High level of complexity and what now seems like a large learning curve to go from casual familiarity to expert level comfort with the framework. Angular is also a fairly large framework and unless you go through a complex asset pipeline build process (which is part of the reason to use Angular 1 is to avoid complex build processes) it will not be shrunk down with features like Tree Shaking.
Advantages: Doing complete rewrite allowed the developers to take everything that they learned developing Angular 1 and improve on it in many ways. Faster, more modern, and has less hacks than previous language. Built from the ground up to be easily interoperable with IDE’s ()Integrated Development Environments). Improved performance.
Disadvantages: The complete rewrite produced a painful upgrade situation where, and soured a great many original Angular Developers. Angular 1 skills and knowledge do not translate with Angular 2. Requires a lot of of outside tooling to get up and running (Nodejs, WebPack as well as a lot of boilerplate, and is quite a large framework in size.
Disadvantages Relatively small following, and the documentation is not as extensive as the frameworks. The build system leaves a bit to be desired, but hopefully will be improved over time. Basically the project of a singular developer (however one with quite a pedigree), without a major company backing the project might lead to some trepidation.
Advantages: While it has been around for a while it managed to improve performance from version 1 - 2 without the complete rewrite headache that plagued Angular. It is well documented, and has passionate followers, especially those in the Ruby community.
Disadvantages: May seem cumbersome to those outside the Ruby community. It is a fairly large framework, with a lot of concepts to grasp (for example, the router is introduced as one of the core concepts in the getting started guide). Has never caught on in the way that React and Angular has.
Advantages: It’s meteoric rise in a short period of time, and it’s backing by Facebook due to its simplicity and lightening speed has made it probably the #2 framework in the past 2 years. Its very well documented, easy to use, and due to the fact that it is not an all encompassing framework makes it easy to add to existing projects. Since it doesn’t attempt to do as much as other frameworks it is considerably easier to learn.
Disadvantages: Not as much of a framework as the other listed here, more just like a view renderer. Most developers combine it Flux/Redux to flesh out the functionality but the lack of a router/DI and other features included in the other frameworks may mean relying on less reliable libraries to include those features. Some concern over the license has spooked some developers lately.
Advantages: As with other modern frameworks it is fast as it uses a virtual-dom. It’s small codebase makes it relatively easy to debug and understand. It’s rapidly increasing popularity means that it probably isn’t disappearing anytime soon, although it has mostly been developed by one developer. Very similar to angular1 syntax, it is one of the easier to learn frameworks.
Disadvantages Missing some of proscription of Angular 2 or Ember (less opinionated as they say) developers can be left on their own to build inelegant solutions quite easily in Vue. The fact that is basically built by one developer might be a reason for concern, however with over 100 contributors and a MIT license it could easily be forked and continued if the primary contributor ever went away or became uninterested.
How to Choose
Obviously you should listen to your developers or contractor but at least now you should have enough information to ask some smart questions.
Why would do you recommend this framework? - If the answer is its the only framework I’ve looked at you may want to ask some more probing questions or look elsewhere.
Do are developers have experience with the framework - Not the best reason for choosing a framework, I, for example would recommend building a site in BackBone or ExtJS at this date in history, but rather than having your developers spend a week or two learning they could be coding. Just remember over the life of a successful product more time will be spent on maintenance than on the original development.
Are developers excited about working with the framework - Once again, not the best reason to choose a product, I know of far too many places that have a mismatch of “Technology du Jour” foisted upon them be developers eager to work on the new hotness that they greatly regret being burdened with.
Hopefully now you fell a little more prepared to discuss with stakeholders the relevant issues of what frontend framework to choose, wean developing your Single Page Application.