So this is the first post on my brand-new blog. Which, in turn, is on my brand-new homepage. And so I thought, what better topic for a first post is there than talking about how I made and set up the two.
Backstory
So I’ve had the idea of making my own homepage for a while now, but I never actually came around to really starting the project, mostly because I had other stuff to do, and also because I was unsure about the way to go and the technologies to use. At this point I´m quite proficient with crafting websites and webapps, and it seems whenever I start a new project I discover new technologies, libraries and frameworks. Even reading the ‘Get Started’-page of most of those projects is like opening Panora’s box. I learn abut the core concepts and often feel like ‘That’s all I ever wanted!’. I go further and discover integrations with other projects you like and soon enough the little project I originally had in mind is getting bloated into oblivion because of all those new exciting stuff. And this is also true for my personal homepage. When I finally found the time and motivation to really start this project I had about a dozen different ideas how to go about it. The problem was all of those ideas had their strong points, but none of them ticked all the checkboxes I wanted. Wether it took to long or was to complicated to setup, wether it wasn’t scalable or expandable, there was always something bothering me. But then I discovered that my solution was there the whole time, right in front of me. My solution was Github and its gh-pages.
Starting Points
Github is a platform that allows you to host and manage projects (mostly software and code-realted stuff, but you can use it for anything), that you track with Git, the de-facto-standard version control system (which I recommend everyone, not only coders), on your local machine. Github also offers to host static sites for your projects as a unique way of presenting. Those sites are connected to your Github-homepage, and that homepage is exactly what I wanted to create. It really is quite simple, and I recommend taking a look at the official documentation to get a grasp of what gh-pages is about and what projects they are useful for. But simply spoken, all you have to do, is create a new repository, which has to follow the naming-rule of username.github.io (in my case JonasPuchinger.github.io). This will also the URL for your homepage. Now, you could go ahead and and just create a simple webproject with a HTML-file and a CSS-file, commit and push those to Github, and there you go. You’re up and running in no time. And while this approach certainly works and leaves you with all options of customisation, I doesn’t reall make use of the features of gh-pages.
Generating static sites
On of the advantages of gh-pages is that it’s backed by Jekyll, a static site generator, which really makes it so very easy to create a site with a decent structure and an even easier way of creating new content fot that site. Jekyll is based on Ruby. You don’t have to install and configure Ruby on your local machine to host your personal homepage on Github, as it is installed on there. But I strongly recommend setting it up for yourself, not only because you get a better understanding of how it works, but it also allows you to develop and preview your work locally, instead of commiting and pushing every change you want to see in action to your Github-repository. Disregarding of which way you choose, I recommend to check out this tutorial, which also goes deeper into the topic of Github. Following this tutorial will get you to a point where you should be able to comfortable use Jekyll and gh-pages, and that’s what I started out with, too. If you only want a simple page, you’re practically set.
Responsive Design and Themes
Now if you where to view your homepage on a mobile device, you would probably discover that it looks quite different from what you imagined or what you saw when previewing it in the browser on your PC or laptop. This could be solved by using strategies to apply responsive design to your page. If you’re familiar with that, you can of course implement these strategies yourself, most commonly with CSS media queries, grid or even scalable SVGs. If however you are a lazy person, like myself, you could use a CSS-framework. Some of my favourites are Materialize and Bulma. These frameworks are easy to pick up and simple to integrate in your project and workflow. They also make use of a mobile-first responsive design approach. But, while giving you an easy-to-use solution to the problem of designing for different devices, they still give you all the room for customisation, espeacially if you knw SASS. I eventually choose a third option, one that allowed me to learn more about and familiarize me even more with Jekyll and its projectstructures. This option is Jekyll Themes. Think about them as full Jekyll projects. Most of them make use of its inherent ideas and components, like includes. They normally come with some example-content, like blogposts or images, to show how the site is structured. This makes for a good starting point, which you can adapt and customize according to your personal ideas. There are various sites, where you can discover themes for Jekyll, like this one, where I got the one I ended up using, or this one, that offers paid premium-themes. I ultimately decided on Hydeout, because it was very close to the design I envisioned and developed myself beforehand.
Managing content
At this point you might think something along the lines of that this is just great. Everthing is so simple. If you want to change the logo of my website, you just have to change the file in your local directory, commit the change and push it onto Github. Same with a new post. Just create the file, add in your content, commit, push. In theory, this really is great. It would even work if you ran your blog with some friends, or in general, multiple contributors. Simply have them clone down the Github-repository and let them create and push. No problem at all. Except everyone has to know Git and Github. And an even bigger problem: as your site grows and the content on it gets more and more, you realise that it’s actually not that great to store all the files, posts and images on your local machine, having to git pull everytime someone makes a change, not to speak of merge issues. The great thing is, there is a way to solve this stupid problem. It makes use of the fact that your site lives online and all its files are stored on Github. This solution is what is called a CMS (content management system). A CMS lets you expose all the content creation to the contributors, while giving you admin rights for managing purposes and the best thing, it hides all the technical stuff. There are a plethora of options for choosing a CMS. I first discovered jekyll-admin. It’s a Jekyll plugin, which you just have to install in your project, and, completely out of the box, it just works. Reload your app, and point your browser to username.github.io/admin, nd you will be presented with a graphical dashboard, that lets you control and manage all of your content very easily. Jekyll-admin only has one drawback: it only works locally. Meaning you still can’t delete your local project, which is what we initially sought out to do. So you have to switch over to a hosted CMS, which imports your site and you can access via your browser or an app. The Jekyll team recommends Siteleaf, I ended up using Forestry, which I’m currently writing this very post on. The reason behind my decision was that Forestry allows you to import sites from private repositories on Github, which the free version of Siteleaf doesn’t offer. But both are great options.
Conclusion
So, all in all, I think creating your personal homepage with Jekyll and hosting it on Github is a great solution if you aim to further develop your webdev skills and online presence. Static sites, like the ones generated by Jekyll, load incredibly fast, because they can be cached very well, and are especially suited for blog-like site-structures. I didn’t really go into technical details in this post, and tried to focus more on the the journey and the decisionmaking I underwent while creating this homepage for myself. If you have any questions regarding the stuff in the article, be it a certain decision I made, or a problem you encounter while builind your own site, just hit me up. That being said, this site is far from finished. I have some ideas I want to integrate in the near future, and some a bit further in the future, but if I think it’s interesting, I’ll either update this post, or, more likely, create a new one.