Make a Website

Home Sweet Home

To the Blog!

This blog supports RSS! Find it here!, and if you don't know what that is, you should learn! (or join my newsletter instead)

If I had a nickel for every time this damn post would have been a helpful resource for someone in the past few months I’d have at least 8-10 nickels.

So fuck it.

Why build a website

You should build a website. I am talking to you. I don’t give a shit who you are. I don’t give a shit what you know. I don’t give a shit how many brain cells are left.

If you can read this, you can, and should, build a website.

I’m not convinced

Go read my article on media and the indie web (if that’s up). Go surfing. Check out some forums

Still not convinced? Bullet point time.

• Personal websites and the indie web are non-evil social media.
• Personal websites allow you to fully own your online presence.
• Personal websites reduce your reliance on corporate platforms and algorithms.
• Personal websites allow you to control exactly how you express yourself online.
• You can share your chipotle order or wishlist with people without typing out the whole thing
• You look really cool

Woe! No brain cells remain! I am simply too stupid!

That is a cop out. You are not too stupid. You simply do not have the time, mental capacity, or desire to learn.

Which is totally ok! If that is the case, no shade whatsoever. You’re welcome to leave and pull this guide back up if/when you can continue.

I categorically reject the idea of measurable intelligence though. Brains are big and mushy and weird and complicated. Any attempt to encapsulate them in a number or metric is going to be incredibly biased if not entirely contrived. Don’t pre-reject yourself from learning just because someone (you included) has convinced you that you are incapable of it. As long as you can let yourself be curious, you’ve won. You have nothing to lose but your chains.

What would I even put on it?

• Anything
• Everything
• Nothing

If you’re in doubt, start a blog! Write about stuff! Your interests. What you’ve been up to. What art you’ve been reading, looking at, playing. That squirrel that’s outside right now.

One thing that I’ve found it really helpful for is as a resource to give to people! If I find myself explaining or infodumping the same thing repeatedly, I turn it into a blog post, so it can act as a resource.

Own your shit

Corporations own the internet. Fuck ’em.

TODO

What is a website?

Before we hit the tutorial, I want to break down the basics of what it is that you’ll be making, and how it works, in plain english. (though in the interest of brevity, note that I may oversimplify some things)

HTTP for noobs

HTTP, hypertext transfer protocol, is the most common way that two modern computers will talk to each other. There are other protocols out there, like gopher and gemini (these are cool!), but the internet runs on HTTP, so we will not be talking about them today. Eventually, with infinite time, I would love to.

Regardless, these two talking computers are commonly referred to as a “client” and a “server”

You can think of a client as someone using their laptop or phone with an internet browser.

You can think of the server as another computer somewhere out there running some software that tells it to wait for a client to ask for something.

When the client sends a message to the server, how does the server decode and read what it’s saying? The answer is HTTP. This is why you see “http://” and “https://” at the start of URLs.

Both the server software (called an HTTP server) and the client software (the browser) have both agreed that they will be talking over HTTP, so when the client says “Hey can I have a website please,” the server knows what they’re asking for, and can give it to them.

The Layperson is probably aware of “404: Not found”; This is actually an HTTP response! When the client asks the server for something that the server just doesn’t have, the server returns a 404, telling the client “Nope, don’t have that. Sorry!” As a fun rule of thumb, you can decode return codes with their first number! 100’s are informational, 200’s are successes, 300’s are redirections, 400’s are client errors (your fault!), and 500’s are server errors (my fault!).

Want to learn more about HTTP status codes? Check out https://http.cat/! Or if you’re feeling like a laugh, read up on error 418: I’m a Teapot

Regardless, when you make a website, you’re gonna need a place to run that http server. Codeberg helpfully offers free static site hosting, so that’s what I’ll be using in this guide, though there are any number of places where similar services can be found!

Hold on, what is the server sending me?

Great question, fictional reader! The answer is: whatever you want! You can store anything on your HTTP server, and clients can request that stuff.

Now, realistically, you’re here to make a website! What a browser is usually requesting is HTML. I’ll get into the details later (and you won’t have to touch any HTML or code in general if you don’t want to), but It’s worth hitting a quick toplevel explanation here.

HTML, hypertext markup language, a simple way of telling the browser what to draw and where. Usually this is text, but it can include lists, pictures, links and more.

You can modify how the browser draws stuff by linking a CSS file in your HTML. CSS, cascading style sheets, allows you to define colors, fonts, and even animations for your HTML. CSS is incredibly simple and powerful. Some simple CSS can go a long way!

Finally for those wishing to wield the dark arts, browsers are also capable of running code. Commonly, this is in the form of a JavaScript file linked in your HTML, (though if you’re cool you can also compile web assembly). This code is distinct from HTML and CSS in that it actually runs logic on the client’s computer. HTML and CSS are just static blueprints that the browser uses to draw things. You’ll be happy to know that you most likely won’t need this.

Working with these files is a skill known as frontend web design. Backend web design gets a bit more difficult, but luckily, you don’t have to worry about it! You’re making a static site! Yay!

No code? Thank god I hate that stuff!

me too You heard me right! I’ll be showing you how to use something called a static site generator, or SSG.

A static site just means plain files that don’t change; In this case, these would be primarily HTML and CSS files. But the question here is: “how do we get these plain files if we’re not writing them?”

The answer is stealing! A lot of code out there is actually really permissively licensed thanks to the open source movement, so you can really just grab it and use it, completely consentually. But then, for the code averse, the problem becomes editing it. This too is solvable, and actually the solution makes things significantly more convenient, even for those willing to write code.

Static site generators take a markdown (almost plain text) document and render it into a website, HTML CSS and all, according to a template. You can get templates from other people, or make them yourself. Either way, the bare minimum is just a template and some text away.

You’re probably already familiar with markdown as well from communication platforms like discord using it to format messages: *this* *is* *markdown*

You keep talking about browsers. What are those?

Browsers are applications that are capable of asking servers for stuff and handling the results.

You don’t even need to observe the first part of that to use a browser though! If you have an HTML file downloaded to your computer, you can ask the browser to display it and it’ll do it no problem. They can display all kinds of content though. Music, Pictures, PDFs. Try it out sometime! The things are incredibly versatile.

Aaaanyway, a browser is just a window to the internet. Some examples are Firefox, Chrome, Safari, Librewolf, and Zen. When you’re designing, keep in mind that different browsers do different things; Your website may not render identically on different browsers. Here’s what you need to know:

There are three genders of browser: Chrome, Firefox, and Safari.

This is not a joke; There are only three modern browser engines that exist: Chromium, Gecko, and Webkit. Eventually, you will want to test on each browser engine to make sure everything works everywhere.

Sidenote: Responsiveness

This idea of your website rendering well everywhere is an important one in frontend web design (and most UI design in general!). It’s called responsiveness.

If your website is responsive, it responds gracefully to different conditions. For example, a responsive site is as usable on mobile as it is on desktop. If a site only renders well on your laptop’s screen, on your browser of choice, on fast internet speed, then anyone outside of those conditions will struggle to experience your website.

Domain name system

Ok let’s talk about the elephant in the room: Domain names. What is a domain and why do you need it?

First, let’s get back to that idea of a client and a server. How does the client know where to send their request?

Very basically, the client is able to direct queries to the IP address of the server.

Pretend IP addresses are just arbitrary numbers handed out to computers. Now if you wanted to go to this website, all you have to do is remember the arbitrary number assigned to the server that hands out its HTML pages and type it into your browser! It’s just that easy!

I jest. Nobody is going into their browsers and typing https://217.197.84.140 to go use a website, unless you’re just cool like that. (as of writing that IP address should work though! Try it!) We silly humans like words, not numbers! So, instead, we go to https://codeberg.org.

How do we translate codeberg.org into 217.197.84.140? The answer is DNS. Basically, we have a bunch of infrastructure that just has a biiiiiig directory of domains that all point to addresses. If you want your own entry, you’ll have to get a subdomain from someone else (eg: subdomain.domain.topleveldomain), or buy your own.

Luckily, codeberg pages provides free subdomains of “codeberg.page,” so that is what we’ll be using; (for example, mine would be fireye.codeberg.page). If you ever want to buy a domain for yourself down the line, you can just swap your site over, and be totally fine. As an added bonus, if you do that, you can make as many subdomains as your little heart desires!

HTTPS

The last elephant in the room: HTTPS. In short, HTTPS just makes sure the server is who it says it is (According to a “Central Authority”), and that anything you send to it or receive from it is encrypted.

This does not make it scam proof. You are not immune to social engineering, and if your central authority gets compromised, we’re exactly where we were before with a false sense of security.

This is also mostly useless for our use case. Oh noooo someone can intercept and read publicly available html! The horror!

The only reason we’ll be using it is because codeberg is kind enough to set it up for us, and browsers get pissy when they see a lack of https, and will block your page/ scream about it to users.

My hatred for https is mostly theatrical; it does make the modern internet significantly safer; I do wish people understood it better and browsers weren’t assholes about it though!

Running locally

One last thing I want to note is that clients and servers aren’t necessarily as distinct as I’ve made them out to be. In this very guide, you’ll be running up an HTTP server and a browser client on the same computer; no internet required. Computers are versatile!

Onward!

Let’s make a website

Welcome back if you just skipped the glossary! In this section I’ll be walking you through setting up an environment, using a template, running your static site generator, and getting that baby on the internet.

Preface: stack

The “Stack” in this context refers to the tools that we will be using to help run your site. Every developer (which you are now, congrats! Don’t forget to touch grass) has different opinions on what tools they want to use and why, and the decision is a highly individual one. Since you’re probably not terribly familiar with the process of web design, nor the tools involved, I’ll be using ones that I largely prefer (with a few exceptions), given a high bar of accessibility.

My priority is a “best effort” approach; I would rather you make a website using non-ideal tools than give up and not make a website in the first place. Perfection is ephemeral, after all.

In this guide, we’ll be using the Zine static site generator, Git for version control, Codeberg pages for hosting, and vscodium for text editing. Here’s a toplevel overview:

Zine is young, but it’s good software, and doesn’t accept LLM contributions, which matters to me. If you want a more mature option with more options for prebuilt themes, I’d recommend taking a look at the Hugo static site generator instead. You should be able to follow the broad strokes of this guide as well, but there might be tweaks you have to make to certain steps to make it work. If you take this approach, I’d recommend referencing your specific theme’s documentation.

Git is gonna be required for this one. Basically it’s what handles the storage and versioning of your website. You don’t need to know a lot about it, but I have a full newbie-friendly guide available here if you’re stuck or curious.

Codeberg is where you’ll be storing your website. It’s reliable, and will give you a “username.codeberg.page” domain name as well as solid hosting for free. You can also host it with any other static site provider, including github, which will you “username.github.io” instead. Again, making this change will allow you to follow along, albeit with a few tweaks here and there.

Finally, vscodium is the purely open source version of the vscode text editor/ide. I don’t love recommending microsoft products, but the accessibility therein is unfortunately a good step above the next best option, and my priority here is to keep this guide as easy and straightforward as it can be. More technical or curious individuals are welcome to try gram or some flavor of vim/emacs.

Downloads and Installations

Let’s get your environment set up. I’m on linux, so I’ll be going over how to do things on linux first (which should translate very well to mac), but I will also be addressing windows, as I anticipate a good number of windows users reading this. I’m sorry for your loss.

First off, let’s make a folder somewhere you can find it. I’ll be calling it “mysite”, and I’ll place it in “~/Documents”, making the full path to that folder “~/Documents/mysite” You can name it whatever you want and place it wherever you want, just remember what and where.

Next, you’ll want to install Zine. If it’s in your package manager (pacman, nixpkgs, apt, dnf, brew, chocolatey) I’d recommend using it, but at the time of writing, it’s not reliably packaged everywhere yet, so I’ll be installing it manually like a caveperson. You can find the binary here, and unless you’re using an m-something mac (which needs aarch64), you’ll want to select the “x86_64” version for your operating system (if you’re using anything else, you probably already know what you’re doing). From there, extract the program into your “mysite” folder. For those of you who know your shit, you can add this executable to your path for convenience, but that’s a whole can of worms that we can just sidestep by referencing the binary directly. Don’t @ me.

From here open up your terminal (PowerShell for you windows users) in that folder. Most operating systems should allow you to do it by right clicking the file explorer background. If not, copy the path to that folder. You’ll want to open that terminal, and type cd <path> then paste in that path in place of the brackets. This should get you to the same place.

Once you’re there, go ahead and run ./zine init or whatever the executable is. You may have to extract it first. Linux users can use tar -xf <zine.tar.xz> zine to do so.

zine init should create a full directory of website for you to work with. From there, you can run ./zine and copy the localhost address it gives you into your web browser. Tada! A website! If you edit the files in that directory, you can see the website in your browser update with your edits as you save them. neat!

Web dev

From here, you can do whatever you want.