Getting Started

The Goal: A Site of Your Own

I really wanted a website. I’ve wanted one since starting my career as a web developer, and it’s finally here after about 6 years of mostly procrastination.

You can totally do this in a weekend (if you don’t do what I did) and try to spin up things so you have as much control of the components as possible, sure. But if you’re like me, when you read about site builders like Hugo, Jekyll, and Gatsby, and they tell you that you can make your website, the thought is a alluring.

You don’t have to rely on a Tumblr, a Facebook, or even Wordpress.

So I’ll be detailing the systems and processes I’ve used to get this site up and running.

Now, what I’ve done here is a bit overkill: there are services that do most of what I’m doing here for you. Wordpress, for instance, handles basically all of this with way less hassle. But I didn’t want to use Wordpress for my project.

Why? Well making a site like this is not only a good exercise, but it’s also deeply satisfying. I can say that seeing my stuff up on the internet, just hanging around being hosted in public was cathartic. wSo I’ll tell you what I used, and in this series of articles I’ll also walk through how to get those pieces set-up

The Technology

What some might call “the stack.” These are all of the components I’ve used to build this site. If you haven’t seen any of these technologies or heard of them, then a top-level check of each of their pages might be a good idea.

• Hugo
• Webpack
• GitHub
• SCSS
• Material
• Firebase
• Google Domains

I’ll go over each of these in quick detail.

Hugo

Hugo is a static site generator, and it’s a fast one at that. The details don’t matter for our purposes, but it’s a tool built in the hacker favorite Go Language and it’s open-source. For our purposes, Hugo lets us write new articles fast. Content is written in markdown, and the rendering of the site is done with the famously fast Go language.

My site (and yours too if you do what I did) is a static site; it doesn’t collect data, it doesn’t let you log in, it doesn’t know who you are, and you can’t interact very much with it. That’s kinda the point. The other popular systems for making sites like this include Jekyll and Gatsby, but Hugo seemed to work fine, and it’s really easy to get installed.

I saw a lot of talk about how easy Hugo is to use, so I picked it up and tried it out. I’ve also seen Jekyll users really admire the speed of the Hugo system. Another feature that I want is the extendability and on that front I find Hugo pretty impressive. I’ve only ever seen it be fast, but a good half of my time getting this thing to work was used setting this bad boy up. But I’m here now so it’s not bad at all. And if you plan on publishing a lot, apparently it’s great for that too!

If I had a criticism for Hugo, it’s the documentation: getting a site propped up in the specific way they talk about getting a site propped up is easy. Woe to you who travel far from the beaten path. From my perspective, most of the detailed documentation is in forums and arcane pull requests and sometimes in the actual documentation. It’s serviceable, but I wouldn’t consider it the best experience. I often need to dig for several days to figure out intricate bugs, or do specific things in Hugo. This is not that big of a problem, but it’s still a problem.

Webpack

I mentioned that Hugo is “extendable.” One of the coolest features of Hugo is the Pipes system. Essentially, the Hugo pipes system lets you perform lots of cool transformations on some elements. Of particular note, the SCSS preprocessor pipe seemed very promising. In short, I’m using Webpack is because this statement is a lie:

Hugo Pipes allows the processing of SASS and SCSS files.

That’s not completely true. And it’s not really true in a truly maddening way. I’ll deep dive into this lie in a future article, but let me just say that if you are using an SCSS library that isn’t a few years old, you can probably bet it won’t work. Essentially, the processor cannot handle the newer use keyword. That shortcoming took me 2 weeks to figure out.

This took me back to 4 years ago, before the pipes feature of Hugo existed when people would use things like babel and Webpack to build their website.

Oh boy.

Long story short, I needed Webpack.

Webpack is a packaging utility and general pipeline for making web content and packaging code. It’s focused mostly on people writing interactive apps with javascript. Since I’m stubborn and wanted SCSS I needed to use it. Webpack really boils down to a series of modules in a pipeline and what you get at the end are packages containing scripts and assets you can ship to your website.

I use this to bundle my assets and styles for my site. Is it strictly necessary? No. If you use prebuilt Hugo themes, simple CSS / SCSS, or don’t need a content management pipeline outside of Hugo, then Webpack is overkill.

Even if you use more complicated SCSS, you can use the SCSS compilation tool with this system. The downside is now, if you make any style changes, then you need another step to compile them to something your system can use. In my mind, if you’re now including SASS you’ll also want to include Webpack, because let’s face it if you’re willing to add a build step for the style sheets, then you’ll probably want a more robust system for other things (like images, javascript etc.).

If you’re like me you forget things, and you want to have control of the things you’re making, then you need help, and Webpack. What’s the benefit of this? Well, if you’re not a designer (like I’m not a designer) then you can get complete control of your website and its pipeline, you can minify, serialize, and fingerprint your assets, meaning you’ll never have cache issues again! You also need to maintain that now, unfortunately. One upshot is you now know how one of the more popular web tools works.

Webpack, being a popular tool, has a lot of support but that does not make it a simple tool. For me it took the other half of my time building this site.

GitHub

I’m a programmer at heart, so that means GitHub is my bread and butter. I’m a bit paranoid about losing all of my work to head failures, cosmic rays, or me spilling crap on my computer. GitHub is basically an extra life to your own mortal clumsiness. GitHub built on top of git is a no-brainer. I’ve never used another system for hosting my repositories, but I’ve heard good things about GitLabs.

GitHub was bought by Microsoft recently in 2018, but it’s long been a hub of open source projects… at least if you don’t look too far back and find the arcane secrets of the early web. The old ways are best forgotten.

GitHub has its own hosting and content management system. GitHub Pages is surprisingly capable and you can make a serviceable website on it. If you want to dip your toes in on hosting… well the GitHub pages service is a bit too removed for me. You aren’t really running a website: if you ever need any extra tools or processing power then you’ll outgrow GitHub Pages pretty quick. Otherwise, you might find it a really solid option!

GitHub for me is my source control. If my computer catches fire then this site is fine. If all of my computers catch fire then my site is still fine. If I have to push a change and only have access to a different computer, no problem I can still work on this. GitHub is a marvel of the modern world.

my github

SCSS

I’m not a designer, but SCSS is pretty great, and I’ve used it effectively in the past. If you’ve followed CSS’s journey to becoming a real styling language, you may remember SASS, LESS, and SCSS dunking on how bad CSS was. Today we have modules and flexbox and all the bells and whistles that 2000s web devs didn’t have. I was lucky to miss the worst of it, but I still see the artifacts that harken back to those days. Modern CSS incorporates a lot of the features that SCSS pioneered, but if you wanted to have any sort of hierarchical styles, this was one of the only options.

SCSS today still provides more features, like smart importing, variables, functions, mixins and a few other features. Technically you can do all this with smart javascripting too. But if you want to keep your logic and your styles separate (and sometimes, you really do), you may want a tool like SCSS.

The downside with any CSS preprocessor is… well you have to process it! As soon as you say “I want SCSS in my site” (like I did), you will now need 1 of 2 things:

1. you already have the tools to process your preprocessor CSS, or
2. you need to add more tools (yuck).

When picking SCSS for my stack I thought “Well heck, Hugo already has the SCSS Pipe I’m good.” Again, this was a lie. And therefore, after building something I kinda liked, I was stuck in the realization that I needed to add yet another component to my site (see my prior Webpack). A rather hefty one as well.

SCSS is great, and I still think it’s one of the nicer additions to my stack. It’s pretty easy to get vendor styles in, and many vendor style packs will give you modules for their stuff, meaning if you’re careful about what you import you can reduce your packet size.

Neat!

Material

I think most sites would advise you to work with Twitter’s Bootstrap. They’d be in the majority, but for this system I wanted to try out Material in a setting it’s not accustomed to. I’ve used Material in Angular sites before to great success.

Material is a styling system from Google emphasizing minimalist styles and components. It works very well with the Angular framework (it’s basically built in) but it’s also an SCSS library (with some javascript components).

Most websites use Bootstrap or Bulma or something similar. I wanted to try this out and it works alright.

One thing about the Material.io system is that the documentation is not nearly as solid as the bootstrap documentation. If you want to save yourself a headache, Bootstrap is very solid and also uses modular SCSS.

When it comes down to it, if you really like an SCSS style framework, use Bootstrap. If you don’t, use bootstrap anyway. If you want to try something new, try Material or go out there and find something really weird!

Firebase

The big 3 cloud hosting solutions that I know of are Firebase, Heroku, and AWS. All 3 have a free tier that smaller bloggers and hackers should totally take advantage of.

You’ll need a Google account (free) and it’s owned by Google… so there’s that. But if those aren’t hard stops for you then Firebase has what seems to be a fairly generous free tier. I’ll be trying out a few pet projects of my own here.

I mentioned it before, but if your site doesn’t need any of the systems these platforms provide, it’d probably be a smarter idea to go with a simpler system like GitHub Pages.

In any case, Firebase works well for me; it’s easy to set up, Google Documentation is very solid (woo!), and I already have a Google account which made it easy to set up. Firebase also lets you set up a bunch of other tools if you find yourself expanding!

Google Domains

Finally, if you want your site to be hosted somewhere you need a website name. I went with Google Domains because it’s super easy. The price is pretty low for most domains too: about $1 per month (for now) is nice.

Google Domains also provides other convenient integrations with things like Wordpress. I decided that I wanted to build a site so I didn’t connect to those services, but if you really only want to get a site up, then either getting a domain and linking it to GitHub Pages works wonders, or working with one of the integrators from Domains will be your quickest bet.

Interestingly, the integration between Domains and Firebase isn’t actually seamless! You still have to set up both systems to work together, and there’s no “button” that does that for you. That was the only truly surprising part about it; you’d think one of the high-tech giants would have these two connected a bit more seamlessly.

Ok, so that’s all the stuff I’m using

I’m not actually diving in on how to use each technology in this article, but the next article I’m planning is getting started with Hugo. If you’re interested in any of these tools, check out each of their main pages. If you think you can do this you most certainly can. Try things out!

The next article on Hugo will probably need a few more enhancements to this site to get that done. Maybe I’ll have a post about that as well!