When I first started working with the Block Editor a few years ago, I wasn’t excited about it.

As a user, I was lukewarm about it simply because of change (I’m not a fan of change 🤷🏻‍♂️), though I’ve come around to it and don’t mind the new writing. Sure, it has its learning curve (especially as someone who has used WordPress for for 15+ years) but I still use it every day as a user and developer and am working on developing the muscle memory that comes with that.

As a developer though, I wasn’t fond of it at all. There wasn’t a lot of documentation and whatever was there was always changing. Whatever was working for this release may not work in the next release. That gets frustrating after a while and it’s is enough to demotivate you to step away from building things for it.

Plus, coming from someone who generally works on the backend of software, getting started in a completely new paradigm was tough. Not because I mind learning new things (can you work in this industry and not expect to learn new things?), but because however I may learn to do something now isn’t going to necessarily work later and this was happening at an incredible pace. The inconsistency was a problem.

That seems to have settled a little bit. Sure, there are still things that I’m sure I’ll hit on in this series of posts that aren’t going to work whenever future me reads this and I’m not particularly a fan of experimental packages but here we are.

Regardless, fast forward a few years, and I’m far more comfortable building blocks that I once was.

  • I don’t and won’t claim to be as good as many of the frontend developers who are building and doing amazing things with the Block Editor,
  • I’m not satisfied with the fact that there isn’t yet a consistent standard for how to organize project files (perhaps this will come in time, but we’ll see).

But that doesn’t mean I’m not at a place where I can’t get on with whatever may be needed from a block development standpoint.

  • There are ways we can organize things to make our work easier. And that’s good enough for me.
  • I know the basics and I know how to use the reference material.
  • And if all else fails, there’s plenty of people online who are able to help or point me in the right direction.
  • I also think it helps to try to figure out a mental map of how what we’re doing in JavaScript maps to what we do in PHP (or how it may be similar).

With all of that said, though, I thought it might be worth holding myself to the task I mentioned in the previous article on writing better the Block Editor tutorials.


Before going any further, I want to reiterate something that I’ve already shared:

Ryan Welcher and Learn WordPress are two places that seem to be the most popular for learning block development and I want to make sure they get the credit they deserve.


Starting with this post, I’m going to go write a series of articles in which I’ll share my experience as something like “a backend engineer is learning to build Block Editor blocks.” I’ll go from the very rocky beginning to the full functional ending.

Maybe it’ll help some of you along the way. And if not, at least it captures my journey.

Continue reading