Angular 2 falls under a broader category of client-side MVCs. Client-side MVCs frameworks are used in many languages and have a similar architecture or design. Let's break this term down in detail. First, we'll discuss what "client-side" and "MVC" mean. Then we'll explore how these terms apply to Angular 2.
Before we can discuss what client-side means, we must first understand the difference between a client and a server.
In terms of web frameworks, a client is usually a web browser (Chrome, Firefox, Safari, Internet Explorer, etc.) that runs on the user's local machine and facilitates their interaction with the internet.
The client sends a request to the server when a user clicks a link or enters a URL. The client also processes the server's response and displays it to the user.
In simple terms, a server is a machine that waits for incoming requests from clients. It contains resources (such as web pages and files) that can be provided to requesting clients.
For instance, when we type
www.epicodus.com into our web browser client, the client makes a request to the server the Epicodus website is hosted on. The server responds with the necessary resources (HTML, videos, and any other content) that the client requires to render the website for the user.
The term client-side means the actions that must occur to run an application are handled primarily by the client instead of the server.
In a client-side environment (like Angular 2), the web server provides source code to the requesting client. The client is responsible for turning that source code into something it can display to the user.
We specify that Angular 2 is client-side because not all programs rely solely on the client to complete the actions necessary to render a page. In a server-side application, the client's request to view a page triggers the execution of a script that runs on the server itself to generate dynamic HTML. This HTML is then sent to the client browser.
Client-side applications rely on the web client (usually a browser) to turn source code into something the browser can render (like HTML). Server-side applications rely on the server to translate source code into something the client can render.
Other programming languages like Ruby, PHP, and Python aren't inherently understood by most computers. With these languages, the client needs access to a server that understands these languages and can "translate" them into code the client can understand and render for the user. For this reason, frameworks in these languages are often server-side.
For more information, further exploration, or review on these general web concepts, check out the Web Clients and Servers lesson included in many Level 2 Epicodus courses.
The MVC in Client-Side MVC stands for Model-View-Controller. This term refers to the three primary pieces these types of frameworks use to save, retrieve, manipulate, and display information to their users.
The model-view-controller pattern is composed of three main parts: a model, a view, and a controller. (The "C" in MVC often also refers to components, which we'll explore in a moment).
A model represents data. Most applications require some sort of data. For instance, if we created a To Do list in Angular 2 (like we will in an upcoming lesson), we would need to save information about each task. A
Task class could act as our model, containing information such as the description and a
boolean denoting whether or not it is complete.
A view is the portion a user sees, or views. It represents the user interface of the application. The view typically observes the model and automatically updates it when necessary.
For example, we'll use a view in our To Do List to dynamically display a user's list of tasks. It will contain both hard-coded HTML and dynamic areas that display different information depending on the current list of Tasks in our model.
A controller handles input from the user such as clicks or browser events. It is responsible for updating the model when necessary.
However, Angular 2 is phasing out controllers in favor of components so we will not cover controllers in this course. Keep in mind that many other MVCs still rely on controllers.
Many frameworks, including Angular 2 and Ember, have replaced the "C" in "MVC" with components. A component is like a small, reusable package of both front and back-end code that works together. That means components handle both rendering front-end pieces of user interface and any back-end logic required to make those front-end elements interactive. Because Angular is organized into components, sometimes we say it uses the Model-View-Component pattern instead of the Model-View-Controller pattern where one centralized file (App.java, for example) controls the flow between the Model and the Views.
For instance, our To Do List will need to display the same content for each
Task: a description and eventually a checkbox to mark it complete. We will create a component containing this content and render the component for every
Task. The component will display the
Task name and checkbox and will also contain the back-end logic to mark a
Task complete when the checkbox is selected.
Don't worry if you can't envision how this all fits together yet. Just keep these concepts and terms in mind as we develop our first Angular 2 apps. The picture will become clearer as we see each of these moving pieces in action.
Many other frameworks use this MVC structure. Here are just a few (both client-side and server-side):
The MVC concepts you're learning for Angular2 will serve you well in the future as you learn other frameworks which also use the Model-View-Component paradigm.
Even though Angular2 doesn't strictly adhere to the traditional Model-View-Controller paradigm (since the framework uses components instead of controllers), having a strong understanding of models and views will still help prepare you eventually learning more traditional MVCs, too.
In the next lesson, we'll explore how Angular 2 in specific utilizes the MVC pattern. Then we'll begin creating our first Angular 2 application together.
Client: A tool (usually a web browser) that runs on the user's local machine and facilitates their interaction with the internet.
Server: A machine that waits for incoming requests from clients. It contains resources (such as web pages and files) that can be provided to requesting clients.
Client-Side: The actions that must occur to run an application are handled primarily by the client instead of the server.
Server-Side: Considered the "opposite" of client-side, in a sense, applications in which the client's request to view a page triggers the execution of a script that runs on the server to generate dynamic HTML. This HTML is then sent to the client browser.
Model-View-Controller: A type of design followed by many frameworks (including Angular) in which application, and all interactions are managed by models, views, and controllers.
Model: Represents data, and how the data is defined. Most applications require some sort of data.
View: The portion of an application the user sees, or views. It represents the user interface of the application.
Controller: Handles input from the user such as clicks or browser events. It is responsible for updating the model when necessary.
Client-Side MVC: An application that both follows the MVC design structure, and relies on the client to handle most of the actions necessary to run. Angular 2, for example.
Component: A small, reusable package of both front and back-end code that works together. That means components handle both rendering front-end pieces of user interface and any back-end logic required to make those front-end elements interactive.