$ ls -R ~/








Dev log: Creating art on the web – tech stack part 2


Date: 08/16/2019

Even though I’m still months away from working on code for the new website, when it comes to tech stack, you should always plan far in advance when redesigning a website.

As I mentioned in my previous post on the subject of tech stack, I’m on the fence on the tech stack.

On one hand, I could go the traditional route and write a WordPress theme to do what I need. In some ways, this would be easier, but there are maintenance concerns. When I start working full time again, will I have time to update my theme to manage any sudden changes to the WordPress backend? As well, development is a more involved process, requiring me to essentially mirror my site locally to develop efficiently. Sure, I could manage it all through some somewhat clever tech on a remote server, but frankly, I’d rather skip that.

Which leads me to my current serious consideration: Going headless.

I love React. Ever since I started learning it, I’ve realized it is exactly what I’ve missed in life since I started doing web development.

My first “real” programming language was C++. While I had written BASIC beforehand, and learned Pascal after (for a computer math class in HS), C++ was.. Beautiful. Javascript isn’t too far off from that, and utilizing React, JSX and OOP methodology just feels natural. Hell, I prefer it over PHP now, and that’s saying something.

There are some headaches associated with going headless, however. Number one is hosting: I can’t run node on my current hosting for this website.

I had always planned on picking up a VPS setup for hosting my Node/React work, and keeping its software install slim (basically just running a node server, no LAMP stack). With this, though, I’ll have to consider.. Do I move my WordPress backend to the VPS, or do I leave it on the current hosts (and set it up for CORS for JS queries to the REST API)?

I’m leaning towards keeping the WP install on my current hosts just for the security aspect, but it is an important decision to make. By splitting the backend and frontend servers up, I have 2 major points of failure. If one host goes down, the other is unusable. Siteground has been great in that regard, but I don’t like taking the risk.

A benefit of splitting is resource management; Since I won’t be using my shared hosting for server-side rendering of the design, I’m putting less strain on the server overall, relegating it to just a fancy API and a management backend for it.

This is what goes through my head when doing my twice-a-year website redesign. It’s not just making art on the web; it’s making something functional and new on the web.