Where Your Code Runs — Browser, Server, and Phone Apps

This article covers where the code you write runs.

There are three places it runs: inside the browser, inside the server, and inside the app installed on a phone.

Web app code runs in two places: the browser and the server

The software that reads HTML on the user's device and draws the screen is the browser, and a computer set up to accept requests at any time is a server.

The common browsers are Chrome, Safari, Edge, and Firefox.

The language a browser can read and run directly is JavaScript.

my-app is made of four files: the two for the screen are the frontend, and server.js, which takes bookings, is the backend.

When a user opens the URL, only the two screen files reach the device.

Even within the same my-app files, the place they run splits into two frames.

Only index.html and app.js reach the device, and after that, only data passes between the two frames.

Of the next three lines, the middle one exists only inside the browser, and the last one exists only inside the server runtime.

console.log("Book");
console.log(navigator.language);
console.log(process.version);

Run these three lines inside the browser, and the results come out like this.

Web app code splits into two places

index.html and app.js, which build the screen, reach the user's device and run inside the browser.

server.js, which takes bookings, never leaves the public server, so text you do not show to others goes on that side.

To make it usable on a phone, you either keep it a web app or build a native app

Phones have browsers too.

my-app runs as it is if you open the URL in a phone browser.

That is the first way, and there is no need to rebuild the code.

The software that manages app startup, the screen, communication, and files inside a device is the OS, which on a phone is iOS or Android.

The second way is a native app — an app put directly on the OS and run there — which you build separately for iPhone and for Android and deliver through the App Store and Google Play.

Putting an app on a device so that it can be started from the OS is installing it.

As the diagram shows, a native app sits on top of the OS, while a web app runs on top of the browser inside that OS.

A program or device that sends requests to a server is called a client, and the side that runs on the device is also called client-side, and the side that runs on the server, server-side.

You choose between them by lining up the strengths and weaknesses.

A browser gives you only the features the browser provides, and when you want device features beyond that, you build a native app.

The same goes for when you want people to find you through store search, and if neither applies, you keep it a web app.

There is also a way to build apps for several operating systems from a single codebase, and the name for it is covered in the next article.

However you deliver it, server.js is shared

Keep it a web app, and it runs just by opening the URL in a phone browser.

A native app is built separately for iPhone and Android and installed from a store, but whichever you choose, server.js and reserve.db stay on the public server.

What differs between running on your own machine and running live

The my-app you built can still be opened only from your own computer.

The inside of your own computer, seen as a place to run code, is called local.

The number at the end of the http://localhost:3000 you open locally is there to tell destinations apart inside the same computer, and it is covered in this course's article "What Happens When You Enter a URL."

Inside the frame is your own computer, a single machine, and the browser, server.js, and reserve.db are all in there.

Once you publish, the contents of this one machine split into two places, but what fills each role does not change.

The names of the files that run are the same locally and after publishing.

Moving the four files together to a public server outside your own computer is deployment.

The four files move to the public server, and the only thing left on your computer is the browser.

Open the same example.com from any device, and the same screen appears.

As long as it stays local, it does not accept requests from outside, so other people cannot use it from their devices.

localhost:3000 points at the device you typed it on, so typing it on a colleague's phone does not reach your computer.

What the work of publishing involves is covered in this course's "Deployment and Environment Variables — From Working Locally to Going Live."

Change where you put it, and you change who can use it

The my-app you got running by following a beginner book's steps can be opened only from inside your own computer — that is, locally.

Move the four files to a public server and other people's devices can open it too, and that work is deployment.