Insights

JavaScript Framework Selection

Javascript Hero Image

Front-End Development Evolution

Classic evolution image with developer working on room sized computer -> clunky desktop computer -> laptop -> smartphone / tablet

One of the areas of software development that has seen the most evolution has been front-end/client-side development. From the first days of the Alto Graphical User Interface - created by Xerox and co-opted by Steve Jobs at Apple - we have been building and improving upon the GUI. 

In the early computing days, client-side interactions were limited to form validations, call to action buttons, and routing links which required refreshing the browser or calls to the server for every single interaction. 

With the advent of Ajax in 1998, we gained the ability to make specific calls for information without having to refresh the page, allowing the client-side to decide what to do with the information and how to display it. This simple feature removed several shackles and provided tremendous amounts of flexibility to the client-side interactions. Along with the flexibility, complexity was also added to the process: security, multiple browser support and considerations, state management, and performance were introduced to the mix. 

In the early 2000s (mostly 2004 and beyond), people like John Resig and Jeremy Ashkenas saw common patterns in client-side development and created client-side libraries like jQuery and BackboneJS, respectively. These libraries took commonly used tasks like Ajax calls or Document Object Model (DOM) manipulation and made readily available functions around them. Removing the barriers to development - readily available functions, browser support, and improved performance - allowed for yet another evolution in the development process. 

Frameworks like AngularJS and ReactJS were the natural progression of libraries. The significant difference between a JavaScript library and a JavaScript framework is the opinionated characteristic of the framework. 

A framework includes all the benefits of a library (Ajax calls, DOM manipulation, etc.), and they also provide JavaScript patterns, specific language and coding requirements, and strict guidelines. 

When you adopt a framework, you are adopting its way of writing code, aka its opinions. This aspect can be very beneficial in the way front-end development is designed, as it will provide a cohesive structure and pattern that can and should be adhered to by all team members. 

Nevertheless, it begs the question: should we adopt a JavaScript framework or not?

To Framework or Not to Framework

The most considerable benefit of using a JavaScript framework is the ability to implement a User Interface (UI) that is guaranteed to sync with the internal state of the application. 

Traditionally, every time there is a state change in an application, new code is required to update the UI using VanillaJS, jQuery, or similar libraries. This process often leads to implement a lot of ad-hoc presentation code to mutate the DOM efficiently. If any mistakes are made, the UI will be out of sync from the data: missing information, showing wrong information, or unable to respond to the user, triggering wrong actions (For example: clicking on a delete button deletes the incorrect item). 

It costs a lot of time (and money) to implement all the fancy UI interactions (dynamic validation, and so on) a client is hoping for. The cost is not in the choice of the front-end technology but in the quality of the UX, which heavily impacts development time. In the long term, maintaining and keeping the UI in sync with the data involves writing a lot of tedious and fragile code. 

JavaScript frameworks allow for:

  • Developers to define UI components in a single shot without writing a particular UI code into every action.

    • The framework automatically updates the component after the state changes. 

  • A higher level of interactive fidelity to the user experience of a UI over static-driven server-side delivered content. 

  • Consistent implementation of UI components that support complex interactive JavaScript patterns.

    • Form input masking (Formatting a phone number field as the user types)

    • Dynamic form validation

    • AT supported UI components like tabs, modals or show/hide more content patterns

    • Multi-page user input workflows

  • Data binding - automatic synchronization of data between model and view components: 

    • This feature saves developers from writing a lot of code.

    • Easier for testing, less custom code to write to test both data coming in from back-end services and how that data propagates into the UI

  • Standards - All popular frameworks follow the best of industry standards and promote healthy engineering practices. The product team adopting it is likely to follow the same.

    • You have finished half of the work when you decide to build a project with the help of a framework: No need to worry about cross-browser compatibility, security flaws in code, namespacing, core functions, etc.

  • Reduced learning curve for a team over an internally developed framework - All products eventually need a framework somewhere in its lifespan to keep everything organized. A team will have to establish a framework in-house or adopt a third-party solution, but it must be maintainable and organized.

    • Utilizing an already established framework exposes team members to a pre-determined program without the need for exhaustive internal documentation for a custom framework. 

Challenges with JavaScript:

  • Edge Cases - Frameworks need to work for the masses. To achieve that goal, they must avoid addressing situations that occur rarely.

    • It becomes a significant pain if solving such a problem goes against the framework fundamentals. Almost every product has something unique about it. Eventually, there will at least be one such case that doesn't fit into the approach suggested by a framework. 

  • Upgrades/Compatibility - Adopting a framework means you need to start tracking its upgrades, bug fixes, security advisories, and so on.

    • It might be inconvenient to upgrade a framework once you start using it, especially if the upgrade breaks backward compatibility. Framework updates sometimes adjust their approach to a specific issue which creates a lot of refactoring to upgrade to the newest version.

Narrowing Down the Selection 

Chart

Other Areas of Consideration

The selection of a JavaScript framework also affects other decisions within our architecture. Some areas that are affected are:

·       Testing: what testing framework will fit within our framework. Are there any frameworks that play better with our JS framework selection than others?

·       Logging: Logging on the front end has not been promoted very much. Nevertheless, this is an important decision that should be implemented on the front end.

·       Documentation: Although some say that excellent code will speak for itself, there is a level of documentation that needs to be established. Documentation acts as a road map for other developers that come after us, and it is our obligation to document our code properly. 

You've Selected Your JS Framework, Now What?

Now that we have selected our JS framework, we must ensure that our presentation layer is properly "presented," which is when a CSS framework can help. 

Glossary

JavaScript Extension (JSX) is an extension to the JavaScript language system. It indicates that the script needs to be processed and converted to actual JavaScript. JSX uses shorter and simpler syntaxes to simplify coding when compared to JavaScript.

Graphical User Interface (GUI) is an interface that provides a simple way to navigate your desktop and programs by presenting options using icons. GUI also offers the ability to use a mouse to navigate around the screen with ease and precision. 

Client-Side refers to the end-user, you, sitting at home or your office, interacting with your personal computer 

Document Object Model (DOM) is a cross-platform and language-independent interface that treats an XML or HTML document as a tree structure – wherein each node represents a part of the document.  

 

Contributed by
Name
Aaron Boudreau
Job Title
Senior Creative Technologist
Name
Kianosh Pourian
Job Title
VP, Development and Solution Architect