Rebuilding My Home On The Web

Bilbo Baggins meme: "After all, why not? Why shouldn't I rebuild it?"

I like using projects to learn new things and keep my skills up to date. Everyone has their own pet projects that they keep coming back to. For some it's a version of a todo app they rebuild in whatever tools their interested in at the moment, for others its their blog, or maybe a game. For me, it's my websites. Over the last few years, I've built my resume, blog, homepage, and calling card in a variety of tools. The last few weeks I've gotten that itch again, so decided to start yet another rebuild. At the same time the past few years I've really come to appreciate the idea of learning in public, but haven't taken part as much in the process as I'd like. So, instead of this post being a "Look at this thing I made!" post, this is more of a "Look at this thing I'm making" post. I'll post my plans here and updates as I progress with learnings I've gathered along the way.

The Plan

Over the past couple years, I've slowly started to migrate all of my websites into a monorepo powered by Nx. This project will see the completion of that work, pulling all projects under the same repository with tooling that encourages best practices. Here's the planned architecture : architecture diagram of new websites

❗note: these plans could change at anytime. I'll update here if they do.

The three websites will be built in three different front-end frameworks. My blog will be built with Astro (most likely using React within it), mainly because it's the new kid on the block and I'd like to get to know it a bit. The resume will be built with Angular, because even though I don't work with it every day anymore it still has a special place in my heart and I'd like to see the new standalone components in action and revisit Scully. My homepage will be built with Next because it's currently my daily driver at work and I'd like to strengthen my skills there and work more with the recent ISR tooling.

Those projects that have more dynamic content (e.g my blog, and online resume) will be using Storyblok as the CMS. Why? To be honest, I use Storyblok in my day to day work. It's great! I'm comfortable with it, but want the chance to explore some of the newer updates they've released since the 2.0 rollout last month in a lower-risk environment. I'm deploying my Next based site to Vercel for the same reason. The other two pages, are planned to be deployed to Netlify. I'm hoping by the end of this I'll get a nice refreshed comparison between what it's like to work with all these tools. In addition to the above I have the other goals in mind:

  • standardize my styling to use Tailwind across all projects
  • have live previews working within Storyblok, especially for blog posts
  • organize components and shared logic better via the libraries (mentioned in the above diagram)
  • incorporate A11y testing via end-to-end tests
  • add a feature to share interesting articles/books I've read on my homepage

At this time I'm not planning any large design change, unless I deem it necessary later on. Simply a rebuild and consolidation while learning a few new tools and I'll be happy.

Current Status

All my work can be found on this branch. I'll probably start opening PRs against it vs blindly pushing changes soon. My main landing page, brenden.dev, is mostly complete and can be found deployed on Vercel here.

I have no set schedule or timeline, but hope to have everything finished in the next few months while I work on it during my free-time. Here's hoping! Updates will be posted here, unless the update is huge, in which case I may split it off as a separate post.

Update 1

I've recently updated the styling of my site header so that it fades in as the user scrolls. Scrolling on the page makes the site header visible I had two ways that I could approach this:

  1. Using the Intersection Observer API
  2. Keeping track of the distance scrolled and apply CSS to hide and show based on that distance.

I first tried option 1, but ultimately decided against it. In order to wait to display the header until another element was visible (the next section on my page for example) I'd have to attach the observer to that element or one near it. There isn't a great way to do this that give consistent behavior across a wide variety of screen sizes without tightly coupling the navbar to other components in the page.

Instead I used a trick I found a while back on this great post by Matt Holland. I created a hook that throttled scroll events and would call provided callback with the previous and current distance scrolled from the top of the page. After implementing that it was just a matter of setting the distance I wanted to watch for and then toggle the flag to show the full navbar when the distance was exceeded. Added benefit with this approach: It also cleanly handles with a user scrolls back to the top of the page and hides the navbar. Neat!

Added some testing in my cypress setup to ensure that the element was behaving as intended with scrolling, and we're good to go. I also setup some basic accessibility testing for my app with the cypress-axe plugin and fixed a couple minor issues as a result. I plan to add more a11y testing on the component libraries, but having an overall check on the page is good for now. Checkout the changes here, here, and here.