My [static] ‘Portfolio case’

Eugen Y
Eugen Y
Aug 8, 2017 · 6 min read
Static Website Generator’s interest over the years

In today’s internet, it’s essential to have a decent representation of yourself. However, as a coder a.k.a developer a.k.a ‘techie’, it might become messy to pick the right approach for your own portfolio site.

Obviously, the first decision would be whether to go from scratch or use a CMS. Actually this one is pretty easy and straightforward: if you’re a coder or designer — and we’re strictly talking about them now — you’re gonna have to build it from scratch. A portfolio is a showcase of what you can do in a variety of tech-related fields, show others how detail-oriented you can be, how you take care of different ways of representation or visualizations, etc. Content Management Systems, as cool and updated that they might be, can never offer the same level of ‘freedom’ in comparison to building (and often hosting) your own site.

So if you want to properly show your potential employer what you can build, build from scratch: pick your favorite web language, a good enough framework (not bothering to guess what that might be) and go from there.


But — and there’s a huge but — the variety can be insane, especially if your language of choice is JavaScript [and there’s a very good chance it will be it]. So, being the busy man I pretend to be, I was looking for a relatively fast solution, but also something that said “I’m a developer and I know my s##t”.

Enter: Static Page Generators

The idea behind them is simple: you take advantage of existing build architectures from the likes of NPM, Webpack or Babel to create instead a static website, with a simple and functional caching flow, making for a great User Experience. You still have to take care of some configuration, routing or maybe some cache ops, but it’s a child’s game in comparison to dealing with PHP or some other 15-year-old related web paradigm. If you need reasons and more arguments for Static Generators, I think this article would do it.

Skimming through the possibilities for static page generators takes a relatively short time, since there aren’t a lot of choices… Since I was diving [and still am] into React, I picked Gatsby, versus Phenomic, since it looked more mature and with a larger community. This is important when it comes to static website generators: most of the frameworks are immature, still being worked on, APIs will break, and there’s a very good chance that the first time you init a project with one of them, you won’t know what the hell is going on.

And with Gatsby it was almost no different. You could quickly set up a blog with a starter pack (I picked Gatstrap, since it looked much closer to a portfolio site than a blog or documentation site), but the development process was not that straightforward. Still, it was nowhere close to ‘difficult’: the file hierarchy is simple and readable, it uses markdown files but you can also put your own html and it has a very cool procedure to create wrappers for adding new components to your project, based on React.

The Gatsby wrappers work like a mix between React’s JSX and the good ol’ [web] templates — which by the way, you’re going to use to make the necessary page types you’re going to use.

Case in point: the ‘Gatstrap’ starter comes with a ‘Page’ and a ‘Post’ type of template. Consider them as different templates (because they actually are). For my own pleasure, I added a new one for the home page while adjusting the other types to my needs, i.e the ‘post’ layout would be used for my portfolio works, treating them like mere articles, while the ‘page’ layout would be used as a parent node to these articles and the ‘about’ page. Pretty simple. The markdown file ended up being a beautiful-to-look-at 30-something lines of JSX:

class MarkdownWrapper extends React.Component {
render() {
const {route} = this.props
const post = route.page.data
let layout, template
layout = post.layout if (layout == ‘post’) {
template = <SitePost {…this.props}/>
}
else if (layout == ‘page’){
template = <SitePage {…this.props}/>
}
else {
template = <HomePage {…this.props}/>
}
return (
<DocumentTitle title={ `${post.title} — ${config.siteTitle}` }>
{ template }
</DocumentTitle>
);
}
}
MarkdownWrapper.propTypes = {
route: React.PropTypes.object,
}
export default MarkdownWrapper

This snippet made the whole project work effortlessly.

All that was left was to build the templates in JSX for my own home page. Speaking of which, I really liked the simple animations of react-typist package as a simple, straightforward presentation home page for the site. But be warned: if you add new React packages and use their components, like I did with Typist, you can’t just npm install it, ES6-import it and use it, but also have to update the JSX wrappers (like the one above), the markdown files/layouts and the routing logic. Oh, and also rebuild the project, otherwise it won’t hot-reload. It’s really not a lot to do though:

import React, {Component} from 'react'
import Typist from 'react-typist'
export default class HomePage extends React.Component {
render() {
const {route} = this.props
const post = route.page.data
return (
<DocumentTitle title={ config.siteTitle }>
<div className='container'>
<div className='headline col-md-12 text-xs-center'>
<h2>Hello World</h2>
<Typist>
Some presentational stuff, like blah-blah-blah.
</Typist>
</div>

<div dangerouslySetInnerHTML={ {__html: post.body} }/>
</div>
</DocumentTitle>
);
}
}

This is the index.jsx for the Home Page component. Since every component page of the website has its own index and style, organizing the project becomes easy AF.

On the plus side…

A part from the usual pros that come with developing React (which, if you don’t know them, you really should), you do have some other advantages that you might not be used to having when dealing with static websites. First of all, there’ll be almost no need for media queries — well, maybe, but depending on your site, responsiveness does go quick cause there’s not much to take care of. Building is fast, files are easily organized and each one of them was less than 50 lines long. With some help from hot-reload or ESLint, developing in Gatsby was indeed fun to do. Another plus was Analytics, which was already setup and you just have to paste your UA code.

On the down side…

Well, animations can be a hassle, especially with exterior plugins such as WOW.js which kept breaking now and then, and when it does, the chances are the good ol’ debug console won’t be much of a help to find the error. It sometimes becomes irritating when having to rebuild the project every time you mess with routing (although I guess this isn’t restricted only to Gatsby).


Building with Gatsby was a real joy, especially when you start messing with static page generators for the first time — as I were.

It has already impressed quite a few of my interviewers/recruiters/employees/whatever-they-wanna-be-called-today, and after all, that’s what it’s about.

Not only you’re demonstrating proficiency in wide platform, such as React, but also creativity and simplicity, by providing a static website that almost looks old school, even though it’s the last thing it is.

While you’re at it, take a look at what I built here.

Photo by Eddie Kopp on Unsplash

Eugen Y

Written by

Eugen Y

Software Developer; stock and crypto enthusiast; art lover;

Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch
Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore
Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade