DEV Community

Sloan
Sloan

Posted on

What's the difference between Front-end and Back-end development?

This is an anonymous post sent in by a member who does not want their name disclosed. Please be thoughtful with your responses, as these are usually tough posts to write. Email sloan@dev.to if you'd like to leave an anonymous comment or if you want to ask your own anonymous question.


I'm brand new to development and am trying to understand the difference between front-end and back-end development.

I think I kinda understand that front-end is what the user sees and back-end is how the information is retrieved, but I imagine there's a bit more to it than that. I would really appreciate hearing others' thoughts and explanations on this.

Analogies and examples would be very welcomed! Thank you all very much. 🙏

Discussion (30)

Collapse
leouofa profile image
Leonid Medovyy

I’ll explain it from a simplified monolithic perspective (Ruby on Rails, PHP, etc), because it’s easier to understand.

The browser displays your webpage. HTML is the language of the browser. It tells how the page is structured. CSS describes how it should look like and JavaScript adds interactivity (think light boxes etc).

You can write all of the code by hand and it’s going to work fine. That’s front end and it’s how web started.

Now imagine you have a cookbook your grandmother left you and you want to create a website that’s going to serve up recipes.

There’s a lot of recipes and you’ll end up writing a lot of identical HTML with the only difference being title, description and ingredients.

That calls for automation. The server can store the recipe in the database (think of it as excel). You can use a programming language to go through every record one by one and generate the HTML for you. That’s backend.

Collapse
jeremyf profile image
Jeremy Friesen

Can't help but add a bit of a joke… "One's a pain in the rear and the other is a headache."

For me, back-end development is about navigating and mapping the "canonical" persistence layers (the RDBMS that holds all of the articles, comments, users, etc). It's about sending that information from the server to the client. So creating HTTP end-points that the browser makes requests.

An analogy is a fast food restaurant:

Front-end is walking up to the register looking at the menu, placing an order, and then getting your meal. Back-end is the grill and fries station preparing the food, maybe grabbing things from the refrigerator, or opening a new pack of buns.

Collapse
aarone4 profile image
Aaron Reese

What about the maitre de (load balancer/router) and the bus-boys that take the food from the kitchen to the table (middleware) or the comics chef preparing food for cooking (API layer) or they team that mend the cooker ( DevOps/architect) or the team that design the menu (UI/UX) or the team that sets the menu (Business Analyst/Product owner)

Collapse
jeremyf profile image
Jeremy Friesen

Love this, and it's so very spot on.

Collapse
webbureaucrat profile image
webbureaucrat

I mean... yeah that's pretty much it. These aren't technical terms so much as they're generalizations or shorthand.

For example, server-side rendered HTML is a template that represents what the user would see but includes some logic that runs on the server before it's sent over. (E. g., if I wanted to write one HTML file which could display the username for whichever user is logged in, I might say <h1>Hello, @{firstname}</h1> and then when requested for a certain username, the server replaces the placeholder and sends down <h1>Hello, Sloan</h1>.) Depending on the context, I might call this "front-end" or "back-end". It is front-end in the sense that it is mostly HTML and would be written by a front-end specialist (or full-stack dev), but on the other hand, if I'm debugging, it's important to know that it's running on the back-end--the server.

So where I'm going with this is that while there is a grey area between, I think your definitions are about as good as anything. Give yourself credit for understanding more than you think. :)

Collapse
peerreynders profile image
peerreynders • Edited on

Just to augment what's already been stated (from Front end and back end):

  1. Back-enders work with only one environment, their server. They have the option of changing their environment; for instance by installing new software or upgrading the hardware.

  2. Front-enders work with an unknown number of radically different environments, ranging from state-of-the-art desktop computer to three-year-old, crappy phones with limited memory and processor time. They cannot change these environments because they have no power over their users’ browsers. Still, their code should work in all of them.

Either area has it's own unique challenges and have gotten more complex over the years. The front end is known for "JavaScript fatigue" and there are always the obligatory "How it feels to learn JavaScript in 20xx" articles but the back end added over the years containerization, container-orchestration, cloud-native computing and dev ops into the mix.

This typically isn't an issue in larger organizations where individuals can focus and master a particular area (e.g. database administration) but can be challenging in smaller teams where everybody has to fill multiple roles - lest they use some SaaS to take care of the some of the details (trade off: that vendor now controls their view of the world and dictates the required skill set).

And even when you can specialize you have to communicate with other people. Members of a product team will tend to have varying technical expertise, so while it isn't necessary to become a "fullstack developer", full stack awareness makes team communication a lot more effective. Ultimately all these bits and pieces have to work together to create a working whole.

The reason why front end is often seen as "easier" is because it seems easier to get started - learn HTML/CSS/JS and your off to the races, right? This overlooks the variety and combinations of rendering options on the web, each of which is suitable for different use cases.

"Just learn React!" somebody says;

"Indeed, we've started to notice that many newer developers aren't even aware of an alternative approach, as they've spent their entire career in a framework like React."
SPA by default (Hold)

Also the industry doesn't even apply the term front end developer consistently. At the very least a front end developer has to communicate effectively with visual design and UX experts. Visual design is often acknowledged to require a very different mindset from development. Yet there is a growing demand for designer-developers - a designer-developer is more versatile and one person is cheaper than two or three but it also cuts communication overhead which can speed things up (unless there is too much to do for one person at any one time).

It's not that one has to know everything to get started—far from it. But it should be clear that either way working in the back end or front end area is a continuous journey (and not necessarily strictly separated) of learning (often resolving fewer "known unknowns" than it adds).

Collapse
etampro profile image
Edward Tam

front-end and back-end development are still very broad terms, even within each category there are multiple domains that can be very different from each other.

But let's say in terms of feeling, I think the biggest difference is that front-end in general produces a lot more code and you get instant gratification (like a artist painting a picture) vs backend is more logical and computational oriented (like a mathematician). Obviously, front-end logics can be complicated, but I think in general you spend more time trying to visualize things comparing to backend.

Collapse
scottshipp profile image
scottshipp

There are many good answers here.

But I want to chime in with something that I think is getting overlooked.

It's important to point out that frontend and backend are terms that grew up around the web and programming for the web. They aren't great terms for someone starting out, unless that someone intends to only program web applications like Google Docs or Spotify-in-the-browser.

(Which is what many of us do, and that's totally fine. It's just a distinction that should be mentioned.)

There is a lot of other programming. Code is running inside your microwave, your car, your smartphone, your television, etc. And also inside your computer: such as the browser itself.

Usually, none of these things fall under the "frontend" or "backend" programming labels. Instead, you will hear labels like "mobile," "OS," "desktop," "embedded," etc. "Frontend" and "backend" relate only to stuff that happens after you type a URL in a browser and press enter (at least, the way most people use these terms.)

If you are starting out and want to think about any programming outside of things that you can point a web browser at and interact with, then forget about "frontend" and "backend" programming for now. Just focus on learning a good language and the rest will follow.

On the other hand, if what you do want to do is create something like Facebook or the site you're looking at right now, then they're good terms to know and you can focus on one or the other. In that case, think of frontend as the programming related to anything that happens within the browser. And think of backend as everything else. It could be data access, a long-running process like generating a file to download, some kind of communication with the outside world like sending someone an email or text, placing an order, or many other things. These are usually performed by "web services" which are also accessible via the web, but just not in the browser-renderable formats.

HIH

Collapse
theaccordance profile image
Joe Mainwaring

If you were to think of building a web application like building a car, front-end engineers would add the paint, rims, window tint, interior, and accessories. Backend engineers would be the ones who deliver the engine, transmission, suspension, and chasis.

Front end will focus on what the end user sees and interacts with. Backend will focus on making it actually work.

Collapse
aarone4 profile image
Aaron Reese

This is where the confusion comes in though. Front-end USED to mean the HTML, CSS and text copy and back-end was anything on the http request.
TODAY front end (imho) also requires form validation, dynamic update of DOM based in user actions, management of the data store, local storage strategy to work offline, async fetch and post data without a page refresh, manipulation of data from an API endpoint that is not in quite the right format
All if this requires extensive knowledge of JS and/or frameworks, computer algorithms, and entity modelling. If you include the new WASM technology then you will also need to know A LOT of .net/python/rust/go

Collapse
theaccordance profile image
Joe Mainwaring

All of that was either in play a decade ago or was just coming out, and I can speak from experience that you don’t need to learn all of that.

Frameworks exist to help accelerate implementation of most of the features you listed.

Collapse
hunghvu profile image
Hung Vu

Here is my personal definition.

Front end: Whatever runs on your browser engine, which means, locally. Be it a user interface, or internal computing. It's not necessary for users to see a component on screen to be considered as front end.

Back end: Whatever runs on the server, located elsewhere on the globe that can be connected via a specific network protocol.

Collapse
j_mplourde profile image
Jean-Michel Plourde

I'll try an answer as simple as possible.

Backend: has the data, has the ability to transform or return that data when asked about it on one of its endpoints (urls). When the data is sent to the client, there is no possibilties for the backend to interact with it unless you reload the page.

Frontend: After the data is received, you might want to represent your data in the browser in a way that a user can interact with it. The frontend will be able to alter the presentation with the data it already has. If it requires more data, it will call the server (backend) without the need to reload the page.

Collapse
ricobrase profile image
Rico Brase

Front-end developers build applications primarily used by humans.

Back-end developers build applications primarily used by IT systems (computers, other applications e.g. front-ends, etc.).

Collapse
aarone4 profile image
Aaron Reese

Is a GraphQL query front end or back end?
The query is crafted by the user but the resolver is designed by the API team

Collapse
ricobrase profile image
Rico Brase

But in the end, the GraphQL API is still consumed by another IT system, not a human.

GraphQL is just another way of accessing the backend, just like REST, SOAP, exchanging raw byte data, etc.
It doesn't change the overall structure of the backend as a system.

Thread Thread
aarone4 profile image
Aaron Reese

that was kind of the question. Would you expect a FE developer to be able to form a GraphQL query to get the data that they need or would you expect the BE Developer to tell them what the query needs to look like.

Thread Thread
ricobrase profile image
Rico Brase

Why would this be of any relevance for my idea of backend and frontend developers?

It literally does not matter if the frontend dev writes GQL queries theirself or get them by a backend dev.
Ideally, the frontend dev should be familiar with the interfacing technology used - whether it's GQL, REST, or something else. It's their job to gather the data provided by the backend.

Thread Thread
aarone4 profile image
Aaron Reese

I think it is critical as to where the line is drawn between FE and BE which is why I asked the question. Would you expect your FE developer to be able to structure a complex query to fetch the required data efficiently, or would you expect the BE Dev to develop the data Map that the FE then renders
For a concrete example.... Although I was doing both BE and FE on this project I had data that was in 4 dimensions: style, size, colour, location. Do I take the computational hit and create nested JSON of all attributes which makes presentation easier (equivalent to a noSQL document model) and if so so I so size in colour or colour in size, or just use object keys and dynamically map the data from the arrays using their keys (more like a RDBMS model) the latter is more flexible but requires run time overhead. The former is probably more responsive but with a larger time to first interaction and only optimised for one access pattern.
Personally I would only expect a Senior Dev to be able to make that call and in reality it is more likely to fall to the BE dev to structure the data as required for consumption by the FE. Not saying that is right, just practical reality. And if that is the case should the multi -level JSON object be created at the database or API level where there is likely to be more processing power and the ability to cache the model.

Collapse
realneilc profile image
Neil Chaudhuri

I think you nailed it. That's exactly what front-end and back-end are.

At least as traditionally defined.

But I think modern software development should force us to rethink things. For example, what about tooling? What should we call the development of Gradle or Turborepo? DX is super important, but the tools that make it happen don't neatly fall into the front-end vs back-end dichotomy.

So one way to look at this is Product v Platform. What if Product was everything that users pay for while Platform is everything that allows you to build and scale?

Anyway, just food for thought, but I think you are totally right.

Collapse
stiby profile image
stiby

As most have already said your fronted is a user interface which I'd call a client. A client can be a browser, a mobile app, a desktop application.

A client has a backend which provides services used by the clients.

Collapse
coderamrin profile image
Amrin

to demonstrate i'll say, Imagine a Mobile Phone.
What you see is the Frontend, and what is inside the cover that runs the phone is the Backend.

In a javaScript stack:
Frontend is built with: Html and Css and
Backend is built with: Node.js

Collapse
perssondennis profile image
Dennis Persson

I've explained the difference with the help of the human body here. Lots of memes but quite accurate actually :) It explains microservices and testing as well.

Collapse
tqbit profile image
tq-bit • Edited on

Frontend developers

are responsible to design user interfaces (UIs) for the web. They're doing so using

  • HTML & CSS for structure and styles, respectively
  • A browser in which the website / webapp can run
  • Javascript to give the user a way to interact with the website / webapp.

Frontend devs work closely together with designers and implement simple to sophisticated UIs. They also collaborate with backend developers to show persistent data from the backend to users of the website.

Common technologies on the frontend are:
-> Javascript frameworks, such as React, Vue, Angular, are used to streamline the process of development
-> Browser APIs, such as Websockets, Fetch or WebGL

Backend developers

are responsible for the serverside. Since this is a broad term, I'll exclude system architect- and admin tasks to focus on the basic idea.

Backend developers are responsible to build the Information Architecture of a system on the serverside.

Backend devs are often specialized on one or few technologies. They're working closely together with architects and admins to design IT systems. At the same time, they're assisting frontend devs to bring data to the customer. Or collect and organize their data, respectively.

Common technologies are, only to name a few:

  • Selfhosted, batteries-included solutions, such as the LAMP - stack
  • Standalone runtime environments, such as Node.js, Python3 or PHP, to develop custom backend applications
  • Each of them comes with famous frameworks, such as Express for Node, Flask for Python3 and Laravel for PHP. They aim to make development of bigger applications easier

Modern technologies enable backend devs to outshore administrative tasks to third party services, such as Amazon Webservices (AWS) or Netlify. This again is a topic for its own.

Collapse
adam_cyclones profile image
Adam Crockett

In restaurant terms:

Frontend: the chef, waiting staff and front of house

Backend: the people who built the restaurant, plumbed in the gas and electric

Collapse
aarone4 profile image
Aaron Reese • Edited on

Absolutely disagree.
Waiter is the http transport. They take a request (order) and return a result (food). They have no say in how the result is achieved
The chef is the web server. They take the request and pull together whatever resources are required to achieve the result. The chef is very definitely back end.
You can think of the maitre'd as a load balancer; they make sure that no one connection (waiter) is overloaded and limit the number of diners so that the chef is not burnt out by too many requests (DDoS)
What you described as back end is actually infrastructure and architecture. They are important but not necessarily relavent to this discussion

Collapse
adam_cyclones profile image
Adam Crockett • Edited on

Well this is a new kind of disagreement 👨‍🍳👩‍🍳 - I have kids, didn't sleep well last night and I think I wrote this at 4am...

You think of it how you like thats alright by me. I can barely read your reply anyway 🥴🛌

Collapse
adam_cyclones profile image
Adam Crockett

Im glad that atleast the idea served some inspiration and you whisked up another analogy

Collapse
danielbellmas profile image
Daniel Bellmas

Coder Coder explains it pretty well for the visual learners: youtube.com/watch?v=kQeAY_13XgY

Collapse
eugenman profile image
Eugen • Edited on

To simplify. Development is a car.
Frintend is car body, tires, glass, bumper etc. outer parts.
Backend is engine, transmission, gas system, inner parts you can't see.