[00:00:00] Nathan Wrigley: Welcome to the Jukebox podcast from WP Tavern. My name is Nathan Wrigley.

Jukebox is a podcast which is dedicated to all things WordPress. The people, the events, the plugins, the blocks, the themes, and in this case, the past and future of website hosting.

If you’d like to subscribe to the podcast, you can do that by searching for WP Tavern in your podcast player of choice. Or by going to WPTavern.com forward slash feed forward slash podcast. And you can copy that URL into most podcast players.

If you have a topic that you’d like us to feature on the show, I’m keen to hear from you and hopefully get you all your idea on the podcast as soon as possible. Head over to WPTavern.com forward slash contact forward slash jukebox, and use the form there.

So on the podcast today, we have Steve Persch and Brian Perry. They’re both employed at Pantheon, an enterprise website operations platform. And they’re here to talk about the evolution of website hosting.

Back when the internet started, hosting was a fairly straightforward enterprise. You created HTML files and uploaded them to a server. That was it. An HTML file was a page.

Server-side technology such as PHP came along, and the picture became a little more complex. Web pages needed to be constructed on the fly. Databases were thrown into the mix, and the complexity increased. Add in the different languages that you could write your code in, and the server configurations. The CMS that you choose also plays into this mix. Now we’ve got CDNs, headless, React, Gatsby, Node.js and much more. Is it even possible for the non-technical to have any understanding of where their website is?

Steve and Brian talk about how they got into the hosting space, and what’s changed over the years. We address what Pantheon is doing with WordPress and Drupal.

We discuss how headless can be difficult for content teams, given that there’s a disconnect with hitting the publish button and that content going live on the site.

What’s certain is that there’s no end in sight in terms of the rate of innovation in the website hosting space. What’s popular today might not be several years from now. And so it’s a timely discussion of what Steve and Brian see as the best bets for the future.

If you’re interested in finding out more, you can find all of the links in the show notes by heading over to WPTavern.com forward slash podcast, where you’ll find all the other episodes as well.

And so, without further delay I bring you Steve Persch and Brian Perry.

I am joined on the podcast today by Steve Persch and Brian Perry. Hello.

[00:03:37] Steve Persch: Hello, Steve Persh here. Happy to be here.

[00:03:39] Brian Perry: Yeah, Brian Perry also really excited to chat.

[00:03:42] Nathan Wrigley: Well, thank you for joining me on the podcast today. We’re going to talk about something, and I seem to have said this sentence much more often recently, about something that that really is a mystery to me. You are going to school me in all sorts of ways about something that I’m really not that familiar with, and that is all about how files get served up. Where are our website files being kept? Where are the computers? Where’s the infrastructure, and how much more complicated it has become over the last 10 or 15 years.

Before we begin that, I think we’ll take you in order. I’ll go Steve first, if that’s all right? I’m wondering if both of you can give us a little bit of orientation about who you are, who you work for. Your history with technology and possibly WordPress in particular. So yeah, we’ll launch that with Steve.

[00:04:28] Steve Persch: Sure, so Steve Persch here in Minneapolis, Minnesota. I’m the director of technical marketing at Pantheon. We’re a website operations platform for Drupal, WordPress and now front end frameworks, which is, much of what, thinking about that question of what computer makes the website.

I’ve been in the web space for a while now. I first started making websites, first semi-professionally, and then professionally in the early days of WordPress. I built some of my first professional websites in WordPress 2, back in 2006. Then for some of the sites that I wanted to make, that took me into the Drupal world. And now in Pantheon, we play in both of those worlds, in the lamp stack, and as Pantheon is aiming itself at running extraordinary websites, as we like to say, the best possible websites. We see that that requires us to step more fully into the JavaScript centric front end framework ecosystem.

[00:05:23] Nathan Wrigley: Well thank you Steve. That was great. We’ll hand it over to Brian to do a similar job.

[00:05:28] Brian Perry: I’m Brian Perry. I’m a staff software engineer at Pantheon. What I’m focusing on at Pantheon is leading a project we’re calling Decoupled Kit, which is a set of open source utilities and projects that aim to make this decoupled architecture or running headless WordPress and Drupal sites easier.

What brought me to that is, prior to Pantheon, a lot of my background was in the agency space. Specifically focusing on front end and front end develop. More and more I found myself interested in what was going on in the JavaScript ecosystem, and working on projects where using a CMS like WordPress or Drupal to feed data into the front end. But also found that there were a lot of solutions that were being invented over and over to solve those problems. So being able to focus on trying to make that easier for folks has been really exciting.

[00:06:24] Nathan Wrigley: Thank you very much indeed. So you’re both coming from Pantheon and you mentioned there that you have a very keen focus on, well you mentioned two CMSs, which is curious actually. Obviously this is a WordPress podcast, but we’re not here to destroy the opposition if you like. But Drupal and WordPress, I think I’m right in saying that you don’t find too many hosting companies that lay claim to both of those. Is that a relic of the past of Pantheon, how it all began back in the day?

[00:06:51] Steve Persch: It’s an intentional choice. We think that supporting both of those systems gives us more flexibility. It ends up fitting us better to our core audience. Pantheon started with digital agencies. Our four founders came from running web development agencies, that’s the background.

And for a lot of the agencies and in the ecosystems we came from, we knew that it was normal for those sorts of agencies to have a preference between Drupal, WordPress or, you know, Ruby and Rails or any other of system. But often, the given client you’re working for might have both, for any number of historical reasons.

So yes, the initiation of that was, uh, somewhat happenstance. Our customers figuring out like, this platform was first built for Drupal, I bet we could make it run WordPress. And then Pantheon as a company realizing like, yes, we should support WordPress. That’s something that I think was a bit inevitable.

It’s good for us technologically and business wise to support more than one. And at the same time it’s good for us to not open it up as wide as, well, anything PHP. Some of our competitors take the other extreme of, hey, if you can make it run then you’re good. We think of ourselves as, we prefer the term, a website operations platform.

And hosting is a feature of that. But don’t want to have a relationship with our customers that’s as simple as like, well, yeah, if you can make it run, that’s good. We’re only here to provide the server. We see ourselves as facilitating more growth of value of the websites, not just the question of can this run at all?

[00:08:21] Brian Perry: Yeah, I think that, that same sort of concept also extends to the front end and JavaScript frameworks in that, there’s definitely a lot of excitement around Next.js. But we are looking to build a platform where other future frameworks can run on it. But also, yeah, we’re not necessarily trying to be like, run whatever crazy JavaScript project you want. We want to have some guardrails there.

[00:08:44] Nathan Wrigley: I remember back in the day prior to stumbling across WordPress, which I did quite a long time ago now, I used to use Drupal exclusively actually, and I have a, have a memory of Pantheon cropping up, and at the time, really hadn’t heard of a hosting company that was binding itself to a CMS in that way.

It was curious to me that Pantheon had laid claim to, okay, if you’re using a CMS, we’re somebody that you should look at. Prior to that, it was always, we’re just a hosting company. You know, we’ll host anything.

[00:09:16] Steve Persch: I often go back to the first blog post that was done by, one of our co-founders, our four co-founders, when Pantheon started. I think the title of the blog post was Putting the Humans at the Top of the Stack. And it laid out, or at the time, but a decade plus ago, two common ways of running websites.

One was just that hosting mode of a host providing some baseline technological capabilities, but the team buying the hosting is responsible for assembling the parts and making it all work. And yes, that’s an appropriate choice for some teams, but it’s not a great recipe for success for what we see as the broad plurality of professional web teams.

The other extreme at the time, and it’s still present there, is the Squarespace, Wix, very templatized, cookie cutter way of building a site. Which again, is totally appropriate for certain people who need websites. But Pantheon, a decade ago and still now, wants to find a middle path that empowers the majority, or a plurality of professional web teams to make the best possible websites.

And we see that, fulfilling that mission does require us to build CMS specific capabilities, and now front end framework specific capabilities, while not putting ourselves as narrow as only WordPress, or only Next.js.

[00:10:35] Nathan Wrigley: Okay. That’s really interesting. Thank you for that. The subject at hand is really about how hosting has changed over the last decade, two decades, what have you. And it might be of interest to the listeners to the podcast if they pause for a moment and go and watch one of the videos. It was created by Steve, I believe, created the video.

It’s called Decoupled Architectures, What Computer Assembles the website, and it’s a great watch. It’s. 10 minutes long, and it’ll give you a real insight into the things that we’re going to talk about. What Steve brings to bear is lots of papers and drawing, which we can’t do on this podcast, but they really do help solidify the problem. He’s got lots of nice diagrams of how things are working.

But just to rewind the clock, let’s go back 20 years or so ago. It seems like an age almost at the birth of the internet almost. But if you had a website, whatever CMS it was. You would have to host it somewhere, and you would probably select a host and upload the files.

They were probably at that point, just static HTML. I imagine CSS probably hadn’t even emerged at that point. And you just uploaded them. And you had a great idea of where that computer was. You had a slice, a share of that computer. It was yours. You could point to where it was on the map and so on and so forth.

And that’s not how it’s done now. Or at least that’s not how everybody’s doing it. So I want us to run through a history of how that’s changed over time. Going right back from the beginnings when the internet began and you could build your own websites. Right up to how it’s done now. We can really be ponderous about this, we’ve got a whole episode ahead of us. So, whoever wants to begin that journey, you can flip flop and change, do tag team if you like, but that’s what I want to do. The history of how hosting has changed.

[00:12:19] Steve Persch: Brian, if you don’t mind, I’ll start from flat HTML files, and enter us into the era of PHP. And then you can talk about CMSs. So one of my first experiences getting paid to maintain a website, a thing, I wasn’t even pondering as a career path. I was a theater major, and then I found myself working in the marketing department of a theater company. And they had a flat HTML website that did the job, was good enough for the early two thousands. A few hundred pages of flat HTML files, mostly it’s like if you want to buy tickets, call this phone number. Here’s the production that we’re producing, here’s the calendar.

And one of the most annoying tasks, once I became the person getting paid to update the website was, add this menu link in the sidebar. And that sidebar appears on like a dozen pages. Okay, so I open up a dozen flat HTML files and then I notice, oh, this sub sidebar menu for the education department of the theater company. This menu isn’t even consistent on these 12 HTML files, because over however many years, copy paste errors happened. And that’s annoying, and creates a bad, confusing experience.

But, I know enough to realize that I could put in some PHP tags, and save myself some time. That’s how I first started transitioning that question of, what computer assembles the website? How does this website really come together? The first answer of, it’s all flat HTML that I’ve got to hand code on my own machine to, what if I put a little bit more, just a little bit more intelligence in the server and told it to like PHP include education sub sidebar dot PHP.

Then I don’t have to worry about copy pasting menu updates across 12 HTML files. That started to transition the question of what computer assembles the website, but the content management systems that were cropping up at the same time, WordPress, Drupal, others, provided a much more robust answer. But I can let Brian talk about that.

[00:14:25] Nathan Wrigley: I’ll just interject at that point because the pain that you’ve just described was my pain. I remember exactly that. I mean, it wasn’t the 200 page website, but I remember the exact same thing. And then stumbling across the, oh, you can include something with PHP can you? That will take that whole burden, maybe the header or the footer or wherever it may be on the website.

And I do remember finding that really quite startling, and thinking good grief. I’ve just saved myself literally hours of time, and it was fabulous. It was really, really an excellent moment. So, okay, so.

[00:15:00] Brian Perry: It’s also a, it’s a gateway to the danger of creating your own CMS, I don’t know if anybody on this has done that?

[00:15:07] Nathan Wrigley: Yes, that’s exactly what I did. We’ve laid the pathway then to, we’ve got PHP in there somehow now, and so now we’re moving towards CMSs. So I guess we’ll hand it to Brian to tell us what came next.

[00:15:19] Brian Perry: Yeah, and Steve, feel free to jump in as the overall tour guide with any color commentary. But yeah so, many of us have rolled our own CMSs. But then projects like WordPress and Drupal come along and provide a consistent user experience to being able to manage your data. Have an associated front end.

It’s the great situation where there’s a community of folks making that project better, rather than the CMS we built on our own. That is a situation where you have your CMS, that handles that data. But it is essentially a single lamp stack. And your CMS is responsible for assembling your website. So you can edit things in the admin. But at the end of the day, WordPress, for example, is what puts everything together, using its templates and providing the end page that the user interacts with.

[00:16:15] Steve Persch: Another way I think about this progression is through the lens of the three really broad groups of people who make a website like this possible. Especially in those early PHP days, to make something like this work there’s someone probably with an IT sort of job title who’s setting up the server. There’s someone with like a web developer type of job title who’s making the Drupal or WordPress part work, and they may be working with designers as well. And then there are people managing the content.

So in addition to what computer assembles the website, a more specific framing is where is the work of these three broad groups of people coming together? It’s coming together over and over and over and over again, to make a functioning website. And in the lamp stack era, it’s that PHP server, you know, be it shared hosting or a server in the closet. That is where the work of those three groups has to fit together.

And for the decade or so that the lamp stack was dominant, there became pretty solidified best practices on how those three groups need to work together in order to do their jobs most effectively.

[00:17:26] Nathan Wrigley: I feel that’s a really nice segregation of the different things that were going on. But also it makes the two bits that you are not involved with suddenly quite mysterious. If you’re the content editor, suddenly the IT bit, the hosting if you like, you’re no longer involved in that in any way. And, so that over time becomes a little bit more murky and what have you.

But the advent of the CMS suddenly opened up a whole range of possibilities for people who really don’t have any technical, they don’t desire to be technical. They want to be consumed with the content. They want to log into something, type away, upload images, what have you, and press publish, and for it to be done.

So I think that’s a really useful definition. Prior to that, you had to be fairly technical, at least technically enough to create the HTML and what have you, to then upload it to the server. And now we’ve got a kind of career path coming out of it, haven’t we? We’ve got the IT people, we’ve got the editor people, and various other different pieces of the puzzle.

It feels like maybe that is where quite a few people will still be with WordPress. That is to say they’ve got a WordPress website, they’re paying a monthly fee to a hosting company. That hosting company is literally holding the files of the CMS, in our case, WordPress. Holding them on a particular box somewhere. The DNS is pointed correctly. It all works. That set up is still doable, but I guess the journey doesn’t end there. I suppose we’ve got quite a long way to go in this journey.

[00:18:59] Steve Persch: Yeah, the journey does not end there. Actually it might, because it comes back around. There are other steps along the way. So, I see the next big event in this history as the release of the iPhone. Which for a while I wondered like, am I drawn to that as the key moment? Because that’s when I was coming into professional web development, around 2007. In the decade plus remove, I can see, no, that really was a big deal when we had to figure out how to make websites squish, and fit on different size devices. Phones, tablets, Android devices of every single size and resolution.

That was a huge change. And it came about at the same time these native application ecosystems sprung up, and really, really raised the bar for how good of an experience you could have on these devices. So not only is this just a new form factor to make work at all. The quality bar jumps up very, very high. In retrospect, I can see like, oh, that set off a bit of a panic in the web development community. And different people reacted in different ways and, you look at the 2010s and think, oh yeah, people ran in a bunch of different directions trying to handle or deal with the existential question of, how does the web stay relevant when literally billions of dollars are pushing technology towards native applications.

[00:20:33] Nathan Wrigley: I feel there’s some other pieces I might add into that as well, and that is, the invention of the iPhone, which then spawned so many other similar devices, some slightly larger, some competing operating systems. But the thing there was suddenly the internet went from something which was probably peripheral in your life.

You would interact with it, maybe with email or something at work. You’d have to turn on a computer and sit in a chair. And the internet would be on that screen and then you’d walk away from it and you’ve forgotten about the internet. Suddenly you’re at a point where the internet is with you 24 7, should you wish. It’s there all the time. So it marks a moment where not only is it technically possible to do it, but it increases the importance in everybody’s lives. So, almost everything now, what are we now about 15 years later or something?

Almost everything can have a web presence. You know, you were talking about buying tickets earlier. Well, what’s the best way to do that now? It’s the internet. How do you consume your radio? It’s the internet. Where does your entertainment come from? It’s the internet. There’s almost nothing, which the internet hasn’t touched, and I feel that that was the inflection point when it went in your back pocket and suddenly every company on earth had a window into everybody’s lives.

[00:21:50] Brian Perry: It’s a blessing and a curse.

[00:21:52] Nathan Wrigley: But also a convergence of the technology, you know. So cellular data was suddenly getting rolled out. Prior to that it was just mobile phones was as, as much as you could do. You could do voice chat and so on. But then mobile data came along and it all coincided at the same time. So I, yeah, Steve, I think that’s a really insight thing. The iPhone being this moment.

[00:22:09] Steve Persch: So the iPhone, when it comes out, it suddenly becomes the most powerful computer in the whole stack. If you’re thinking about what can we make a website or a native application? What can I do with this device? A lot of people consciously or unconsciously realized if we push more responsibility to this last computer in the chain. From the developer’s computers. There are still servers involved.

There are increasing number of computers in the cloud that are involved in getting the website to that iPhone. But the iPhone in many respects, the most powerful computer in the whole stack, and that leads to an architecture of, oh, let’s make that end device, be it a laptop, a high powered iPhone or a low powered budget Android phone. Let’s put all the responsibility there. Brian, I bet you could talk in greater detail about the upsides and the downsides of the single page application architecture that came about when a lot of the web development ecosystems said, oh, let’s put all the responsibility in the client, in the end device.

[00:23:16] Brian Perry: Yeah, there’s definitely like a huge trade off to that in that the end result that we’re doing there, especially thinking about modern JavaScript frameworks, were essentially pushing more responsibility, more code, more JavaScript to that end device. So there’s more places where things could potentially go wrong.

There’s more cases where rather than having just a HTML document that is passed from a device to device, it actually has responsible, responsibility for rendering the page and executing all of that code. And it’s even a situation where things as simple as being able to click the back button in your browser to go to the previous HTML document, that’s things that need to be handled within that client device.

So it really does increase the complexity there. And then also related to what we’ve been talking about and thinking about, the three audiences that we talked about before. One thing that jumped out to me is that as we’re finding all of these, you know, the internet everywhere, and all of these, different devices that can be used for these different purposes. I think some of also what brings us to the headless architectures that we’re going to get to down the line, is in some ways, I think driven by the content editor. In that they still want to have one place where they can go and manage content that is going to show up in all of these different places.

Whether it’s a client side page, a traditional website, things managed by PHP, and I think that also does start to lead us in the direction of how can we manage this content in one place and make that data available to all kinds of different consumers.

[00:25:01] Nathan Wrigley: So we have the, we have the iPhone, and prior to that we have just regular servers. I guess we’ve now got to take a bit of a leap and stray into an area where maybe many of us really don’t know what we’re talking about, and I’ve very much include myself in this. What are the evolution of things that have happened subsequently since the iPhone?

And what was the purpose of all of that? Were there things which were tried and failed? And I suppose we are slowly getting towards the present day, but if there’s been some interesting evolutions during that time which need to be mentioned to give context, please do.

[00:25:35] Steve Persch: Absolutely, I think one dynamic that played out in the 2010s was the splintering of all these different disciplines. I said in that lamp stack era, there are these three broad groups, of IT and content editors and developers. And I was even lumping in designers with the developers there.

There might be some designers who take offense to that, but you know, it’s a blurry line. I lump them together because at a very, a very zoom out level that that’s the group that’s responsible for controlling how the website looks. And the handoffs that happened between designer and developer have changed over the years.

But in the 2010s, there’s just an incredible splintering of the amount of detailed knowledge necessary to make websites look good across all these different devices was so large it was just unreasonable to think that you can hire one human being to know how to even implement a good design across all of these devices.

Who also knows how to, like, configure Advanced Custom Fields and WordPress. That’s not a terribly reasonable expectation, to think you can find one person who is excellent at both of those things. Some of those people do exist in the world, but for many team leaders putting together teams, they’re realizing, we’re going to be better off if we say like, Steve, you’re going to be the backend expert, and Brian, you’re going to be the front end expert. And, even though Brian has a whole lot of that backend expertise, for many teams, they just decided to make a hard divide in the people.

And then subsequently, or the order was sometimes flipped, a hard divide in the technology. So for, you know, a lot of websites built in this era, there is a very hard divide between the content management system is over here, be it WordPress or Drupal or a natively headless system like Contentful or Sanity. That’s going to be managed by one group, and then this group of front end specialists will handle the front end presentation.

That’s a hard cut to make. A question I’ve been asking for the last decade or so is, if we’re going to cut off WordPress’s head or Drupal’s head, where is the neck? That is an answer that is constantly moving. The next era, after single page applications, is static site generation. As people saw the, you know, that downside of single page applications, then it’s, oh, well what if we, what if we get some of the benefits of that old way of doing it where it was just flat files? Can we have flat files again, Brian.

[00:28:06] Nathan Wrigley: Full circle.

[00:28:07] Brian Perry: Exactly. That introduces a whole new set of challenges and trade offs. You know, it certainly does, things being completely static does provide a build asset that is immutable, and it’s easy to roll back. It’s something that can be cached on a CDN. But also it really changes, kind of going back to again, the editing experience. It really drastically changes that experience where someone who was used to editing a page in WordPress and clicking publish and then being able to see the page.

Now you have a workflow where you make a change in your CMS or whatever the source of the data is, and then a build has to run to be able to have the end website updated. And how do you preview what that looks like before the build runs? Do you need a separate environment? That trade off definitely brings a lot of additional complexity potentially to the content editing experience now.

[00:29:07] Nathan Wrigley: Yeah, I think it’s potentially very frustrating as well because although the technological benefits and probably things like SEO and all of those things. There probably are great benefits there. If you’re the content editor, there’s probably only annoyance that when you click publish nothing happens.

We’ve got to wait for some, like you say, some build process to carry on. You’re adding in a great deal of incredible technological innovation, which speed things up and pushes things to different parts of the world, and I’m sure it’s something we can get into. But also from the content editing point of view, we’ve had this evolution toward being able to edit everything right away, and click publish and seeing it, to then suddenly yanking that carpet out from underneath them, which is yeah, kind of frustrating I guess.

[00:29:55] Steve Persch: I called this the cliff of complexity. If you search on YouTube for that phrase, you can probably find a presentation that I did at Gatsby Conf. So Gatsby, as a front end framework, really became popular as that static site generator pattern was on the ascendance, because there are so many technological benefits to be had, but when you add in a handful of possibly extra requirements. Requirements like, well, the content editors really like to be able to press publish and see it immediately. That shoots you up this cliff where making that work in an architecture that is fundamentally static, is really cutting against the grain.

Like it can be made to work, but is massively complex. And we think for a lot of teams like that complexity is just now worth it. The fundamental mode that WordPress has done for 20 years of like, you press publish and then you see it immediately. That is something that should not be compromised on for most teams.

[00:30:56] Nathan Wrigley: We’re used to a trajectory where technology just gets better in every respect. So, not only does it get quicker, but the, you know, the UI is easier to use and there’s a complete expectation that if I could publish it yesterday, and click publish and it was published right away and I could examine and look for errors that I’d made.

Well, we’re a year on from that. Why have you taken that capability away from me? We’re going backwards? Well, we’re kind of going sideways. We’re not going back because we’re just changing things. I think that would be a bitter pill to swallow. Hard to understand if you’re not technical.

[00:31:30] Steve Persch: Yeah, absolutely. And I think that’s, that backwards moving or that sideways moving does happen in other places. That’s not something I think that’s unique to web development. I remember the first time I got a car that relied heavily on a touchscreen. I was like, no, I want a knob to turn up the volume on the radio. This is so much worse. But somebody thought, no touchscreens, that’s the future. No. A lot of cars are now backswinging. There’s some parts that we do need physical buttons and dials for. That is better.

[00:32:01] Brian Perry: I was going to say, it’s funny that you bring up the car example because, my car actually has both, which is somewhat infuriating. There is a touchscreen that could do everything. And then on the console, all the knobs and buttons, they can do the exact same things. I feel like the JavaScript frameworks in trying to address the shift aggressively in the direction of static sites has had a period of time where it was the equivalent of my car that had both.

So things started shifting back over to server side rendering. But a lot of the frameworks had, and still have, concepts of both at one time. So there are ways that you can say, I want to either build things statically by default, and after some period of time they’re invalidated and re rendered on the server. Or say that it’s this subset of pages that are pre-rendered statically. Maybe it’s my homepage, and my 100 most popular pages.

And then other things are handled server side. That also does increase the complexity now. You have to know what things are static, what things are not. It’s kind of two different approaches. But yeah, it does feel a lot like my car that has essentially two completely redundant ways to interface with it.

[00:33:19] Nathan Wrigley: I’m waiting for somebody to invent the car which has levers in it. So that you’ve got screens, dials, and levers. Then we’ll, we’ll truly have the car from across the entire century. So is that where we’re at now then? If we chart our history we spoke about HTML files, and then PHP coming along and then flattening things. Is that this history lesson ends, or is there more to say?

[00:33:42] Steve Persch: The way I think about it, a phrase I often like to repeat to myself that came from a customer of ours, is that Pantheon needs to aim for state of the art, not bleeding edge. We see the state of the art for many web teams right now is one where you use a totally stable content management system like WordPress or Dupal for the content management systems.

And because so many front end developers simply expect to be working in JavaScript centric tools for teams in that, in that pool. Yes, you should have the front end then controlled through JavaScript centric tools. But do so with server side rendering because the content editors expect to press publish and then immediately see the change. And that works well with server side rendering.

So that’s, that’s a mode that we support in our front end sites product, the front end sites product does also support that static mode. Which is beneficial for a subset of teams out there. Like Pantheon’s own documentation site has been a totally static site for nearly a decade. I think as long as we’ve had a standalone docs site, it’s been static. And that works for that team where everything is all just in a Git repo. An edit to code can happen at the same time as an edit to the content markdown files. That works for that mode.

But we see that, you know, the state of the art for some web teams, as that mix of a contact management system, and a server side rendered Node.js framework. I should also say, because we’re on a WordPress centric podcast here, if you are totally comfortable with WordPress, as is, you don’t need to jump on a new React framework or a new JavaScript framework, just because there are a lot of people on Twitter saying it’s great. If you can do your job without taking on the extra complexity, stick with what works.

[00:35:28] Nathan Wrigley: Yeah, it’s a really good point. You mentioned there, now, I can’t remember the exact phrasing that you used, but you made a differentiation between bleeding edge and something else. Is that an approach that you take? Do you keep a watchful eye on what is happening at the extremes of technology.

[00:35:44] Steve Persch: Oh absolutely, yes.

[00:35:46] Nathan Wrigley: PhD thesis which are describing what the future might look like. But holding back just a little bit until it’s embedded and we figured out what all of this stuff is. That’s the approach?

[00:35:56] Steve Persch: Absolutely. So it is not a coincidence that Pantheon as a company started a decade after Drupal came into being. It was starting as a Drupal centric company, and then adding WordPress a few years later. That’s not a coincidence. There needed to be a decade or so of figuring out, how do we make websites like this before Pantheon or any company like Pantheon could do what we did. Which is put guardrails around what our founders considered to be a best practice mode of developing and maintaining and improving a lamp stack site.

Trying to impose those guardrails the same year that a system like WordPress or Drupal comes out, that wouldn’t make sense. Similarly, we didn’t really enter this front end framework ecosystem until about a decade in. I think almost exactly a decade after React, was released publicly is when we entered this space fully.

We’ve been keeping an eye on it for a very long time. I’ve been at Pantheon for seven years and that was one of my very first questions, my first week, like, when are we going to get into the Node.js space? And the answer then was not yet. And then for a while, it was soon. And then the answer was like, okay, now.

And now we can see, okay, the edge and one of the reasons I like to use that term bleeding edge is because that’s also the term for where the bleeding edge is now. The edge, as a synonym for the content delivery network. So companies like Cloudflare or Fastly that cache your website all over the world, have been adding more and more advanced capabilities beyond the simple caching that makes the website faster. That is very clearly where the bleeding edge or the cutting edge is now. We have a CDN baked in. We have ways of exploring that. However, put it all on the edge is not an acceptable answer yet for the broad plurality of professional web teams.

[00:37:50] Nathan Wrigley: Why is that? What’s the thing which makes that untenable?

[00:37:53] Steve Persch: The very short answer is because your database is still in one place. Even though the cloud abstracts so much like. There is a MySQL database or an abstraction thereof that lives physically in one place. Because we run on Google Cloud, that place for most sites on Pantheon is in Council Bluffs, Iowa.

For a WordPress site that you know, may be making in some cases hundreds of MySQL queries to generate an HTML page, hopefully fewer than, than a few hundred, but in many cases, hundreds of queries. It’s best if the PHP process that’s making those queries is right next to, physically right next to that database.

There are new companies popping up spreading your database all over the world at the edge. Okay, that sounds cool, but before, before we take some of the biggest websites in the world and say, oh yeah, your database will be everywhere. We need to see how that plays out with those who, who want to jump on the edge earlier. Because for the sites we serve and cater to they need to be planning in very long terms.

We’re highly adopted in the edu space, and I, I’ve put together timelines on yardsticks to represent like the multi hundred year history of these universities that we’re working with. And asking like, on a multi a hundred year scale or a scale of decades, it doesn’t matter that much if you switch to the new thing, whatever the new thing is, this semester or next semester, or this year or next year? Let’s wait till we know that that next thing is solid before we jump on it.

[00:39:23] Brian Perry: As the JavaScript guy, I got to say I want it now. But, aside from that, one thing that’s interesting from the front end perspective as well, thinking about running things on the edge. One of the challenges there is that right now, all of the different solutions for edge functions tend to use different variations of JavaScript runtime. So there’s really no consistency there. And I think that’s another thing that’s going to have to change before that gets real wide adoption, when there can be one consistent JavaScript runtime that is typically used for that solution.

[00:39:54] Nathan Wrigley: You mentioned Steve, but Brian maybe can answer this as well, I don’t know. You mentioned that there are people who are endeavoring to break up the database and put it in all sorts of different parts of the world and what have you. So that’s one innovation which people are trying to achieve. I’m just curious about what the next 10 years will look like. What kind of fun, interesting projects have you guys been keeping your eye on, which the listeners may be interested in? Just to give some insight into what hosting a WordPress website might look like Well, in 2025, 2026, whatever it may be.

[00:40:29] Brian Perry: My kind of, it’s partially my hope, but also where I’d like to think that things are going. With all of the constant changes in the JavaScript framework landscape, I think that more and more of the things that people like about that sort of developer experience is going to find its way just more generally into the platform and into browser standards.

Again, like looking back in the rear view, jQuery is a good example of that, in that jQuery brought so many wonderful niceties for how you can interact with the DOM. And then over time, most of the things that jQuery can do are just in JavaScript now. So they’re part of the platform.

So my hope is that the things that people like about React and Vue and et cetera, start to find their way into the general platform. Web components are one potential technology that might help there. A component based approach that can be used regardless of the framework.

My hope is that in the next 10 years, a lot of the things that people turn to React or Vue or different frameworks for, are just a part of the platform, rather than having to find your cool JavaScript framework that was released three months ago,

[00:41:47] Nathan Wrigley: Yeah. Nice. Thank you, Brian. Steve, anything to add to that?

[00:41:51] Steve Persch: I’ll give a quick tech answer, then a longer, uh, philosophical sort of answer. So the quick tech answer is web assembly. I’ll be quick because I can’t speak to many of the details of web assembly, maybe Brian can? I see it as a layer that can abstract away many of the differences between the different computer languages that we’re all writing in. PHP, JavaScript, TypeScript, Rust. If web assembly is a common target that can be used to leverage software. You write in these different modes. Run it in the same place, be it at the edge, or I saw a demo recently that I think involved web assembly getting WordPress to fully run in your browser, like the WordPress running in web assembly in your browser. Okay, that, that looks cool.

The thing I’m, I’m probably most excited about right now for where the overall web zeitgeist is going is, is that the web development ecosystem seems to be coming back to what WordPress has been saying for a long time, of decisions, not options as that philosophical pillar for the WordPress community.

I find it very reassuring that these front end framework projects that for a decade or so, provided so many options and put so many decisions on the plate of individual web teams and said like, you figure out whether or not you want Redux or this other thing to pair with your React project, and good luck sorting out the hundreds or thousands of NPM dependencies that get installed.

The frameworks that seem to be, that just are ascendant, right now, are the ones that are consolidating a lot of those options. Turning them into decisions that are made at the framework level, be it Next.js or Astro or Remix. The leaders of those projects seem to understand that there’s a desire in the community for, for those framework maintainers as experts to make a good quality decision that works for the broad majority of users of those frameworks. Be it Next or Astro or anything else. The users of Next.js are comfortable with an increasing number of decisions being first made in a centralized framework. WordPress has been doing that again for 20 years. Again, it’s fashionable.

[00:44:11] Nathan Wrigley: Yeah, history I think in many respects is fairly cyclical. What goes around does seem to come around. Yeah, good observation. I’m curious at this point, we’ve reached the 50 minute mark, and I want to wrap it up. I know you’ve got things to do with your day. But is there anything that you had wished that we had talked about that we failed to?

[00:44:31] Steve Persch: Brian, do you want to touch on Decoupled Kit?

[00:44:34] Brian Perry: Yeah, I’d love to talk about that a little bit. The Decoupled Kit project is essentially what we’re thinking of as a kit, is essentially a backend starter project and a front end starter kit that are intended to work together as close to out of the box with as little configuration as possible. To try to simplify the process of setting up the headless or decoupled architecture sites.

And also provide some common examples of types of integrations and common problems that need to be solved there. And the thing that I think is most interesting about some of what we’re doing there. Again, thinking about this being an open source project sponsored by Pantheon, is we’re trying to solve some of these problems in cases where it makes sense in a framework agnostic way.

So, obviously starter projects for both Drupal and WordPress. And then within that we have a starter kit, we have multiple starter kits that are based on React. So we have a starter kit for Gatsby and WordPress, and a starter kit for Next.js and WordPress. So we’re trying to find cases where there are things that we can abstract out, which are just essentially like general utilities for sourcing data from WordPress. And not things that are really strictly tied to any one framework.

So that if there is, you know, another framework in the future that we need to support, or gains popularity, it’s easy to make adjustments there and adapt to that. And I think in the headless CMS community, both in the Drupal world and the WordPress world. I think there’s a lot of opportunity for tools that are a little bit more framework agnostic, that can still serve popular projects like Next.js. But hopefully are things that the community can use as the JavaScript world evolves.

I’ll just also throw out there that, would love to, as we continue to build things, any feedback on the project. The main repo is decoupled dash kit dash js, under the Pantheon Systems GitHub. Would love to hear what people run into, any features that they’d love to see us support in the future. Any feedback is welcome.

[00:46:45] Nathan Wrigley: I will make sure to link to all of the bits and pieces that we’ve talked about in the show notes. So if you are listening to this and you want to follow up on what the guys have been mentioning, then head over to wptavern.com, search for the episode, and all of the links will be in the show notes. Just before I let you go and get on with your busy days. If somebody wants to reach out to you personally and connect, what are the best ways, what are the methods that you are willing to share publicly? Let’s go with Brian first.

[00:47:16] Brian Perry: Sure. Yeah, I’m in a number of CMS and Pantheon community Slacks, usually as Brian Perry. That, that’s one decent way to get at me. And then also I am still on Twitter. That is my main connection to the web development social media world, currently. Bri Comedy, b r i comedy on Twitter.

[00:47:38] Nathan Wrigley: Brian, thank you very much. And Steve.

[00:47:40] Steve Persch: I am spending less time on Twitter these days, although I’m still there as at stevector. And LinkedIn is the social network that I’m opening most often these days, and I’m easy to find just by searching for Steve Persch.

[00:47:55] Nathan Wrigley: Thank you very much. Brian Perry and Steve Persch really appreciate you coming onto the podcast today. Thank you very much indeed.

[00:48:02] Steve Persch: Thank you, Nathan.

[00:48:03] Brian Perry: Thank you.