How to build a website
June 1, 2018
The OG appearance of the site
Consider this the grand opening, a christening, a welcoming party.
What you're reading right now is the block barbecue party for the new neighbor: my website! I thought a great topic for the inaugural blog entry would be about something I recently completed: how I went from an idea to actually creating this website.
My audience is my former self: someone with zero website creation experience. And finally, disclaimer: I ~~might be~~ am certainly wrong about how some of the processes outlined below actually work. Please call me out on it!
- Why a web page appears as it does
- A framework
- A database
- Location of files and how they're deployed
Why a web page appears as it does
Well like all things computers, it starts with bits and bytes, 1s and 0s. But climb the ladder of abstraction and let's get to Hypertext Markup Language (HTML). You've probably heard of it. HTML is a language written to make it easy for humans to tell computers how to render content in a browser. This webpage you're looking at right now is HTML. If you right-click somewhere on the page and click the Inspect option, you will see all the HTML that went into creating this page! Great!
Someone could write all the HTML themselves for a website, but it would take a long time and be difficult to remain organized. Others have thought of this already, and created already-put-together HTML chunks that developers commonly use. With only a tiny bit of code, a developer can link to where that nice HTML chunk rests elsewhere on the internet. This method also bonuses as loading content faster in some ses. This website right here was built to make use of this type of service - a Content Delivery Network (CDN). I am using a popular one named Bootstrap. Bootstrap handles the pretty navigation bar up top, the footer with the icons on the bottom and organizes the layout of the rest of content on the page. All this using with way fewer lines of HTML code than if I had hammered it all out myself.
This process of turning languages like HTML into monitor output is called rendering; it's the principle job of browsers. Browsers do a lot. We'll skip over a bit of their duties and stick to how they interact with HTML. A browser takes a URL (Uniform Resource Locator) and uses it to send a request to a server (a computer). The server does internet magic and follows a trail to where the URL leads, gets the information from the other server, and sends it back to your browser. The info it sends back typically consists of HTML code. Great. So how is it rendered? The browser take a look at all the HTML and other applicable code received in its request, and using a set of rules it decides what content should go where on the computer screen. This boils down to which pixels on your browser should display what color. Upon a change, such as scrolling on a web page, the browser reloads (almost instantly on most 2018 browsers) the page based on the HTML.
So a simple website could be a single page of HTML that shows one page. However, when growing the website - such as adding more pages - it would be quite the headache to write entirely new pages of HTML everytime.
To make it easier to add pages to a website there are two key tools beyond simply writing extra basic HTML pages: a framework and a database.
The framework is like the brain. The organizer. A framework essentially uses some shortcuts to reuse code already written once in another location or webpage.
The framework - which is coded with a language different than HTML (in this case, Python) - can instruct the website to re-use previously written HTML code. For example, the same footer is on every page of my website. Yes, I could have copied and pasted all the HTML code for the footer to every single page on this site, but the framework used here automatically applies that code to each page. It keeps things much cleaner.
For the database, it works a little like this. The database functions kind of like a hard drive for the website. A database is setup to store and then spit out information. It could be email addresses, passwords, blog posts, etc. This is different than an HTML page, which is not optimized for storing or recalling pieces of information. Additionally, depending on who is accessing the website for what purpose - a database allows unique information to be shown to specific users. Plain HTML doesn't judge like that.
For example, a simple database is like a simple, editable Excel spreadsheet. Let's illustrate. Say you have a commerce website. You want your customers to have an online account with a shopping cart, be able to add and remove items to the shopping cart, and be able to logout of the website and return later to find the cart with the same items still in it. A database makes this all possible. Customers can make their account, which is saved in the database. When they add items to their cart, that too is saved in the database. If they remove an item from the cart, the database is edited to remove the item. When they return to the website a few days later, their account information and cart inventory is extracted from the database, put into HTML form, and shown back to them.
At the time of writing this website is not currently using a database to obtain any information from users (like you!). I considered implementing comments on the blog posts, which would have used the database to store and show, but I decided to stick with Twitter. Still, this site's database creates, saves, and then displays the blog posts and journal entries on this website. It also automatically updates the /blog page after creation of new posts. Django makes it easy to talk to, manipulate, and add or extract information from from the database then present on the website. Like web frameworks, there are many different databases. This site uses PostgreSQL.
Location of files and how they're deployed
HTML files. A database. Python code to help organize and optimize everything. Where is all this - stuff - stored? For starters, it's not on my laptop where I wrote it.
These files are all stored in a remote server(s). Again, that's a computer or computers that I can't physically see or touch. There are a plethora of options for your average Joe to use servers - as of the time of writing this site is hosted on a free server service (Heroku free tier) that is known for being simple to setup. Yet, if this site begins to get any kind of sizable web traffic then I'll need to pay for more or better servers. The action of sending and storing all the website files from my laptop to the server and connecting the server to the URL (which I paid for the rights to use for a set duration of time) is called deployment. Heroku is the server-hoster and deployment option I am using at time of writing. As mentioned, it's known for being simple and easy to setup as it does a lot of standard stuff for the user already. It also has a free-tier for baby websites (like this one).
How to communicate with Heroku? Heroku plays nicely with a tool and service called Github. Github is immensely popular and super useful for many people in the programming world. It's out of the scope of this blogpost, but in summary a user commands the Git / Github program to send the files to servers owned by Github, and then from those servers to the ones for deployment controlled by Heroku. Essentially, Heroku and Github work together upload all the website files via the internet and save them on their servers. To make changes to the website files, one must first make them on their own computer, then "push" the updates to the Heroku server via Github again.
Wrap it up
There's a whole lot more to a website - mostly stuff of which I'm not qualified to write about. Next I'm going to be looking into Search Engine Optimization (SEO): how to make the website appear at or near the top of Google/Bing/Yahoo/DuckDuckGo searches for "Spencer Tollefson". There's also website security (Django - this framework - does a lot of that under the hood already), user analytics (information about who, why, when, where, and how people are visiting the website), and other topics I don't know even exist yet.
Please tweet at me (button below) or email with any comments on this piece. As I disclaimed at the outset, I'm sure there are factual errors in this post. I'll edit the post when you let me know what they are.