It had been close to twelve long years since the first release of my personal website and since then it rarely got an update UI wise. Yes, I would write posts from time to time, but it more or less served as a container to house all my writings and showcase my portfolio. I never felt the urge to update it as at the time I felt it did well. That was until I figured it was time for a change after seeing how it compared to what I have learned over the past twelve years.
The shiny toys
The old site held its own for a while. I had created it using Expression Engine to run the back-end and had it hosted with my first company out of college, Imp Designs. It was built in a pre-SASS era and storing HTML templates in the database. Both of these made maintaining or even updating the layout/look and feel incredibly hard. Needless to say, it laid dormant for quite a while with the exception of blog posts every now and then.
Then came the time where I was ready for a change, to try something new, and finally apply all the years of experience of using different tools to accomplish tasks at hand.
Hexo, the static site generator
Over the years I had tried different static site generators, one of which being Octopress which is built on Jekyll as in my jobs over the years I have heavily used the Ruby language. While these tools work great, I figured it was time to move to my other passion in the JavaScript world and work with something that utilizes Node. Enter Hexo.
I chose Hexo after looking at a few options and found that it had a great community support behind it, was regularly updated, and also worked with the technology outside of the build system that I was familiar with. It is also written utilizing JavaScript and the CLI tools were pretty straight forward to use. The only learning curve I saw was getting used to how it handled the layouts, included the partials, and built the site from the files I created. I had to do some custom scripting to get somethings not typical to its workflow, but out of the box, it performed very well. It also utilized markdown which my current blog posts were already written in, so porting over was relatively simple, yet tedious due to old posts living in a database.
Moving to a better form of CSS writing
The old site was developed in a time where the pre-processor tools like SASS or even LESS didn’t exist or were just fledglings. This left me to writing regular CSS without the aid of nesting, mixins, or even shared variables. This also lead to difficult upgrades stylistically wise because of the unfortunate complex nature of the beast. I also can say I was just fresh out of school and starting to get into the front-end web development so of course my code of the time makes me cringe now.
I have been using SASS (in SCSS form) for some time now ever since I jumped into using Ruby on Rails. It made writing CSS much simpler and straight forward so of course I was going to utilize it here. Combined with all the local scripting tools, using it was a no brainer, but I wanted to take my CSS a step further to make it more semantic, usable, and extendable. This is where Block Element Modifier (BEM) comes into play.
Introduced to me and the UserTesting engineering group by @mpgstew it allowed for us to conform to a certain convention that made sense. SMACSS was also a contender, but she researched the needs and feasibility and ultimately landed on BEM. It has definitely changed my mind set and thought process when it comes to not only laying out a page in HTML, but also when naming and using CSS classes. Audiós ID use in CSS!
Visible on every form factor
What’s a smart phone or let alone a tablet? That would have been me back when I created the old version. Needless to say, the old site was hard coded at a robust 960px for the time. Shrink your browser or load it up on your phone? Too bad, you had to side scroll. I didn’t want this to be the case for the new site because everyone should be doing mobile first.
So from the start of the new site creation, I made sure to make use of media queries in my CSS to allow for the different acceptable break points found today in the multi-form factor world. Granted, I am now starting to see a lot of discussion from others in the industry that setting break points is now not something we should be doing. Interested to see how this discussion turns out in the near future. I definitely think the introduction of CSS Grid will help conform and remove a lot of this, but unfortunately, not every browser is up to speed with this new specification.
Less pixels, better scaling
I relied heavily on using PhotoShop to create my pixel perfect designs in the past. The trend of today is to utilize Sketch, or some other vector art creator, to produce more flat looking and scalable sites. When it comes to creating the CSS and also the page weight, this trend definitely has its benefits. Luckily, even with CSS you can still create non-flat things using some of the great additions that were not widely available in years past of the CSS specification.
Now, when I create and export graphics, I make sure to use SVGs so that when viewed on different form factors, the scaling of the images stay crisp. This stays true when viewing on a 4k or retina monitor. In order to get jpg or png images to not look fuzzy on these type of monitors, you would have to produce two sets of images at different scales. This would lead to more page weight very quickly.
In addition to using SVGs, I switched from using png style icons to utilizing FontAwesome for the icons you see through out the site. This again allows for scaling and versatility in their use.
A free host with amazing backed technology
As mentioned above, my site had been hosted on my first job’s server running PHP, a MySQL database, and controlled by ExpressionEngine. I am grateful that they supported me this long, but I was needing a change based on the direction I needed to go with the tech stack. Yes, I could have just hosted this static site up at same server, but I was looking to integrate a Continuous Integration system for the build without the upkeep of setting one up. Luckily, GitLab provides a free static site hosting through their repository setup and built in CI tools to write your own config file to deploy and build the site!
What is next?
I have mentioned a lot of different technologies in this post that helped me create the new site. My plan is to expand on a lot of these to provide tips and tricks of things I ran into over the course of the build. Of course, seeing how my last blog post was almost three and a half years ago, we will see how that rolls out.