Building momentum with some simple CSS

Sticking with the theme of leaving this project much longer than intended, I finally got back to making some progress. My other work has seen me buried in writing CSS lately, so I thought that a good way back in would be to put together a simple stylesheet to move the site away from the browser defaults.

However, my approach to writing CSS has changed since the last time I wrote about it. Longterm readers may recall how I wrote enthusiastically about Tachyons back in 2016. Since then, TailwindCSS has taken the development world by storm and that's pretty much what I've been using since – even purchasing the TailwindUI library of components.

It's been a very comfortable framework to use — once you've got tailwind.config.js, purge.config.js, and whatever build tool you're using all set up. To be clear, getting a TailwindCSS setup working "just so" is not a trivial exercise, but the benefits always felt worth it.

That was until I needed to work on a project that had a shared "core" with multiple, variable implementations. This approach wasn't just for business logic but design too. Each application needed to look similar, even sharing some pages, but each needed to be "reskinned" to use brand colours, fonts, etc.

"Oh easy!" I thought, "This is what CSS was designed for, I'll just use the cascade or some custom properties to apply different styles". Turns out it wasn't so easy... I ended up having the same variables declared in the Tailwind config and in CSS custom properties. I started getting into specifity issues — something I had even forgotten was a thing! — and struggled to make the changes in each application without upsetting the shared core. I could feel myself being torn between how Tailwind works and how CSS is supposed to work.

By treating CSS as single-purpose utility classes, all with equivalent specifity Tailwind had removed one of CSS' biggest pitfalls but also removed it's biggest strength. Tailwind is popular with JS developers because it suits the way their applications are built with CSS that is scoped to localised components, but CSS is fundamentally about the cascade — it's in the name after all!

I went back to writing BEM-based CSS which is how I did things prior to the atomic approaches. I was immediately reminded how clumsy and verbose it was, but only because my CSS skills had dulled. I had gotten lazy and failed to see the big picture which is vital to writing good CSS. Instead of writing generic .media-object-type classes, I was writing incredibly specific classes for single elements — much like I was still styling with Tailwind.

Enter Andy Bell

I searched around trying to find some direction and remembered I had bookmarked 'Every Layout' a while back but not really looked into it. The idea is that it provides a textbook example of how to build every primative layout you'll likely need for any website. There were the usual suspects like centering items and the good 'ol media object, but I wasn't prepared for what I found.

Looking through the free layouts didn't much inspire me, but when I read the 'Rudiments' series of articles that accompany the layouts, it was a complete revelation. In five short articles, Andy explained how CSS was designed to be used and how to embrace this rather than fight it. I've been doing frontend development for eight years now and these five articles taught me more than all the blog posts and books I've read.

I won't enumerate all of the concepts behind this was of writing CSS and instead I encourage you to read his work both on Every Layout and his own site, Picalil.li where he expands these ideas to a more formal methodology he calls CUBE CSS.

By all means, take a look at the source code of this site, either here in the browser, or on GitHub and see for yourself how much you can do with very little CSS!

Writing a brief

Been a little longer than I said it would hasn't it?! Never mind...

I like to start a new project by roughing out a brief of some kind. It's never too long and detailed as I like to be able to take advantage of the things I learn along the way, but there needs to be some direction. I find that stating the requirements, examining the shareholders of the project and perhaps identifying some constraints or possible issues early are all that's needed. Once I get started I tend to use Basecamp's Shape Up process to build each feature or requirement. This gets me out of the gate and building something "real" quickly.

The Brief in brief

• Post articles — I'd obviously like to be able to write. Articles will be pretty varied in length – some pretty long! – so I'd like to provide in-article navigation.
• Post 'photosets' — Photography has always been my thing. I've flirted with professional photography a few times but much prefer to "go amateur". I don't use Instagram anymore but would still like a place to share individual photos and also larger "photosets" that tell a story and are accompanied by a few words.
• Going with the grain of the web — This will mean using proper, semantic HTML markup with all the attributes required to be a11y and SEO friendly. Using HTML for markup, CSS for styling and JS only where necessary. A bonus of this approach is that it should be fast and work well for years without suffering web-rot.
• Static pages — For the defacto "about" and "work" pages.
• Lists — I'd like to experiment with public watching/reading/listening lists. Something that also occured to me was consolidating the hundreds of browser bookmarks that I don't really look at (even though I saved these pages for a reason, so should!) into a public reference on different topics.
• HTML caching — Static sites are great...until they aren't. I can get pretty far with my likely web stack of choice (more on that later) but adding full HTML caching will take a lot of load off the application if I ever get a spike in traffic.
• RSS & JSON feeds — I'm ashamed to say that my site has never had either. Something I'd like to rectify

Other features I'm considering

• Private posts — To navigate around my avoidance of social media it might be nice to share articles and photosets that only select people like family and friends can see. This will require a lot of work relative to the results so may ultimately end up on the never-ending back burner.
• Email digests — 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

Tool-less front end development

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 and tools like Webpack are pretty much end game in this regard and I've been down that road before. I found that going 100% static actually creates as many problems as it solves, and that 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 tired of all my CSS and JS needing a compilation step. I've 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 because at this point I've already sunk the time into understanding it. However, I always feel uncomfortable adding it to a project – it just feels fragile and brittle – and open up the project to a world of npm and a huge node_modules folder.

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. That was how I — and many other developers my age — learnt to build websites.

Besides, I don't intend to use much JS so Webpack would primarily have been concatenating files and optimising images in a single command. This is something that MAKE or even a simple bash script can accomplish, without bringing half of all Javascript ever written along for the ride.

Is a database "right" for content?

Representing content as data rather than markup allows for templates to generate the precise HTML required, whilst also keeping design and content as distinct entities — something that's important if you ever want to update the design without migrating your past content to a new format.

Changes to content shouldn't (always) require changes to templates and vice versa. In reality however, the two are dependant on each other and ultimately using a markup language like HTML or Markdown provides a much clearer idea of the content and how it will be displayed. The cherry on top is that using a tool like git to version-control your content provides a litany of benefits over content stored as rows & columns inside a database.

The issue is that using markup often creates a technical-bar that must be met in order to contribute to a site. You need to know HTML (or something simpler like Markdown) in order to write new articles and edit old ones. That's why most CMS' will provide an editing interface regardless of how the content is stored — and once you've got an interface and abstracted away the markup, you may as well use a database for the benefits they can offer.

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 favourable approach unless I want to build a complex editing interface. This is something I'll need to explore in a future post.

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