Published by James Gallagher on .
This article takes approximately 5 minutes to read.
I designed this website with simplicity in mind. The fewer the bytes, the better. I’ve been thinking about it and I do not think that simplicity is just about how many lines of code I use in my websites. It’s about how I can use as few lines as possible to achieve a particular goal.
I set out with one big goal for this website: to make it simple. That was the only idea I had in mind. I decided to go bare-bones because I have seen a lot of plain text sites lately. I’m a big believer in plain text. This site could be plain HTML documents. It’s not a good idea.
Reducing a site to its most basic components has taught me a few things.
It has made me reflect on the importance of semantic HTML. I now know a few extra tags that could be helpful further down the line. That reminds me, I need to look up when <nav> and <header> should be used. Semantic HTML is about treating each HTML document like a piece of art. Every component should be easy to read.
I can read almost any HTML document. That’s because I know the basic tags of HTML. I may not know about a few of them. My knowledge covers what I have needed to know so far in my journey as a developer. I struggle to read documents that are <div>s after <div>s. What does each <div> mean? This is a question that I don’t want you to ask when you view this site.
View source used to be such an important part of learning how to code. I didn’t use it. I never really thought how useful it would be. If I were starting again, I’d probably want to give it a go.
The trouble is that there are so many websites out there whose HTML documents are unreadable. They are generated by frameworks like React. They are littered with ridiculous tag setups. I believe one reason for this is because people don’t think about how every component in a UX framework is just HTML and CSS. The abstraction makes it easy to ignore how things work. I believe this because it’s how I treated web development myself. I thought in components, not bare-bones code.
Semantic HTML is nicer to write. It’s easy for me to maintain my site because every tag tells me what it is doing. I’ve tried to avoid pyramids of <div> tags in favor of using the most appropriate tag for the job.
What’s more, semantic HTML comes with its own built-in accessibility features. Buttons are coded with accessibility in mind. I don’t know much about ARIA but I do know that if I stick to semantic HTML then I’ll have access to a lot of accessibility features out of the box.
Simple, not Barebones
I reduced my site to its barest form because I wanted it to be fast. It became sort of an obsession. I wanted fewer lines of code. I have since changed my perspective. I do not want a barebones site. I want a simple site. A site that works, but without the bells-and-whistles.
This is what I believe I have today. My site could be much more complex but I do not aspire to make it so. I’m happy with the way things are. I don’t import any CSS from external services. I don’t use any fonts from a repository like Google Fonts. All pages are statically generated.
I made three crucial changes to the site yesterday. I have added more color. The site now looks a little bit more beautiful. I have had to sacrifice the contrast of links because I had a particular color that I wanted to use in mind. I am not concerned about this. The contrast is not too bad; it could be much better. I am willing to make this compromise because I want a site that’s not just black text with a few styles here and there.
I changed the font. I used the default system font initially on this site. I have changed the font for this site to another “web-safe” font. You still don’t need to download any fonts to use this site. The site looks more appealing because I am not using the default. The default may be simple but there’s always room to add in a few pieces of complexity to make something better.
The metric by which I measure this site is not loading times. The defining metric is purpose. Does this site fill its purpose? I believe so. I like to make pages load as quickly as possible. Every page is going to load a tad slower because I had to add in a few lines of CSS to implement the changes I had in mind. This is acceptable because the site is now a little bit more my own.
It was always my own. I have moved away from the defaults and added some personality. I’ve been careful in every change that I have made because I do not want to go over the top. Some color on the site and a nicer font is as far as I want to go. I want to follow through on my promise of delivering fast user experiences. A few more bytes for each page does not matter. If I were entering a challenge to design a web page in under a certain number of bytes, I’d not feel this way. I am not in such a challenge. I am building my personal site.
I don’t want purpose-driven development to become an acronym. I like to ask myself: what is the purpose of this site? Does my code reflect that purpose? That’s it. This has helped me keep my code lean and simple. That’s my goal: to write simple code that fills its purpose.