Frontend And Backend — What Is The Difference?

Frontend and Backend. You’ve probably already heard these buzzwords in the field of web-programming, but what is behind them? I propose to figure it out.

Frontend and Backend. Difference. Source: Vectors Market
Frontend and Backend. Difference. Source: Vectors Market
Frontend and Backend. Source: Vectors Market

Let’s start with the definitions.

Frontend and Backend — How it might look like. Source: Twitter
Frontend and Backend — How it might look like. Source: Twitter
Frontend and Backend — How it might look like. Source: Twitter


Frontend — anything the browser can read, display, and / or run. That is, it is HTML, CSS and JavaScript.

HTML (Hyper Text Markup Language) tells the browser what the content of the page is, for example, “heading”, “paragraph”, “list”, “list item”.

CSS (Cascading Style Sheets) tells the browser how to display elements, for example, “after the first paragraph, there is a 20-pixel indent” or “all text in the element bodyshould be dark gray and written in Verdana font."

JavaScript tells the browser how to react to some interactions using a lightweight programming language. Most sites don’t actually use a lot of JavaScript, but if you click on something and the page content changes without blinking the screen white, then JavaScript was being used somewhere.

If you want to become a Frontend Developer (or at least try yourself in that role 😉) you can start with writing a real web application, that is actually working:


A backend is anything that runs on a server, that is, “not in a browser” or “on a computer connected to the network (usually the Internet) that responds to messages from other computers.”

For the backend, you can use whatever tools are available on your server (which is essentially just a computer configured to reply to messages). This means that you can use any universal programming language: Ruby, PHP, Python, Java, JavaScript / Node, bash. This also means that you can use database management systems like MySQL, PostgreSQL, MongoDB, Cassandra, Redis, Memcached.

Structure of interaction between backend and frontend

There are several major architectures today that determine how your backend and frontend will interact.

Server applications

In this case, HTTP requests are sent directly to the application server, and the server responds with an HTML page.

Between receiving a request and a response, the server usually searches the database for information on the request and embeds it into the template (ERB, Blade, EJS, Handlebars).

When the page is loaded in the browser, HTML determines what will be displayed, CSS determines how it looks, and JS determines any special interactions.

Communication using AJAX

Another type of architecture used for communication AJAX ( Asynchronous Java Script and XML). This means that JavaScript loaded in the browser sends an HTTP request (XHR, XML HTTP Request) from within the page and (historically) receives an XML response. For now, JSON format can also be used for responses.

This means that your server must have an endpoint that responds to requests with JSON or XML. Two examples of protocols used for this are REST and SOAP.

Client (single page) applications

AJAX allows you to load data without refreshing the page. This is most used in frameworks like Angular and Ember. Once built, such applications are sent to the browser and any subsequent rendering is done on the client-side (in the browser).

This frontend communicates with the backend over HTTP using JSON or XML responses.

Generic / isomorphic applications

Some libraries and frameworks, like React and Ember, allow you to run applications on both the server and the client.

In this case, the application uses both AJAX and server-rendered HTML to communicate between the front-end and the back-end.

Outside the frontend and backend

Standalone frontend

The web applications that you are going to create will require less and less Internet connection.

Progressive Web Apps only load once and work (almost) always. You can store the database in the browser. In some cases, your applications only need a backend on first load, and then only to sync / protect data. This level of persistence means that most of the application logic resides directly in the client.

Lightweight backend

The backend, in turn, becomes lighter and lighter. Technologies such as document stores and graph databases result in fewer calls to the backend to re-aggregate data. The client’s task is to clarify what data he needs (graph databases), or retrieve all the different pieces of data he needs (REST API).

It is now possible to create backend services that don’t run all the time, but only when needed, thanks to serverless architectures like AWS Lambda.

Frontend and Backend — Blurred boundaries

Computing tasks can now be moved between frontend and backend. Depending on the type of application, you can make the calculations happen either in the client or on the server.

Each of the options has its own pros and cons. Server — the environment is more stable, has fewer unknowns, but it constantly needs a network connection. Some users are using the latest browsers, and they benefit from client applications that do most of the work and boast a beautiful interface, but then you will alienate users who are not using the latest browsers and high-speed Internet connections.

In any case, it’s good that there is plenty to choose from. The main thing is to choose exactly what is best for a specific task. I hope you have a better understanding of the state of web development today.

Read More

If you found this article helpful, click the💚 or 👏 button below or share the article on Facebook so your friends can benefit from it too.

Written by

Bioinformatician at Oncobox Inc. (@oncobox). Research Associate at Moscow Institute of Physics and Technology (@mipt_eng).

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store