 Good afternoon. Is this on? Yes. My name is Lee Barker. I'm a senior project manager at HumanMade. I'm Mike Sealander. I'm a senior developer at HumanMade. And over the next 30 minutes or so, Mike and I are going to be sharing with you our experiences collaborating with TechCrunch to deliver a semi-decoupled WordPress application using a React front-end. Now there are a couple of high-level points we're going to be touching on during this talk. I'm going to just quickly review them before we dive in. First off, we're going to be taking a look at the partners who are involved in bringing this product to life, followed by the business opportunity and motivations that drove this particular initiative. With that, we're going to then be looking at our technical approach to the project and the features that allowed us to deliver for TechCrunch. Finally, we're going to be addressing some of the technical challenges and solutions that we're able to deliver as part of this project and that we have now open source to bring back to the wider community. So without further ado, TechCrunch first approached HumanMade with an ambitious redesign concept in 2016, led by their head of product, Nicole Roegi. Now, I'm sure most of you here are familiar with TechCrunch. They are a leading publisher in the technology and startup space based in San Francisco. Now, not only are they recording on this space, but they're an important influencer in it as well. Through their suite of events, the flagship one being Disrupt, they create opportunities for entrepreneurs and startups to connect, network, and identify funding opportunities. TechCrunch is also a long-standing WordPress user. They've been on WordPress for about 10 years now. In fact, they are hosted on WordPress VIP, which is a great hosting partner for organizations like TechCrunch that need to use WordPress at scale. Now, TechCrunch has really enjoyed using WordPress as their CMS. In fact, they feel it's a foundational element of their product and it supports their editorial workflow. However, being in the startup space, for their redesign, they wanted to do something that was going to push the envelope and really embrace that ethos of innovation that's such a core part of their organizational philosophy. So with that in mind, TechCrunch came to us specifically with the idea of approaching this redesign as a decoupled WordPress application. It has a mind of its own. So at the beginning of any project, we want to work with our clients to make sure that we have a really deep understanding of the context and motivations behind the business decisions that are driving their tech initiatives. So with that in mind, I was brought on early as a senior PM to work with Nicole to identify what those were for TechCrunch and how our approach would be most appropriate for that. In Nicole's own words, they wanted this redesign to be ambitious, as we said. So they did come to us with, already in mind, the idea of doing a decoupled WordPress React application. This would allow them to achieve a couple of things, right? The first is that it would allow them to continue to use WordPress as their CMS. And as I mentioned, this is the cornerstone of their product, their editorial workflow, and all of the other business elements that go along with that, advertising, marketing, et cetera. However, by decoupling their front end, they would have the flexibility not only to deliver something that was cutting edge and exciting, but also something that would give them a tremendous amount of flexibility in a changing market and in the pursuit of new streams of revenue. Improved user engagement is an important part of the publisher's desires for a redesign. It was just as true of TechCrunch. They wanted a design that would leverage a decoupled approach to let their end-users feel that we were delivering them a single-page application. So TechCrunch worked with a design agency called Work&Co to develop a fluid and interesting interactive design. The hope was that this design coupled with a decoupled approach would allow TechCrunch to embrace that single-app experience and to deliver a continuous flow of content to their end-users. This immersive experience would not only encourage end-users to stay on the site longer, but to discover new content and share content as well. While end-users may have the most visible side of our redesign, editorial and administrative users are just as important to consideration for us as well. TechCrunch's product caters to multiple teams, editorial, marketing, advertising, events, and we needed to ensure that the CMS, as part of this redesign, would provide increased efficiency and improved transparency for these teams collaborating, often in a very distributed way. And finally, collaborative development was, always from the beginning, a very important piece of this project. Working on such an innovative, new approach, it was important that we worked with TechCrunch to provide a level of support throughout the development process to help TechCrunch's team be prepared to continue to innovate and iterate on the product following launch. So not only did human-made lead the build, but we provided architectural consultation, guidance on WordPress best practice, and some react orientation and training. So with the business goals in mind, it was time for our team to really dig into the technical approach that we would take, and Mike's going to tell you a little bit about that. Right. So, as we mentioned, the goals of this site was to create something a lot more interactive and a lot more engaging than your typical WordPress kind of monolithic theme. We wanted something very next generation, something where a user would go to the site and feel like they're on an application, if they're on their desktop or any particular device, where they could flow through content really smoothly and have a lot of extra interactions on top of your typical theme. So we knew from the get-go that we weren't just going to go monolithic. We weren't going to go server-sided templates for everything. It was going to be a lot different architecture. So for our site, for TechCrunch's site, we decided to go with React built on top of WordPress. Now, as Libby mentioned, TechCrunch has been on WordPress for almost 10 years now. So this is still the bedrock of the application. There's still all of the administrative side on here. There's a little bit of templates, which we'll talk about in a little bit, and it still serves almost the entire website. And then we use React on top of that to create more interactions and to handle most of the front-end that you would see as a user on the site to give you a lot more engagement on this. Now, Libby's mentioned decoupled a lot of times so far. We're going to say this a lot of times throughout this talk. For this project, we chose to go with a slightly different architecture than you typically would when you're building React or View or Angular on top of WordPress. Because typically what you would do is go with a fully decoupled or headless application where WordPress and the administrative side is stored on its own stack, you know, lamp or some equivalent, and then React or View or whatever is stored on its own stack, and they only ever communicate through the REST API. And this has a lot of benefits, but we wanted to go with something slightly different to give us some more advantages and simplify the architecture of this website. So we built what we like to call a semi-decoupled React application. And the semi-part of this is going back to where I said just a minute ago that WordPress still serves a little bit of templating. So it still handles a little bit of the visual display, which I'll show you guys in a second. And it also still serves the assets for the JavaScript bundle that provides React and the styles and everything on there. So we only have to have one stack to handle all of this on top of WordPress VIP. So it keeps this architecture really simple. And it also gives us a benefit that we can serve a small view to a user really well-cached from the server almost instantaneously. So let's look at what this actually looks like in real life if you were to go to the TechCrunch website. So this is what you would see if you visited TechCrunch.com without and a JavaScript turned on, or if you have a really, really, really slow connection. And this is just a simple river. A simple outline of posts. You can navigate through this. You still get images. You still get some content. Google can scrape this without any issues whatsoever. But it's also very simple. This isn't a whole website. This isn't all the interactions you would expect out of TechCrunch.com. So let's see what this looks like after we actually load up the React application. And that was all served by PHP. So now what has happened here is PHP has loaded those initial templates. All the while React is sitting in the background and it is loading up its views and all of its routing and everything on top of this. So as a user, we instantly see some content that we just saw. React kicks in and it feels like it progressively loads in some of these elements here. So we have a menu. We have an editorial controlled feature island on top. We have some advertisements and everything on top of this. But you still see this post right here is the exact same one that you saw on that PHP side. So as a user, we get all this extra elements loaded in on top of that really instantaneous return. And from this point on, React serves as a decoupled application. Because from this point on, it handles all of its routing, all the interactions, and it only talks to WordPress through the REST API. So if we go back to the basics of the architecture, we have WordPress, and WordPress serves some data up to React. We call this hydrating. So as soon as React loads and it kicks in, it already has the data it needs to serve up what it needs to. And then after React is fully loaded in, it goes back to the WordPress REST API for all the data that it has and everything until you open up that site in a new tab or a new window, everything from that point on is all served in JavaScript. So now Libby is going to talk about some of the features that we're able to build using this semi-decoupled architecture. So there were a number of features, obviously, that we delivered for TechCrunch. They have a very dynamic team. But we're just going to talk about a few of them today. The first one that I want to touch on is the river experience. Now, we mentioned at the beginning that TechCrunch wanted to deliver a site that would feel like a single-page application. And the river experience was the underpinning of this across the site. We looked at it a little bit earlier. We might show this the architecture. But I'll pull it up again here. The little video you can see. There we go. Do you mind if I please? Yeah. Okay. The single article. Do you want me to go back? Absolutely. Okay. Okay. So as an user arriving on TechCrunch.com, this is the homepage that we would see. The continuous kind of river of content. It was called a river because the goal was for the end user to feel as though they were being swept through content and encouraged to discover new content as they go. You'll notice that I'm clicking into some topics pages here. And that experience is consistent regardless of whether you're on a category page or a topic page. It feels like you've never actually left the page. The content has reloaded. So you're getting that single-page application. All right. This presented a couple of challenges that we wanted to resolve. The first was with regard to wayfinding. As an end user, when you're in a river of content, that's very exciting. But how do you effectively navigate through? So we developed a couple of wayfinding tools for the end user. Here you'll see the progress indicator at the top of the article. If you scroll through at the end, you get a little congratulatory check mark before the article then snaps shut. Now, I want to pause on the snapshot behavior for a moment. It is very subtle, but it's an important kind of component of that river experience. You'll notice that when the article closes, you're actually dropped right back where you were in the river of content. The article you've just completed is great out, kind of gently encouraging you on to consume the next piece. This also provided sort of a platform for TechCrunch's editorial team to reconsider some of the features that they have been using previously, or in this case, developing stories, which was a new feature as part of the redesign. TechCrunch's editorial team, as we mentioned, is distributed, but they found they were often reporting on similar stories at different times as new information came to light, and they wanted a way to group those to be more compelling, tell a more compelling narrative. So they used this river experience to do just that. They're developing stories, which served sort of an umbrella story for a larger network of content, editors working on disparate pieces of content. And you'll see on the homepage in this example, it's very striking. You see the urgency through the timestamp and into it. You'll notice that same kind of single-page application experience, that river of content, is replicated in this specific feature. As you scroll through, you're led onto the content, all related to the same story. You have the wayfinding tools, but it was also important for TechCrunch's editors that these stories remained autonomous. They wanted end users to be able to share content to drive other users to the site. So you'll notice when I clicked in here, I was taken directly to that story that has its own shareable product. For any publisher interested in significant redesign, one of the most important questions is always how you are going to be able to better understand your end users. And this comes into play when we consider ads and analytics. Analytics are sort of the underpinning of many advertising relationships and editorial strategic decisions. So it was really important that we get this right for TechCrunch. However, we encountered a couple of challenges as a result of our approach. The first is that React presented some constraints that wouldn't allow us to deliver ads in a way that we would with the traditional monolithic state. So that was our first consideration. The second consideration is that we were requested to use the proprietary ads system of Oath, TechCrunch's parent company. So we developed a custom library to resolve this quandary and to speak more to that and ask Mike to come back up. Right. So the basics of this is that React introduces a lot of new paradigms that traditional third-party providers don't really anticipate when they're writing their scripts or expecting you to build out your website. So most ads and analytics providers that we've encountered in the past expect a very traditional, very monolithic model of web pages to load. And it looks something like this. You have a server, serve up your content. You wait for the window to load or the DOM to be fully done. You wait for some very predictable event to happen in JavaScript, which means that all your contacts and all your data is available right then. And then you serve up your ads in a particular slot that's always going to exist in your DOM. And you send off some analytics off to the provider because you're definitely going to have that data. Go to another page. You reload. Same thing happens again and again and again. And this is very stable. This is very static. Like this loading flow and loading order is going to happen on almost every single page load when you go to a new tab or new browser or you reload something. But when you're dealing with a single-page application, the flow is a lot more complicated and you're consistently churning through elements and you're churning through data. And you're changing up the shape of what everything looks like on the page as you go through. So you get some new API data. You put that in your store. You serve up components. And it just keeps churning and churning and churning. And so the events that would normally exist for an ad provider script or an analytics provider script to trigger at the correct times no longer work. Because I mentioned earlier on TechCrunch that we load up that monolithic page, then React kicks in, and until you go to a new tab, React is handling all of this. So DOM document or window being done loaded, any of those events no longer trigger as you navigate between pages and articles and sections. And so we had to find a way to trigger this when we wanted to as opposed to when the ad providers wanted to. So we use a tool called Redux built on top of React, which handles all of our data store and our state management. And Redux provides what's called actions, which are very similar to the WordPress hooks and filters that you're used to, in that you get to run some code when a particular point is done in the application. So as soon as we know that we have the data and we have all the components loaded that we need to, we can then send the data off to the analytics providers, load up some ads in the correct locations and make sure everything runs as smoothly as possible. But the story from this is that you can't always trust what your historical third-party providers give you or how the system has worked so far. You have to anticipate for extra customizations and make sure that everything works as you're constantly blowing out elements on the page. So the last feature that we want to talk to or talk about is the videos on the TechCrunch website. And videos are very important for TechCrunch because they have a lot of content that isn't particularly well-served in just a story or picture format. Like if you're talking about, let's say, DGI, for example, and you want to show how the video, the first-person video, actually works on a drone and get people excited about that startup or talk about their funding opportunities, text just doesn't work. And so they needed a whole section and a whole editorial workflow separate from how the normal content came into the website. So we built them an automatic video-importing functionality that pulls in all the videos from Vitable, which is their third-party provider. And Vitable is a source of truth for videos. WordPress should know about videos, but it shouldn't necessarily own or control the videos. So we pull those in automatically, give the editors a little bit of control, and then we serve them up in a customized front-end view that allows users to constantly churn and scroll through videos much faster than you typically would on a monolithic application. And this is just one example of one of the interfaces that we built for them, but a lot of them revolve around carousels and being able to smoothly transition between videos very quickly without having to blow out and reload providers. That's a little janky. It's not this janky in real life. But we can quickly load a video and using the same Vitable box to display these videos, churn through a video as a user, and we can navigate from one to the next very quickly and never leave that page and never leave that experience, but we still have the same way-finding tools available to us at that load and work for everything else. All right, so as we mentioned, those are just a few of the features that we were able to deliver for TechFunch. And there are a lot of other interesting ones as well. Unfortunately, I just don't have that much time. But if you would like to talk with us further about those, please find us after. Before we conclude, though, we did want to talk about some of the technical challenges and solutions that we were able to deliver. Many of them are now open source that we can share them with you. Should you be interested in pursuing similar types of projects? And Mike's actually going to speak to those as well. So this is kind of like the epilogue to the story of us building this website. These are some tools that we were able to create and abstract out of this, out of some of the challenges of building this site and make them available to you as open source tools and to our other clients as we're moving forward with this. So these are just three of the tools that we built. They're all available on GitHub, all available for you to use. Please come and talk to us about them and more afterwards if you'd like to. You can chat your ear off about any of these and some of the things that we built. So the first challenge that we wanted to talk about and solution we made available to you guys is a disparity between the way that WordPress expects a development environment to work and how React or View or a single page application expects these environments to work. Because WordPress typically expects static resources served from the same location all the time and effectively production ready. You enqueue a resource by telling it where to look for this resource and that has to always exist or WordPress just isn't going to load anything. But React and View are handled and served locally by a program or a compiler called Webpack. And Webpack does a lot of really fancy things like hot reloading and component swapping and it allows you to build a JavaScript application constantly reloading this page without having to go back and forth between a lot of different locations but it's served from its own development server. It's not handled in WordPress, it's not handled in PHP and so you have to have a bridge to talk between these two applications and that's what React WP scripts is. It's built on top of Create React app but it can be very easily extended for any Webpack-based application and it looks to the Webpack bundle to find out what assets to load. It loads them using our own on-queuing function and so all you would have to do is access the library, use our own on-queuing function instead of the WordPress one and you get all the benefits that come from having a local Webpack development build. So you're able to really quickly get started and get running on a single-page application site instead of having to manually create these bridges yourself. And the second challenge that we encountered is a friction between actually writing API endpoints and having to document your API endpoints. And this exists in all of development for sure but within API endpoints it's particularly important because if your endpoint is not documented it doesn't exist for all intents and purposes. If I have to go and try and find out if an endpoint exists because there's no living documentation, no way to find it by default and I have to then find out how it works, the amount of time it's going to take is very exponential even over just looking through a regular code base to find this. And so we needed some way of quickly generating documentation for these endpoints without taking time away from developers actually writing it. And that's what this tool called RestSplain is. It's a WordPress plugin that you include on your site. It automatically scrapes all the schemas that are generated as you're already writing your endpoints, something you have to do to create fully fleshed out WordPress Rest API endpoints. And then it presents a UI that you, your developers, project managers, client, everyone can look at and get a very clear understanding of what this looks like. And this is what this looks like on the human-made website and we haven't done any customization. We just put the plugin on here for this demo and let it do its thing. And this is what the UI, how it works and what it looks like. So you can see on the left you have a full list of all the endpoints available on here. I can click into one of these endpoints, get all the data I need about it, like what data I need to put into it, what I can expect out of it. And then I can also get real-time examples of what the data looks like coming out of there and what an example call to this endpoint would be if I wanted to get more information about it. So it allows this kind of living documentation that's automatically generated and you don't have to pay your developers to write that instead of actually writing the code. And the last kind of challenge and tool I want to talk about is based around providing WordPress Ombeds in a single-page application. So WordPress gives you embeds as this really nice little blob of text in the content. And it works really well in a monolithic application because you load up the content, it's going to trigger any scripts and styles that exist within there, and it's just going to kind of work because then you move on to the next page load, keep moving on to the next page load, like it will constantly reload as you want it to. But in React, React is trying to load those scripts as text as you're putting it into it. And so you need some way to intelligently pull those scripts and styles out particularly with a whitelist because you don't want to just randomly inject JavaScript into your application. Put those into the DOM and load them when they need to. And React Ombed Container is a React container that wraps around your content. It finds any scripts from Ombeds, particularly that you need to inject in the page, puts them where they need to go, and then you can constantly just churn through this content so that users can and expecting those Ombeds to work as they normally would within WordPress. So finally, Libby is going to talk us through some of the resources that we have available to you if you want to find out more. I can hear, and I are here as representatives of what was a larger team, and I want to make sure that we acknowledge everyone that was involved in this project, which was led by Senior Engineer Frank Klein, Senior Engineers Robert O'Rourke, and Catam White were also an integral part of this project as well. We also have some important consultation of our CTO, Joe Hoyle, and our Director of Engineering, Ryan McHugh. If you are interested in learning more about some of the libraries that Mike was just discussing, we do have them linked here, so when our slides are published, you'll be able to access them. We also have some further reading if you want to do a little homework. Who doesn't? A couple of white papers, the REST API white paper is linked here. We also have our sponsor table outside. We also have a white paper specifically about the TechCrunch project, as well as the REST API white paper, and a few others as well, including Gutenberg. If you'd like to catch up with us afterwards, please do. We'd love to talk to you, of course. But if that's not possible, our Twitter handles are here, and we are available there as well. And that is the conclusion of our talk, so thank you. And if you can wait until we get to you with the mic so we can get it on WordPress TV and on our live stream. Good question, and you did say this, but I just wanted to emphasize this. You're saying that you've got this river of articles that are displaying fully in a React-generated presentation, and that you found that you had no problem getting Google to crawl those, and they had decent search ranking. Yeah, they definitely have a decent search ranking. They rely very heavily on both search and social media engagement to drive traffic to their articles, as a lot of journalism organizations do, and they've had no issues since we launched whatsoever. At least that I'm aware of. Thank you. Thank you, that was a great talk. Did you see a need to rep any of the React components or elements like is done in Gutenberg, like WP components, in case you might need to use a different library, or would that even be useful in this context? So you mean like the with API wrapper and being able to swap out containers and that kind of thing? Uh-huh, in case you were to consider View at some point. Maybe that wouldn't be useful in this context, but just curious. No, we didn't really consider that for our use case, because we knew we were going to use React throughout. If we were to use View or something else, we would probably just rebuild that. We didn't build reusable web components. We built very specific React components for this case. Sure, that makes sense. Thanks. Could you elaborate on why that sort of hybrid, headless architecture was decided on over a more fully headless design? So it goes back to the simplicity of the architecture and being able to immediately render some content for users. So we didn't really want to wait for that React bundle to load as a first-time visitor on the website, because it's extremely heavy. It's about 300 kilobytes, and so loading that in and waiting for that to load would be a really bad experience for users. So we just wanted to provide them with something instantaneously, and on the flip side, we could have done something like server-side rendering on top of Node, but it's really not an architecture that we had time to integrate into this, or the availability to do so. So it was more an architectural decision for simplicity's sake and to provide that instantaneous response for users. And using React server was too complicated, was it? Using React server was too complicated? Yeah. Just complicated things, I guess. So you mean something along the lines of V8.js or...? Well, I haven't done too much myself, but I've seen that you can use React and have a Node-based server to actually render. Yeah, that just wasn't really a good use case for us in this particular case. It's a great architecture in a lot of situations, but in this case, it just didn't really work out for us. Your nomenclature is amazing. How did you stop at islands and rivers? That was a client... That was their terminology. That, I believe, was part of their terminology for the site even prior to the redesign. And so it was carried through the redesign with working code, the design agency, and then onto the build as well. And are there any others, like deserts of ad spaces? No, but if you have any good ones, I'll suggest that. Time for a few more. So you talked about using Webpack on your same stack you're running PHP, right? Is that what you were saying? So Webpack handles building the bundle into something that the browsers can actually read. So we don't use Webpack on PHP. Webpack runs on its own server and the ReactWP script basically tells WordPress where to look for that server. It's not running on top of PHP, it's kind of running alongside it. Yeah, I mean, it could be on the same, you know, virtual machine or something, but... Yeah. That's only for your build process, though. You're not using Webpack in production at all, are you? No, we're not. So in production, we're using typical WordPress on-queuing. At that point, we've bundled it into a production-ready script. And I just wanted to ask about your... When you're going against the REST endpoints, you're going against the standard WordPress REST endpoints and you use GraphQL at all? We don't use GraphQL. We go straight to the REST endpoints and we use a lot of embedding requests. That could easily... Well, I won't say that could easily be swapped out for Graph. We could have used Graph, but that came along a little bit long in the project. So we wanted to just use the core REST ones plus some custom endpoints. It provided us all the data that we needed, so... Other questions? I would like to ask about the rendering. So PHP renders HTML, and then React could erase it, yeah? So do I get it correct that you support two code bases, the first one in React and the second just the same in PHP templates? That's correct. So we only do a very, very small amount of that rendering and the templating in PHP, and then everything gets fully blown away and everything resides in React, but we do maintain two visual code bases, but just a very small version of it in the PHP. And so the Google crawler, it takes the templates that go from PHP, yeah? You know, I don't have access to the tooling to see how Google crawler actually renders the page to see it, so it might be grabbing the PHP. I know that the Googlebot will render JavaScript as long as it loads fast enough, but we have enough information on both sides of it that either way, it doesn't really matter which one that it renders because it's the same content. Okay, thank you. It's great to see an innovative use of the REST API. So I saw the sites hosted on WordPress VIP. If theoretically the REST API wasn't in core, would you have been able to build this for your client? So it ended up being, we moved from VIP Classic to VIP Go, which means that we could have included our own plugins. And so theoretically, yes, we could have used REST API as a plugin in this particular instance. On Classic, you wouldn't be able to. However, VIP has its own version of the API, which is just different. So we could have in either situation for sure, but it was a lot easier going on to go, or would have been. Thanks. Other questions? Well, hey everybody, can you give it a round of applause one more time?