Future-Proofing the Website

One thing I've struggled with in the past is scaling things up, and I feel a part of this is because I don't use JavaScript frameworks. More accurately, I'm not too interested in learning a framework, and I'm much more interested in learning and implementing basic pragmatic solutions to things. A lot of the websites I make tend to be for fun (including this one), so putting things down in a fast or standardized way isn't a priority to me.

A big priority to me, however, is making the blog easier to update. I find that when I don't have to setup a lot of things before I start working on something, I finish more things. I think that can be said of anybody, so much so that there's a ton of advice for people looking to make things easier and faster to do in any field.

That being said, I recently updated the website with some improvements aimed at helping me out with efficiency, so I wanna talk about them a little here. I also want to talk about some other ways I've future-proofed the website in the past as well. Perhaps one of you might look into these improvements and implement them into your projects!

This one is a lengthy blogpost so I'm splitting this one up into the following sections....

Custom HTML Elements for Consistent Sitewide Elements

So to start, the header and footer of the site looks unchanged, but they have actually been revamped to make sitewide changes easier. Rather than going into every HTML file and changing each header and footer, I can edit a set of elements once, then have those edits show up on every page.

This is possible via custom elements, a method in vanilla JavaScript that enables the creation of homemade HTML tags. The file responsible for this on my website is called templates.js, and it uses classes that extend the HTMLElement class. These have connected callbacks that call innerHTML to insert a string of tags to the HTML file. Then these connected callbacks are executed when a customElement is defined, then used in the target HTML file.

Magic little class that gives me more time to write about random shizz.

I got this implementation from Freecodecamp.org, and it's something I've implemented one other time, but the code for it is relatively easy to understand. It's easy to implement if your site is smaller however, which makes it a must to implement early. As a site gets bigger, it becomes a more tedious and time-costly endeavor to update all pages with sitewide elements like headers and footers. It can get frustrating to backtrack, so I try to implement stuff like this as early as I can, though obviously, I skipped out on this feature and had to manually add it to seven pages.

Luckily, it took less than an hour, and I ended up doing this in a class. Also, I may grow to resent this directory format, it freaken ugly as fugg.

Individual Blog Navigation and an Archive

Okay, so you might've noticed a (currently) maroon bar above and below the blog's body with navigation links, a link to an archive, and a date with a link in it. This was put in place to better organize, search for, and link to blogs. While the previous implementation of the blog on this site was simpler to add content to, I was already seeing a scrolling problem. If I kept it as it was with all blog posts on one page, there would be so many that finding any particular one would be challenging without using Ctrl + F.
Not only that but when linking to any article on another page, meta properties couldn't be specific to the article linked, meaning I was losing information and a chance to draw people in.

This!!!

Now the way I implemented this is kind of counter-intuitive from my future-proofing idea since the way it works adds more effort on my part. The implementation is quite naive actually: each anchor literally links to the article before it and after it. This is a manual thing I must do for every single article I do, but luckily, it isn't too big of a deal on my part. I don't tend to push too many blogs out, so doing these one at a time is very manageable unless I mess up and have to rechain everything.

The archive is another page with links grouped into the years blogs are published in. I was going to narrow this grouping further by grouping months into years as well, but since I don't tend to publish things multiple times a month, I saw it as unnecessary.

CSS Variables

A thing I implemented before I published the site was CSS variables for stuff like fonts, colors, the background, and the size of the main content element. Things like this make sitewide changes even easier to implement, and will save you a fair amount of time if, say, you have over a dozen elements that use the exact same color for whatever reason. There's also "Find and Replace" options for those weary of code editor commands, but I feel having all your customizable variables on top of your stylesheet is just... handier! It takes the guess work out of stuff, especially when you stick to a naming convention that makes things easy to figure out and/or type into another ruleset.

As you can see, all my variables are all lowercase, sorted manually, and have a little prefix thing going on so you can see what elements are related to what elements.

Non-Element-Specific Rulesets

Another thing to do very early on is non-element-specific rulesets. Going back to the reason I don't use frameworks, putting things down in a fast or standardized way isn't a priority to me. When I make stuff like this, I like making a sketch of the thing I want to build then manifest it with what I know. Whatever I don't know is then part of the fun of building websites from scratch since learning and actually practicing a concept you can use in the future, I think, is interesting.

This is especially so if you use something you learned so much that it becomes something intimate and reliable. For example, one thing I use ALL the time when it comes to website building is flexbox. It's a display option for elements that makes their contents easily scalable and friendly to other elements. You can build an entire website from flexbox containers if you really wanted, and the possibilities for how to arrange them are endless as well. It's a tool with several easy-come easy-go options, and while they can be unwieldy and confusing sometimes, it makes building websites for a variety of screen sizes easier.

Now this being said, sometimes I DO want the features a framework could offer me. For example, frameworks offer more scalability as a website grows. It makes stuff like the customElement thing I discussed earlier the default in a way that makes it a non-issue in the future. Furthermore, frameworks also offer what Mozilla calls "opinions about how software gets built". To future quote what I think is a good description of what frameworks accomplish, "these opinions allow for predictability and homogeneity in an application; predictability allows the software to scale to an enormous size and still be maintainable; predictability and maintainability are essential for the health and longevity of software."

Seeing that making a custom website from scratch can leave you open to this lack of predictability and homogeneity, I find non-element-specific rulesets important to implement in my workflow. They take the form of rulesets that can be applied in a multitude of situations such as when I have to center an element or make the text of a paragraph smaller. I like thinking of them like using markup to change how letters look. Bold will always be bold and italics will always be italic; centered elements will always be centered and elements with a glow around their border will always have that glow around their border.

Non-specific-elements can also be used in cases where you want an element type to look a certain way globally, but still want the ability to customize specific element. For example, rather than styling all anchor elements the same or with different classes, we can instead identify certain rules all anchor elements happen to have (for example, setting text-decorations to 'none'), then put element specific changes into classes. Maybe you want navigation anchors to have different fonts and colors, so you'd put those adjustments into another class ruleset, then use a different ruleset for something like general body links. Then from there, you could use rulesets separately from each other or use combinator selectors to effect elements related to others in a particular way. For example, you can select the child of a container using >, or get an element with a class by putting the tag of an element then putting the class next to it (.class p)

Examples of what I'm talking about here.

Sometimes things like this can be flimsy, but playing around with them will lead to them becoming more and more predictable. Eventually it'll become like checking boxes to properties you want to include. It becomes not only homogenized, predictable, and scalable, but also satisfying like having a palette of different colors to chose from. It really takes the guesswork out of having a large stylesheet, especially if you organize the whole thing using comments.

I should also mention that organizing rulesets also makes building and managing websites a helluva lot easier.

To Conclude

As you can see, there are several ways to future-proof websites without frameworks. Though they require effort, I find these techniques great for my use cases, and they haven't let me down yet. There are several ways to skin a cat of course, so there are several ways to go about remedying the things I've attempted to solve without frameworks. I'm hoping to hear from others about this, but I don't have a comment section here. Maybe I'll have to use a framework for that, I'm not so sure, but here's where I leave y'all on this topic. Boy oh boy was this a long blog, I hope its cohesive.

A Brief Status Update

Some brief updates on life real quick, I'm working on another stationary blog about how I got into fountain pens recently, so be on the lookout for that. I think that may come out faster than my last since I wrote this while my brother from the Army visited (he's in a far away place now wishing he still had grandma's beans).

I haven't been working on anything else due to college, it's been an effort to keep up with homework. I'm still planning on releasing a track that still needs vocals and lots of cleanup, but it'll be out when its out.

That's all really for now, so uh... just chillax ig. Go watch more indie web cartoons please, I've been having fun sitting back and watching random stuff online. That and they've begun to kindle something I thought I lost a long time ago. Anyways, buh-bye! Thank you for reading my blog!