Category: React

  • What it takes just to get the product out the door

    It’s horrifying to think about the number of times I’ve thought (and said out loud) that I was within three weeks of having the first sales of PeakZebra.

    It’s taken forever, literally forever, and there are reasons for this, some of them good, some of them stemming from deep-seated psychological shortcomings. My therapist long ago came to view the rollout as emblematic of my reluctance to fully commit and dig in to bring a project to completion. He’s not wrong.

    But there were other factors, including some classic entrepreneur mistakes that I spotted pretty early but thought I could dance around without paying the full price.

    The opportunity

    Way back long ago, I was doing some SEO consulting for tech startups and was very much aware of the coming deadline after which Google would start using its new Pagespeed metrics (that’s how long ago we’re talking).

    My thinking at the time was that WordPress would, in many cases, wind up with really poor scores. And I thought it would matter a whole lot more than it has turned out to.

    So I had a solution in mind, namely building static sites using Gatsby and React. I’d make boatloads of money migrating sites from WordPress to Gatsby.

    Google foo

    While I was waiting around for this to happen (and you may recall that Google delayed the rollout of the new metrics more than once), I was looking into WordPress and the still fairly-new block editor and block-based, full-site editing.

    As it became increasingly clear that most WordPress sites would be just fine in the new metrics era, it seemed to me that there was a huge opportunity lurking in blocks. The WordPress world needed blocks, all sorts of blocks. There were already a couple of companies (Kadence, for one) rolling out sets of basic blocks that offered considerably greater design control than the built-in “core” blocks.

    What interested me in particular about blocks was that they were built in a way that made it easy to run code (and even React code) on the front end. They were a clean way to compartmentalize functions in separate blocks. There were capable of doing a whole lot more than just inserting text and images.

    In short order, I had a fairly full (and laughably large) vision of what I needed to build. And I thought I could build it pretty fast. Maybe three months, I thought.

    Lots of things happened in the ensuing couple of years. Lots of development, lots of interruptions, lots of changes in the WordPress world. I’m going to skip those bits for now.

    It changes you

    Getting back to my therapist, what I hadn’t really reckoned with was the amount that I needed to change as a person to stop being a guy coding a big plugin to a guy launching a business. You have a big idea, you’ve spent a ludicrous amount of time and effort bringing it into existence, but putting it out in front of the world and asking for sales is an entirely different proposition. It requires a person that I, until quite recently, just plain wasn’t.

    It wasn’t like flipping a switch. Different views on different sorts of things changed over time. There was a time when I was embarrassed to tell people who asked what I was up to that I was launching a startup. But I got used to that, even embraced it.

    Then I needed to get clarity about how I talked about the product, exactly who it was targeted toward, and so on. You simply can’t go off in twenty directions at once. You have to choose your direct, take the risk in hand, and create the conditions to either succeed or to definitively know that what you had in mind won’t work.

    Embrace the possibility of success

    Strangely, you have to be fully prepared for the possibility that you just might, weirdly enough, succeed. And then you’ll be at the real starting line. You’ll have a company to build.

    I’m not, I should say, a malleable kid still being tossed to and fro by the world. I’m on the far side of a couple of full careers. But I had to become a different person to become someone who launches a startup. I don’t mean that I had to become adept at sales, though being ready to sell is a part of it, to be sure. I mean a different person, a better person, a person ready to live with bigger energy.

    So finally it’s time to launch. You can buy our magic toolkit and build WordPress sites that do things that WordPress sites haven’t been able to do. It’s time to build the coolest things you can think of.

    Now it’s not about solving the problem of how to pull a codebase out of thin air, but rather about the problem of how to get it in front of potential buyers and then close the deal with them. My therapist (who is not, just for the record, ChatGPT) is encouraging me to view it as just another complex problem to solve. Once again, he’s annoyingly on point.

    You, dear reader, can help me with this. Even without becoming a customer (though, couldn’t hurt, right?). You can share your ideas, your confusion, what you like and don’t like about PeakZebra marketing, and so on. I hope you’ll do that.

    Did I mention that prices will never again be as low as they are during rollout?

  • Headless WordPress and why it matters

    You know there’s headless WordPress, but may not be clear on how you’d make it happen. Or, more importantly, why you’d make it happen.

    What is headless WordPress?

    Let’s start with a quick rundown of what makes a WordPress site headless, why the naming in this case is exactly backwards, and just generally get ourselves on the same page.

    The conventional headful approach

    Normal WordPress is a world in which the action happens on the server. A website visitor requests a page from the server and the server assembles the page components (header, body, footer) from the database and any relevant templates. This is sent to the browser, any browser at all. And if something happens down there on the browser, it will result in a new page being requested from the server.

    Where this basic operation is perhaps most clearly visible is when the site provides some kind of data application. Maybe it’s a CRM application, so you might request a list of clients in the system. You get a display of the first 25 of them from the server, say. If you want to see the next page of clients, a new page will be requested from the server. If you want to see a particular client, a new page will be requested to display that client’s information. If you change the information for that client and want to save it, you’ll submit a form to the server and a new page will be delivered to show the update.

    Meanwhile, in the rest of the universe

    For most of the rest of the web, this isn’t typically how an application works, however. If you start with an application that shows a list of client records, then when you want to see the next page of them, a request will be sent to the server to retrieve only the data for the clients that need to be shown. The page with the client list won’t be replaced; rather, the new set of clients will be displayed on the existing page where the previous clients were listed.

    It’s possible that you can edit any of the client fields you can see on each row of the listing. Let’s say you do this and press a save icon at the end of the row you’ve changed. Again, this doesn’t result in a new page being requested. Instead, the listing continues to show the change you made and the change is sent as an update request to the server.

    The server, in other words, is just supplying data at this point, not pages (though, in our scenario, it probably supplied the initial listing page).

    Decouple this

    There are two things we should notice about this scenario. First, there’s got to be some kind of back end that answers requests for data and updates, even if it’s not supplying the pages. Second, the pages still have to come from somewhere. But the pages and the data don’t really have to come from the same place, and thus we can say that the presentation and the data have been decoupled.

    When you decouple the head of a thing, well, it becomes headless. So the baseline idea of headless WordPress is that there’s a WordPress server running, but it’s not supplying the pages that the website visitor is seeing.

    So where are the pages coming from? That depends, but most scenarios out there on the web right now fall into the basic pattern of using React (or some React framework that extends React) to create pages that can be retrieved from web servers as plain HTML and JavaScript files. These pages aren’t assembled or calculated on the server end, they are simply sent to the client as they stand. You’ll hear these scenarios referred to as static sites. That’s because the server doesn’t muck around with them–they can be plenty active once they are displayed in a browser window.

    One question that may already have popped into your mind is: what is React? And that’s an excellent question, but not one that we’re going to answer in any detail here. Suffice it to say, it’s a pre-built set of capabilities implemented in JavaScript, where the capabilities mostly have to do with user interactions.

    The key thing is that JavaScript and React are capable of asking the server (or more than one server) for data that it needs to display. The server that sends the data down to the browser in the headless WordPress scenario is, you guessed it, a WordPress server.

    Headless

    There are plenty of headless scenarios where the server isn’t a WordPress server and there are even scenarios where there arguably isn’t a server in the traditional sense.

    But we’re talking WordPress here. In that scenario, there are two primary ways that WordPress might interact with whatever’s going on down there at the browser window. It may, in the older and more widely adopted approach, use a REST API to make requests for data (or requests to place or update data on the server). Making a REST call is based on requesting a particular URL and it either places any changeable data at the end of the URL (as parameters) or it arranges them in the same way you might arrange data when posting a form to a web server.

    The other approach out there these days involves using a Graphql interface. This is more like opening a window directly into a database and making queries. The details of this don’t much matter for this discussion, the point is that it’s possible to install a plugin that creates a Graphql access point for a WordPress site.

    Wait, but why?

    Why would you take this headless approach, though?

    The obvious first answer is that it enables you to have a different language and framework running on the client side of things. If you want a React application that serves up a lot of server-side content, using WordPress as your CMS might very well make sense.

    Additionally, though, it gives you the capability to render and rerender a page in sections, so that you aren’t necessarily requesting a whole new page from the server every time anything happens.

    Now, as it happens, you can pull off this same trick using the new Interactivity API in WordPress, because it makes the front end capable of doing various things on its own. It let’s you build a “headless-seeming” user experience completely within a WordPress context.

    It’s not clear yet how well the Interactivity API will fare, as it’s still relatively early days, but it’s an interesting option for dynamic front ends (plus it’s in use within WordPress core, so it’s not likely to go anywhere anytime soon).

    WordPress makes a pretty solid CMS, particularly where the content is of the human-readable sort.