Building products: Moving from WordPress to Laravel

Why would a diehard WordPress contributor, organiser and business owner jump ship to a new platform?

In this first post, I’ll look at how I was building with WordPress and some great practices I honed. How I got around the limitations of WP to build  successful lean products.

I’ll also talk about the direction of WordPress, why it isn’t as suited for product development as it was a few years back but why I used to think it was.

In the second post I’ll look at why and how I’m building in Laravel with Vue.js now. I’ll also look at starting from scratch in a new community after being so embedded within the WordPress world for so many years.

As with most of my work it’s very much product focused. So I’ll start with a story about my main client for the last few years whose main focus is Product…

A project that needed MORE from WordPress? Just add MVC?

I’ve always loved product and spent a lot of time building my own side-projects (even a few SaaS sites in WP).

In 2017 I found my dream client. I’ve been enormously lucky to work with and build MindTheProduct.com. I learnt an enormous amount about product and working in agile, inspiring and friendly teams.

MTP are a successful content creator and events company, leading regular ProductTanks in most major cities as well as Conferences in Singapore, San Francisco,  London and more.

They had an ambitious vision to build out an event management platform, schedule builders, membership functionality and more into their online offering. They wanted tight integration with their content already on WordPress. It's a great example of how you can build out on WordPress but I'll also share some of the limitations.

We needed to build bespoke and we needed scale. It wasn’t something we wanted in a custom post type.

So we built within WP but just outside the core. We built out our own application interface that gave us the best of both world.

My good friend, excellent developer and fellow Skiffmate Hazlitt Eastman, came on board the project and we built an open-source MVC counter-part to WordPress.

You can learn more about it here in this early 2018 talk I gave at WordCamp London: Using MVC with WordPress - WordCamp London Talk 1. - Raison

I used this approach for a few other projects with WP over the years as well as building out functionality in more OOP focused plugins. It’s a great way to build and much cleaner than the classic ‘stick it all in one procedural file way’ which too often is the WordPress way.

That said it's a barebones process. WP-CLI is great but it doesn't come with much tooling for this kind of project. You'll want to bundle your own migration packages for keep your database upto date and you wont have access to clever generators to build the bones of your architecture.

The big takeaway is MVC and OOP actually simplifies your development. If you're not familiar with it then it won't seem like that at first, but persevere and you will see how messy procedural code can get. WordPress has a lot of inconsistencies and a lack of opinionated structure often makes it harder to code.

A great place to start is to use Lumberjack, built by some fellow Brits or Sage. Both are much more comprehensive versions of the MVC framework I mentioned above (and will be better supported ongoing).

Bootstrap! Good for MVP but with limitations

Alongside our new MVC architecture we used Bootstrap for MTP as our style foundation. This served us well. We could build out quickly and experiment with low overhead.

Under the guidance of our excellent product manager and top jokesmith Chris Massey we worked in a lean way. Chris would work with his users, get feedback and prioritise development. Using Bootstrap helped us be fast and effective.

Oftentimes our designer Megan Sayers (another Skiffmate) would style our work after the fact, because we would build out functionality, see what got traction and then hone down on that feature. This might be anathema to many out there but it allowed us to move fast and ship more.

Bootstrap and our component design system was key to letting us do this. The more components we built, the faster we could build out and ship.

But it wasn't always that simple. The main issue I had with Bootstrap was the technical debt. This slowed down development sometimes at the later stages of the project. The more css we wrote, the more chances we would step on our own toes.

It didn’t matter how diligent you were with your BEM naming and Sass structure, conflicts happened. There were headaches. It was awkward. One false style adjustment in a global style can get inherited in ways you didn’t anticipate. It can be bit like whack-a-mole. Amend something here and something breaks over there. It can become unwieldy.

While it allowed us to move fast at the start, in truth the Bootstrap slowed us down as we progressed. I still hold it to be a better option than if we had built out everything from plain CSS, but there were drawbacks.

My takeaway here is that be wary of the time savings of using Bootstrap. It's not always the best choice. I've now jumped ship to using the new shiny css framework Tailwind and it banishes much of the headache described above by using purely utility classes. More on that in the next post.

Moving from jQuery to Vue

A lot has happened to WordPress since the halcyon days of 2017. Namely the adoption of Gutenberg and consequently React.

I was excited about the introduction of better practices and modern Javascript. But React wasn't an ideal fit for the WordPress projects I was building.  I needed something I could ‘drop-in’ rather than have to use wholesale.

Vue.JS was perfect for this, especially where it could be dropped in as a jQuery alternative.

As for Gutenberg, it wasn’t solving a problem I had or my clients had so I didn’t focus my attention on it. I remember the WordPress mission at one point to be the CMS of the Web. My clients were looking for that and that’s why WP was a good choice. At least it was when it was on that trajectory.

It's May 2020 and we are still talking about it and thats not a good sign: Where Gutenberg went Wrong

My takeaway is that Vanilla JS and jQuery are not going anywhere, but are not the best tools for the job. We're fortunate to see micro JavaScript frameworks like Alpine.js appear but for more dynamic projects it's really a call between React and Vue.js. I much preferred Vue.js and it's a shame that WordPress decided Matt decided to opt for React. I think the drop-in nature of Vue.js would have been a better bedfellow for WordPress developers.

It was just the push I needed

In the last few years it’s clear the WordPress mission has become more niched as a content curation tool (blog tool). Perhaps even as a full-page builder if the plans for Gutenberg are fully realised later this year.

As such it’s not the tool for building products. I take back what I said in 2017! WordPress no longer has ambitions to be the CMS of the web.

I'm not writing WordPress off at all. Perhaps it's healthy to pop out of your bubble every once and a while? Pandemic permitting, I'll still be heading to WordCamps and will keep a close eye on the community. There are huge opportunities in WordPress. It has a thriving eco-system and some brilliant minds creating huge value.

With a lot invested in the WordPress community it was hard to look at alternatives. I had been very active organising my local Brighton WordCamp and Meetup, as well as a WooCommerce meetup. I regularly spoke at conferences and contributed the open-source project. But I've made the leap and can report I've landed on sturdy ground.

I'll post soon about moving to use Laravel and Vue.js. I’ll talk about my new tech stack and how I’m building, but also how I have discovered a seriously positive, incredibly innovative and friendly community.

Most shocking is the lack of any #wpdrama - it's like the good old days.