MasterWP is sponsored by LearnDash. Your expertise makes you money doing what you do. Now let it make you money teaching what you do. Create a course with LearnDash. (Use coupon ‘MASTERWP25’ to save $25 on your purchase!)
When we started mapping out the development process for WP Wallet, we examined many of the popular tech stacks in the ecosystem today. After a lot of internal discussion, we honed in on a few key principles that guided us through each technical decision. We’re going to break those down here and share some basics on how we’re building the front-end of WP Wallet.
One: We wanted to use WordPress.
These days it’s pretty common to build anything remotely SaaS-adjacent using a SPA or full-stack approach: something like React and MongoDB sitting on Heroku or Netlify with maybe some Parsley on the side. Ok, I made up Parsley, but it sounds like a real thing and I could’ve easily pretended it was.
Over here, we’re all WordPress developers, serving the WordPress marketplace, so we wanted to use WordPress as the foundation. With the WP REST API, robust and scalable hosting options, and decades of combined dev experience, we knew that our team running with the WordPress codebase would give us more than enough stability long-term, even if we eventually decoupled the front-end completely.
Two: We wanted a low barrier to entry.
Our development team runs the spectrum from amateur to expert, designer to developer, front-end to full-stack. Some of our team has experience building custom applications or using the latest frameworks. Others are just stepping out of a Bootcamp or into advanced WordPress for the first time.
We wanted to build WP Wallet in a way that was easy to spin up for our entire team, so that everyone could eventually contribute anything from a few lines of code to a brand new feature. This meant we wanted to stick as close to our typical development process as possible, with approachable tools like Bootstrap, SASS, and more.
At the end of the day, we did want that modern web app feel. We knew we could take full advantage of the WordPress REST API when handling data storage and retrieval, so we wouldn’t be stuck with PHP page reloads or writing tons of custom WP_Ajax handlers.
Comparing Vue vs React
WordPress itself recently went through a similar battle, first abandoning React due to its license, then eventually coming back to React as the framework that would power Gutenberg and one day most of the WordPress admin. It would’ve made a lot of sense for us to use React as well, if only to allow ourselves more familiarity with the tools of the core team and the block editor. On the other hand, most of us involved just deeply preferred working with Vue.js over React. I’d recommend this article about Vue.js founder Evan You, as he lays out a pretty solid case for picking the scrappy upstart (Vue.js) over the Facebook-owned behemoth that is React.
In the end, we chose Vue.js for a number of reasons: familiarity, the documentation, the community, and just plain taste. We enjoy working in Vue.js the same way we enjoy working in WordPress. Vue.js is meant to feel user-friendly, and while React really ‘clicks’ for a lot of developers, it doesn’t feel as fun for any of us. (I’m really looking forward to finding out how wrong I am about this from Twitter.)
Vue.js was maybe a riskier choice, as it doesn’t have the funding and development of WordPress and Facebook behind it, but we’ve really enjoyed it. Here’s just a few of the benefits we’ve found so far.
Get up and running without a build process
Because we wanted to just get some basic UI elements up and running quickly, we didn’t use the full build process to get from zero to prototype. Instead, we just pull in Vue.js as a dependency and use a smaller subset of its features. At some point, we’ll probably rewrite a lot of the code to transition to using Vue’s Single-File Components, especially as our feature set gets more extreme, but for now we’re working quickly and comfortably.
Spending more time in HTML instead of JSX
Vue.js lets you write your HTML in a way that looks and feels more like HTML. You don’t have to wrap your HTML in a return statement, you can keep it nice and separate. The way you can sprinkle in HTML attributes like
v-for have a real classic-PHP feel to them.
The sign of true learning in web development is when you look back on your code from six months ago and roll your eyes. You know you’re improving when you can actually see the room for improvement in what you just completed. While we have a backlog of great features we’ve been cooking up for WP Wallet, we’re also thinking about “under the hood” enhancements for our codebase. We’d like to take advantage of the larger Vue.js ecosystem, custom components, and other features like animations that come with using a full build process. We’d like to clean up our work by moving every UI piece into separate
Eventually we could run WP Wallet completely headless, so that the only PHP building happens when our application makes REST API calls instead of on the initial page load. All of these things are possible, thanks to Vue.js and the modern development ecosystem.