2020 Site Redesign

Potential ideas

• Private posts Again to navigate around my avoidance of social media, perhaps some posts of family adventures and the like which only select people can view. Will require a lot of work relative to the results so may ultimately end up on the never-ending back burner.
• Email digests I don't use much social media, so I'd like people to be able to sign up for email digests at regular intervals (for example once per week, once per month or as new posts are made) without using a newsletter provider like Mailchimp. By building it myself I can keep user's email addresses out of a third party's hands and automate the content of each email.

Objectives & Constraints

Precompilation

I initially thought it might be a good idea to explore "precompilation" as the driving concept of the software design: Optimising the deliverables as much as possible ahead of any requests. However, static sites are pretty much end game in this regard and I've been down that road and found that going 100% static actually creates as many problems as it solves. I think there's real value to having a running application behind a site, even if it *could* get overwhelmed in a traffic spike.

I'm also a bit fed up of all my CSS and JS needing a compilation step. Instead I'd like to concentrate on writing and delivering human-readable code without a compilation step where possible. This improves the value of the code as a learning resource both for me and any one that chooses to take a look at the source code.

I've lately become a big fan of StimulusJS and TailwindCSS, but to get the best out of them you really need to be using Webpack. This isn't the end of the world. At this point I've already sunk the time into understanding it, but I always feel uncomfortable adding it to a project - it just feels fragile and brittle.

Of course I have to weigh this approach against the ultimate performance of the site. Ditching Webpack isn't a valid excuse to suddenly be serving huge assets. This will likely require that I take an extremely conservative view on using libraries and frameworks. Not a bad idea, but it will come with a productivity penalty. As this is a personal project and one where a primary objective is exploring the web as it should be, it's a trade off I'm happy to make.

Database?

Representing content as data inside a database allows for templates to generate the precise HTML required, whilst also keeping design and content as distinct entities. (*cough* looking at you Wordpress! *cough*)

Changes to one shouldn't (always) require changes to the other. This seems to be exactly what I want, except that you largely lose the ability to author content without an interface specifically designed for the structure of that content and how fine-grained that data is can be a balancing act. Whilst a nice feature, an online editing interface is a huge undertaking, and I would like be able to at least view my content in any text editor, ideally write it there too.

Using a database for content has always felt wrong to me. It creates more problems than it solves. Content is best represented as markup which is why we use things like HTML and Markdown, the latter becoming the default for most static site generators. Using git to version control your content is a compelling enough reason to store content as markup, rather than data.

The problem is that HTML is cumbersome to type and Markdown loses a lot of it's appeal when you're adding lots of attributes to it - you end up writing HTML anyway.

As mentioned in my first post, I've always marvelled at Paul Stamatious's site and particularly his photosets. The layout and design is incredibly varied and nuanced with lots of small edge cases that make it look just right. I've always wondered how complex his templates must be to allow for all those variations. Turns out he actually authors his site in HTML rather than Markdown so that he has the control over the layout that he needs.

This leaves me in a quandry. I don't particularly want to be writing HTML whenever I write a post, but it does genuinely seem to be the best approach all round. This is something I'll explore in my next post when I start planning out the application

The application will of course require the storage of other data, but I'll hold off on using a database until it's utility can justify the additional dependency. There lots of other ways of persisting data!

The Open Rebuild Begins

It seems that 2020 is the year of the open site rebuild. So far I've watched as Jonnie, Frank and now Nathan put their thought & work process out there for the world to see.

My site isn't more than a collection of a few blog posts these days, but I've had big plans for it since about 2018, at least according to my journals. I've wanted to post more of my photography, share smaller thoughts more often but also have a place for deep dives and series. Inspiration unashamedly taken from Paul's site.

These plans scared me. They are big and imposing, and I struggle to find make time to even update my Twitter bio. An open, incremental rebuild seemed the perfect solution.

However, whilst I cut my teeth on design, I'm primarily a developer these days, so my public rebuild is going to be a bit different. I'll cover the (minimal) design decisions that I make, but this is going to be about the code that runs the site.

This site has been built 100 different ways at this point - all of them complete overkill considering it's needs. My personal site has always been a place for to experiment with new ideas and test new technologies. Given all this, you're probably anticipating that I start talking about the hot JS framework du-jour, but instead I'll stop you there.

Rapidly moving from designer to developer, I missed a lot on the way, most of which could be considered fundamentals. I spent a whole week with only the most basic of CSS selectors before jumping into SASS frameworks (it wasn't Bootstap...what was the other big one?). I learnt JS whilst building a marketplace with MeteorJS & React (that was a wild ride). Using Meteor meant using Mongo, so I was very late to the SQL party!

I'll be doing my best to follow Jeremy's Resilient Web Design principles, using the native tools of the web to their fullest before cracking open anything more complex. I'll be server-side rendering everything, and I might even stick to using flat files. In short, I'll be coding like it's 1995!

Why?

This seems like an odd thing to do right? Well, as I said, I missed a lot of the fundamentals along the way. I learnt pretty much everything I know about development from reading blogs online, and the problem is that most blogs - particularly today - only talk about building with the hottest of hot tech. Those fundamentals just aren't sexy enough to get much screen time, but they are kinda... y'know... fundamental.

That's why I want to build this site in the open, always taking the simplest, most resilient and durable path I can; documenting it all the way with articles, guides and source code. I'll examine my options and explain my decisions as I go. I learnt so much from the open web: it's time I gave something back.

I'm going to be doing this around regular work and looking after an 18 month-old that's just starting to learn his own mind (no easy feat itself) so I can't say how long this will take, or when the next post will go up. I'll try to find a rhythm and make regular updates, but bear with me whilst I find my feet again. It's been a while since shipping anything!

You'll find the git repo with all the source below, along with a link to my (now) old site. In time I'll move the old content over too.

That's all for now!

- Jamie