Actually, we never left. We didn't stop building Drupal sites, even through the long release cycle. However, we did move our company website, activelamp.com, off of Drupal about 18 months ago. Our company site had been built on Drupal since the Drupal 4.7 days. That was back when it started to become uncool to write and maintain your own home-grown CMS. I eventually found Drupal, ditched my custom CMS, and never looked back.

Our site started on Drupal 4.7, upgraded onto Drupal 5, then Drupal 6, and also Drupal 7 all at the beginning of the release cycles of Drupal. About 18 months ago, when our site was in dire need of an update, we evaluated Drupal 8 but realized with no release date in sight, and the fact that we did not want to chase HEAD and develop on unstable API's, we decided to go a different route and build our updated site on Jekyll, a popular static generator. It's more fun to tinker with new technology when working on non-billable stuff, which is what we did. We brushed up on our Ruby skills and built out a Jekyll site (which is this site you're looking at if you're reading this blog post before Q3 of 2016).

We're getting ready for another update to our company website and moving back to Drupal to do it. Jekyll was great, but it came with its disadvantages over something like Drupal. This post will highlight some of the advantages and disadvantages of working with Jekyll the past 18 months, as well as highlight why we're excited to put activelamp.com on Drupal 8 in Q3 of this year.

Getting off the Island

If you've been around the Drupal community for a few years, you've probably heard the phrase "Get off the island". There was, and still is, a big push to bring other technologies into the Drupal stack and rid ourselves of NIH Syndrome -- Not Invented Here Syndrome.

We as a team took this movement quite literally and started doing more than just Drupal. We started to take on projects utilizing the Full Stack Symfony Framework, Laravel, AngularJS, Ember, Express / Node, Hapi, and Jekyll. We had successfully gotten off the island, so to speak, and it felt good. We decided to build activelamp.com on Jekyll, it has several advantages over using a CMS like Drupal.

Advantages of Static Generators

Having a statically generated site has huge advantages. Let's review a few of them:

Performance / Scalability

You don't need a complex hosting setup to host your site. We are currently hosting activelamp.com on S3, a simple storage service provided by Amazon Web Services. In fact, several months after we launched activelamp.com, we built a Jekyll site for Riot Games hosted on S3. The start of season League of Legends site we built on Jekyll handled millions of requests per day, hosted on AWS S3. Not bad for such a highly trafficked site. No moving parts equals a fast site.

Security

Since Jekyll sites are static HTML, there isn't a backend to exploit. There are no scripts that actually run on the server. This means you don't have to stay up-to-date with security updates -- there are none.

Structured Content

The final output of a Jekyll site is a static HTML site, but we still have structure when creating content. On activelamp.com, we have blog content, video content, job postings, etc. We add content using Markdown, with a little bit of YAML at the top of the file, and place the files into specific folders in our document tree. Jekyll compiles the site from a set of HTML templates, YAML, and Markdown files. Our content is written into discrete files and compiled on build. Since our content has semantic structure, we are still able to compose pages together with whatever content we want, we just need to write a Ruby plugin to do so. Which leads us to the disadvantages.

Disadvantages of Not Using a CMS

We found ourselves spending lots of time writing Ruby plugins when we wanted Jekyll to act more like a CMS. A few of the disadvantages we faced with our site on Jekyll include:

Editor Experience Sucks

If you have non-technical people on your team that want to contribute, there is a high barrier to entry. We have a few non-developers on our team, and it would be so much nicer if they didn't have to use Markdown to write blog posts for our site. The rich experience you can have with Drupal 8 and CKEditor is top notch, something we're missing using Jekyll. Running Jekyll, our non-technical users needed to learn how to compile the site to preview changes and also had to learn how to use git to submit their blog posts for review before publishing them. Jekyll is great for developers, not for non-developers.

Have to Write Code for Everything

Not that I have anything against writing code, but I've been spoiled by the Drupal community. For the most part, there is likely a module for anything that you want to accomplish. If there isn't a module in the wild, there is a huge community behind Drupal that will hopefully contribute to a new module that you put out, continually improving it (Plus, I would much rather code PHP than Ruby).

No Backend, No Interactions.

I listed no backend as an advantage above under Security, but you really can't do anything interactive without a backend. Our activelamp.com Jekyll site actually has a small backend written with Node JS. We have a small Express app that handles the forms and social streams, and a small Handlebars app that calls out to Google Analytics to create the most popular posts lists on blog category pages. Our site isn't 100% static, it's just not possible unless you truly do want a brochure type site where users are just consuming content, not interacting.

Excited for Drupal 8

We have been building on Drupal 8 since last December. We launched a portion of a site on Drupal 8 a couple months ago, and we're launching a full site in a few weeks on Drupal 8. Drupal development has become exciting again.

Our new website is going to call for more interactivity with our users (premium content, client portal, partner portal, etc...). It's in our best interest to go back to a platform where we don't have to code every feature that we want. Another advantage for going back to Drupal 8 is that we'll get to setup a nice content publishing workflow for ourselves again. Jekyll was fine, but we've built some pretty nice workflows for our clients, it would be nice to get an easier workflow into our internal processes too, to relieve the tension for the non-developers on our team.

Most importantly, Drupal 8 is fun to develop on. The OOP approach to writing modules, and leveraging composer packages is amazing. Drupal has definitely taken a step in the right direction. In my opinion, as Drupal 8 gains traction it will become the de facto standard for Enterprise CMS needs.