How we apply the Rails Doctrine to the Jamstack

For the first decade of Ample's history, we were a Ruby on Rails shop. (Rails is a framework for building web applications, written in the Ruby programming language.) We built the first version of Everything But The House with Rails. We built marketing sites like Buffalo Wings and Rings with Rails. We built our own proprietary CMS that powered our brochure sites with Rails. We even turned down work because it wasn't Rails.

Sometime in 2017 we started picking up on murmurings in the community around the Jamstack, and we immediately began a shift in our business model. We saw the potential of the methodology and chased it.

But that wasn't easy. We were a Rails shop. We had Rails expertise in house, and that doesn't necessarily translate into Jamstack expertise (or interest). And we had all these Rails apps to maintain and support.

While those are all solvable problems, this felt different. It was a shift to an entirely different way of working.

Why?

Well, see, Rails has this doctrine. It provides a foundational set of principles on which Rails is built. It's opinionated. Like, really opinionated. But that's also what makes Rails so powerful — most of the low-level decisions have been made for its developers, and the framework just works.

The Jamstack is different. It doesn't make low-level decisions on the behalf of its developers, but provides the theoretical foundation on which developers are empowered to make those decisions for themselves, considering what works best for their particular scenario. It's a methodology, not a prescription. The Jamstack is a game-changing approach to building websites, but it takes some settling in to get the most out of it.

As our developers at Ample start to settle in and find their groove in building Jamstack sites, I took a minute to consider the path we've taken to get to where we are today. I wondered what influence our experience with Rails played into the decisions we've made with the Jamstack.

To help with the reflection, I asked our CTO Taylor MacDonald which pillar of the Rails Doctrine speaks most to him today, and how he sees that pillar surface in Ample's work with the Jamstack.

Here's what he said:

Omakase is a Japanese phrase used when ordering sushi in restaurants that means "I'll leave it up to you." I recently enjoyed some omakase sushi on a work trip in Seattle and it was fantastic, mostly because I didn't have to make any decisions. Think of this concept as a chef's tasting menu. I don't know shit about sushi so just tell me what to eat! 🍣

To me, the biggest benefits of using any framework is that it does things for you (hopefully lots of things). A well-developed framework should reduce the volume of decisions you have to make and give you options for an exit strategy as you get more comfortable and opinionated.

Rails did just that — made low-level decisions on my behalf. That's why it clicked for me.

Applying that to our work with the Jamstack is tough. Frameworks like Stencil and Gatsby have really empowered us to follow this paradigm as we continue to invest in them. As we grow into this space, we're largely playing the chef role while establishing our own best practices over time.

The more consistency and process-oriented approaches we can apply to our craft, the quicker we'll move and the less boilerplate crap we'll have to negotiate.

In a Jamstack world, we have to be the chef.

We have to establish conventions that enable us to move fluidly from one project to the next. But there's so much we don't know. We're learning one decision at a time and one project at a time. But if we can keep the Rails Doctrine in the back of our minds, we can craft a Jamstack development experience that is both productive and effective.