• 10 min read
• CMS,
  Case Studies,
  Smashing

Smashing Magazine is drastically different today than it was just a few years ago, and you may not have even noticed. That’s how it often is with back-end development — the complete architecture changes, yet the front end you see is still very much the same.

You may recall this site was powered by WordPress up until 2019 when the team migrated our large archive of articles, guides, and tutorials to a Jamstack setup. The change was less of a mission than it was an experiment that stuck around. Sure, WordPress is still an incredibly viable CMS, especially for a site like Smashing Magazine that focuses on long-form content. But after seeing a blazing 6× improvement in page speed performance, Jamstack was something we couldn’t dismiss because the faster experience was a clear win for readers like you.

What we may not have expected was how the migration from WordPress to Jamstack would improve our developer experience in the process. We knew for sure that users benefitted from the change, but it wound up making our lives easier as well, as it opened up even more possibilities for what we can accomplish on the site — a real win-win outcome!

It took work to get to where we are today. We went from authoring in WordPress to authoring in Markdown files, so it’s not like we started reaping benefits right away. It is only now that we have integrated TinaCMS to our stack that our entire team is reaping the full benefits of our Jamstack architecture.

That’s really what I want to share in this article: a peek behind Smashing Magazine’s curtains at how we manage content. TinaCMS is not WordPress, so it has influenced the way we work. We think it’s pretty cool because TinaCMS is all about the developer experience in a CMS context, so, of course, the inner developers in us have nerded out over the sorts of things that we are now able to do.

Tina Who?

TinaCMS is not a household name in the CMS space. I’d say that’s likely by design, as its niche is clearly in the developer community rather than a “low-code” offering like WordPress or a completely “no-code” solution like Squarespace. TinaCMS has a clear audience, and the team here at Smashing Magazine just so happens to fit that profile in spades. Not everyone on the team is a developer, but most, if not all, of us are comfortable working in Git and the command line.

TinaCMS can be broadly characterized in two ways: an open-source Git-based CMS that supports Markdown files. In fact, TinaCMS saves content to Markdown, MDX, YML, and JSON, allowing a team like us to query data on top of our static assets. It also creates a GraphQL API for that content, allowing a team like us to query data from our files. And since it’s all connected to a GitHub repo, we own and control everything. That’s an enticing value proposition for a company whose business is content. A self-hosted WordPress instance is similar in that regard, but having all of our content in a centralized repo that contains hard files makes “owning” our content more tangible than it is to store it in an SQL database on some server.

That’s a bit about TinaCMS. It’s designed for Jamstack the same way that you might think of Sanity, Storyblok, or Netlify CMS, but it goes further than what we’ve seen, offering everything from a content API (in GraphQL) and visual editing to an integrated local development workflow that serves us quite well here at Smashing Magazine.

The Current Writing Process

Before we look at TinaCMS’s UI and specific features, I think it’s worth sharing how content is written before it’s published on the site. It’s far from perfect and still a work in progress, but it will give you an idea of how we work and why TinaCMS fits our needs.

There are two paths we follow for writing articles: write in a Markdown file connected to a GitHub repo, or write in a collaborative space, like Dropbox Paper or Google Docs. The path we take is whichever one a contributing author is most comfortable using because both have pros and cons.

To be honest, the process is pretty much the same, no matter which path we use. The author writes something, and an editor on the team reads and edits it. Dropbox Paper exports to Markdown, so it’s really a matter of whether the author prefers a GUI or a code editor for writing. Dropbox Paper might be a little more work