Welcome to the seventh edition of the Jukebox podcast from WP Tavern. My name is Nathan Wrigley. Jukebox is a podcast all about WordPress, the software, the events, and the community. Every month, we’re bringing you someone from that community to discuss a topic of current interest. If you like the podcast, please share it with your friends. You might also like to think about subscribing so that you can get all the episodes in your podcast player automatically. And you can do that by searching for WP Tavern in your podcast player, or by going to WP Tavern dot com forward slash feed forward slash podcast. You can also play the podcast episodes on the WP Tavern website, if you prefer doing it that way. If you have any thoughts about the podcast, perhaps the suggestion of a guest or an interesting subject, then head over to WP Tavern dot com forward slash contact forward slash jukebox. Use the contact form there and we’d certainly welcome your input.

Okay, so on the podcast today, we have Ajit Bohra. Adit is a keen advocate of WordPress having used it, and committed to it, for many years. He’s a full stack developer working at Lubus, which is based in Mumbai, India. His team works with WordPress as well as offering solutions built with Laravel and React. He’s on the podcast today to offer up his opinions about the near future in WordPress and why he’s confident that the project is moving in the right direction.

To make matters easier we break the podcast up into three distinct sections starting off with Gutenberg, we discuss where the block editor is at right now and what Ajit sees as the benefits of a block based approach to content building. We go into some concrete examples of why Ajit thinks that the block editor is preferable to the classic editor, as well as discussing some of the projects that he’s been working on to enhance the editing experience for his team and the community.

We also talk about the pace of development and whether or not it’s keeping up with the expectations of WordPress users. We then move on to a detailed conversation about full site editing, which is going to play a pivotal role in WordPress’ utility, going forwards. The power that it will often non-technical users to build out their entire site is an exciting prospect, but right now it’s still a work in progress. Ajit talks about why full site editing is needed to compete in the CMS market, as well as how block patterns will make site building much easier in the future.

Finally, we get into the subject of WordPress’ need to move towards a future in which React is playing a vital part in the software’s core. Why does Ajit think that the project needed to move away from a PHP based platform? After all, it was easy to work with and people have become very familiar with how to build sites using their PHP skills. It’s a case of having to keep up, and as Ajit says, he thinks that you have to unlearn to learn.

We briefly discuss the resources, which Ajit used to up-skill. Websites that he frequents and courses, which he recommends should you wish to take the plunge?

In parts, the audio is a little choppy. In fact, this is a second pass at recording this episode, but I felt that the message contained within it, it was well worth publishing despite that, and I hope that you do too. 

If any of those, the points raised in this podcast resonate with you, be sure to head over and find the post at WP Tavern dot com forward slash podcast, and leave us a comment there.

And so without further delay, I bring you Ajit Bohra.

I am joined today by Ajit Bohra. Hello, Ajit, welcome to the podcast. 

Yeah, hi Nathan. 

It’s very nice to have you on, as we typically do at the beginning of the podcast, we’d like to allow our guests to introduce themselves and tell us a little bit about their journey and how they came to be involved in WordPress. So, it doesn’t matter how far you want to rewind your life, but if you could paint a little picture of how it is that you’re on the podcast today. When did you start using WordPress? What is it that you’re doing currently? 

Yeah, so I am from Mumbai, India and on a professional front, I own an agency where we provide WordPress based solution to the clients. It has been quite an interesting journey for me because I have been someone who always hated computers and programming.

And it’s exciting that today it’s my passion for everything. I started working with WordPress when it was around version one x. We had that blue, white screen where we didn’t have the sidebars at an early stage of WordPress. It’s been around 10 to 12 years of experience working with WordPress. I’ve worked with a lot of technologies being Drupal, being Joomla, being DotNet.

And then eventually I fall in love with PHP. Probably I got into PHP because of WordPress. So I can say WordPress was the entry point for me to get into the PHP world. There was a time when I was just working with WordPress, I was not a community guy or something. Then I was hearing a lot about the meetups, WordCamps and everything, and then happened to be part of the local WordPress community.

And then started visiting the WordCamps and I think, and I was like, damn, I have been missing out on a lot of interesting stuff. Like this is something I have missed out. And then for three, four years, there was a lot of travelling around the country, visiting international WordCamps trying to speak at a couple of WordCamps and local meetups. It was quite an interesting journey. And then at one point, after visiting this WordCamp, I was like, damn, I’m not even contributing to the WordPress, and it’d been 10, 12 years. I’ve been in the industry and I’m being like a leech where I’m just taking things from WordPress. That was the point I was looking to contribute to WordPress. I was like, okay, now I want to learn something new, because there was a shift in WordPress. So Gutenberg become an entry point for me to learn new things and also contribute to the, contribute back to the WordPress community. So I started with one refactoring PR and from that things accelerated and start contributing more PR’s to looking at different aspects of development, helping people get into the Gutenberg bandwagon. And then I started writing the notes for the weekly editor meeting. So quite interesting thing happens. And then finally I’m into the WordPress community. 

Thank you. That’s really interesting. So you go back really a long way. Community is obviously a part of this discussion, but we’re really going to focus on everything post Gutenberg.

When we started communicating about this podcast episode, we decided on three different sections and that’s how the episode is going to be chunked today. We’re going to talk initially, just about Gutenberg and have a conversation around what we think of it and where it is and how the community has been involved with that and so on. And we’re going to move on to a discussion of full site editing, and what we think about the state of play there. And then finally talking about the future of the way that WordPress will be built from the coding side. We’ll talk about React and how that’s impacting things. So we’ll kick off the conversation with Gutenberg.

Now, obviously you just mentioned that you got yourself involved in the community side of things around Gutenberg, and I’m curious because it does seem to be quite a divisive issue. On the one hand, we’ve got people who really enjoy using it and love it and find great pleasure in experiencing it. And then you’ve got other people who are finding it to be a difficult transition. They wish that perhaps that it hadn’t come along and things had continued with the old TinyMCE implementation. What is it about Gutenberg that you enjoy so much? Why do you feel that it’s a good thing that the community has done pushing Gutenberg into core in WordPress five. 

Before I say I enjoyed Gutenberg, I have to admit that I was the guy who hated Gutenberg. When it was introduced, I put it that, right now I have to learn everything new and this is going to be difficult. So I have a love, hate relationship with Gutenberg. Eventually came to a point where I was like, oh damn, I’m enjoying it.

I can connect with a lot of people because I have never been a Javascript guy. I knew React, I knew other stuff around it, but I was more comfortable with PHP and I can see a lot of people are comfortable with PHP for them. So there is a resistance saying that, okay, now we have to learn new stuff. And also problem is it changes a lot of things. How we have been approaching things. You have to change the mindset. You have to have that bloggers mentality. So that’s the reason why people have a resistance because you have to unlearn, to learn new things and people are not ready to unlearn. That’s the biggest problem. When they look at Gutenberg, they are still with that process of PHP base with a system where you have this hierarchy of files and everything. Which has changed.

So Core is trying to provide a backward compatibility and also making things smoother for people. At the one end where developers are trying to move, push the envelope. There are people, they are still holding their old envelope and saying we want things this way. So that resistance is creating the problem, but when you take a step back and look at things, things look a lot more, good. If you look at it from a positive side, you end up learning something new. Like if it was not Gutenberg, WordPress community will have not ventured into JavaScript and React. That’s opening door for you. If you think from a developer perspective, it is adding a lot more feathers in your cap.

Okay. Previously, we are working with the PHP. Now you’re working with JavaScript. Now you’re working with React. Now you can create desktop apps because React and JavaScript helps you create desktop app, mobile app also. So Gutenberg just becomes a reason for you to enter into different dimension and a different nuance.

And that’s the reason why I love it because Gutenberg gave me that push to go an extra mile, which is a technically helping me on my personal professional front also. And if I look from a WordPress perspective, like previously, we were doing certain things and we were quite convenient and comfortable with all this stuff, but at a certain time, and I used to wish, if we can do this thing a different way, because let’s accept it now, even if whatever we were doing with PHP was comfortable, easy for us because we have been doing that for 10 years.

And after 10 years to tell someone, you have to do it that way, you are going to have resistance. But there are a lot of problems that we had since last 10 years, there was a lot of fragmentation of implementations. You have this custom meta boxes, a lot of other stuff, you just want your content and it look good, and user-friendly, you want to give your end users a UI UX in a way where they can control their content. And we ended up creating… it’s a lot mess, because somewhere someone using XYZ page builder, some are creating their own page builders. Technically everybody wants ‘what you see is what you get’ real editor because everybody’s struggling.

So down the line, we are admitting that whatever editor right now we have is problematic because we are trying to stuff in ten different plugins to make it work in a different way. Not do any extra work on your content editor to have that kind of experience. That means there is a problem with the implementation that we have in Core, and I guess Gutenberg just takes care of those problems. If you look at one problem is shortcodes. Like we have shortcode we have widgets, there are ten to twenty different implementation that you can have on your content editor, but when the block editor steps in, that is one implementation that rules out everything, you no longer have those clumsy shortcodes.

Even if you look at the shortcodes, people have these shortcode builders, and that is where block editors coming in with features, where you no longer have to do all those teams because you have a UI, you can configure that your end user can use. So from an user perspective, it is a very good product. Like I’ve been working with a lot of publications and brands. They love Gutenberg. They have been transitioning their old system, to the new system because their marketing team, their content team enjoys it. Even the small to mid-level clients, when they see Gutenberg, they are like, why we didn’t have this previously.

You look at the WordPress user base. We have different kinds of people we can categorize. One are the people who are very hardcore developers. And then there is a second category. I call them the people who do tinkering. They are not hardcore developer, but they happen to get into development accidentally by tinkering with WordPress. And then we have the third category of implementation. So if you ask me the people who do implementation jobs, their job is to take team, take a couple of plugins and make everything. They are the happiest person on the earth when it comes to Gutenberg. But if you talk about people who do a lot of tinkering, they find it very difficult because they have not been a hardcore developer. They have learned PHP the hard way. They have invested a lot of time figuring out tinkering and they are kind of a semi developer. So they find it very difficult for them venturing into JavaScript. It’s like, oh, damn, this is a different game. But if you look at hardcore developers, they know PHP and everything. And if you look at the ratio, we have a lot more people who are doing implementation jobs on WordPress based website. We have way more people who are a semi developer, they are not hardcore developer, but they tend to make things work for WordPress. And if you look at hardcore developer, that ratio is very low. And the resistance that you see from the people is from these other two categories. 

I’m just wondering, just maybe to illustrate your excitement about it. If you can bring to our attention, some example, perhaps of a block, something in use inside Gutenberg that you feel encapsulates why it’s so good. It could even be something that you’ve built yourself or a third party thing. Just something that you think… this represents a really great to use of what Gutenberg is capable of. 

So I will do that in two. Part one is if you look at previously how the Classic Editor works, we had all the content on one page, and I always hated when I have to move content. If I have four paragraphs, if I want to move the last paragraph to the top, the only thing that I have was copy and paste. But with the blocks, I can just move around the content. And that’s the beauty that I love about blocks. And second is, there are a lot of shortcodes and everything. That’s gone. That’s the Core thing. And if you look at building things, the only option that you have is, custom post types. If you want to segregate content and create different types of content, the separation is only at the level of content, but what if you want to give your content and pull together different templating and everything? That is not possible with the classic one, because you have to do a lot of meta boxes in them.

So I remember working on a couple of projects lately, where we have this campaign building tool where a theme needs a lot of banners on their website. So . Just by creating a custom post type and utilizing the power of Gutenberg, you are giving a marketing team, a tool where they can create their own banners. Like it can be a mashup of a cover block with headings, with image and buttons and boom, they have their own banner tool. Like you don’t have to do lot of extra stuff. All the building blocks are there. You have to just assemble them, give it to your users. They can just generate all the banners on the fly. So that’s the beauty. 

Yeah. The ability to have everything inside the one UI, all of the settings for all of the different bits and pieces that you may be building your page with as opposed to having to go and tinker with settings in a different part of WordPress is quite compelling. It makes things significantly quicker.

When we began our conversation, talking about what we were going to discuss in this podcast. You mentioned that you’re involved personally, I don’t know whether this is something to do with the business, or if it’s just personal playing, you mentioned that you were involved in building some experiment, mental things in the block editor. Just curious if you could tell us what it is that you’ve been up to? 

Yeah. So I have been planning on that lately, but I haven’t been getting time, but there are a lot of experiments that I have worked on. There’s a lot of blog blog blog, we have been talking around. So I have named the project, blah, blah, blocks. It’s a sarcastic name, yeah blah-blah-blah blocks. It is not something of a blog pack or anything. It is not intended to create a library. It is just experimental to let people know that this is something that you can do and build. So whatever random ideas that I get, or the random ideas I get from a team while working on different projects. So just write it down that this is something that we can build someday, or maybe we can, kind of experiment. So there are a couple of things that I have been experimenting with blocks. So blocks are not the only thing because a lot of people have been looking at Gutenberg from a block perspective and blockss have been the poster child of Gutenberg. But block is not the only capability that Gutenberg provide. Apart from blocks, if you look at it, we have patterns, we have variations. We have a rich text format, which have a lot more potential, even block extensions is another category where people can explore. Like we always look at block extensions. There are only a handful of developers that I have been following who are actually, kind of creating block extensions, where they are extending the capability of the core blocks and everything. So that’s an interesting area. So I’ve been working on a few of them. I remember creating a couple of blocks where, for example, if you add color code to your editor, so it just displays a hashcode. So that is a format that I have worked on, which create a color token out of it. Like how you look into your color editors. If you paste a color code into a vs code, it will actually display a small icon with the color of it, it will actually show the preview. So that kind of format that I have created, and I’ve created this format for a sound seed format, where you can attach an audio on top of text and display a play button. And lately I’ve been working on another experiment where you create a list or using a list block, and what if you want to convert that list into a to do list? Where it stores now, like you can literally click on it and it will strike off the item. For example, if I’m creating a conference checklist you know, this is a speaker application checklist, and these are the five items that you need to do. And I want to give user capability that they can just click on it and it was strike off and it was store into that local store saying that, okay, this item is completed. I’m working on that block extension also with kinds of convert the list block into a to-do list block. It’s like without creating a new block, we are just utilizing the list block and extending it. So these are the different experimentations that I’m working on. So just to give an idea, and food for thoughts to people out there that there’s a lot more that you can do with editor, you can just be creative.

I do love the idea of building on top of the core blocks and changing and adapting them in the way that you’ve just mentioned with your to-do list. Really interesting. You mentioned block patterns and I have to say that this is something I’ve made really good use of. I’m extremely confident that the block patterns are going to become something that many people will make use of. In my case, I repeat a similar format in content that I produce. It has a title, it’s often got an introductory paragraph and I find myself retyping the same thing over and over again. Or at least I did. And so I’ve been creating and saving away block patterns, which essentially create templates for my work. And I can see this being useful all over the place, having complicated layouts and saving things that you wish to use over and over again, and possibly even a marketplace that could spring up around block patterns were pre-configured things that many people would like to have, hero images and so on. And I can just see a few of those starting to come into the marketplace. There seem to be a few players trying to get their block pattern packs, If you like… noticed. I feel this is a really good area for growth in the future.

So I have seen Justin Tadlock has been doing great work, that block pattern he has been doing and putting it up, putting up on Twitter. So there’s a great lot of pattern he’s worked. I loved it. I remember working on a project recently where the team needs a lot of landing pages for black Friday sale. There is always a struggle between, the content team, the design team and everything. But patterns are the lifesaver. You just talk to the design team, create certain patterns, give to the content team and they are happy editing the content. There is a separation of concern also design team works on the patterns, content team gives them like, this is the content and this is going to be, and then finally give it to the content editing team. So I guess with patterns, we are enabling people to have certain kind of process and protocol, which was not possible with the classic editor, because everything was mashed up.

Moving on staying with Gutenberg and the whole block editor, but now talking, instead of talking about the functionality of it, just talking about the implementation of it and how it’s come about over time. There seems to be right at this point, we seem to be at some kind of inflection point where people are discussing whether or not it’s going in the right direction, whether there’s enough involvement. Whether people’s voices are being heard. Perhaps people are saying it’s going too slow, it’s not moving at the speed of commercial page builders. And I’m just curious what your thoughts are on that. Now it may be that you don’t have any thoughts on this, but I’m just interested to know whether you think the project is going in the way that the community wants it to go. Perhaps you’ve got some personal experience of that. But also whether you think it’s going only in the direction of a tiny subset of people who have the time, energy or capacity to actually tell what it is that they want to be built in the future. 

So I’ve seen a lot of comparisons have been drawn Gutenberg with the commercial page builder, but there is a fundamental difference because I find this comparison a little floored. Because when we talk about commercial product and community projects, they work in a different way in a different fashion, and how decisions are being taken. In a commercial project, if we talk about any page builder they have you know, a limited set of decision makers. They will just put out the product at the pace they have decided they will have a clear guidelines. So everything is isolated in terms of development. So they’re now going to work on core features and being able to put across and all of these commercial products have taken like four to five years to stabilize themselves, roughly around four to five years for Gutenberg also. And Elementor has taken a lot more time where they are right now. Like it’s more elegant way before. And if we do the plus and minus, we can see, they have invested lot more years into the development. So obviously they are going to be way ahead of what Gutenberg is right now. 

If you look at it, initially, all this page builder started working with the PHP and everything. And eventually later on, now they are going into the JavaScript, where Gutenberg itself started with the JavaScript itself because they knew they want to give an experience on the client side, and that JavaScript has to come into it. 

It’s also curious as well, the way that these different commercial page builders are set up, I think allows them to iterate more quickly. Not only do they not have to worry about the backwards compatibility of core, they only need to worry about the backwards compatibility of their plugin and the ecosystem that they’ve developed. But also they have a smaller audience and so they can probably poll them and ask for their opinions and be a little bit more decisive about what it is that they need to build. Whereas I feel the core project, it does have to be backwards compatible, and also it has a giant audience of, let’s say 42% plus of the web. So they need to be very mindful. And it’s something that I keep saying over and over again, when the audience is that large, it must be very difficult not to have paralysis about what it is that you’re going to introduce and so on. So yes, I can. Understand that. 

Let’s move on. Let’s change tack a little bit. And let’s talk about full site editing. Now full site editing, we’re in a really difficult moments because we know that it’s coming. We can sense that it’s coming. There are bits of it, which are now available to us, but it’s very limited. We can modify only certain bits and we’ve got a roadmap, and so we know what’s coming. I’m just curious as to what your thoughts are on full site editing. Do you think this is an important milestone for WordPress? 

Yeah, this is definitely an important milestone because that is always a comparison between the page builders that we have in market. And most of them cater with the full site editing where if you can control the header, footer, global styles and everything. And that’s the reason where people feel Gutenberg is lagging. And once the FSE comes in, I guess it is going to, kind of also reduce the fragmentation that we have right now between the PHP. If you want to create a theme, okay, you can create blocks, but you don’t have complete control of your website in terms of block-ifying everything. But when FSE comes into picture, you are in complete control of the website. So right now it is mainstream where a lot of people are actually using it on the live site. There are also certain people, which are, they are experimenting with the FSE. But again, if you look at the FSE, the mindset of the people is still in the old implementation of themes. You know, they still think that hierarchy and everything, but FSE changes a lot of stuff. I have seen a lot of videos, a lot of people talking about how it is changing or creating a confusion on FSE, and confusion only happens when you see something new and you expect that new thing to be functional and similar to what you have seen past. It is new for a reason that there is going to be a different implementation. And if you honestly ask me, FSE is doing what actual themes were supposed to initially do, like the job of theme is to give you a foundational thing where you have a base layout, you have your design system place where you say that this are my fonts, these are my colors, and this is my master layout. And this is the building. Now you just craft your content and create all this stuff. So FSE actually enables you with that. If you look at classic themes, there is a lot of stuff that developers have to do. Like they have to look after not creating and handling the global styles. Looking after the topography, looking after all the designs and layout, like they have to do a lot of work on the code. But with FSE it is like, you don’t focus on this stuff. You just focus on the design elements. As a theme developer your job is to actually work on the look and feel, not on the small nitty gritty. They are giving you the building. So for me, Gutenberg is more of, laying down a lot of processes for the community, how they work, in terms of how you craft your content, how you write your content, how you design your themes. It is redefining the processes. So rather than looking at Gutenberg as just a way to edit your content, we should look at it in a way where we have a certain process and protocol in place, how we use our WordPress website or content editing experience. And we should look at Gutenberg as a way to redefine those processes. We can say, now we are getting a different set of processes, which are more refined and which are more optimized. We have to just unlearn the old process and get into the into the new process. And that is going to open up a lot. 

Yeah, that’s a really interesting point. And I was trying to think about wordPress from the perspective, this was the other day. I was trying to think about what it would be like if I was fresh to WordPress and I’d never used it before. And also I had no experience with any kind of software. I’d never had a website. I have no expertise in anything to do with putting content on the web. And so I was trying to think to myself what, what is it that I would want. The full site editing what’s promised is exactly what I would want. I would want to be able to set things up, set some basic global styles, pick some fonts, pick some colors and so on, and then to be able to create my menu. And I would be wanting to do that in one place. In one part of the overall software, I wouldn’t want to be having to go over to this different section, modify things, save things, go back and check things. I would wish to do it all in one space. And I think you’re right. The idea of modifying the workflow, if you like modifying the workflow so that everything is easy for non-technical people out of the gate is the goal so that we can continue to democratize publishing, but we are in a transient period where the old things have to be adapted, perhaps replaced and the new things have to be accepted and it’s going to be a bumpy ride, which of course leads to the problems that we’ve got at the moment where there seems to be confusion, and in some cases, people are a little bit, perhaps even upset because of the way things are happening. But I guess change is going to be needed in order to make the content management system usable by people in the future. By having one interface for everything. 

And a lot of people think that FSE is going to kill themes. Let me tell you it is not killing themes are not going anywhere. Technically FSE is helping team developers. If you look at any marketers, you can see if you pick five different themes, those five different themes are done in a different way. They have a different set of page builder. They are either tied up with a third party page builder, or they have their own custom page builders. They are using customizer. There’s a lot of work they are doing just to get the basics of theme setup done. But after FSE and it will make theme developers and theme shop jobs easy, because now they don’t have to maintain their own version of, maintaining design systems and everything because Gutenberg is I like, I know you need all this stuff. So let me give you all this in core and standardize this for you. So Gutenberg is going to extend the rise the overall process of themes, and rather than working on those core sectors, you just focus on theme. If you want to create a university theme, so you create the color palette, you create the theme, you create, you just define the font size into the theme json files and you ship the required patterns that are required for a university website. So you are now working on the content. So rather than building your car from the ground, you are saying, okay, I have my engines and bonnets and everything ready, I just need to work on the body color and the interior. That’s it. So you are getting semi build cars for your themes. So themes are there. They are not going to die.

And my phrase throughout the day when I started working on the Gutenberg is you need to unlearn to learn. And that is the important when there is something new out in the industry where you are working, you have to often unlearn, because you cannot sit there and say that we have been, using this for 10 years. It’s okay. 10 years things have to redefine. 

Yeah, good point. One of the things which causes the disagreements in the community or the upset that we’ve got from time to time is simply that this can’t happen overnight. It can’t be just okay, finished in the background. Let’s just throw it into the next version of WordPress. It does need to iterate. And I liken it to imagine I’ve got a house and I wish to have an extension built onto the side of my house to increase its size and make my house more desirable. There isn’t some sort of Jack and the Beanstalk magic beam that you can throw in the ground and sprinkle water on it, and suddenly I’ve got an extension. I have to go through a process of watching the house being built and everything gets messy. There’s dust everywhere. Bits of my walls need to be knocked down to make it happen. And eventually after a period of time, when everything is finished and tidied up, the house is better, but there was a process that I had to go through, which was a little bit difficult in the meantime. I don’t know what you think about that analogy, but that’s the way I’m thinking about where we are right now. We’re in the process of building something, adding something new. It’s difficult, but it has to be difficult. 

Yes, because if a lot of people have argument that it should have been plugin. It was a plugin for quite a good amount of time and which kind of, enabled the team to gather feedback. But eventually you someday you have to put it in the core and you cannot wait for five years and say that now we are going to put it into core and test. Because the moment you add things to the core, one is it increases the adoption and you get like a lot more clear feedback. It is very crucial for it to land in the core. And even if you look at it, it landed in the core with a small set of features where they only focused on the editing experience. Like they only replace the editor. I can say that, no, it is not perfect, but yeah, you have to do it someday. People say you should stabilize it because if you talk about stability and perfection, they are very subjective. If you take 10 people and ask a view about Gutenberg, I’m sure a lot of people will say, this that is perfect. A lot of people with that, this has just started. Perfection, stability are very subjective, a lot of, a lot more people, a lot more voices, and we can never say what is perfect. People complain about these things. I guess period is going to be slow. There are two reasons. One, there are a lot of people involved. There is some central decision making, but still it is a community project where a lot of people talk about it, they write issues and have people speak about it. It is shared on the Slack. So it kinds of creative friction and resistance. We have a set plan, but to move slow, it is a community project. We have to take care of good compatibility. So for example when working on the FSE, FSE is going slow. While working on a team realizes that there are a lot more changes that needs to be done into the core API’s. If you look at the blocks API, they are lot more flexible. Like we previously didn’t had option for design tools you know, defining padding and everything. So they realize, okay these options are required on the block to enable FSE. There is an argument that team will have thought about implementing this, but you cannot startup, adding ten different options in first place. Like a lot of commercial page builder, they work in a template fashion where they add all the option in one go. But in Gutenberg approach, if you see we are starting with a minimal set of features and flexibility, we are not giving all the options to user. They are slowly added and iterated in a way where things are flexible. Things are backward compatible and then they don’t even create a bloat also. So that is the reason why processes is a bit slow because we are looking for creating something, which is long-term sustainable. 

Yes. Good point. I guess if you are after this being quick, then it’s likely to be poorly implemented if we rush it, but I can well understand the arguments of people who feel that the pace of change is not necessarily as, as quick as they would like, but I guess we just have to just hold on and see what the future holds.

There’s an interesting quote that I’ve written down from Justin Tatlock, who obviously is with WP Tavern. He wrote the following in a blog post, which I’ll link to, he wrote, "If WordPress must become more complex for developers to provide end users with this much power", he was talking about full site editing, he says, "I can live with that". And I think that’s my position as well. 

Okay. Let’s move on to our third and final section. Now, obviously in the future, WordPress has decided to become more JavaScript focussed. In the past, very much since the beginning, it’s been all to do with PHP and template files and all of that stuff. Now we’re moving into an era where new languages, new capabilities, new ways of doing things are possible. And so we’ve entered this new era where React is taking over the heavy lifting for many of the things in WordPress. It does by definition, a little bit like we talked about just previously, it does mean that if in the future you wish to really get involved with WordPress and it’s core, you will need to have those skills, sounds to me like you have embraced that and you’ve decided to learn those things, but I’m just curious how you think the WordPress community is handling this and what you have done to upscale yourself and learn these new things.

So I still see a lot of people complain about it and they have resistance because they are thinking from the perspective of (?). And I have been a fan of Laravel also, I’ve been active into that Laravel community, which is more a PHP focused, but I have seen how they embrace different technologies and where, when you are into different communities, you learn a lot.

So it’s good for WordPress developer also to hang out in different communities, in different technologies, also different perspective, and also help you grow. So a lot of people who say that they don’t want to move to the JavaScript. Even if you have to admit we are not doing PHP also fairly good. We are using PHP in a limited scope because I see a lot of PHP developer, they are using PHP at a basic level. They are not moving up. And if you look at the core. The core has been slowly modernized in terms of PHP also. There was a time when there was a lot of functional programming, but we can see a lot of OOPs has been implemented. We have a lot of classes and even the way things are handled is way far better than what we had in the previous version of the WordPress.

If you look at the developers right now, even on the PHP front also, they need to redefine. You need to step up your game. You need to get into the modern PHP. You need to start embracing the OOPs. You need to start embracing the dependency management. So I’ve seen a lot of PHP developer also who have resistance, who don’t even want to go and use Composer also to maintain the dependency.

So these are the category of developers who eventually have resistance. Like they work on certain set of things and they are comfortable in there. The only problem is that comfort backfires you because that just stops your growth. And that’s exactly the reason I have been extensively working in the past year, improving myself on the PHP front also, but when JavaScript jumped in. So I remember Matt saying that learn JavaScript deeply. So at that time I was like, at some point I will learn JavaScript, and I’ve always been comfortable in the PHP area, but there are a lot of interesting stuff happening in the JavaScript arena. And I was like some days, some day, but eventually Gutenberg happened.

I started getting involved in it and I was like, let’s address the elephant in the room. So I started now, I took three months, a break from everything, isolated myself, and I started reading stuff about it. I was like, damn, this is interesting. Not bad. Once you start loving things and stop hating it. Now, you open a lot of doors and don’t look JavaScript from the perspective of WordPress. The biggest mistake that we can do is as a developer is if you are working with WordPress and saying, now WprdPress needs JavaScript, I need to learn. No, rather look at it from a distant, different perspective and say that, now there’s a lot of JavaScript that is in general being used outside. Which you can explore and embrace. So there might be case when you start working on React or JavaScript and WordPress being the reason, and you ended learning a new skill. And then you realize, oh, now you can work on a lot of stuff outside of WordPress also. So WordPress become the teacher who’s pushing you to learn something new, and that completely changed things for you. So right now I’m working extensively with React, NodeJS, working with clients and on the complex projects where I remember working on a completely different mobile app built on React, native Electron app, a PHP generation tool, complete written on NodeJS. All this was impossible previously. Gutenberg being an entry point for me to enter into this, it helped me.

I have seen a lot of developers who embrace the JavaScript and React because of WordPress. And now they are into a full-time React and JavaScript development. They are enjoying working with different kinds of projects. They are working on their pet projects. They are ended up getting paid better because of their increased skillset in React and JavaScript, because React and JavaScript have a good market share. There are a lot of jobs out there paying well for you. So there are a lot of reason for people to learn React and JavaScript, not just because WordPress is introducing it, but it is going to help you. 

Staying on the WordPress side of JavaScript, I’m just wondering if you can perhaps explain some solid examples of where you feel WordPress will improve because it is using JavaScript instead of the way it’s been doing things with PHP in the past. It always strikes me that we’re always told, learn JavaScript deeply, it’s the future and so on. But very often that doesn’t come along with an argument as well, this is the reason, here’s a concrete example of why it’s going to be. 

So the reason if you look at WordPress core itself, and if you look at the entire history slowly, slowly, there are a lot of components that are slowly been transitioned to the JavaScript. There’s a lot of JavaScript that is written into the core, core base. And so far people have never realized we are interacting with a lot of JavaScript code in core. But that’s all behind the door. It has never been the front facing into the developer arena. So we never realized that we are working with JavaScript. So even if you look at customizer, I don’t think a lot of people use customizer, but there is a lot of JavaScript involved when you’ve worked with customizer.

If you work with the media uploader, there is a lot of JavaScript involved. There is a backbone JS that is behind the scene, which you can use. So already there is a fragmented, JavaScript implemention in the core. So we have been slowly, already adopting JavaScript. Even if you use jQuery, I just put it in the category of JavaScript because you are just doing a library. So we are using JavaScript already, but rather than using a different mashup of them, like using backbone or different things, now we are standardizing and seeing that this is how our JavaScript is going to work. So for me, again, even if I look at, from a development perspective, in terms of JavaScript, you’re also putting a protocol and you’re getting a standardization, like rather than using this and 10 different things. We are giving you a set of components, a set of helper functions and everything which you can use and build your own stuff. So Gutenberg is a foundation for the front end experience and also for the backend development and processes also, like here they are giving you blocks and everything to craft your content. In terms of front-end usage. In terms of development usage, they are giving you as a theme builder, they are giving a themes for the right person. And if you go further, down a lower level, they are giving you this handcrafted components and everything with React to build things. 

Eventually this is going to spread across the code base. I feel we are just started with the small section. We can see that it is going to span across the different area of admin area. WP admin is going to be invaded by the React and JavaScript. Because it is going to be re-used. So it’s better that, start embracing the JavaScript and React right now, rather than waiting for another two, three years down the line and then realizing, oh, now we have to like, you actually get into it. 

With that in mind, what do you make of projects, ACF blocks is one that comes immediately to mind, where, people are trying to create a nice bridge, the opportunity for people to do things in the way that they’re accustomed to. So just to illustrate ACF blocks enables you to create your own blocks, but instead of getting involved in the whole, that the whole in inverted commas, normal way of making blocks, you can do it with reference to PHP and ways that you’re perhaps familiar with. Do you feel that these are a good stop gap? They bridged the gap in the period of time where people are learning these skills or do you think actually it would be better if everybody just learned the stuff and moved on. 

So I guess they are good for people who are transitioning. You know, like they are good for now. It’s not a clear yes or no, if you talk about ACF blocks and because I have seen projects, and even there are projects where I recommend people like, go ahead and use the ACF blocks. You don’t have, that tailored requirement for creating something from scratch. It’s a fairly small requirement where you just want certain input fields and that works. So in those cases, ACF is good. Even if you’re transitioning, it’s good. But if you look from a long-term perspective or if you have very complex requirement, I have seen that ACF blocks don’t because there was one project where we have been working on where ACF blocks, but if you wanted to create a more controlled user experience, not using lots of other components. And eventually we have to deprecate the ACF implementation and that create everything from scratch and creating a handcrafted blocks using the core functionality.

So if you have to just evaluate when ACF blocks fitting and when you have to use core blocks, but eventually core blocks are going to fair well because they always have access to the newer API. You have more control over it. And if you look at how APIs are transitioning, like if you look at the initial version of block APIs, that was a lot of code that you had to write. But now you write less code to create those blocks. You have CLI tools. You have a boilerplate APIs, very light have to just couple of lines of code to get things done compared to writing almost 5,200 lines in past. So I guess the development path on which APIs are working is also. If you look at the sort API, if I want a background support or gradient support on that, I just do define the support. But previously have to implemented that entirely. I guess start learning how to build blocks from scratch. All the third party solutions are a patchwork on top of what we have. So like it, it might be controversial, but yes. For me, it feels like a patch. You’re like patching something. You’re just trying to run away from something saying I’m going to use. 

My final question then it leads perfectly on from what you were saying, it feel that the need to learn React, for example, is essential going forward. I don’t know if you have any resources that you’d like to mention or places, perhaps websites, anything in fact, which you found to be useful, which we could add into the show notes, which might enable people to get to the good stuff quickly.

Even before people start working on the React, they need to get their basics clear in term of JavaScript. And there is a lot of arresting tutorial available out there, but I will, I like to recommend the one by the Wes Bos. Wes Bos have two JavaScript courses. One is JS for everyone, and JS for beginners. They are quite good material on the ES6 and everything on the build tools. Like it’s a one-stop shop for you. You know, just get those two courses and you will learn everything in depth. Apart from that, if you are looking for resources on YouYube, there’s is a good channel by Net Ninjas. This guy goes a lot of interesting stuff. Like you, you don’t have to pay those, those are free of course. So these are the two good resources where you can learn ES. For the React also that you can refer the official documentation. They are best. Just go through it. If you are a person who likes to refer videos again, Wes Bos have a lot of videos on it and other resources that can decode. It is on Egghead. This is a free course. It is available there. You can just visit the website and learn the React for Beginners. He has epic React course, which is a more elaborated and detailed course, which you can go through. These other resources that you can refer, which are very good in terms of investing your time.

Thank you. We’ll make sure to add some of those links into the show notes so that people can access them. But I’ve run out of questions that I would like to ask today. I’m just mindful that we would people, if they wish, if they’ve listened to this podcast and they would like to get in touch, I’d like to provide them with a way to do that if you’re willing. So if there’s any best way of getting in touch with you, it could be Twitter or an email address or whatever you feel comfortable sharing. Go for it. Let us know. 

People can DM on Twitter, like a lot of people already ping me on DM for our doubts, queries and everything they have around Gutenberg. So it’s been a couple of years I have been already helping people on the Twitter with the right resources if they need, or they have any doubts on queries around Gutenberg. It’s @ajitbohra.

Ajit, thank you so much for coming on the podcast today. I really appreciate it.