Frontend fundamentals

The frontend is where users interact with your system. There's a lot to consider and prepare for in the frontend since users, unlike machines, are not homogeneous and this affects their experience when using a website—some have technical experience and some do not; some are young while others are older. The design should be inviting, the flow of work should be clear, and the way things work should help the user be effective and avoid mistakes.

We achieve these targets by working with three technologies that complement each other: HTML, Cascading Style Sheets (CSS), and JavaScript — the undisputed kings of the WWW:

• HTML: Describes what exists on a page
• CSS: Describes how a page looks
• JavaScript: Describes how a page behaves

These technologies have been the foundation of the internet almost since the day it was born. They have been growing and maturing ever since, adding much-needed features that enable more complex systems to be written on top of them.

As a result, frontend development frameworks have started to pop up in the last decade. Their goal is to take advantage of HTML, CSS, and JavaScript and bring them to the next level. These frameworks have added conventions, programming models, and advanced patterns and techniques, and have generally enabled developers to create massive systems using web technologies in a productive and stable way.

These advances indicated the beginning of a big shift in web development architecture—from traditional, server-centric architecture to Single-page application (SPA), client-server architecture.

Since the beginning of the WWW, the way web applications has been developed was server-centric, with minimal to no code running on the client. For example, the following sequence describes the usual flow of work:

1. The user browses to a web address.
2. The server gets the request, generates HTML for the user, and sends it back.
3. The browser gets the HTML and displays it to the user. The user sees the web page and clicks a button.
4. The server receives the button click, generates HTML that matches the button click, and returns it. In the meantime, the user sees an empty browser screen.
5. The browser gets the HTML and displays it to the user. The user sees the web page.

On the one hand, this was easier to code and maintain, since all the code was located on the server. On the other hand, this way is slow and provides a poor user experience for the user.

This architecture was used mainly because browsers didn't support features required for rich client development. Once that started to change with new versions of HTML, CSS, and JavaScript, the shift toward full client-server architecture began too.

The new architecture is known as SPA, which is basically client-server architecture. It was named SPA because of its differences from traditional web applications. In traditional web applications, the user navigates between different pages that are retrieved separately from the server upon request. In SPA applications, there is only one page, which contains the entire application, and every UI change is made locally via JavaScript. A usual flow of work in SPA architecture will look like the following:

1. The user navigates to a web address.
2. The server responds with HTML and multiple JavaScript files that contain the client-side application code.
3. The browser gets the files and displays the web page to the user. The user sees it and clicks a button.
4. JavaScript code on the client handles the click and calls the server side for data. In the meantime, the user sees a loading animation.
5. The server gets the request for data, retrieves the required data, and sends it back to the client.
6. JavaScript gets the response from the server, generates matching HTML, and displays it to the user. The user sees the updated web page.

This architecture enables rich client development that works quickly and smoothly. However, it does make it more complicated to develop web applications, as developers are required to master both client and server technologies.