This is a large and complex topic, and I’m 100% positive I’m not going to be able to catch all my thoughts on how I use Pinegrow or what features are the most useful to me. So, I’ll list my main use cases for Pinegrow and try to organize some high-level thoughts about each.
WordPress themes and blocks
This is by far the thing I use Pinegrow for the most – creating classic themes and blocks. For the most part, things work very well, and I don’t have any workflow-related feature requests that I can think of. My biggest pain point when working on WP projects is creating the menu and/or page header. Even with a starter template, it’s just so time-consuming! Of course, adding a menu builder is a massive undertaking and arguably has no place in a product like Pinegrow, but it sure would be nice
Most of my WordPress work is with plain HTML & CSS (Sass) since frameworks like Tailwind create unnecessary friction with the WP Block Editor.
Pinegrow WP Plugin
I’ve been using this on smaller projects where I need to make more frequent changes to the theme or blocks. My biggest pain point is that Sass is not supported, so I have to use a modified starter template and different processes than I normally do in Pinegrow desktop. Additionally, the relative inflexibility of the built-in Tailwind compiler makes this far less useful than I’d like it to be. Version control is also more difficult in the WP Plugin and I find myself exporting projects to save them locally for safety.
Prototyping & Mockups with Tailwind
I use Pinegrow to create quick mockups and/or prototypes. It’s so easy to copy/paste components and templates from places like TailwindUI, Alpine, Flowbite, etc. As I mentioned earlier, the built-in compiler feels limited, and even using things like @apply directives are not possible since we can’t modify the input.css file. I think giving us even limited ability to modify the input.css and tailwind.config.js files would go a long way toward making it more useful.
As far as the external build process goes, it’s relatively complex, and the scattered documentation covering several versions doesn’t help. That’s part of the reason why I made a video documenting it. Creating a helper inside Pinegrow to automate some of that work and give people a default configuration to build on would be a huge help, especially to people who aren’t familiar with how Tailwind works.
I’m not doing much in the way of Application UIs or true components, so my views on Tailwind and how they relate to Pinegrow are from the perspective of someone building WordPress and static websites for clients.
Vanilla HTML/CSS/JS Projects
I’ve created a few static HTML/CSS/JS projects, and overall, I love the tools that are in place. I would love to see support for Open Graph properties in the HTML Header, though. At least og:url, og:title, og:description, and og:image.
This has so much promise, and I want to use it, but in practice, I find that copying HTML and CSS from another “master project” is generally easier. The main struggles (for me and my tiny team) are that creating a custom library page for the inserter is more trouble to maintain than it’s worth and that the component styles are cumbersome to manage unless I’m using a utility framework like Tailwind. In my mind, having not given too much thought to it, I’d love a way to store each component with Sass partials and have the destination project simply add or reference them in the destination project. The current method of referencing the resources from the reusable library is fine during development, but packaging all the various resources for production adds another layer of complexity and hassle.
That’s all… for now!
I’m sure I’ll think of more as time goes on. These are the things that immediately came to the top of my mind.