6 years ago, I got my first freelance web development job and it happened to be custom WordPress theme development. Since then, I’ve built about 14 other WordPress themes.
Before working with Frontity, my workflow was to use my custom scaffolding to generate a theme that utilizes the ACF Pro and Timber plugins and usually include Bootstrap as a UI toolkit.
While sites with my scaffolding were fast to build, I was never happy with their performance. Many of the problems probably stemmed from either lack of client budget or laziness on my end in not removing unused CSS, utilizing srcset and optimizing image sizes, and implementing a CDN and/or lazy loading images.
After learning React very slowly over the last year and watching @mburridge’s Frontity workshop as part of JSNation, I decided to try Frontity first on Linda Jean’s restaurant website, which won the Frontity JSNation competition.
I had made only a handful of create-react-app-based React sites and the Frontity workshop helped a ton in getting me up and running. I’d say the key is understanding connect(), state, and Emotion.sh styled components and css() function. I used ACF Pro as I always have (no need for Timber of course) and found that Frontity plays fantastically with ACF Pro, for both posts and for global options.
Linda Jean’s website isn’t terribly complex and the most interesting feature is the menu viewer on the Menus page. I simply use React’s state to change the content within the scrollable <div>. It was simple to create straight in React; whereas, it would’ve taken a bit more effort to concoct in my old set up because I’d have to create my own state-like object with Javascript and render the changes with jQuery.
Somehow, I found coding in React to be faster than coding my Twig templates. I also adopted a different workflow on the project were the back end was completely structured before tackling the front end. In the past, I’ve sort of tackled both front end and back end simultaneously, especially since it feels easier to switch between the two when you are working in Twig and PHP. But, separating the process may have factored into how quick development time was.
One negative in Frontity development is that code separation is really important because in some elements (namely the header.js file), I piled a lot of different components into it. Along with the styled components, this makes the file super long and hard to navigate. At least, when I coded in Twig, the styles were in a similarly named SCSS file. In the future, I would separate components as much as possible.
Another negative is that I am used to Bootstrap’s _variables.scss file for configuring the theme. I sort of know what goes into Bootstrap’s variable-based styling and could emulate just what I needed for buttons, cards, break points, and theme colors etc.; however, it was painful to have to pass theme everywhere. During development, I looked into providing context but realized that Frontity’s connect() already sort of does that and I didn’t feel like modifying state much in my first project. With Linda Jean’s website being so simple, it wasn’t too bad but it really took a while to stop getting rendering errors from theme not being defined and forgetting to pass it to all the elements that required it.
Since I had to pass theme to every styled component that required it, that made using it within styled components tiresome. Having every time to write ${props => props.theme.colors.light} wherever I needed just a light color or any other variable felt ridiculous at times. I have since spoken to @mmczaplinski and it looks like having connect() wrapping styled components is something coming up soon and will help immensely.
These styling issues were a bit offset by how delightfully similar styled components and Emotion’s css() was to SCSS. Using css() in my theme’s object was similar to mixins in SCSS, the nesting was helpful in maintaining appropriate scope in my styles, and style(MyComponent) for styling custom components (whether I built them or they were included as an NPM-installed component) is powerful. I also revelled in using NPM packages like color to emulate SCSS color processing, all the while realizing that because everything was in Javascript, I could modify my styles however I felt without limitations from SCSS functions etc.
Site speed is where Frontity outshines everything else. Between the SSR, Frontity’s image lazy-loading, Vercel’s CDN and stale-while-revalidate, it was as if I had already spent a day optimizing the site when in reality, all I did was deploy the first iteration. Deploying with Vercel is amazing and easy compared with how I was doing it before; uploading theme files and synchronizing the database. Having the front end on Vercel as a SSR-ed React app removes the bottleneck of cheap PHP hosting and enables me to recommend the cheapest plans for my clients and my own projects. I also cannot wait to try coding a theme that uses Gutenberg and WordPress.com’s free plan to provide top-notch themes for clients that cost just the price of a domain to keep online.
Over the years, I always wanted my local theme development to more-or-less use the same WordPress back end (database) as the production site and that’s pretty much the default once you push your back end live. It can be hazardous when making changes on the back end but if you’ve planned it out well and have a way to duplicate the site locally, it’s not impossible.
My opinion of Frontity is that it’s a fantastic tool to build websites with the most modern tool-set. It elevates WordPress development out of controversial PHP for the front end and gives theme development flexibility (in that one could replace wp-source with any other data fetcher to use something other than WordPress as a CMS). Plus I found I learned React much better during the process, including styled components, which I now love.
There are still some things that I have to learn about Frontity and there are some items on the Frontity development roadmap that need to be worked out before it dominates but it already provides a capable and modern WordPress development workflow.
