Understanding Modern JavaScript in Gutenberg Development

Reading Time: 4 minutes

Before we get into developing a block for the new Gutenberg editor let’s take a breather to understand some of the modern JavaScript in Gutenberg development.

What is Modern JavaScript?

Way back in the year 2009 JavaScript released ES5. ES5 is short for ECMAScript 5. ECMAScript is the standards JavaScript follows. So for our purposes ECMAScript === JavaScript.

Modern JavaScript refers to anything ES6+. With the release of ES6 in 2015, JavaScript switched to yearly releases. That makes ES7 in 2016, ES8 in 2017, and ES9 in 2018.

Then there’s ESNext which always refers to the features available in the next version of JavaScript. Think of it as your bleeding edge features.

What about JSX?

JSX is another story. JSX is a syntax for writing HTML like structure within JavaScript. This allows for creating more human-readable markup. And is a must if you’re going to be nesting any number of elements.

Here’s an example of creating <h1 class="greeting">Hello, World!</h1> without JSX:

return wp.element.createElement(
    {className: 'greeting'},
    'Hello, world!'

And now using JSX:

return (
  <h1 className="greeting">
    Hello, world!

Both of those output the same thing, but the JSX version is much more readable and easier to nest elements.

Note: You might notice className is being used. That’s because class is reserved in JavaScript.

React and Gutenberg

The Gutenberg editor is built on top of React.

React is a JavaScript framework maintained by Facebook and Instagram and one of the leaders in the JavaScript space.

At its core React is a JavaScript library for building user interfaces. React lets you create custom components which are essentially highly customizable HTML elements.

One example component you’ll see used a lot in Gutenberg block developlment is the <RichText> component. Which is a custom component for rendering a rich contenteditable input for blocks.

Protecting WordPress Against React Updates

If you were following the Gutenberg project at all last year you might be aware that the project nearly switched from React due to its licensing terms.

Luckily Facebook saw the light and shifted their terms allowing the WordPress project to stick with React as the framework of choice. But the team behind Gutenberg is taking precautions to make sure changes to React or switches to other libraries doesn’t break backwards compatibility in WordPress.

In my, admittedly basic, understanding the wp.element library in Gutenberg is actually an abstraction layer on top of React.

That makes it possible for WordPress to have it’s own way for making use of the createElement and render functions from React. And if it were ever necessary switch it to a different library.

Browser Support for Modern JavaScript

Not every feature used in modern JavaScript is going to work cross-browser. To get the best browser support you’ll need to compile your modern JavaScript into browser-compatible JavaScript.

Babel is the go to compiler for taking next-gen JavaScript and JSX and outputting it into browser-compatible JavaScript.


Webpack is a build tool for JavaScript applications that can take all of your dependencies and bundle them into a final output application. In the case of Gutenberg webpack could be used to manage the various dependencies required and output a build of your final JavaScript and styles used in your custom blocks.

Libraries in Gutenberg

One of the really useful tools when developing blocks for Gutenberg is making use of existing JavaScript libraries in the project. Some are required (wp.element and wp.blocks) when enqueueing scripts. While some are optional (wp.editor, wp.components, and wp.i18n to name a a few).


The wp.element library is an abstraction layer atop React that gives access to the createElement and render functions. This is a required dependency when building custom Gutenberg blocks.


The wp.blocks library gives access to the registerBlockType function. The registerBlockType function is for registering the definition of your custom block to make it available in the editor. The wp.blocks library is required for developing blocks.

Every block starts by registering a new block type definition. The function registerBlockType takes two arguments, a block name and a block configuration object.

– Gutenberg Handbook


The wp.editor library gives access to the BlockControls and RichText components. As mentioned earlier RichText can be used to give users a content editable input in the editor. BlockControls gives your block access to a toolbar of icons in the block editor. wp.editor is an optional library.


Much like wp.editor the wp.components library is useful because it gives you block access to a ton of predefined components that can be used within your block. Things like tooltips, popovers, and more can be easily used as components. wp.components is optional.


The internationalization library for Gutenberg let’s you easily make strings translatable using the __() function within JavaScript. You don’t have to include a text domain as you would in PHP because the build tool will automatically use the namespace/block-name when generating a .pot file. wp.i18n is optional.

Begin Update 10 / 31 / 18


The wp.data module in Gutenberg has the goal of making data organizing and sharing simple enough for small plugins and scalable for much more complex integrations. It’s similar in function to Redux, with distinct characteristics of its own. Look for a post delving into wp.data soon.

End Update 10 / 31 / 18

Wrapping Up

You don’t have to use modern JS when building Gutenberg blocks. You can build blocks entirely with ES5. But you’re going to have a better time working with modern JS.

Modern JS is a lot to learn. There are some very useful tools being developed to make getting started with modern JS and Gutenberg easy. The quickest I’ve come across so far is Create Guten Block.

Feel free to drop any questions or comments in the comments below.

Pin It on Pinterest