Avoiding premature (feature) optimization
I tend to get a little feature-happy whenever I start a new project, like this blog.
I knew I wanted to have a blog. So naturally, I’d need the basics: an index page, a post page, and somewhere to write my posts.
That’s more than enough to start, but inevitably my thought process devolved into something like this:
What about a Table of Contents for longer posts? Clicking on a ToC item should smooth-scroll the content into view. Oh! And why not have a neat animated font-weight effect on the ToCs as we pass content on the page. And let’s allow ToCs to be deeply nested until Heading 3 tags. Gotta consider all the edge cases. What about categories? We have to keep everything organized. Also tags. What’s the difference between a category and a tag again? Better have both just in case. Okay so now I need to have separate blog index pages for categories and tags. And we should probably validate against duplicate categories and tags because it would be bad to duplicate routes. What else am I missing? Pictures! A picture tells a thousand words blah blah. Okay, so I can render images inside markdown files, and — oh wait if I do that then I would have to store the images in GitHub and that would make my repo size too big. Is that what Git LFS is for? Maybe I should just use a CMS. Nothing too heavy like Contentful of course but I heard Netlify has a CMS that’s basically a light-weight wrapper around the linked GitHub repo. So I guess that wouldn’t solve the image storage issue but I could always use Cloudinary or some service for that. The big win would be that I could preview markdown styles and stuff easily, and oh! I almost forgot about markdown styles. I got my basic headings and paragraph tags covered, but what about quotes? Code blocks? Yes all legit developers have nicely-styled code blocks in their blog posts so this is a must-have. I can use Prism.js for this — no need to re-invent the wheel. Since I already have three different color modes I just have to make sure that code blocks appear nicely for all three. Wait what was I working on again? Oh right images. I know that it’s trivial to put images in markdown files, but what if I wanted to adjust the layout? I am thinking to start we’ll just have three layouts: an inline style with the same max-width as the paragraph tags, a full-width style that stretches to fit the outer container, a side-by-side view of two images (maybe with horizontal scroll in case I want more than two), and a neat staggered layout where the first image takes up the full height and images 2 and 3 take up about half the height each on the right side of the container. It’s hard to explain but trust me I can see it in my head and it all looks great and it’s all about that golden ratio — oh wait that’s four image layouts, but it’s fine I’m creating these layouts anyways it’ll be easy to add another. If I use Gatsby Image I can render a loading placeholder for each image, and in terms of options there is this blur placeholder, traced SVG placeholder, also I’m pretty sure there was this colorblock placeholder but I can’t find it right now. Anyways, I’ll spend this afternoon testing how these different placeholders look on different images with different backgrounds and colors and …
The great irony in all of this is that of all the many times I’ve tried to start a blog in my life, I’ve never gotten even remotely close to the point of having to worry about any of the above. I’ve got to wonder if it’s related.
Anyway, the main reason I wrote this up was because I wanted to add a “previous post” and “next post” nav bar at the bottom of each blog post. It didn’t make sense before when I only had one post, but now that I have two this doesn’t count as pre-mature optimization. Ha!