The difference between Frontend and Backend Web Development

In this post I want to help you conceptually make the move from frontend to backend, in the context of Web development.

Let’s first define what is frontend. Frontend is the term that we use to identify programming inside the browser. We also call it client-side Web development.

In the frontend side you worry about creating and distributing an application that runs on your clients machine, which can be a laptop, a desktop computer or a mobile device. You build something that you distribute and then runs inside each client browser.

In the backend side you architect and build an application that runs on a single server (in the beginning), and every client accesses that application. The application runs in the server, an environment you control, and then you either send to the browser an application using server-side rendering of the app, or you create an API that just distributes JSON data to the clients (something pretty common lately, especially paired with frontend frameworks/libraries like React, Vue and others).

You can already see there’s an overlap here. The backend can be used to serve the frontend-facing application that will run in the browser.

HTML, CSS, JavaScript, images, animations, React, Vue, Svelte, CSS-in-JS, state management in the frontend, performance optimization, all of those topics (and many more!) are linked to frontend programming.

Some kinds of applications just need the frontend part. My website, for example, does not have a backend. It’s a static website generated using Hugo, and all the work I do on it is considered frontend programming: the CSS, the markup, the JavaScript I use to power search, for example.

Frontend programming has its own unique set of challenges: the browser support of features, for example. Or performance of an application on a low-end device. Building single-page applications.

Backend development is completely different from the frontend. First, you exit the browser environment, which is freeing on one hand, but can also be overwhelming.

Why? Well, you have more choices.

In the browser, the programming language choice is always JavaScript. Or a language that compiles to JavaScript, like TypeScript, Elm and others.

In the backend you can use anything you want. My usual choice is Node.js, because being JavaScript based I can be an expert in one single language, and work in both the frontend and the backend with JavaScript.

But you can use frameworks like:

• Django which is based on Python
• Laravel which is based on PHP
• Rails which is based on Ruby
• Phoenix which is based on Elixir
• Deno which is based on TypeScript

and many others, including more enterprise-oriented ecosystems like Java and .NET.

And I’m not even mentioning Go and Rust, two great choices.

This is probably the greatest strength of backend programming: you have lots of choices in the language you can use, so you can use the one you prefer. But it can also lead to “analysis paralysis” if you’re not sure what you prefer, yet.

On the backend we don’t have the problems we need to face on the frontend. One thing I often hear is that frontend development goes too fast. New things pop up every day and the best tool change from month to month. Which is not a false statement. The backend in comparison looks more a low-paced ecosystem, especially in well-known and mature environments and tools, and a well-written backend can feel modern for years, while we can’t say the same thing in the frontend.

In the backend we have its own set of issues, of course. For example, how to store data in a database. How to choose the right database. SQL vs NoSQL. Microservices vs monoliths. How to deploy our application, and where. How to handle more traffic. How to securely deal with data and requests. How to test and handle error handling. How to choose the right architecture.

Then we have topics that overlap with DevOps like how to use Docker and Kubernetes, how to set up a Continuous Integration and Continuous Delivery workflow, how to deal with Linux, infrastructure and server-level networking. We need to face choices like using our own VPS servers or using a PAAS like Heroku, or going serverless with AWS Lambda. Depending on the company and team you work in, you might need to be ready to tackle those topics, too.

And we need to figure out how to connect the backend to the frontend, of course. How to build an API. GraphQL vs REST. How to handle authentication. How to make the API fast at scale. Those are topics that involve both frontend and backend in the quest to make them talk to each other.

It’s a lot of stuff and you can find entire books on those topics, and this is why we have the separation between frontend and backend developers, and why being a full-stack developer that can navigate through all those problems is a valuable skill to have.

And of course you don’t have to know all of those things to be qualified as a frontend or backend developer. You need to know those things at a high level, to get an idea of what you don’t know (yet). But it’s a great idea also to specialize in one particular niche and become great at that.

For example you can be a backend developer that does not know how to deal with advanced Linux configuration, and rely on a PAAS like Heroku to do that for you. Or use AWS Lambda to avoid that altogether.

The important thing I think is to know when it’s best to learn and do-it-yourself versus using tools that support your work.