A man leaving wordpress, headed toward the nice astro booth.

Goodbye Wordpress

By Jayson Lindsley

I think it’s really important to talk about how good Wordpress has been for a lot of things i have worked on for a few years, and why I am migrating away, and where I am going. This is going to be a long post based on my personal experience working with Wordpress for years, and i recognize it’s not a one size fits all for everyone and every business - but if you’re thinking of moving I think it’s a good time.

Wordpress Is Stuck

When we have projects like Laravel that exist in the open source space it’s hard to sit here and stare at WordPress which has moved at an abyssmally slow space.

While we’re at it - let’s get into this list of what blows my mind - easy wins:

- No first class reusable blocks

- Media Management could have folders

- First class support for Post Types

- No user avatars

- Weird ass queue system (WP-Cron, lol)

- No 2FA

- Filtering pages is horrible

- No folders or any content organization system

For Profit Companies

When the fight between Automattic and WP Engine broke out we really saw some pretty intense fighting that, to me at least, showed the priorities of both companies are to leverage WordPress without contributing enough back to it’s core development and keeping it in this insane feature hold. They both rake in millions while not proportionally contributing to the core project.

It does make sense that companies don’t want to break sites - but we break shit all the time in programming. That’s life! We have breaking changes, major updates, and with that we cope with careful detection and block updates, backport security fixes, and call it a day.

Page Builder Overhead

I think that using Gutenberg + Generatepress is the best route forward for WordPress, maybe even absorbing it into the core, but for most users that simply drag and drop components and don’t customize much Elementor is still incredibly popular.

Content Management Systems, Compared

After having spent enough time with my team looking at content management system such as Sanity, Strapi, Contentful - I just simply do not like them. I personally think that builder.io has the market here, and will likely set the tone moving forward on how to interact with codebases.

Sanity

Sanity is great if you use their canvas feature, but as far as implementing it with Astro, I have to say it’s really not it for me. To me, this platform simply does not bridge the gap fast enough between code and platform for users. We’re talking about GROQ, modeling schemas, slugging through some awkward preview system, and kind of insane pricing.

When we were attempting to talk to an engineer over there, they basically said “you’re not really big enough for us to bring on an engineers time to answer a few questions”.

Additionally, the database is now vendor locked in, API requests cost money, bandwidth costs money.. I don’t really understand how this makes the problem easier compared to a solution like Builder.io

Strapi

Strapi has the same problem as Sanity with declaring the content management system \ data types for these things. I have no doubt it can build a beautiful project from scratch, but a lot of the customization again seems to be a big lift.

And one big thing for me, which is missing here, is a feature like canvas. I don’t want to use some uncooked WYSIWYG editor - it’s actually crazy how poor the writing environments are in these services. If anything, I would assume they would want it to be a more fully fleshed out system similar to Obsidian or other markdown note apps.

Contentful

Contentful sits in a weird spot for me - it’s basically a backend. We still do the work that the other tools do, such as Strapi, but let me pose this question:

If the backend goal is just for hosting blogs, would it be worth the move? No.

Also, it’s expensive.

Builder.io

I’m not going to glaze builder.io too much here - but it seems to be the sweet spot for us. We can have our people work in their products, spit out page updates, and then hit review and invite us to it. We submit a PR, and send it up to production. Cheap, easy, effective.

Astro

I love Astro, I love static rendering. But there are some gaps with the content part that we need to talk about pretty deeply. I’ve tried Editors such as Tina but still did not really jive with it - but it’s MUCH closer to what I am thinking the ideal setup should be.

TinaCMS

I want to like Tina, but she just kinda fucking sucks.

Introducing: Astro Companion

I ended up focusing on making the ideal setup for me, and found a decent balance by having a separate app that pulls the repo and builds it out - I called it Astro companion.

In fact, it’s literally how I wrote this blog post.

A preview of a new notion like editor.

Astro Companion has something special going for it:

  • No manually fucking with collections in awkward web uis
  • A familiar notion like \ kinda gutenberg like editor
  • Simple sidebar, simple uploads
  • All changes live in a staging area, then are shipped into the repo by default
  • Fully SSG - no GraphQL, no hosted database, we’re not married, you own your files
  • Builds right inside of Cloudflare with previews then ships into your repos master branch via Pull Requests

Configuring Collections

All collections and frontmatter live in a single astro-companion.json in the root of the repo - that is it. Here’s mine:

{
  "url": "https://www.jaysonlindsley.dev",
  "collections": {
    "blog": {
      "label": "Blog",
      "content": "src/content/blog",
      "images": "src/assets/images/blog",
      "sidebar": {
        "groupBy": "year",
        "pinDrafts": true,
        "sortBy": "pubDate"
      },
      "fields": {
        "title": {
          "type": "string",
          "label": "Title",
          "required": true
        },
        "description": {
          "type": "string",
          "label": "Description",
          "multiline": true,
          "required": true
        },
        "pubDate": {
          "type": "date",
          "label": "Published",
          "required": true
        },
        "updatedDate": {
          "type": "date",
          "label": "Updated"
        },
        "author": {
          "type": "select",
          "label": "Author",
          "options": ["Jayson Lindsley"],
          "default": "Jayson Lindsley"
        },
        "tags": {
          "type": "array",
          "items": { "type": "string" },
          "label": "Tags"
        },
        "heroImage": {
          "type": "image",
          "label": "Featured image"
        },
        "heroImageAlt": {
          "type": "string",
          "label": "Featured image alt text"
        },
        "ogImage": {
          "type": "string",
          "label": "Custom OG image path"
        },
        "noindex": {
          "type": "boolean",
          "label": "Block search indexing",
          "default": false
        }
      }
    }
  }
}

That’s it. The server and editor handle the rest on this side at the top in a way that people can understand.

Deploying

Straight forward - right? Take this stuff, and make it. Or edit it. Single commit, single PR. You can push multiple commits, too, but it’s just really the idea that we’re not committing each change like you’d see in Tina.

Real Pages When?

Still working on this and how to pull it off - but i do want a way to allow clients to change copy more easily. Again: the focus is on ease of use. Very little overhead, not bloating, no databases, no SSG shit - just easy ass direct editing of stuff we (devs) expose to them to change.

Currently, the site is in early preview with only my clients - but at some point I expect I’ll do general availability for it so others can let their clients make blogs without tons of overhead and CMS nonsense.