Generate full markup on build

[Quicksaver]

With #27 we started using React to share content markup (React components) between the site's pages and Netlify CMS pages. This means we are now rendering a lot of content on the browser side, which is a step (or five...) away from the JAM Stack architecture we want.

So let's fix this by rendering our React components on the server side, to get back to a truer static site boilerplate. React itself is already prepared to be rendered server-side, so we should be able to just do it almost as-is, but failing that we can visit alternative strategies like leaving hugo and trying other react-based static site generators like Gatsby.js.

[jolidog]

I would explore Gatsby already which from my understanding would streamline the process, since it would be the same tech across. We don't have particular fondness of hugo, at the time it was better then Jekyll but that's basically it.

Would suggest a bit of an investigation on Gatsby before proceeding it. Check how well it fits with how we are organising content for example.

[Quicksaver]

So the last few days I've had some time to investigate things. First of all, full disclosure, I was supposed to create a proof-of-concept of a react page built with Gatsby. I haven't done that... Might not get to it anytime soon. 😝

A few Gatsby notes:

• Gatsby self-encloses the build process in itself, much like hugo does. We'd have to pretty much rebuild everything around it and call gatsby build from within yarn, just like we do by calling hugo.
• We'd also need to build a routing system (which hugo does itself), plus completely rewrite every html/hugo template as a react component.
• Gatsby does allow for the creation of plugins to extend its inner workings much like webpack, I don't see them at the same level of development of... well, webpack. Which would likely mean we'd need to develop our plugins if we needed anything a bit more out-of-the-original-scope. So... yeah.
• I've also found other possible React frameworks, Phenomic caught my eye but there are a few more and of the bunch Gatsby seems to be the most polished one.

After some research on it, I decided to go another way, personally I'm much more interested in understanding how to actually build on the server-side than how to tell something to do it. I also thought it would be a much more direct approach to reuse what we already and just have it build server-side than to implement Gatsby at this stage.

So, to avoid an indecision, I went with both the "learning exercise" and "get a MVP out" approach. I'd rather learn how to do things right now, and get back to the JAM stack architecture so that any future projects that should come up soon can still benefit from all we've done so far.

That wasn't too difficult (https://59f21620df99534d31708e1f--besugo.netlify.com/, PR coming soon). I banged my head on the desk a couple of times and stared at the pigeons a few times after hitting a wall... but like I said, nothing too difficult.

I'd still like to move away from hugo eventually, and Gatsby is a definitely a strong contender. I believe we can do it gradually though, as I don't think we should do massive rewrites like that all at once would, after all a move to Gatsby only brings benefits to us developers and not really to the site itself.

[Quicksaver]

Also, working out our own server-side/hugo hybrid routine in no way goes against implementing Gatsby. On the contrary, we can more steadily start migrating other kinds of layouts into react components that will work immediately with this, and later we can use them almost (maybe completely) directly in a Gatsby implementation.