About frontend and backend, and where my JavaScript runs

“Close-up of colorful lines of code on a computer screen” by Markus Spiske on Unsplash

When I first started learning to code I came upon the frontend and backend terms. Although I had already built a calculator and a weather app, these terms were still not clear to me. Through some research I found this article and this one, both of which I liked as a start.

Frontend & backend

The frontend, often referred as “client-side”, refers to the part of a website that you can see and interact with through the web browser. While navigating the Internet, everything you see including fonts, colors and dropdown menus, is a combination of HTML, CSS, and JavaScript being controlled by your computer’s browser.

The backend, often referred as “server-side”, usually consists of a server, an application and a database and also usually handles the business logic and data storage for the website.

To book your hotel online you open a website and interact with the frontend. The application processes and stores your information in a database created on a server, and that info remains there, so that the next time you log back into the application it’s still in your account.

That was clear. However …

Javascript is no longer restricted to being a browser concept

The JavaScript language (or JS), created in 1995, was initially intended to add small effects to a webpage. Historically, It was used primarily for client-side scripting, in which scripts written in JS are embedded in a webpage’s HTML, to be run at client-side by a JS engine in the user’s web browser. That means that the visitor’s web browser runs the JS code and performs the actions on the webpage.

Node.js, introduced in 2009, is an open-source platform that enables JS to run on the backend, away from the browser, to produce dynamic webpage content before the page is sent to the user’s web browser. That means you can develop server-side Web applications.

Consequently, Node has become one of the foundational elements of the “JavaScript everywhere” paradigm, allowing web application development to unify around a single programming language, rather than rely on a different language for writing server-side scripts.

But if JavaScript can run anywhere, had I been using it on the frontend or the backend? I reached out to IRC (Internet Relay Chat) channels for help and asked: “If I have a program that requests a user to provide two numbers, then calculates the sum and displays the result, is my code considered frontend or backend?”

JavaScript is pretty much the same anywhere. As long as you don’t use browser or Node specific commands, your JS can run in either place

Node has commands that the browser does not and vice versa, so if you don’t use any of those commands your code can run anywhere. For example you can’t read a file off of your computer with the browser, but you can with Node by using fileOpen, fileRead, fileWrite. That doesn’t exist in the browser. Similarly, window.location and document.body don’t exist in node.

If it runs on the browser, it’s frontend. If it runs on your server, it’s backend. The same code can be executed on both

This raised more questions. How to make JavaScript run on the browser or the server if it can be executed on both? What exactly does “run or can be executed on both” mean? What are the reasons to choose running JS code on either?

First, establish your requirements and preferences for the project

Regarding my IRC sum example I learned you could generate the sum on the client-side or send the input to a server for it to process and return the sum. One reason to do the latter would be to protect how one arrived to that sum, considering that client-side JavaScript can be read by the end-user. Another reason would be the need for tracking all sums generated by user input, which involves storing data in a database.

However you should ask yourself if it is necessary to make it backend. Does producing the sum need to be protected, stored, or something else? Do you want to indefinitely run a server for a calculator app to work? If it’s a website that you want google to find, then you probably need to serve that HTML page somehow. If you’re building a forum where users can create new topics after filling out a form you’d need somewhere for them to save that topic so that other people can see it. And you can’t accomplish this with just client-side JavaScript. Another example is user input itself. You can put in sanitization and logic-checking in the frontend, but you’d also want to do the same or similar routine server side when receiving the input. Anything running client-side can be seen, read and torn apart so definitely operate under the assumption that anything in the browser is exposed to anybody and ultimately the end-user cannot be trusted.

Your code runs where you make it run

It’s all about where the code is executed. A JS script could run on both the frontend or the backend.

• If you save it as server.js and then run “node server.js” on your server, then it runs on the server (backend)
• If you include it in an HTML page that you send to a browser, then it executes in the client (frontend)

It was finally clear to me that frontend and backend refer to where you execute something, not to what you execute. Something “is” not server-side, it is “used” server-side, and “designed” to be run as a server. Similarly it can be designed for and expected to be executed in the browser.

There’s no such thing as a “frontend” or “backend” sites

Frontend and backend refer to the different parts of your application, and to whose system they run on. Frontend means “whatever runs on the user’s system”, whereas backend means “whatever runs on a remote server”. In some projects, the backend does most of the work and in others the frontend does, but there’s no choice between “having a backend” and “having a frontend”, you always have both. The question is just which logic exists where. For example, the HTML and CSS parts run on the frontend, and your validation code might run on the frontend and the backend. So if a part of your application runs in the browser it’s frontend, but if it runs on your server it’s backend.

If I deploy my calculator on a server and expose it over HTTP, then the code is still only the frontend, but I do have a backend, the server that I use to send it to a user. My backend would just only have one task, sending files to the user when they request them. In the case of my weather app (which stores data to a db) the backend would be responsible for the logic and the frontend only does the displaying/styling of data (using HTML/CSS). It would be an app where the logic is in the backend.

Where possible, always opt for having as much logic as possible running on the backend system, rather than the frontend

The reasons this is preferable:

1. it’s a predictable environment. You know exactly how much processing power you have available. For example, a server doesn’t have a battery that drains, it doesn’t have a poor processor in a budget phone, it doesn’t share its environment with several other apps all trying to do stuff simultaneously
2. it’s a controlled environment. The user cannot access anything other than what you explicitly send to them, or accept from them
3. it’s an environment that you can monitor. If an error occurs server-side, you can reliably log that error and do something about it, whereas if an error occurs client-side, there’s no guarantee that you’ll ever see it, or be able to investigate it

One limitation of a mostly-backend application is that for the page to change in a meaningful way, you need to navigate to another page, or reload a page

That is not viable for example with a chat application because the page needs to change as the messages come in. So the reason a chat app can’t really be a mostly-backend application, is that the model of “the user interacts with something and then a new page is loaded” doesn’t work. Messages still come in, even if the user does nothing.

However, for my weather app, the page only needs to change if the user interacts with it, and it’s not time-sensitive. The user might pick a different temperature unit or a different city and the page reloads. I could speed things up with client-side JS, but it can work with only backend logic.

Treat the frontend and backend as two entirely separate applications that happen to be written in the same language. There’s no inherent relationship or connection between the two

The frontend JS doesn’t know that the backend is running Node, just like the backend doesn’t know that the browser runs JS. There’s no direct connection between the two, everything goes over HTTP. If you want to communicate between the client and the server, you use HTTP. The client can never see the server code, it can’t call the server code, and the server can’t directly call client code either.

HTTP (HyperText Transfer Protocol) is the underlying protocol used by the World Wide Web. It defines how messages are formatted and transmitted, and what actions Web servers (the computer hosting the website) and browsers (client) should take in response to various commands. For example, when you enter a URL in your browser, the browser turns the URL into an HTTP request message and sends it to the server. The server interprets the request message, and returns you an appropriate response message, which is either the resource you requested or an error message. The browser then interprets the response message and displays the content.

Here hoping this helps throw some light on the frontend and backend terms, and where JavaScript runs. 😉