Site vs. App

This article will break down the high-level overview of how software works in today’s world — and what all those terms mean that you probably often hear in conversations. This is geared for a non-technical crowd (non-technical in the sense that you know how to use technology, but don’t know how to program/make technology) — so if you are a software engineer reading this please don’t feel the need to correct every little detail.

The hot trend it software today is web-based applications. This means applications you access directly in your web browser (like Facebook) as opposed to an icon on your computer (like Microsoft Word).

Web-site vs Web-application

To begin, it’s important to know the difference between a website and a web-application. A web-site simply presents static information and doesn’t allow for much user interaction. Think of a local business’s website. They are there to give you their hours, talk about what they do, and maybe give you contact information. There isn’t much interaction from your end. You are accessing the site, digesting the information, and then leaving.

Now a web-application, this is where the fun happens. A web-application involves various layers and user-interaction. Examples are Facebook, Twitter, eBay, and Gmail. When you access these, it involves logging in/out, processing payments, writing on your friends walls, checking your email, etc. i.e lots of interaction from your end. An easy way to think about it is that a web-site shows the same page to everyone. If anyone visits a local business’s website it’s going to look exactly the same for everyone. However a web-application, will be unique to each user. If you log into Facebook it will be vastly different than if your friend logs into Facebook. You will see your posts, your news feed, your photos; and they will see all of theirs. This lets us know that Facebook is serving a unique page to every single user who logs in to use the platform. Since they have over a billion users — this means that Facebook needs to be able to serve over a billion different versions of Facebook!

Now that you can see the difference between a web-site (static non-changing information) and a web-application, we can dive into the difference of two terms you probably often here around tech friends: front-end and back-end. In short, here are the differences between the two:

‍Front-end: This is the code that drives everything that you can physically see on your screen. For example do you see a large blue button that changes color when you hover over it? That is front-end code saying “make this button blue, make it large, and when the user hovers, change the color”. This is front-end code insofar that you are able to actually see what is happening. A reason you are able to see this is that front-end code is actually executed (or run) directly in your own web-browser! This is a reason why it’s also often referred to as 'client side' code.

‍Back-end: This is everything in the background you cannot see. Think of it as an iceberg. The front-end is the tip, and the back-end is the beast below the surface that contains 90% of the mass. When you enter in your username and password on Facebook and click ‘login’ there is A LOT going on in the background that you cannot see. To yourself it simply looks like “login, wait a second, and boom I’m in”. During that second of waiting though, all the back-end code is doing the heavy lifting. This includes security measures such as authenticating your username and password and making sure there’s nothing ‘suspicious’ about your login. It also includes ensuring the correct user gets the correct account. Imagine if you tried to log into Facebook but instead of your account, you were logged into someone else’s. This would be a big problem! The back-end code ensures everything runs smoothly and accurately.

A good metaphor for these two is to imagine a car. The front-end code says “it’s blue, it has 4 doors, and a back windshield wiper”. Remember that the front-end code is what we can physically ‘see’. The back-end code, is the part below the iceberg that does the heavy lifting. So here this would be the engine. The backend code is the real driving force behind any web-application. Making a car frame isn’t that hard, making a functional car engine though…

Knowing these differences, we can also now say that websites contain mostly front-end code since there isn’t much going on behind the scenes. You go to the local business’s website and what you see is what you get (and the same for everyone). Because you can physically see everything on the page, that is simply front-end code.

For an actual example I can tell you that all front-end code boils down to 3 languages you’ve probably heard of: HTML, CSS, and Javascript. Here’s a breakdown on what each does:

• ‍HTML is the noun. This language tells us what is on the page. It could be text, images, videos, or whatever we want. Using our car example, HTML says “There is a car”
• ‍CSS is the adjective. This describes and styles the noun HTML gave us. It will make text blue, make an image larger, and make the background of the page be red. For the car, HTML says “there is a car” and CSS says “the car is blue”
• ‍Javascript. This is the verb. Javascript can make text on the screen move around, and can make an image appear and then disappear. Basically, it can take actions on the nouns HTML gives us.

So, HTML says “There is a car”, CSS says “The car is blue”, and Javascript says “The car goes forward when the pedal is pressed”

After the front-end comes the back-end. This is where web-applications enter the picture.

Web-applications have a rich back-end and generally if you take all the code written for a web-application (like Facebook) a huge portion of their code is on the backend (and thus you don’t ‘see’ on the screen). The backend is much more complicated than the front-end (remember the backend is the engine, the front-end is the car frame and other parts). Where the front-end has only 3 languages that always appear on every website, the back-end has hundreds of possible languages to choose from. Some popular back-end languages (and companies that use them) are PHP (Facebook), Ruby (Twitter), Python (Google), Java (not to be confused with Javascript — they are totally separate), and many more.

The purpose of the back-end is to serve and ‘change’ the front end. For example, when you log onto Facebook you are presented with your account. Once logged in you see your own pictures and friends. Since you can ‘see’ the pictures this means it’s front-end code. However, the important piece is how that code got there. The back-end code did the heavy lifting and said “ok this is Mike logging in. I’m going to send the front-end code that properly shows him his own account and not that of someone else”. Effectively, the back-end code is there to ‘deliver’ the code to the front-end that you can see from your end.

The Database

Lastly, there is the database. A database is where all your information is stored. Your Facebook pictures, posts, friends, etc are all stored in a database. The reason back-end code exists is because of databases. Databases are extremely good and effective at storing large amounts of information (imagine how many Facebook photos there are in the world), so they are necessary to have. However, front-end code cannot talk to the database. Back-end code has the advantage of being able to talk to both the database AND the front-end. So, when you log into Facebook what happens is that: The back-end code verifies your account information, it retrieves your data from the database (photos, posts, etc), it then serves the code to the front-end that displays the information from the database to your screen!

The Stack

When you hear developers talk about ‘the stack’ this is what they are referring to. Since there is a hierarchy of the pieces of the app, it is eloquently called a ‘stack’. The stack is the front-end code, back-end code, and the database.

Each piece of the stack allows the developer to choose the tools and languages they prefer. A very common method is to use frameworks, which offer a foundation to speed up the development process. In the next post, we will dive into what frameworks are, how they work, and why they can (and cannot) be a good idea.