If you know me, then you know I’ve been a huge Genesis framework advocate for quite some time. But then I met the Beans Theme Framework. Though I tried to resist the temptation and stay true to the Genesis Community, I fell hard for Beans. I fell so hard that I joined the team and am now a co-maintainer. Let’s talk about what’s so special about Beans and why I’ve made the switch.
UPDATE: I’ve switched back to Genesis.
After WP Engine acquired StudioPress, I felt a renewed sense of optimize about the Genesis framework. A major company in the WordPress ecosystem is now investing in it.
In the summer 2018, I switched back to the Genesis framework.
I’ve truly enjoyed working with Thierry Muller, Christoph Herr, and all of the Beans contributors.
Quick Link: What I Like About Beans
I’m slow to switch my workflow or processes. That’s a fact. I know the Genesis framework inside and out. I teach and advocate using it. It’s an incredibly flexible, extensible theming framework with a vibrant community.
For a few years, Thierry Muller has asked me to do a code review of Beans. I resisted, not out of disrespect, but more to stay focused and on task. I’m often asked to review various products and frameworks. But I guard my time. Genesis worked for me. Why would I ever consider anything else?
Beans excites the engineer and architect in me. It knocks my socks off.
For the past year or so, Alex Spalato, one of my mentees, kept asking me to look at Beans. She frequently talked about how fast it was and how she got perfect scores on various speed grading sites like Pingdom and GMetrics. “Head down, Tonya. Stay focused.”, I tell myself.
Then one day, I got curious. What’s all the buzz about? Seriously, why are Thierry and Alex so passionate about it? Okay, I’ll take a look.
Where do I start my review of Beans?
Starting on anything new requires a learning curve. Where do you start?
For me, I start by exploring the architecture, how it is constructed, is there separation of concerns, and how is the code’s quality. Immediately, the quality jumped off the page. Thierry did a brilliant job in crafting the architecture. Makes sense, since he’s a WordPress Architect at XWP.
Now I’m intrigued. Let’s go deeper.
I think what caught my eye and pulled me in were these key components:
- The Smart Event API. Seriously, this API is smart and the missing component for WordPress. We may just need to make this a separate API. It’s that good.
- The Asset Manager. The ability to gather, concatenate, and optimize all of the stylesheets and scripts is something that’s been on my TODO list for awhile. Bam, it’s right here in Beans.
- The Compiler API. Loading what’s needed on a per page basis makes my heart sing.
And then I saw the speed. This framework is blazing fast, far exceeding Genesis. Vroom….sign me up!
Personal Message to Genesis
I’m sorry Genesis, but I’m switching to Beans. It’s not you, it’s me.
I just want something more innovative, faster, extensible, and configurable. We’ve had a lot of good years together, you and me. But I’ve outgrown you and it’s time for me to move on. I wish you nothing but the best.
P.S. I promise to only speak kindly of you and continue teaching Genesis developers.
What I Love About Beans
Okay, I said it. I love Beans. It excites the engineer and architect in me. Let’s talk about what I love.
- Reason 1
-
The Smart Event (hook) API. OMG so smart and much needed. You can change only the priority number, callback, hook (event name), or arguments. #giddy.
- Reason 2
-
The Compiler API. It rolls up all assets into a single stylesheet and script. The Asset Manager I’ve been waiting for.
- Reason 3
-
Vroom, it’s incredibly fast!
Here’s proof. Click Beans and then Genesis for a side-by-side comparison on Pingdom.
- Reason 4
-
No need to remove default behaviors and components before building what you need in your child theme. Did that ever frustrate you with Genesis?
- Reason 5
-
HTML5 out-of-the-box with no legacy, old XHTML baked into it and weighing it down. Psst,
genesis_html5()drives me crazy in Genesis. - Reason 6
-
You pick what should be on each web page and only that loads. Powerful!
- Reason 7
-
Rock solid, compliant, and expressive HTML markup.
- Reason 8
-
Better, easier, more intuitive markup. I find the markup and attributes much easier and more intuitive in Beans than in Genesis. It’s all configurable without the need to add a hook for markup attributes.
- Reason 9
-
The amazing UIKit front-end UI framework is baked in. Look at the goodies you get. And in Beans 2, you’ll be able to add any UI framework or none at all.
- Reason 10
-
Prebuilt, ready to use fragments (snippets/partial views). Need post meta or a gallery. Bam, load it right into the page.
- Reason 11
-
Well-built, thoughtout, and architected by a rock solid WordPress Software Architect and Senior Engineer, Thierry Muller.
- Reason 12
-
And drumroll please…Beans is FREE and Open Source (FOSS). WooHoo!
Highly interested in this framework. Thanks for sharing your enthusiasm. Keep up the good work.
I’m going to start developing using the Beans Theming Framework too.
Hello Ruy!
Thanks for stopping by. I’m excited too!
As I noted to Dom, it’s a process to switch over from any tool, workflow, app, or framework. We’re working to make that transition as quick, painless, and smooth as possible.
Welcome to Beans, Ruy!
Cheers and <happy coding>
Tonya
Colour me intrigued. It’s lightning fast, isn’t it. I’d love to learn more about this. Not sure I’m ready to relinquish my Genesis comfort blanket just yet, though!
Hey Dom,
It is incredibly fast! Vroom! Come join us in our Slack group to stay current.
There’s no need to abandon Genesis just yet. It takes awhile to change your workflow and master a new tool, framework, or workflow. I want you to be as productive as possible.
That’s why the Beans Community will be focusing on driving down the learning curve time and providing tutorials, quick starts, and tools to help you go from zero to Beans Ninja in no time. I’m thinking about a Genesis-to-Beans Converter tool too. And there will be plenty of hands-on labs on Know the Code too….coming soon.
But soon….you’ll naturally transition over to Beans and a huge smile will be on your face as your clients’ sites get even more amazing.
Cheers and <happy coding>
Tonya
Thank you so much for sharing your thoughts Tonya!
As a non developer, but a technical person that creates tutorials I have used a few years to slowly get into Beans. My intuition told me about 2 years ago that Beans is a powerful framework that I should use for my client sites (even without fully knowing why). When I get even more proficient in using Beans and am able to customize more areas then I will start creating client sites with it. I have for a few years now used and still use Genesis and will gradually change over to Beans as soon as I am able to. I am so glad you shared the various reasons why you made the switch!
Hello Paal,
Thanks for stopping by my blog and sharing your story with Beans.
Bam, you were spot on and saw it years ago. I was slow to check it out, as that’s my nature to stick with what works for me. But like you, I’m onboard now!
Change takes thought and planning. Shifting your specialization from Genesis to Beans is a process. But as you know, the Beans Community (which includes you!) are working to make that transition as easy, painless, and effortless as possible.
See in your our Slack group!
Tonya
This looks legit. The compiler API especially — I’m curious, is there a plan to include optimizations for HTTP/2 protocol into future versions? Compiling all assets into one file isn’t best in that scenario.
Well Hey Calvin,
Thanks for stopping by. Always great to chat with you!
Like everything in Beans, you pick. From the settings page, you can turn it on or off.
In some scenarios, depending upon the plugin stack being used, something might break as all of the scripts are loaded into the footer.
And as you pointed out, the HTTP/2 protocol has single connection, multiplexing, and more. As such, combining all of the assets isn’t always necessary, when something changes often (as the whole file would have to be downloaded again) or the size of the file makes it slower to download than the individual ones. This is where we need to look at Developer Tools when working on a project’s optimization to make the right call.
For render blocking, there are things that can be done to mitigate the issue while staying as fast as possible.
One of the Beans core promises/principles is: “Knock Your Socks Off” Performance. Optimization, speed, compliance, etc. are key components to performance. Therefore, it is important that we optimize to HTTP/2.
Here, I just added it to the Beans v2 Roadmap. Thank you for tapping me on the shoulder to remind me.
Come join our Slack group. I’d truly appreciate your insights, input, and contributions!
Cheers,
Tonya
Thanks Tonya! I appreciate your clear and concise answers. 😉
As many people, I was happy with Genesis when Thierry talked to me about beans, and the first time I said him I was not interested, as I was happy with Genesis and have no reason to change, + I was preferring sass to less, and I was not working with front-end frameworks.
Then a few time later we add a call for another reason, and he took the time to explain me more things about beans, as I am extremely curious, I went to beans just after our call …. and here I stay the whole week, learning and building a nice starter theme for my needs.
Then I built my next client project with it and never stopped 🙂
I have also built some genesis sites these last month … And really realized that I preferred Beans. Oh, and I fell in love with UIKit!
I am so happy to see Tonya switching, and all this new buzz around!
Well, Alex, you were a driving force behind me taking the first look at it. For a couple of years, you talked about it and kept asking me to review it.
This year, I had concerns that Genesis was in the “fixing” mode instead of pushing it forward and innovating. Release after release kept the old XHTML code in it. I started thinking about building my own framework. Hmm, starting from scratch is appealing, but also very time consuming.
Then I remembered Thierry and you. Okay, I’ll take a look. I reached out to Thierry to ask a few questions. Then I set off to do an audit and code review. Okay, why build my own when I could contribute and help Thierry drive Beans. He and spent some time talking and found we thought alike. Bam, I switched and became a co-maintainer/co-owner.
Thank you for being persistent. Your voice rang in my head. It was a big reason why I finally dove into Beans.
Happy to hear that 🙂
Super intrigued! I’m a Genesis fanboy and build everything with Genesis, but this is extremely interesting and something I think is worth looking in to. As much as I love Genesis you bring up a LOT of really great points and things that could make workflow simpler and performance better.
As you’ve mentioned, changing workflow is certainly difficult especially when you’re so accustom to well-versed with what you’re doing…but color me intrigued!
Cheers!
Matt
Hey Matt,
Thanks for stopping by. You are so right that changing your workflow is difficult. You’ll need to take a systematic process and incrementally switch over. We recognize that there’s a learning curve and process change. We are working on ways to ease both of those and help you to quickly ramp up with minimal effort.
Alex is a great case study, as she switched her agency from Genesis to Beans in a week. It took a week for her to dive into Beans and then switch over.
I wanted to share The Beans Way with you with these core principles:
Come join our Slack group. Ask questions.
Cheers!
Tonya
Hey Tonya,
Great post! I was just wondering if you are familiar with Roots Sage and what the pros/cons are compared to Beans?
Hey David,
Thank you. I have not built with Roots Sage, though I have looked through its codebase.
Roots Sage is a starter theme. That’s very different from Beans. Why? It will cost you time while increasing your risks.
Let me explain.
A starter theme is a beginning point, a bootstrap if you will. You clone it and then customize to fit your needs. A framework on the other hand, like Beans or Genesis, has 90% of the code within the framework.
You build a child theme for the customization that is needed in your project. But you never touch the framework itself.
Why is the distinction important?
Think about this.
When you use a starter theme and then customize it, what happens when something in the original starter theme needs to be updated? What happens if there’s a bug, security issue, patch, or change due to something like a change in WordPress? How do you get those changes into your customized version of the starter theme?
You have to manually go to each instance of your customized version of that theme and update it yourself. Think about how much work that could be. That increases your costs and risks. Plus, you have to be alerted and remember to go manually update each of the themes. That’s a risk for those who use your theme, i.e. as you may not remember or be aware that it needs to be updated.
Conversely with a framework, since you never ever touch the framework as all of your customizations live in a child theme, the framework’s community keeps that framework up-to-date. That means the vast bulk of the theme’s code is constantly patched, tested, and upgraded. There’s nothing you need to do. Rather, your clients just upgrade the framework and bam, they’re done. That reduces your time, costs, and risks.
Roots Sage is a beautifully designed starter theme. But it’s not a framework. I have a fundamental philosophy opposition to the intent of a starter theme, as I believe a framework is a better solution for rapid web development and continued innovation and integration.
I hope that helps.
Cheers,
Tonya
Hey Tonya,
Now its time to port your lovely Hello Minimal theme to Beans 🙂
I am happy that Thierry gets some help from you.
🙂
Jochen
Hey Jochen,
Thank you. It’s on my TODO list. But I’m waiting until I get Beans 1.5 completed and released. Then I’ll convert my theme over to Beans.
I know Beans few years ago and I really like it even I am just a writer but interested in web development with WordPress. Since then I thought it will be the framework that I want to use for learn and build WordPress websites with. I am about to jump in to learn code soon and I will go directly to Beans.