Shifting Gears in WooCommerce Development From PHP to React

Zach:
Welcome back to another episode of Do the Woo. Woo DevChat, Zach as always. And I’m here with Carl Alexander, my tireless co-host who puts up with me every month. Carl, how are you doing?

Carl:
Good. I’m good. It’s finally starting to warm up in Canada. We’ve gone through multiple fake springs where it seems like it’s going to be warm, but then it snows again. Then it’s warm again, and then it rains, drizzles, and hails. But now, it’s for real. Yesterday we had our first really hot day. I think it was over a hundred. It was like 37 Celsius, which I think is over a hundred Fahrenheit. I never know how to convert to Fahrenheit, but it was hot. It’s great. I’m happy.

Zach:
Yeah, it hasn’t gotten quite that hot here, but it’s been in the eighties, so quite warm for northern Illinois this time of year, which I’ve been very happy about as well. So I hear there’s a rumor swirling around that some people are trying to do another dev chat. Have you heard about this?

Carl:
I’ve had inklings; my little birdies have told me something is cooking. Bob is cooking something.

Zach:
One of those birdies named Bob?

Carl:
I should not tell you if it’s Bob or not, but it was Bob.

Zach:
Yeah, that’s true. We don’t want to reveal our sources here. So yeah, I guess all of you like hearing Carl and I talk so much that we’ve decided to add another Woo DevChat that’s not Carl and I, which is pretty cool actually. But who’s going to be hosting this one?

Carl:
I think Bob would go crazy. He’d be like, “I can’t edit Carl twice a month. This is an unacceptable arrangement to me.”

Zach:
I mean, I think at that point, even the AI that Descript uses to somewhat auto-edit would probably say no.

Carl:
The AI would peace out. “You’re on your own, Bob.”

Zach:
Yeah, that’s just enough. Bob, you’re going to have to go back to the Stone Age and use Audition to chop this up.

Carl:
I mean, that was the original Terminator script. The AI had to edit Carl, and they were like, “No more, no more. I’ve had it with humanity. We’re done.”

Zach:
That seems pretty accurate. So I guess we should just drop some knowledge here. We have some guests today, and they may or may not be, I can’t confirm or deny, the hosts of this new Woo DevChat. Why don’t we start out with Mike? Mike, why don’t you introduce yourself? Carl is sitting there waiting to learn all about you.

Mike:
I’m Mike. I am a WordPress performance specialist and WooCommerce dude who runs a performance agency called WP Bullet. I’ve been working with this stuff for a long time. I’ve also been freelancing for a good six or seven years now, and I live right down the road from my buddy over here who’s up in the top right-hand corner.

Zach:
And that buddy, I know his name. I’ve met him before. I may have taken photographs of him in front of a giant well-used elephant at WordCamp US. And that would be Marcel. Marcel, why don’t you introduce yourself to everybody?

Marcel:
That’s true. The famous photo. I have to replace that photo with my avatar photo they have everywhere. Hey everyone, my name is Marcel, a WooCommerce expert. I live in Porto, Portugal, just a couple of minutes away from Mike and our source Bob. I’ve been working with WordPress for more than 12 years, 13 years now, WooCommerce for eight years. I’m currently freelancing as well, for eight years now. I had an agency before that, I had multiple products coming out. Just happy to join, happy to be here, and we have a lot to talk about I guess.

Zach:
Yeah, so we’ve been doing the dev chats now for a little over a year, maybe a year and a half, I think. Bob could answer that. We’ve done quite a few of them and they seem to be pretty popular. People seem to be learning from the things we’re talking about. I think there’s a gap to fill to help people go from builder to developer. There are a lot of people who can build a WooCommerce site and understand how to use WooCommerce as a plugin, but the move to how to extend and optimize WooCommerce as a developer is really kind of a big shift. I think we’ve been trying to fill that gap and help people make that transition into understanding more of the internals of how WooCommerce works, understanding what things like high performance order storage mean, understanding how to write things that don’t, oh, I don’t know, break action scheduler. These are things we don’t want to do, and I think there’s a lot of opportunity for learning more from more voices.

I’m really glad that the two of you have decided to join us here and start to do some episodes as well. And I’m really interested to know what type of guests you’re planning on going after, what types of topics you want to talk about, what ideas you have in the hopper because one, we’d like to avoid those topics to give you room, but two, I think it would be really cool to kind of get a glimpse of the future for some of the people that are listening and really understand what the full package is now with what we’re going to be giving as the Woo DevChat moving forward.

Marcel:
We have been talking about doing a podcast ourselves for a couple of years now. We’ve been meeting every now and then at a coffee shop, talking about development, talking about our work, and we suddenly realized we could eventually just press record on a mobile phone, put it on top of a table and just record ourselves talking about different subjects. Although that never left the phone storage and we never put that together into a proper podcast, the fact that Bob moved to Portugal and actually chose to live a couple of minutes away from me and literally seconds away from Mike just sparked our interest in doing a podcast together and talking about different subjects. We are both developers and we’ve been doing client work as freelancers for a good six, seven years.

I think the topics we will cover can vary a lot. We don’t need to specifically restrain ourselves to the area of expertise that we talk about or that we mainly work in, which is WooCommerce. There’s so much to talk about, not only the development part itself, the technical details and all the little tricks and tips that we can give, but also about client experience, what clients do with WooCommerce, and the challenges that those bring to the table. We have so many people that we know within our freelancer community within Codeable, as you well know, Zach, that could also come into episodes and talk about their experiences and their expertise. We have a couple of things figured out and we have a couple of experiments coming out. We also are planning on eventually doing some live podcasting, doing podcasting at events and having other people join as we record.

Mike:
Yeah, I think we’re going to be experimenting a bit in the beginning to see what works. We have a bunch of cool nerdy friends, so whoever we convince to come on and share their experience and what they’re working with and teach people whenever it is they’re working on, I think it would be fun. Marcel and I have a lot of experience speaking with clients, big clients, and the communication and managing expectations and getting them to understand and appreciate what I call invisible progress when they are refactoring something that’s going to take three or four months and it’s going to work exactly the same afterwards. That’s a difficult thing to try and sell to a client, for example, but it’s essential for the ongoing development of their project. It’s like redoing the foundation of a house and you’re like, well, my kitchen is still where it is. The toilet still works. Everything is still there, but it’s difficult. So I think we’d like to talk about some of these softer skills as well, which are essential developer skills nowadays, especially if you’re freelancing.

Carl:
There was a meme of me a couple of years back, this guy in Montreal, named Michel. Maybe you’ve seen him, Mike, but he made a lot of gifs and memes of me. One was “Soft skills to pay the bills” with some Beastie Boys. I really believe that you need a lot of soft skills, especially if you’re on your own, but even in companies, I find it useful to have soft skills as a developer.

Mike:
Yeah.

Zach:
It’s amazing the power of language and the choice of words that you use can have a dramatic impact on the interaction you have with a customer.

Carl:
Yeah, I mean it’s all communication. I always say I can charge an extra hundred dollars an hour because I answer emails. It’s crazy to me that people aren’t responsive and that it’s really mind boggling to me because that’s a really important part of interacting with people is just being responsive and feeling like they’re being heard and all that stuff. So it’s not just about the actual code itself.

Mike:
Yeah, I was going to say you could add another hundred if the client can feel that you really, really care. You’re really invested in their success and their progress and growth as a company or as a human being and their mission, whatever it is. Once they know that they can trust you with that, they don’t want to let you go. It’s like any kind of relationship where they’re just like, oh,

I know you’re the person I want to take on this journey and you are going to help me be the pilot sometimes, sometimes you’ll be the engineer or whatever. It’s very special.

Zach:
And surprisingly enough, the easiest way to prove to customers that you care is to actually care. It’s amazing how that works. If you take a vested interest in their business and their success and you genuinely want to help them in that regard and it’s not just a paycheck at that point, you’re going to do better work. They’re going to be happier customers.

Marcel:
Exactly. And you’re also going to be more motivated to continue working with that client, right? Because you did this first work, they had success and you were proud of your work that you delivered. You made the client happy and maybe their business also succeeded a lot more, and then you go back again and do it again, and then you repeat it and repeat it. That’s just the joy in seeing those businesses grow because of some contribution that you made to it and even getting paid for the special work that you do. That’s all that matters. The way you communicate and the way you talk to the clients, they will notice that. If you get excited about a success or if you put in that extra hour because something doesn’t work and you want to make it work, and if you communicate out of the regular hours because you figured something out and fixed something on their side without their request, all of those little details add to the relationship and that’s what you as a developer should be able to do.

Zach:
Yeah, it’s amazing how much better a relationship is when you show you genuinely care, respond promptly in the way that you would want to be responded to, and do good work. Those three things, for whatever reason, seem to be the recipe for success. Communicate well and timely and do good work, and you can keep customers very happy with just those three things. Even if you have to shift a deadline, if you’ve communicated well and established that you are never going to push a deadline unless you absolutely have to, and that the only thing that can change your timeline is the unknown unknowns, the things that you find during the process and you’ve set the stage for the possibility of that happening, and established how that happens if it does, you can shift a timeline without the customer getting angry about it. But you have to have set the stage, you have to have that relationship, the rapport with that person in order to be able to do that. So yeah, soft skills are absolutely important.

Probably in some cases, especially on some of the larger, more enterprise clients, almost more important than your ability to deliver clean, elegant code. It doesn’t have to be clean and elegant if it works. In some cases, yes, obviously clean and elegant will be more maintainable and likely more performant, but what really matters is your ability to deliver something the client is happy with. And you do that via using those soft skills. So yeah, absolutely important. I’m excited to hear more of what the two of you have to say on that subject as new episodes come out. Knowing the two of you, being a Codeable expert myself, and seeing the work that we’ve all done there, I know that there will be some hard skills too that we’ll talk about and that all of us have faced unique challenges with WooCommerce. Those unique challenges have happened because we have been on the edge of what’s possible with WooCommerce numerous times. Some of us have even worked directly on the product. So just lots and lots of experience and knowledge around what these unique challenges could be, what things we’ve found.

It’s a big product. Getting into WooCommerce now compared to right after the fork, getting into it now is much harder. The mono repo is a jungle when you first get into it. That was a big shift, a big change. It made it harder, I think, for individual contributors to get into the code base and understand what’s going on. For those of you who aren’t familiar with what a mono repo is, it’s a giant repository that contains all of WooCommerce and everything related to it. It’s a much more complex project than it once was. All the plugins that were feature plugins that have been folded into the main repository have added layers of complexity, things like blocks, and other things that weren’t there before. So now it’s just a much more complex thing to understand. It’s not just PHP anymore, it’s PHP and React and all of these other things that have gone into building a better admin experience and doing all of the other things that they’ve done. It makes a more complicated product, so it takes more to get in and understand everything that’s happening. Action scheduler is part of WooCommerce itself now, instead of just being part of subscriptions, if you’re using subscriptions. There are many more things that have just become part of the project. I’m interested to hear your takes on how you feel about the mono repo after having it for a little while here and whether or not it increased your complexity the way it did for me.

Marcel:
If you were to ask that question to me maybe one or two years ago, I would ask you back, “What is a monorepo?” WooCommerce taught me what a monorepo was because I’d heard about it, but I’d never seen it in practice. I immediately jumped out of it. Back in the day, you could just clone the repository, build it yourself, do a couple of experiments to figure out what things are under the hood and what happens if you change that code. Nowadays, for you to get to a certain point where you can compile and it will not fail or take five or six minutes to do the first compile, it’s just actually not possible. So it’s definitely harder to deal with it and to take a look at the features and how they work.

At the same time, our challenges are also what is missing in WooCommerce for particular use cases, what could be different in a way that would fit certain needs. There are definitely some patterns that we see as we deal with different client projects that could eventually be changed, adapted, or somewhat adopted by WooCommerce as an out-of-the-box feature. That is already very interesting to see, and we’ve seen other features coming into the WooCommerce feature set as well. That’s also something I think we’re going to talk about: our experience adding those little things as extensions, as plugins, as little extras that people need to make WooCommerce adapt to their business model, but at the same time also taking out some features. There are so many things in there and people keep asking, “Why do you need all these 10 fields? I only need those two ones.” So we end up also taking features out of WooCommerce, which is an interesting topic as well.

Mike:
That is really cool. I actually didn’t know about the mono repository. I’ve never been inside of it. It sounds big and scary, but if you can literally compile your own WooCommerce that makes it leaner where you can sort of toggle pieces on and off, that sounds amazing. Is that what you’re saying you can do?

Marcel:
Well, you could eventually do that, but it’s a lot more complicated right now to get it working. There are so many little details. If you look at the PHP classes right now, they do not tell by themselves what they’re actually responsible for because it’s just a tiny little thing that is connected to another one, which is connected to another one. You have 10 or 12 different ones that are responsible for a single change of a string. I’m probably exaggerating here, but it’s close to that. It’s harder to figure out where that filter or hook is to actually change something on the screen. Because you’re adding React on top of it, we now have triggers and filters going on the JavaScript side. So that’s the other side of the room, so to speak. It’s even more difficult to get your head around it.

It used to be the case where you could eventually figure out in your head, I think I have a grip on what things are. Right now, it’s just a complete jungle as you were saying.

Zach:
Yeah, I think that we could benefit from some guidance from the WooCommerce team on where certain things are located and best practices for extending them. Now in this new world where meta fields are harder to make and things are harder to do than they have been before. It used to be really easy to extend the admin screens because they were in PHP, but they’re not now. So how do we do that? How do we make those extensions? What are the best practices for adding things to the new product screen that’s coming? All of these pieces that are becoming more React-based over time and getting closer to the block editor as well. All of these things are changing, and it doesn’t seem like there’s a good path to learn how to do all the new things yet. This is a problem not just WooCommerce-related. It’s a problem across the board with a number of plugins that do updates to their admin and their front-end screens that are using more block and React-based things. It becomes harder to extend those things if you’re not considering how that extension will work, how the ability to extend will happen from the beginning. While we have had this ability as PHP developers to just modify how anything works in the WordPress ecosystem, that’s becoming less the case as things move further into React. It’s a very interesting topic to me trying to understand where we’re going and how to stay on the bus rather than fall off of it. For some people, it’s been a difficult thing to keep up with all of the changes over the last few

years.

Marcel:
Definitely, and it feels like in the first moments when React came into WooCommerce, everything was a little bit experimental. The team implementing all the alternatives for the cart and the checkout was figuring it out as they were releasing it. Some of the stuff that was not possible two years ago is now starting to be possible. So it feels to me that things are sort of being tried in a real world where people are adopting and giving feedback. As developers, we also have an important role in communicating our difficulties. There are different channels that we can use to explain why we think this shouldn’t be this way and how the alternatives could be set up. That is sort of changing. It’s still more on the experimental side. There are still some things that we like to keep locked because of reasons.

PHP used to give us so much freedom that we don’t have right now with React, and I still think that there’s a lot that we can do to regain some of that freedom for changing stuff. So that’s something we can definitely talk about because we live that day to day.

Carl:
I have a lot of opinions on the React stuff. The whole topic for the last 10 plus minutes is about how this code base is really getting really complex. One of the topics even in the larger developer community is how do we keep things from spinning out of control? I feel like we all got the full site editor and everything’s great. I think it’s a really good feature. I feel WordPress used to be something that was a lot more approachable, and now the skill gap between starting and where you need to be to even understand these larger plugins or WordPress itself is starting to be even larger than it used to be. WordPress also is adding a lot of—WordPress loves reinventing the wheels—so there’s the reactivity API now. There are all things that exist with other libraries, but we’re reinventing them, so everybody has to relearn what to do with WordPress-specific things.

Not everybody’s comfortable with JavaScript because they come from PHP. You used to just install a simple LAMP stack and then be off to go. Now you need build tools and the whole thing. So it’s a really different world. Sometimes I worry about developer experience with what I feel like is a recurring topic because for advanced developers, it’s okay, but a lot of WordPress developers aren’t advanced. It makes it very complicated for them to jump in and try to figure out what’s going on or how they can contribute. Even contributing back to a project becomes hard to even find anything to get yourself up to speed. That’s something that is on my mind a lot because I feel like that used to be a WordPress thing, and now I don’t feel it is. I don’t feel WordPress is that accessible anymore.

Mike:
Part of WordPress before was its accessibility from a coding perspective and publishing perspective.

Carl:
From a developer perspective. How much code did you fix that was just some PHP code written straight in the file or something like that? You can’t do that now if you have blocks and things like that. It’s a lot harder, right? I mean, it’s a different world. One of the problems I find is tooling. I’ve been programming for so long, but just looking at where even the rest of the PHP ecosystem is, before it used to be like, oh, doing symphony and stuff like that, that’s hard. Now I feel like if I want to contribute to WordPress core, that’s way harder than making a patch for Laravel or for way harder. To me, that speaks to something about the project and the accessibility for developers.

That’s a bit of what’s been talked about. It’s like, oh, it’s a monorepo. Monorepos aren’t new. Symphony’s a monorepo. There are a lot of monorepos out there. The fact you can’t just arrive and know what you need to do. I don’t even try to be honest, but I don’t think it’s that easy to get yourself up and running the same way it is with a lot of these projects that are more focused on contributions and things like that. It’s a bit gatekeepery in some ways because if you want to get in and do it, it’s not always that simple now. I think developer accessibility is a thing now. I really don’t think WordPress is the easiest thing to use now or to contribute to or understand the way it used to be.

Zach:
No, I agree. Yeah, you brought up the interactivity API. Very interesting stuff. I hope that maybe at some point we get the cart fragment replaced with an interactivity API-based one.

Carl:
But for me, it’s a question of, again, I’m a bit detached now, but why do we need this versus just using something like Alpine.js? Why do we need to add more things that we have to maintain?

Zach:
No, I agree.

Carl:
Before, they used to be a bit more open to that, like the backbone, and they even put some PHP libraries in there. Now it’s a lot of reinventing the wheel. That’s also more complicated, right? Because now there’s no analog. If you’re like, oh, okay, WordPress uses Alpine.js, I can go to the Alpine.js documentation. Now, there’s just the reactivity documentation. You either know how that works or you don’t. There’s nobody else using this, it’s just here.

Things like that I think a lot about because, for me, I’m always thinking about the health of the project. That’s been on my mind a lot in the past year or so. How do you bring new people in? The more you make it your own thing with no analogs anywhere else, and you make it complicated, it’s hard to onboard new developers. They’re going to be like, screw this, I’m going to go do Next.js or some other thing. There’s a million documentation and it’s easier to get started. I think a lot about that. I think WooCommerce suffers also from that. I think it’s a really hard project.

This is not WooCommerce’s fault. E-commerce is freaking hard. Nobody that looked at the Magento code base was like, oh yeah, this is super easy. E-commerce is hard.

Marcel:
E-commerce is a competition, so all the platforms are competing against themselves. The feature that comes into one platform needs to be integrated very quickly in the other one. So everybody’s competing for the next biggest feature and thing, so that adds to it. You were talking about Alpine and other stuff. It used to be the case that, oh, I used Alpine for other projects rather than WordPress, and I know a little bit about this, or I’ve used this other tool for other things. Now you learn about languages and markup that are uniquely exclusive to WordPress that you cannot use anywhere else. So what’s the incentive?

Carl:
That’s true too. Yeah, all the markup too. That’s a really good point. All the markup.

Marcel:
What are you going to do with that markup outside of WordPress? So you’re investing all of this time just for this specific platform. That was not something that used to be the case back then as well.

Carl:
Yeah, no, I love the markup. That’s a really good point. Just all the output that the block editor does is not reusable.

Marcel:
And it’s hard to learn. You’re not going to be able to write a markup without actually rendering a block, seeing what the outcome is, and just copy-pasting whatever. You need to reuse that. That’s not something that you just type as a programmer into language.

Carl:
No, no, exactly. That’s on my mind a lot because I think about the health of the project, and the health of a project is people joining. It’s not just being old farts that have been here for a decade plus, like me and Zach. I think you all have been there for close to a decade or over a decade, so you need new people.

It’s cool to make it sexy, but also if you make it non-comparable to anything else, there are no transposable skills, so you have to be a really good developer, which wasn’t also what WordPress was about. A lot of people learned programming through WordPress. Now again, same thing. I think it’d be really hard to learn programming through WordPress now because of that.

Mike:
It sounds like a lot of overhead, and that’s a barrier to entry if you’re going to be a contributor or developer. You’ve got to find that sweet spot where things are challenging and interesting, but not so annoying that you’re like, I’m just not even going to bother. That’s basically what it comes down to. There was this client; we were trying to fix a sending mail issue. For whatever reason, the hosting wasn’t sending out the emails. So we configured this plugin to use Gmail. We looked at the steps and it was like, wait, it’s way too long. You have to go into Google Cloud and do all this. He was like, I don’t want to do this. So then we debugged it. That’s a good example. When you see that mountain of friction, you’re just like, ah. You don’t know if the payoff is going to be worth it. It makes it far less likely that you want to get involved.

Zach:
A potential solution to that would have been installing the SendGrid plugin and adding an API key, which would have been two steps instead of the

mountain of steps the other way. Now Google and Yahoo have added so many sending restrictions on email. You have to be very careful about what services you’re using, making sure you have all of the DKIM things set up, all of the sender policy framework stuff set up. Otherwise, you’re not going to get through to people because Google and Yahoo now just block things that aren’t verified sources. All these things add layers of complexity to our job that weren’t there before. Google and Yahoo deciding to make a change to how email works across the entire internet affects us as developers, and sometimes it’s really hard to keep track of everything.

Carl:
You brought up a really great point. Why wouldn’t they just have used Alpine.js? I know that for the interactivity API in particular, the reason they didn’t was because it couldn’t do server-side rendering of directives. So they used preact instead. The thing here that we’re talking about is that WordPress as a project has gone from being just PHP with some opinionated decisions around how you build things with PHP to being PHP and JavaScript with very opinionated decisions about how you build things.

Carl:
But even if it’s preact, you don’t even know that unless you dig in, right? It doesn’t use the same API; it’s its own thing. Everything is WP dash; it’s its own thing you have to learn. That’s more of what I was trying to get to with the Alpine. It’s about basically forcing a lot of non-reusable knowledge on developers. There’s nothing wrong with having non-reusable knowledge, but if you’re just constantly doing that, it makes barriers to entry. It doesn’t make it appealing; it doesn’t make it interesting to work with necessarily. On top of the whole stigma of PHP and all that stuff, it’s just you’re like, oh yeah, we just reinvented everything. We don’t even actually use HTML. I love the markup thing now. I can’t unthink it, but it’s like, oh, you thought you’d use HTML? Actually, no, this is not HTML; it’s just block markup and there’s no parallel elsewhere.

Marcel:
There’s also places where you do CSS on JSON files, which is also very interesting.

Carl:
Oh my God. Somebody showed me that. I was like, why? Oh my God, no, you’re right. I forgot about that. I memory-holed a lot of this stuff actually. I’m slightly traumatized and I’m just like… This comes from a person that loves learning. I’m just like, but why is this getting so complicated? I think it’s really healthy. I think part of refactoring is to take a look back and be like, okay, why is this so complicated? But I just feel like we’re constantly adding more and not taking anything back. Now it’s getting in the realm of, like we said, everything’s its own thing and it’s just WordPress. It’s not even JavaScript. I’m not a React expert, but I hear all the time from React people that even the WordPress React stuff is not typical React. So it’s really confusing for me that we’re doing this and making it so inaccessible because even a React developer can’t just be like, oh, okay, this is just standard React. It’s not, and they have to learn what the WordPress React flavor is as opposed to just everybody else’s flavor of React.

Marcel:
I totally agree. We are sort of recreating every library and framework that there is, prefixing it with WP Dash, and then in the React world, just renaming the functions in the libraries we import. Nothing more than that. If you look at the source code, it’s exactly the same React source code that you have in other projects, and that doesn’t make sense. But I wanted to also suggest that we talk good things about WordPress and developing in WordPress.

Today we have all these options and variations, and the fact that people tend to complicate quite a bit when it comes to building a simple theme or plugin. At the same time, the more seasoned experts have the opportunity to keep things simple. There is still plenty of space to solve the most common problems with just simple PHP files, with just simple CSS solutions. We can use whatever JavaScript flavor we want to solve those problems. Even though there are recommended and opinionated ways, it is still a platform that allows us to implement whatever we want to do. If you want to bring in Alpine to a project, you can. If you want to bring other product frameworks to a project, you can. You’re still very much free to do whatever you want. There are no hard restrictions. There’s no downside to it.

That’s what I think is on the positive side because it is still a ground where there’s a lot of adaptation and a lot of inclusive libraries that you can bring in and make it easier for you to work in the way that you know how to solve problems. It is still not at the point where we have to go with a certain way; otherwise, it will not work, it will not compile, it will not run on WordPress. I think WordPress and WooCommerce, for that matter as well, are still the best platforms to offer those options and offer those variations to clients and fix these problems the way that we know that they’re fixable, either by just changing a couple of PHP lines, by just doing JavaScript, or by doing a React component on the front end.

We can definitely dive a little bit more into React in other episodes, but I think React, in the sense of having dynamic HTML on the front end, is fixing some of the problems that the basic HTML and PHP had back in the day and that contribute to a more performing website. Then again, everything gets complicated because of the way they were introduced, the lack of documentation, and the constant sprinting that it seems to be happening when it comes to adopting these features.

Carl:
Yeah, I agree. You can. I always use Roots Bedrock, so I’m always bringing in PHP libraries from elsewhere and it’s still possible to do that. I’m always thinking about accessibility. You can always bring Alpine. It takes seconds. It’s more about how do we make it more accessible? It’s a constant battle, right? It’s a constant battle of, okay, we want to be challenged. Especially more advanced developers want to feel like they’re building something. It’s fun to reinvent a wheel, but at the end of the day, you also have to maintain this for a long time. You have to be really clear about why you’re doing it because WordPress is an old project and it’s not going anywhere.

So you have to think about, will we want to be maintaining this in 10 years? That’s really important too. I think that’s part of the reason why they bring the libraries in, but I think it’s really important to think about why you’re doing this and the knowledge and the APIs and the ways, especially as you’re making it more developer-focused, how you expose these things to developers is really important because you don’t want to end up in a place where it’s just a really specialized skill set. Then it’s really hard to bring in people. It was already somewhat challenging to bring in advanced developers into WordPress before. It’s on my mind. But I agree. I think WordPress is always great for bringing in the tools that you want. You’re never limited to do that. If you want to do something, you can always do it. That’s really good for that. There’s never a wrong place. If you figure out you need a specific tool, there’s no reason not to bring it in. WordPress will never get in your way to do that.

Marcel:
Correct. If you need a Python script to run somewhere, you can do that. You can put it into a project. If you need to bring React in a way that WordPress is not using React, you can do that. Have you guys seen the WP admin redesign and what’s happening in the future to that side that is still very much PHP-controlled of WordPress?

Carl:
I haven’t. I haven’t.

Marcel:
We just got a glimpse at WordCamp Porto that happened this past weekend. Everything is going to be—well, I’m not sure if everything, but at least the things that we saw, the media library and some of the preview of media and documents and post editing—everything is going to be React-based. Everything is going to look like what you have right now in WooCommerce, the experimental page to add a product or to edit a product. It looks very stripped down, but the WP admin is going to be all about React components and JavaScript and state management and client-side computing and performance.

So if we follow all the conversations we had so far and we look into the future and see WP admin and what’s coming, it’s going to get a lot more complicated.

Carl:
Well, exactly. It looks really nice.

Marcel:
As it should, right?

Carl:
Yeah.

Zach:
I just don’t know how easy it will be to extend.

Marcel:
It won’t. It will be the exact same challenges we have and still have with WooCommerce. It’s going to be less extensible. It’s going to be harder to figure out how to adopt things that we used to adopt. I guess the number of those famous plugins that begin with “classic something” are going to have a very good time.

Mike:
So you can always turn it off, right? That’s the good thing about WordPress. You can always usually turn off the new stuff

and keep your legacy familiar, good feeling, warm, fuzzy…

Zach:
Maybe we’ll see a classic admin plugin.

Carl:
Is that what you’re saying?

Marcel:
It’s definitely already created somewhere. There’s a repo with some code already being updated as new beta features come up. But what’s the whole point of it? Also, I’m asking you guys about the WP admin and we are seasoned developers. I’m pretty sure if I ask other people and most of these things that are going on and being planned and screens that we are able to see and we can actually download and play around a little bit, these are all known things to the general developer public. It would be great if we could get a glimpse of how things are. You can always go there and look and see the source code and check out the GitHub and the messages and all the issues and whatnot, but that’s a lot more difficult than if you were invited to participate in a way that they explain why certain decisions were made.

Once it’s out and we get in contact with it, we’re going to throw our hands up and say, how the hell is this extensible? Where did my stuff go? I’m not going to adopt it. Then we’re going to fight as we fought Gutenberg for other reasons, but also for the reasons of not being able to work with it for long years. Then it’s not going to be adopted at the rate that people thought it would be adopted, but it’s going to get even crazier for sure.

Carl:
We’ll see where it goes. I think I’ve been saying this for a couple of years, but I think it’s getting more important. I feel lots of features, very little focus on developer experience, and that’s an important thing. If you’re going to revamp completely how things work and make it more complicated, it’s worth thinking of how can we make it easier for developers to get to the point where they can do the things they want to do?

Marcel:
We are required as PHP developers, or for the most people who have been working with WordPress since the beginning or very close to the beginning, we are definitely more and more required to learn JavaScript in a way and to use it in a way that we were using PHP until now. That is the most confusing part for me. Although I’ve gone through some of the work and some of the understanding of how the JavaScript will replace most of the front end, it is still very strange to me how I’m going to use JavaScript to perform tasks that PHP files are still doing or did in the past. How can we suddenly have to be forced to learn JavaScript in a way that it’s going to possibly hinder us from doing our jobs properly?

Mike:
I mean a developer’s job is already quite difficult and challenging. To add more to the plate of never-ending growing stuff doesn’t feel like the best idea. Especially when you said, imagine someone who is maintaining the future repositories, the React stuff, and you tell someone their task is to clone this other repository that already exists and then run a search and replace to prefix the functions. You’re going to question, is this a good use of my time? At least I certainly would be.

Carl:
Yeah, I mean I think as a developer, this is something I noticed with my friends. I am 41 now. My friends, when they got closer to their forties, they’re like, I’ve learned enough. I don’t want to learn anything new anymore. I’m like, you’re in the wrong profession buddy. To not learn anything, you should go learn some COBOL and work at a bank and then you’ll never have to learn anything else ever again. But in the world of front-end and web development, it’s always changing.

I think, like I mentioned, it’s really confusing when you’re like, why did we reinvent the wheel here? That happened on the PHP side still. I don’t really understand why we had to invent an HTTP API. I found a serious performance bug in there a couple of years ago that I fixed. That would not have been an issue if you used Guzzle, even if you just had it namespaced. They used to do that. So it’s very hard because it’s one thing to force developers to learn new things. I think developers are constantly going to have to learn new things. I just think you should be respectful of what you’re asking them to learn. Exactly.

That’s a lot of what I think about is I love learning, but half the time I’m like, I’m going to wait as long as possible to learn something the WordPress way until I need to because I know that this is not transposable anywhere. That’s not respectful of my time as well. It’s not about just your time maintaining it; it’s your time learning. I want to learn things that I feel help me grow as a developer, not just… I’m more interested in that. If I have to do it to solve a problem, I will do it.

But I won’t go out of my way to learn something. I think you have to be respectful of your time because there’s so much stuff to learn now. It’s getting more complex, not less. I think all of us here are full stack developers, so there’s a lot to learn out there. You have to be mindful of how you’re using your time to learn things, and I think that’s really important.

Even with the WordPress stuff, I try to be like, okay, I will learn it one day, but I’m not going to go out of my way to learn it now. Especially actually speaking of being respectful of your time too is when the APIs aren’t stable either. You don’t want to learn something and then it’s going to change. You’re going to get the rug pulled. That doesn’t feel great either. You have to balance it out. I understand the need to modernize everything and make it client-side, but developers also have to respect their time and their skillset and make choices that make them feel like they’re learning and becoming better developers.

Marcel:
With that said, Zach, you asked at the beginning, what are our plans in terms of subjects to bring in? I think we can sum up by saying we’ll try to demystify a little bit all of these more modern things that are coming out and give some tips and orientations. All of these new APIs that are coming out, we will eventually end up using for client work. We can share how our experience was with that and bring in other people who have been using those APIs and tools and other solutions for the problems we all have been solving for all of these years in different ways. I think that’s going to inspire other people to think differently or to add to their repertoire or just to listen to how we can contribute to adopting all of these new things that are coming.

Zach:
Well, it’s awesome. I look forward to listening to those episodes and learning myself. If any of you who are listening have ideas for topics that you’d like to hear any of the four of us cover, we would love to hear them. Send them to Bob. Hashtag Bug Bob. We started that here. We’re going to keep it going. Hashtag Bug Bob.

Carl:
Hashtag bug Bob.

Zach:
Let him know that you have ideas for things you’d like to hear about on the Woo DevChat.

Carl:
Bug him in person in Turin.

Zach:
You can bug him in person during WordCamp EU. That is coming up very shortly. There will be a Do the Woo table there. There will not be a Zach there. I tried. Couldn’t make it happen this year. However, I believe, Carl, you’re going to be there. I would imagine Mike and Marcel, you’re probably both going, right?

Marcel:
We are going, yes.

Zach:
Yeah, so I will have all the FOMO and you will have all the fun. I hope all three of you enjoy the event, but definitely hashtag Bug Bob does apply in person as well. Feel free to walk up to Bob with your ideas, no matter how crazy they are. In fact, the crazier the better. Bob loves that. We would love to hear from you with feedback on how we’re doing and the things you’d like to learn about. This podcast is for you. It’s not just for all of us to sit around and wax poetic about the things. We love that. We do enjoy doing that. We want to know what you want to learn and what you’d like to see covered or if you want to participate. We are always looking for guests.

With that being said, welcome Marcel and Mike to the WooDevChat.

Mike:
Thank you.

Marcel:
Thank you very much.

Zach:
I think this is going to be a lot of fun. Maybe every once in a while we’ll have to change it up and join each other’s podcasts so that we can just keep people guessing who’s going to be on what.

Marcel:
That would be amazing.

Mike:
Sounds awesome.

Zach:
I appreciate both of you. Where can people get in touch with you other than hashtag Bug Bob?

Mike:
I have my own website, WPbullet.com, which is currently being redesigned. That’s how people can get in touch with me. I’m also on LinkedIn. I’m not really that active on Twitter, but I should be. I hear it’s a lot of fun there. Or it’s X now, right? People still just call it Twitter though, right?

Carl:
I feel it’s really quiet now.

Marcel:
It’s very quiet. People can get a hold of me at my website, MarcelSchmitz.com. I go by schmitzoide on all social networks. That’s it.

Zach:
Awesome. Hopefully, you know where to find Carl and me by now, but if you don’t, I am at ZStepek pretty much everywhere. Carl?

Carl:
I can be located on LinkedIn. I’m trying to connect with everybody there. I’m still on Twitter at TwigPress. I don’t see a lot of interactions there anymore, so I’m not that active on social media, but usually it’s all Carl Alexander. GitHub, all those places. It’s at Carl Alexander. That’s where you can find me.

Zach:
Okay, well thank you all for being here. Here’s to the future of the Woo DevChats and I hope to see you in person soon.

Mike:
Cheers.

Marcel:
Cheers.