Probably the most common question we get asked as we get to know an organization is “What framework should I use?” No matter what some people would have you believe there is no straightforward answer. The answer though is founded in our typical response of “What are you trying to do?”
Through this series of blog posts, we are going to try our best to give you a framework for choosing a framework (how meta is that?) and along the way, we are going to try to provide some analysis of several of today’s leading frameworks. But first we need to establish some common language between us.
What is a web application?
What is a framework?
Early on, it was a wild west of browsers, with each browser trying to vie for slightly unique selling points (USPs) that they would hope would lead them to dominating the internet. This provided a set of unique challenges for those developing web applications, as each USP was a way in which your application would not work as expected in another browser, and for those who could not force a particular version of a browser on someone (which would be every customer-focused business entity in the world!), it was a landmine that would and could frustrate your users. So early on, the likes of Prototype, MooTools, Dojo 1, jQuery, and others really focused on trying to level the playing field, so that you could actually write code that worked in every browser.
As the web matured, web applications became more complex. It became far more than stringing together some web forms. User expectations started to increase towards richer UIs delivered over the web. At the same time, the browser market shifted away from Internet Explorer toward the likes of Chrome, Firefox and Safari. Some of the previous toolkits, like Dojo 1, grew into this rich UI space as well as the rise of commercial solutions like ExtJS. This continued to evolve over several years with the introduction of Backbone, Ember.js, and eventually Angular 1. Libraries that started as collections of browser patches and APIs became application framework platforms.
Over the past couple of years, we have seen the rise of the most mature set of frameworks. A virtual cornucopia of options. By and large, these all focus on creating extremely rich UI/UX experiences that work across the gamut of devices from desktop to mobile. Some frameworks provide highly structured ways to build applications and some focus on solving just a single problem, expecting to be incorporated with other frameworks to build a whole application.
What should I look for?
We will start that answer with a question: “What do you need?” While we are going to dig into as many aspects of these frameworks as we can, our analysis will not be exhaustive. Part of what drives this plethora of choice is the wide variety of different needs. We would even say that it might be folly for any large enterprise to enforce a one size fits all mandate when it comes to frameworks. While there are synergies that come from sharing code and having similar skills among development teams, most businesses these days have a variety of needs, from consumer-facing websites to inward facing business applications. No framework works best in every use case.
Your job, as the reader, is to come up with your checklist of your needs, which should be driven by what you want to accomplish. Some questions to consider about what you need which can provide context as you go through this series:
- What type of web application do I need to build? Is it a consumer-facing website? Is the web application a consumer product? Is the application a business application which will be used by an expert user who knows a lot about the macro business process? Will the application be displaying a lot of data and need to visualize it in an actionable way?
- What environments will this run in? Will it run on mobile? Do I need a native experience on mobile? Will I be able to control the browser set on which my application is run?
- What sort of user interactions will I need to deliver? Will I be comfortable with off the shelf user elements or are the user interactions actually a key component of the value that my application provides? Is my application just part of a larger federated set of web applications, where I need to have a seamless user experience?
- How much of my application will be client-side? Will my business logic reside within the web application or will I need to interface to server-side systems which will drive the application? How much service integration and orchestration will I need to do within my web application?
- What is my development environment going to be like? How integrated will my front-end team be with server-side team? Is it full stack development? What will be the workflow between the product owners, the UI/UX designers and the software engineers? What other technologies will I need to integrate into my application?
- How am I going to know my application will work as expected? How do I want to test it? What is the ongoing lifecycle of the application? Will it be handed over to a support team or will the original engineers continue to maintain the application in perpetuity?
- How much do I expect this application to take from the open source community and am I prepared to give back to the community? Will I have the right level of skills and experience to deal with issues when they occur? Who will I turn to when we get stuck?
Now that you have some of the questions you need to answer, we want to take you through a journey of looking at the aspects of the above frameworks through several different lenses. We plan to cover the following areas in this series:
- User Interface Development – The foundation for most web applications is of course the user interface and we will discuss several aspects of user interface development for the selected frameworks.
- User Experience Design – A web application is a lot more than just a bunch of user interface elements plopped on a web page. Web applications need to fit the user ergonomics of your target user. How do you achieve those with your web application is an important consideration.
- Foundation Technologies – It is important to understand the core of the framework. How are the frameworks built, what do they try to accomplish as far as ensuring web applications built with them work properly in different environments? How forward looking are these frameworks as well, to help ensure it will not be outdated too quickly.
- Applications – Once you have a user interface, you need business logic to drive it. How do the frameworks provide this and how rigid and flexible are those concepts?
- Usage – Be it mobile first, expert-user business systems, consumer applications, or content management, all the frameworks deliver on these use cases in different ways and have varied strengths. Understanding where the frameworks excel (and maybe where they do not) will help in deciding what is best for you.
- Integration – It is unlikely your web application will be fully self-contained. It will need to interface with different systems. The approach each framework takes to this is an important consideration.
- Testing – How do each of the frameworks approach testing as well as what is a good testing approach?
- Soundness – How well does the framework promote patterns and use technologies that help ensure well designed and behaving applications.
- Building – What does the tooling and build pipeline look like for each of the frameworks?
- Community – What is the community around each framework? Are those skills available on the market? Who do you turn to when you need help?
Popularity is not a good barometer for web application frameworks. This is because they all meet different needs in different ways. Having a good understanding of what you need will help you determine which framework is right for your particular application. So hopefully you are strapped in and ready to embark on this adventure together as we strive to explore the depths of web applications frameworks!