Full-stack developer is a term that describes a developer who is experienced with the entire stack of application development — the backend side, which also includes the database, and the frontend side, which is commonly known as the user interface. It sounds like only a few selected developers who have a vast amount of knowledge and incredible, almost mythical, skills are qualified to bear this title - full-stack. However, the truth is different—nobody can know everything, and the secret is to pick a specific stack of technologies and deep dive into them. Being a full-stack developer will allow you to develop any kind of application, and thus opens up an endless amount of opportunities.

Full-stack development refers to a client-server architecture model, or, as it's more commonly known, the frontend and backend. These are different in almost every single aspect. Backend development refers to writing code for the server side—handling data, providing APIs, managing security, deployment, and more. Frontend development refers to writing code for the client side—in our case, web clients running in users' browsers, working on the user interface, presentation logic, browser compatibility, performance, responsiveness, and more.

The backend and frontend parts do not usually share code; it might be written in entirely different programming languages, and run on different types of machines and in geographical locations. They communicate through the network via the HTTP protocol with the help of standards, ideas, practices, and architectural styles such as REST and JSON. The most notable difference between the backend and the frontend is the intended end user that interacts with each one of them—the backend interface serves computer systems, while the frontend interface serves human beings, as shown in the following diagram:

Being a full-stack developer means that you are an all-around developer who understands the different concepts and responsibilities of each part and, moreover, is able to take an idea and implement it from the very first line of code to a finished and deployed product.

In order to begin diving into full-stack development, let's get familiar with the concepts, responsibilities, and technologies for each part of the stack.

Hypertext Transfer Protocol (HTTP) is the foundation of communication on the WWW. It defines the format of messages and the way they are transmitted between the client and the server.

HTTP has two sides to communication — the client and the server. On web applications, the client is the user's web browser and the server is the backend server. Communication happens when the client creates a message called an HTTP request, sends it to the server, and the server, in turn, responds with an HTTP response, as shown in the following diagram:

Each HTTP request consists of a few pieces of information:

• URI: The web address or IP address that identifies the server. For example, http://example.com or http://192.168.0.1.
• Method: The action that should be taken upon the requested resource. For example, GET indicates data retrieval and POST indicates data creation.
• Body: Contains the data to be sent to the server, if any. The most popular data format for HTTP requests is JSON but, generally, data can be formatted in any format that the server understands.
• Headers: An optional set of metadata key-value pairs that add information to a request.

The server retrieves this request, executes related logical steps (commonly known as business logic), and forms an HTTP response to be sent back to the client. This response includes a few details:

• Status code: A three-digit integer that describes the result of the request. For example, 200 means OK, 500 means there was an error in the server, and 404 means the requested resource was not found.
• Body: The data sent back from the server, if any. As with the request body, JSON is the common data format, but any other format is valid as well.
• Headers: An optional set of metadata key-value pairs that add information about the response.

The HTTP protocol is a stateless one. This means that every HTTP request the server receives is independent and does not relate to requests that came prior to it. For example, imagine the following scenario: a request is made for the first ten user records, then another request is made for the next ten records.

On a stateful protocol, the server remembers each client position inside the result-set, and therefore the requests will be similar to:

• Give me the first ten user records
• Give me the next ten records

On a stateless protocol, the requests will be a bit different. The server doesn't hold the state of its client, and therefore the client's position in the result-set needs to be sent as part of the requests:

• Give me user records on index 1 to 10
• Give me user records on index 11 to 20

The slight difference between these examples represents the different approaches. On stateful protocols, you assume that the server knows everything about the previous requests, while on a stateless protocol you assume the opposite—the server doesn't know anything about the previous requests, which is why you send all the necessary information with each and every request.

On the one hand, this makes web service development more challenging, since creating fast, stateless service is not an easy task. On the other hand, this enables services to scale out quickly and support millions of users rather easily.

Representational state transfer (REST) is an architectural style for resource-oriented services. It is used by most web applications today to standardize communication between the client and the server. If HTTP was the spoken language, REST would be a set of rules for that language.

REST-based web services, also known as RESTful APIs, have a few constraints they need to follow:

• Consistent interface: Every entity is a resource that will have a unique endpoint— a unique base URL. All operations on a resource will be available via that URL.
• URL and HTTP methods: When a resource URL is combined with an HTTP method, it describes an operation performed on the resource. For example, GET means retrieving data, POST means creating data, and DELETE means deleting data.
• Statelessness: Just like the HTTP protocol, RESTful services are stateless. This means that each request is independent and information regarding previous requests is never used.
• Cacheable: For each response, the server defines whether it is cacheable or not. Once a response is set as cacheable, the client caches it and uses the data from the cache instead of requesting it from the server again and again.

For example, in an application that manages students, we could have the following services:

REST has become the de facto style of communication between the backend and the frontend. This is especially because it is a simple concept, yet very powerful — it makes the backend understandable to other developers and simple to modify and scale, and supports multiple types of clients, including web and mobile.

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.

Writing your frontend with pure JavaScript is possible, and it was the way websites were developed for many years. Over the years, several libraries have emerged incorporating different controls and allowing code reusability. As they have grown, some of these libraries have merged together to create a framework that helps developers to create complete websites from start to end, while also providing answers to many aspects required by modern websites, such as routing, authentication, data binding, state management, and so on.

In this book, we will concentrate on three of the most popular JavaScript frameworks today: Angular, React, and Vue.js.  

Angular (https://angular.io/) is an SPA frontend web application development platform developed by Google and the open source community. It is the successor of the popular AngularJS framework, which dominated the SPA platform world at the beginning of the decade.

Angular takes HTML, CSS, and JavaScript and puts them in the context of application development with modular, component-based architecture, conventions, and utilities. It consists of a few basic concepts:

• Modules: Containers of Angular code
• Data binding: A mechanism that automatically reflects changes in the code on the UI, and vice versa
• Components: An HTML template combined with JavaScript code that controls it
• Directives: Add behavior to HTML elements of Angular components
• Services: Units of work that are additional to UI development, such as data handling or logging

Angular is one of the most popular frameworks today for web application development, and even has frameworks built on top of it such as NativeScript, which enables native mobile development based on an Angular code.

React, released and managed by Facebook, is a JavaScript SPA framework focusing on components, serving the purpose of a view engine. Contrary to Angular, React is less opinionated on how you build an entire app and requires a milder learning curve, albeit it's just a view engine. React enables building encapsulated and reusable components using its notorious and controversial JSX, a domain-specific language (DSL) that allows you to write the view of the component in JavaScript alongside the component logical code.

 React was released to the public in 2013 and it has made a great impact in the field, introducing great concepts to web apps, such as JSX, Virtual DOM, unidirectional data flow and great performance.

Notably, React is not just for web apps. React follows the notion of Learn-Once-Write-Everywhere. Meaning, you can leverage React to write apps that target different platforms, for example using React Native for cross-platform native mobile apps and React360 for VR.

 Moreover, the innovation and collaboration around React is astonishing and its community is paramount. React is just a component library, thus enthusiast followers have created complementary libraries to provide other aspects related to app development, such as state management, routing, and isomorphic rendering. Some of which have too made a noticeable influence in the field as well, for example, Flux and Redux.

 Ever since its release, React has been gaining popularity at a steady pace, taking its place as the leading SPA framework for quite some time now.

Vue.js (https://vuejs.org/), commonly referred to as Vue and pronounced view, is a JavaScript framework that aims to be approachable, with a less steep learning curve than other frameworks. Vue is based on the Model–view–viewmodel (MVVM) (https://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93viewmodel) UI architecture and is focused on the ViewModel layer. It connects the View and the Model via two-way data bindings. 

Vue consists of the following features and ideas:

• Data binding (reactiveness): A mechanism that automatically reflects changes in the code on the UI and vice versa
• Components: An HTML template combined with JavaScript code that controls it
• Directives: Prefixed HTML attributes that tell Vue.js to do something about a DOM element
• Filters: Functions used to process raw values before updating the view