Brief
This genesis of this article was a conversation attempting to explain the reasons for choosing one Javascript Framework (or really collection of Frameworks) over another to a non Frontend developer. It was remarked that many managers, entrepreneurs, and clients of contractors might find the information useful when thinking about how to develop a new, or in the industry jargon greenfield project. While this is mostly relevant in choosing a framework for a Single Page Application (or SPA), some of the considerations can be applied to a more traditional page based web application (though some of the heavier Javascript Frameworks do really lend themselves at all well traditional web applications). What is a SPA and when is it the better choice for Web Site (or area of a web site)? A is frequently a website that is used like a more traditional application, some examples of SPAs would be Gmail (or really any modern WebMail), Expedia or any travel or hotel booking application, Facebook, Twitter, etc. Think of sites where the main frame of the website stays relatively constant and only the data within that frame changes. Sites that don’t necessarily lend themselves to being SPA’s are more like Shopping Sites, News Sites, a Blogs, basically any site where you want the content to be indexed by a web search engine. Though there are techniques to make SPA’s indexable and searchable, it is generally a better idea to make that content that dynamically changed by the server rather than using data from server and dynamically updating it on the client.
Choosing a Framework, and what is a Framework Anyway?
Without understanding the intricacies and minutiae of Front End Development it is tempting to give your developers either a free reign in the choice of technologies they use to develop a product (“I don’t care how you get it done as long as it works”) or being overly proscriptive (“Angular is the framework everyone uses, so we are using Angular”), but a little understanding of what Frameworks are, how they effect the development and maintenance of your project, and yes even a little history of Frameworks will allow you to make a more educated determination of how proscriptive and how lax to be about the choice of a Javascript Framework.
A Framework is a collection of libraries (code whether that be Javascript, CSS, or server side programming language) that enables the programmer to more quickly develop a project. Front-end frameworks have really only been around for the last 10 years or so (Dojo is generally thought of as the first real Javascript Framework), but have been around in Desktop Client world for a very long time (dating back to the early history of GUI’s).
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.
Javascript is Born
In the early days of the web, the Browser wars Mosiac, Netscape, Cello, Spyglass were are trying to innovate to be come the top browser. Netscape navigator in version 2.0 added the ability to run scripts on a web page (for brevity and the fact that browser plugins are for the most part relegated to history, we will do our best to ignore Java Applets, ActiveX, and Flash as alternate ways to run client side code) with a programming language that was initially dubbed LiveScript but later changed to JavaScript for purely marketing reasons (it really shares nothing with Java other than curly braces which is a feature of a vast majority of the computer languages in the world). While initially JavaScript was a curiosity that was used for little more than basic form validation (you could instantly tell if the user had forgot to fill in a field for example before having to do a costly trip to the server – remember this was the days of 14.4 modems are very slow internet connections), over time and improvements to JavaScript more and more could be done with the paradigm that was deemed DHTML (or Dynamic HTML). Amazing features like interactive menus, images that changed when you hovered over them (I know these seems quaint now, but at the time these were truly amazing). Around this time CSS, which allowed web designers to make web pages look far more attractive was also introduced (another digression about the horrors of how web pages were styled with tables and images will also be avoided at this point).
Ajax Changes Everything
At end of the 90’s, there was an arms race between two browser vendors, Microsoft and Netscape. Microsoft was terrified that if the web browser could truly create programs that could run equally well on any operating system, their dominance with Windows might come to an end. So they did everything they could to create the best web browser, but have it run really only on Windows – and here is where ActiveX plugins from above rears its ugly head – they tried to embrace, extend and extinguish cross platform HTML with ActiveX and have developers create plugins for their pages that only ran on Internet Explorer on Windows. One of the Hot technologies at the turn of the century was XML, XML was a way to transmit data and one of the prepackaged ActiveX plugins that Microsoft packaged in internet explorer was a way for Javascript to send XML (and people later discovered non-XML) data to and from the server without requiring the page to reload. Netscape copied this one feature in their own way, but in a way that clever JavaScript developers could get the same script to run on both Netscape and Internet Explorer, and eventually this transmission of Data without a page reload was dubbed Ajax. It was Ajax that allowed for things like Google Auto-ccomplete, where when you type in the Google Search box it makes suggestions of what you might be searching for based on what you are typing. Rest and JSON services (which are the server portion of Ajax) became a way for a small amount of data to be quickly transferred from Server to Client (and vice-versa) without having to undergo the jarring reload of page. And as this paradigm become more common, web browsers became much better at updating small portions of a web page, rather than reloading an entire page.
JQuery changes everything
Years of developers fighting with the various web browsers differences, and dealing with what many developers thought of at the time was a terrible language (JavaScript), was helped by three major factors. First, in 2006 the JQuery library was introduced to help paper over the differences between the web browsers – JQuery was truly a game changing library that massively improved productivity and allowed the creation of Apps with a level of interactivity never previously seen. Second, there became some norms around the way to use JavaScript, inline code, global variables, and the like became verboten and developers learned how to use the best features of JavaScript without falling to victim to its weaknesses. And third, a renaissance in Browsers came about with Safari, Firefox, and Chrome. Internet Explorer which had held a 90%+ market share eventually dwindled down to about 20% (when combined with Edge) today. In said renessaince most browsers (the exception being Safari), switched to being EverGreen – in which they were updated on a 6 week schedule, rather than the multi-year schedule that IE had been stuck on. Due to the rapid speed of upgrade developers could actually rely on newly implemented features being available, whereas for years before you had to develop your application without those features because they were not available in Internet Explorer 6.
Angular and the Rise of Frameworks
While some might argue that JQuery is a Framework, it is really mostly a library. It does a lot of things, but it does not provide a proscribed way of separating the what the user sees from the data that proscribes what the user should see. In the world of jargon and Computer Science Patterns this is called M-V-Something (MVC, MVVM, MVP, and a half dozen other variants), which is not important but what is important is that a Framework provides a good way to organize the code (think of this as the model) and separate it from the markup (think of this a the view). Even with JQuery where the code was taken out of the HTML page placed in Script Module, the elements on the page were referenced by strings which were fragile. For example, your page contains a field for entering Zip Codes, and the Jquery references the zip code. But then it is decided that you want to be more international and change it Zip/Postal code, and suddenly the reference stops working. While this is obviously an oversimplification it was issues like these, and the growing size of Javascript code bases that required a formalized setup for the organization of code and use of classical patterns on the client side. Angular was one of the first of these Frameworks to become truly popular, and it solved a lot of the problems of having a large client side codebase.
Back to the Present
OK, so now that we know what Javascript Framework is, how they came about, and why you need them; the question becomes why is it important to choose wisely. If your project works out successfully, you will be maintaining it for years – the project that is feature complete, unless it is a truly simple application that you probably don’t need a framework for, is a project that that has no engaged users. If you picked your framework wrong (it stops being maintained, or is for some reason no longer viable), you may have to either take up maintenance of the framework or switch to a new framework. While you can swap out one framework for another, as the frameworks grow more complex it becomes considerably more effort. For example, upgrading from Angular 1.X to Angular 2 (which confusingly is now called Angular 4 or maybe Angular 14 by the time you read this) is no easy feat. The suggested migration path is to include both the Angular 1 framework as well as the Angular 2 framework on the page and have them communicate to each other through a migration translator, slowing taking out Angular 1 code as you change the app. This creates a situation where your developers have to be intricately familiar with both Angular 1 and Angular 2, as well as your clients have to load two frameworks on a page which can affect loading speeds.
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.
Javascript Frameworks as of 2017
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.
Angular 1 (or AngularJS)
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.
Angular 2/4 (or Angular.io)
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.
Aurelia
Advantages: Modern framework that takes a lot of the ideas from Angular and Durandal. For those familiar with XAML, Microsoft’s Client Side GUI language, MVVM’s patterns may feel more familiar.
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.
Ember
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.
React
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.
Vue
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.
Does it match our backend well - For example, if your backend is designed to output GraphQL rather than REST, React may be a more natural fit.
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.
