We recently debuted a rebrand for Chromatic and with that effort came the need for a brand new website. Since a large portion of the work we do is in the Drupal space, our last 3 website iterations have all been powered by Drupal. It is a platform we know inside and out, and we've always felt that if we're going to be players in the Drupal space, we should probably use it for our stuff too. This time around though, things were a bit different.
Is Drupal right for us?
Over the past few years, Drupal has matured. It has become more powerful and more secure, but along with that maturity, it has also gotten a lot more complicated to use. I won't argue that Drupal took a wrong turn by adopting Symfony, Composer, and in trying to keep up with modern PHP applications, but I will argue that it definitely upped the ante on using and maintaining Drupal sites. It simply requires a lot more expertise to build with Drupal 8/9/10 than say Drupal 7, and that's saying something. As we set out to rebuild our own site, we decided to treat this project like any of our client's projects: we'd let the requirements of the project determine the platform, instead of starting with Drupal by default.
A digression: If Drupal is complicated and expensive, who should be using it? What types of sites is it good for?
We still love Drupal and will continue to use it for many of our clients where it is the right tool for the job; where the upsides are worth the costs. Today, I'd say that Drupal is a good fit for sites with at least one of the following requirements:
- multiple content types, each with specific data model needs.
- heavy editorial process and workflows, with reviews, revisions, etc.
- large volume of content (think tens or hundreds of thousands of pieces of content).
- robust media management and generation pipelines.
- custom business logic needs.
- unique role and permissions needs.
- multichannel publishing needs (apps, feeds, APIs).
- multilingual or multi-regional sites or apps.
- tight integration with other 3rd party systems (CRMs, advertising platforms, etc.).
Back to our new site & its needs
We needed a new marketing website to show off who we are and what we do. Literally, none of the requirements above apply to us, so Drupal was off the list. This time around we wanted something that better matched our needs. It needed to:
- be simple to author new content.
- support authoring content in Markdown.
- be fast.
- be easy for any developer to spin up locally.
- be easier and cheaper to maintain.
- support our existing development workflows.
Running a traditional CMS and its associated stack is great for a lot of bigger projects, but I'd say for simple marketing websites today, it is not only overkill but actually the wrong choice. There is simply too much to maintain. Too many dependencies, too many breaking changes.
Enter Jamstack
We've been watching the Jamstack space for a while now and have played around with some emerging platforms in the last couple of years. The simplicity and flexibility these options offer sounded really nice to us. No servers to run, no databases to mess with. Simpler local development environments. Content authoring in pure text files. There are loads of options in this space, but we ultimately landed on Eleventy.
Why we chose Eleventy
Eleventy is emerging as one of the fastest and most flexible static site generators (SSG) around. Outside of those things, which we loved, here are some other features that tipped the scales in favor of Eleventy:
- Eleventy doesn't require any client-side JavaScript to render pages.
- Eleventy's output is purely static HTML.
- Eleventy allows you to intermix templating languages.
- Eleventy is not opinionated about code structure, or much at all for that matter.
- Eleventy requires essentially zero configuration to get started.
- Eleventy's filters, shortcodes, and layout chaining are straightforward and powerful ways to build sites.
- Eleventy is secure since it pre-renders all pages, meaning there isn't a server-side application that could be exploited.
- Eleventy integrates really nicely with Calliope, our open-source front-end development toolchain.
We'd decided that Eleventy checked a lot of the boxes we were looking for so we spun up a prototype and literally within days we knew that it was the right choice for us. At no point in our exploration did we find ourselves fighting the tool. It was such a delight to build with.
Why we chose Netlify
Netlify, like Eleventy, had been on our radar for some time. Its dev- and Jamstack-first approach made it a slam dunk choice for us. Here are some of the things we love about it so far:
- We love that it works the way we do: push or merge to
mainto deploy automatically. - Deploy previews are built-in. Every PR gets a full environment preview, reported back on the GitHub PR automatically. This makes QA so nice. We still love Tugboat, but for SSGs, Netlify is a no-brainer.
- It has built-in global distribution, so it is really fast. Not having to futz with a CDN is just one less thing to worry about.
- Being Jamstack-first means so many of the features are built to support these tools. Coupled with Eleventy, Netlify is fantastic.
The Results
We now have a beautiful, fast, and easy-to-maintain site. With fewer moving parts, myself and others can ship content faster. Our visitors get lightning fast page loads. Our maintenance costs are going to go way down. We'll spend less time engineering and thus have more time to create meaningful content and ship new features faster.
I'm absolutely delighted with this new stack. Eleventy + Netlify is my new favorite thing.
