How websites work— for non-techies (part 1)

The hardest part of going for a run is putting on your shoes. The hardest part of building a website is knowing how it works.

Overview

When I think about websites, I split them into 3 parts. The front-end, the back-end and 3rd-party services. Sometimes you only need one, sometimes you need all 3.

I’m going to explain each part, what they do, and how they’re typically put together. I find that CodeAcademy and others will teach you how to code, but not how to turn that code into a living, breathing website.

I’m going on the assumption here that you either know how to code, or will learn the basics. I’m just here to explain how it all fit together.

The front-end: aka Making it look right

The front-end of a website is a bit that you see, the design and content. For a static website (one where the content doesn’t need to change regularly), this is the whole website.

You start with HTML. This language tells the website what words, images and videos it should show. This is what it looks like:

So that’s the content sorted. You then use a different language — CSS — to explain how the website should look. You can change colours, fonts, sizes, positioning, backgrounds, and much more. CSS simply says “for that part of the HTML, make it look like this”. You can tell it how it should look based on the browser size, which is how you create responsive websites that are easy to use on mobile too. Below is the same page, with a bit of CSS.

This HTML/CSS relationship is the same for the page above, and any other website you can think of.

Next, we can add some interactive elements. This is typically done with Javascript, which lets you spin pictures when you hover on them, create games, have live chat on your site, and a lot of other stuff. I’m going to not go into much detail about it here, because although Javascript is everywhere, it is very varied and not strictly needed to create a website.

So, we have a website that says something, and looks great. But what about if we’re building Facebook — there is too much information, that is created in realtime, to have a different page for each person. This is where the backend comes into play…

The back-end: aka Storing and playing with data

A back-end of a website is typically a database. It’s very similar to one you might create yourself in Excel.

When you create a profile somewhere, you typically tell them your name, email address and password. The website takes this information, and adds it to their spreadsheet of users. They’ll have one column for ‘name’, one for ‘email address’ and one for ‘password’. Then, we you go to log in again, some code (which can be in a few different languages) will go to the database and say “does this email address exist, and if so, does it match the password the user entered?”. If so, it’ll let you in. If not, it’ll give you an error message.

The same basic method applies for creating a post on Facebook (or a blog, or Twitter). You create the content on the page, then click ‘Post’. This then gets stored in a different spreadsheet.

When you go to view other people’s posts, the backend will see that you’re trying to view some content, check if you have ‘permission’ (i.e. you can only see friend’s posts) and then bring you the content from that post.

How does this all fit into HTML/CSS from before? The website will use a basic template, and then simply replaces a small part of the HTML content (typically the words and images) with whatever content is in the spreadsheet table.

A lot of websites do cool stuff with the data in their database. Some are constantly running jobs to check the stock markets, and do lots of micro-transactions to make money. eBay’s backend might constantly be updating based on how people are bidding. Uber’s will handle an intense database of drivers, their locations, and tell you where they are all the time.

Backends are hugely varied, but they typically consist of databases (big spreadsheets) and calculations that it does with that information.

3rd party services: aka APIS aka using other people’s stuff

Finally, 3rd party services. These is some of the most wonderful things you’ll find as an entrepreneur/developer/tech person. They’re typically in the form of APIs, which is an acronym for something, probably.

Basically, they let you use awesome stuff other people have built, so that you don’t have to rebuild it yourself.

How each API works is pretty individual, but the gist is:

An API passes information to/from your website.

Uber’s API let’s your website book other people into a cab.

MapBox’s API let’s you create maps very easily (using their point and click interface) and then display these on your own website.

Twitter’s API let’s you pull loads of information about what people are tweeting, from where, and when. You can also post a Tweet using it.

Google Font’s API lets you add one line of code to your website, and have access to loads of different fonts.

Google Analytics’ API lets you add a few lines of code that then track people coming to your website. You can tell where they’re coming from, what they’re looking at, what device they’re on, and much more.

Segment.io’s API lets you easily add live chat onto your website.

The beauty of the web is that the more common a problem, the more likely it is to have been solved. It means that you don’t need to be a genius to build a website, and you don’t need to spend hours building things that are already live.

That’s it!

So there we have the three parts of a typical website:

• The front-end that tells the page what it should look like
• The back-end that tells the page what information to show
• APIs that let you do cool stuff without needing to be super smart yourself

In the next part, I’ll explain how you can turn your own code into a website, step by step.

I hope this was useful, and if you have any feedback I’d love to hear it on Twitter: @gpat_uk.