Why are organizations still building websites on old technology like Drupal or Wordpress these days when there are so many more hip ways to deliver your content?

JavaScript frameworks are taking over the delivery of website content because they offer much more streamlined experience to visitors, providing a more app-like feel to traditional websites. Navigating through these streamlined JavaScript websites don't require a page load anymore when clicking links to go from page to page. You click on a link on the page and you get the new page instantly without watching that browser loading icon spin while the new page is requested from the server. JavaScript is basically changing the visitor experience to feel more like a web app and not a traditional website. So are these older technologies like Drupal still relevant or should your team be looking at one of those front-end frameworks like Gatsby or Next.js to deliver content to your users? I want to give you some things to consider before jumping ship from traditional web content management and head-first into one of these JavaScript frameworks.

What's up internet; Tom Friedhof here, a solutions architect here at ActiveLAMP. First off let me start by giving you some background on the problem. Our team here at ActiveLAMP has built some pretty large-scale Drupal sites for organizations such as Riot Games, UCLA, and the Grammys. Sites like these get bombarded with traffic and require significant infrastructure tuning as well as code tuning to make sure that servers that they're hosted on can deliver as many pages per second as possible so that under extreme traffic loads the server doesn't blow up and stop serving traffic to anyone causing an outage. There's a lot of complexity involved to deliver content for high traffic sites like these on traditional server-side applications, like Drupal. For instance, code optimization spending countless hours profiling your code to find slow areas that can be improved to speed up response time. Or implementing a caching strategy so that your code doesn't have to execute as often. If a request comes in that's already been processed the server knows how to handle that. There's also scaling servers horizontally so that you can distribute the incoming load across several servers to keep up with web traffic and also ensure high availability of your site. And if your site is prone to burstable traffic setting up auto scanning to deploy new servers when thresholds are met on the currently launched servers so that your site can continue to deliver content when enormous spikes of traffic hit your infrastructure. There's a lot of complexity involved when delivering content from a traditional CMS like Drupal to serve high loads of traffic.

So why am I telling you this? What does scaling a Drupal site have to do with deciding whether or not to use a JavaScript framework like Gatsby or Next.js for the next iteration of your website? Is there a better way to do enterprise content management? The answer is yes, and there is even a new buzzword for this pattern, called the JAMstack. The JAMstack architecture takes the complexity out of writing fast code or implementing a caching strategy or even thinking about scaling servers. It's the holy grail right, well kind of, it's really only a better solution if it works for your organization. Typical consulting answer right? There are a lot of things to consider when embracing the JAMstack architecture. What the JAMstack architecture does is, it pushes the complexity upstream out of the hosting aspect of websites and more on the development team. There are always trade-offs and the JAMstack makes no exception. Some things definitely become simpler while other things become much more complex with the JAMstack. What is the JAMstack? I like to think of the JAMstack as taking all of that complexity out of delivering content to website visitors and instead, jamming all of that complexity into assembling content into a format that can be delivered easily to your visitors. That's not what it means though, JAMstack is yet another acronym for the tech stack that describes it.

JavaScript APIs and markup. That's what makes up the JAMstack. The "M", markup is what makes hosting a JAMstack so simple. The output of a JAMstack website is markup the native language of web servers and web browsers since the very beginning. JAMstack websites are served as static HTML files. Your website becomes a static HTML website. That's how the web has worked ever since its inception back in the 90s. A visitor requests a web page an HTML file the server delivers the HTML file and the web browser reads the HTML and renders it for the visitor. I don't think most people realize it but most content management websites are static content with a little bit of dynamic functionality sprinkled in. You know mostly static, sure you might have 10 contributors publishing a few articles of content to your website per day, but after that content has been published from your website visitor's perspective the content is pretty much static. Now, this isn't a complete throwback to the 90s. The "J" and "A" are what make the JAMstack really sexy. The JavaScript in APIs part of the JAMstack is where a front-end framework like react comes in. JAMstack websites don't have to be completely static. Because JAMstack websites are rendered with JavaScript it's possible to make parts of your static website dynamic with JavaScript calling back-end APIs. For example, authentication could be handled with a backend API service, like Auth0. The login button on your website can be rendered statically but on click open up a login dialog so that a visitor can sign into your website. Commenting on your static site can be handled with a drop-in JavaScript snippet, from Disqus, to get fully-featured commenting. Custom dynamic functionality can be handled with cloud functions that don't require expensive hosting. Having a static website does not mean that your site is static, just mostly static.

This concept of building a statically generated site isn't a new thing. Our team has been building static sites for our customers for almost a decade. In fact, if you're watching this video in September of 2020, our current website activelamp.com is built on Jekyll, the pioneer of statically generated sites. In my opinion, the react players in this space are changing the landscape of static sites and making building static sites the new norn. The new activelamp.com site that we're getting ready to launch is built on Gatsby and it's amazingly fast, faster than our current Jekyll static site.

So what does this mean for technology such as Drupal? Does this mean you shouldn't be building on Drupal anymore? Again the consulting answer to that is, it depends. So what does it depend on? Drupal is still relevant. Drupal is still a great content management system and it's still a leader in the open-source content management space and you still need a way to manage content. The JAMstack doesn't solve the content management side of things, just the delivery of content to visitors. We've recently had conversations with several of our clients that are currently in that stage of making the decision to whether upgrade from Drupal 7 to Drupal 9 or to completely re-platform to another more hip technology. Should you decouple Drupal and use Drupal only for the content management aspect of things? This would keep your content and your content contributors in Drupal while having the user interface of your site not rendered in Drupal, but in a JavaScript framework. This could be a good solution, but then the next question is: If you decide to decouple Drupal what front-end framework should you use? In my opinion, Gatsby or Next.js are the big players in this JAMstack ecosystem. What are the differences between Gatsby and Next.js? When is one better than the other? I have opinions on this and when you should use Gatsby over Next.js.

I'll share my opinions on this in a future video. Once you've decided to decouple, the next thing you need to consider is: Will decoupling Drupal cause more overhead and staffing? Do I need to hire two people now? One with JavaScript experience and one with PHP experience. Which then leads you to asking: Is staying with coupled Drupal a good idea? Or should we check out a hosted headless CMS like Contentful or Prismic? There are so many things to consider when choosing to re-platform to a JAMstack architecture.

I'm going to answer these questions in part two and part three of this series. In my next video, I'll dive deeper into the questions I presented regarding Drupal coupled, Drupal decoupled, Drupal, or hosted CMS. Part three of this series, I'll talk about the differences between Gatsby and Next.js and when I think it's better to use one over the other.

Make sure that you hit that subscribe button so that you're notified when we release these videos and hit that like button for us. See you in the next video.