Hello Again, World!

A return to writing after a five-year hiatus and a quick rundown of the tech powering this site.

Another year, another chance to rebuild my website from scratch. Developers are nothing if not predictable 😉.

This time around, I added blog functionality back into the mix. When I was first attempting to break into web development, I wrote constantly, detailing the new things I'd learned about the latest ES2015 syntax, TDD, odd quirks, etc. Once I got my first development job, though, my writing slowed to a trickle before finally stopping in 2017. In 2023, I'm going to make another go at writing—I've found it to be a forcing function to learn new techniques or solidify my understanding of topics that I "know," but have a fuzzy understanding of. Expect lots of JavaScript, React, Vue, PHP, Symfony, sure … but also occasional experiments with Elixir, RedwoodJS, Astro, and who-knows-what-else.

The tech behind this site

Enough of that, though—on to the juicy stuff, some of the interesting things behind this rebuild. The lion's share is nothing groundbreaking … it's a pretty bog-standard Next JS site. I am excited for one thing, though: MDX with inline React component support 🎉!


All articles are written in GitHub-flavored Markdown using remark-gfm. This isn't interesting by itself—Next has first-party support for MDX—but I didn't want MDX files littering my pages/ directory. Instead, I wanted the following (for tidiness's sake):

  1. All articles live in the articles/ directory
  2. During Next JS's build step, articles get compiled to static pages based on their written date, with the url scheme [year]/[month]/[day]/[slug]

Since I didn't go the "traditional" route (adding .mdx files directly in the pages/ directory), there was a bit more setup involved:

  1. Add a [...slug].js file to the pages/articles/ directory
  2. In the [...slug].js file, add getStaticPaths that builds URLs with the expected parameters of [year]/[month]/[day]/[slug] based on each markdown file's metadata using gray-matter to parse the metadata

This separation of concerns keeps my page-specific development separate from my blog posts—not a huge deal, but it's all about the developer experience.


Speaking of developer experience, one of the features I really wanted in my articles was React component support in markdown. This can allow for inline demos alongside code snippets.

Hashicorp has a module called next-mdx-remote that allows for loading React components directly into MDX via getStaticProps, but it only supports importing components globally (across all mdx pages). This is likely fine for most people, but I wanted to be able to import only specific components for each mdx file for one-off components to pepper into demos.

To that end, I utilized Kent C. Dodd's mdx-bundler. This library compiles and bundles MDX files, as well as their dependencies, ad-hoc, allowing for bundling dependencies on a per-file basis.


Getting all this set up was not the most straightforward—a con of having so much flexibility means, "no one true way of doing things," which leads to cobbling bits and pieces from many different places. However, the pro outweighs this con, as I have a comfortable writing experience alongside an intuitive way to drop in React components when the occasion arises.

If you're interested in how all of this is wired up, feel free to check out the codebase for this site here: https://github.com/dstrunk/danielstrunk-me