Tooling for Block Development
Getting started with custom Gutenberg blocks is fairly straightforward today thanks to the WP CLI 'scaffold' command. Running it sets up a WordPress theme or plugin with a 'blocks' folder containing the PHP, base CSS and JavaScript required for a custom block.
The one drawback noted is that the generated JavaScript relies on the older ES5 syntax rather than modern ESNext. ESNext allows for more concise code and makes it possible to write JSX inside block code.
create-guten-block as an Alternative
Another option is the 'create-guten-block' tool by Ahmad Awais, which ships much of the boilerplate out of the box, including Webpack and ESNext support. Its setup is fairly straightforward and resembles Create React App. It has been used for a handful of custom blocks already and the experience has been positive.
Practical Friction in Block Work
Comfort with this stack tends to come from having a foot in both WordPress development and React development. With one foot in each, building blocks that combine the two technologies feels natural. Had blocks been built on something like Angular, the attempt might never have been made at all.
A second common annoyance is working on a block whose code is actively changing:
Every time you reload Gutenberg, you’ll get the “This block appears to have been modified externally…” message because the markup of the block has changed.
The reason for the error is clear, but it slows you down.
The ACF Approach
Advanced Custom Fields' block support takes a different route, one that feels like a bizarro-reverso version of WordPress. Its model — building blocks with just PHP and templating — is closer to what WordPress might have done in a normal world, with third parties supplying the React-side extras.
