Front-End Development Evolution
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.
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.
To Framework or Not to Framework
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.
Developers to define UI components in a single shot without writing a particular UI code into every action.
A higher level of interactive fidelity to the user experience of a UI over static-driven server-side delivered content.
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.
Edge Cases - Frameworks need to work for the masses. To achieve that goal, they must avoid addressing situations that occur rarely.
Upgrades/Compatibility - Adopting a framework means you need to start tracking its upgrades, bug fixes, security advisories, and so on.
Narrowing Down the Selection
Other Areas of Consideration
· 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.
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.