If you're already familiar with WordPress, you're probably used to its content editor based on TinyMCE. Creating content in WordPress did not really change for many years now. But with new competitors gaining more and more attraction like Medium, Ghost, Wix, Squarespace, WordPress decided to build a new Editor called Gutenberg (After Johannes Gutenberg, the inventor of the printing press).

Gutenberg is a big change, it's a completely new way of creating content. Instead of writing inside a unique rich text input, you add blocks of various types (paragraphs, images, videos, embeds, quotes, lists….) to compose your post's content.

The impact of this change on WordPress Users is not negligible. Content creators will have to learn about blocks, plugins authors will create custom blocks and templates, theme authors will style blocks… There are several posts out there talking about these changes and their impact on the users but very few talk about how Gutenberg is changing radically how we develop WordPress itself (aside from the frameworks battle, VueJS VS React VS Preact)

1- Developing in Github

Usually WordPress development happens in WordPress Trac, through tickets and patches, while featured plugins usually happen in GitHub, with a separate repository for each Featured Plugin. This repository is removed once merged into Core. Gutenberg is being developed as a featured plugin on Github. While this is not the first time GitHub is being used to develop for WordPress, contributors are starting to question whether GitHub is more suitable for longer-term development and not only for featured plugins.

One of the last featured plugins merged into Core was the WP-API. Contributions to the project diminished a lot once the plugin was merged, and Trac has proven to be a huge barrier at entry for several developers already familiar with GitHub and its niceties.

2- Single Page Application?

WordPress is a classic PHP application where most of the UI rendering is done server-side. JavaScript is mostly used to some DOM interactions to server-side generated HTML.

While It's very unlikely that WordPress becomes a single page application tomorrow (or in the next months), Gutenberg renders its UI in the client (similarly to the Customizer or the media library). It's a Single Page Application built inside a regular WordPress Admin Page. In SPAs, the browser doesn’t reload for every click you make. Interactions feel fluid instead of abrupt. Notably, interactions can feel faster.

Gutenberg also leverages the REST API to fetch Data from the server. It's the first project in WordPress Core using the recently merged REST API. Several other will follow.

3- Modern JavaScript

Despite the fact that WordPress recommends PHP 7, it is still supporting PHP 5.2 and thus being written with PHP 5.2 compatible code. But unlike PHP, JavaScript transpiling is a thing, which means we can still write JavaScript code in the last versions (ES2015+ or more commonly called ESnext) and transpile it to ES5 code compatible with legacy browsers.

Gutenberg is leveraging this possibility and being written in ESnext + JSX which has a big impact on the JavaScript developer Experience. WordPress already has some JavaScript build setup based originally based on Browserify and updated recently to use WebPack (Thanks Adam). Gutenberg takes things further bringing babel compilation (using the babel-env preset) to this setup.

4- UI Framework

We can't talk about modern JavaScript without touching on the UI Framework discussion happening in WordPress. Backbone has been the framework of choice of WordPress for some years now, ever since its introduction with the Media Library. But it has proven hard to maintain and extend.

Pushed by the Gutenberg Project, WordPress contributors are exploring alternatives which include a Framework agnostic approach that could be summed up like this:

  • Picking a UI framework for WordPress Core. Gutenberg is using React for now, but this decision is not final yet.
  • Provide an abstraction layer allowing Plugin Authors to use the UI framework they are most comfortable with to extend WordPress UI

Good discussions around this have already happened and are still ongoing in the WordPress Core JS meetings, I encourage you to read the meeting recaps if you're interested in the subject.

5- Testing & Linting

Modern Javascript also brings with it its plethora of new tools.

For testing purposes, WordPress followed the jQuery path in using QUnit. While it's still possible to continue using QUnit with ESnext JavaScript code, the setup would be complex and new actors in the market are changing the way we write, run and debug tests making QUnit feel like the stone age of Unit Testing. One of these tools, Jest is being used by Gutenberg.

Linting and formatting are the other aspects of Modern Javascript Development seeing a lot of changes and updates recently. JSHint no longer support ESnext features properly and WordPress is moving to ESlint for this purpose. The Gutenberg Team and the Javascript Core Contributors also talked about using Prettier to format code, but opted to postpone for now. Using prettier could change the JavaScript Style Guidelines drastically.

6- Modularization

Gutenberg is also built with modularization in mind. Instead of writing a single big package, it's being split into smaller packages:

  • @wordpress/components: Generic UI components reusable outside of the Gutenberg context
  • @wordpress/i18n: Internationalization utilities
  • @wordpress/element: Abstraction on top of the UI framework
  • @wordpress/date: Date formatting and manipulation utilities
  • @wordpress/blocks: Module providing utilities for registering and building blocks
  • @wordpress/editor: Module representing the WordPress Editor's page

These modules are being built and proven in Gutenberg for both Gutenberg and WordPress. This approach has resulted in the new WordPress packages repository. The goals for this repository can be summed up as follows:

  • Provide WordPress reusable modules for use in several WordPress Core Components and Featured Plugins
  • Build autonomous packages reusable outside of the WordPress context
  • Engage better with the broad JavaScript community
  • Bring consistency across several parts of WordPress by reusing modules (The components module represents a WordPress pattern library)

Also one of the most important aspects of the modularization is the way it improves and eases contributing to WordPress. WordPress is a huge application with thousands of files, it's overwhelming for new contributors and it's very easy to get lost in all these files and components. Using a modular approach addresses this issue by splitting the application into smaller autonomous bits with a clear and well-defined API. It's easier for contributors to chime in and understand specific autonomous modules than it is in a unique huge application.

7- UI and styling

WordPress UI has not been significantly updated in years now. With Gutenberg, this could change. While it's not trying to be a complete UI refresh, it paves the way to other parts of WordPress by providing reusable UI elements to build a lighter, more "modern" UI.

Having a set of well defined UI components can help ensure accessibility stays a priority across all parts of WordPress. If one component is made accessible, this accessibility will then apply wherever the component is reused.

Gutenberg is also leveraging some simple SASS features (variables and mixins) bringing consistency to WordPress styles as well. For instance, if you take a look at WordPress's code base, you'll notice more than 50 shades of gray used and dozens of shades of blue. The same could be said for media queries thresholds. Gutenberg contributors have helped make this consistent by narrowing down a canonical list of colors, and refined list of fewer breakpoints.

Even Icons are being updated. Gutenberg is still using the WordPress Dashicons, but thanks to the recent changes to the browser support for WordPress, Gutenberg is now leveraging SVG icons instead of Icon Fonts.

8- Documentation

While documentation is not a solved problem yet in the project, Gutenberg is trying to bring new ideas to the table, such as Documentation in Code as well as the possibility to use and demo the code right inside the documentation itself. Gutenberg is currently using a self-made documentation tool similar to React Storybook but more customizable to match the WordPress Documentation Styling.


These are exciting times for WordPress with big changes coming to the WordPress Development Experience. We could reasonably argue that these changes are likely to demand some investment in the current WordPress developers, to help them learn new tools but "What bring us here, won't get us there". Most of these changes help modernize WordPress Development, they align with the broader Web development community, and all in all are likely to bring new contributors to WordPress, and lower the barrier to entry.

Thanks Joen Jasmussen for the feedback

This post is brought to you by the new Gutenberg Editor

5 thoughts on “ How Gutenberg is changing WordPress Development? ”

  1. It is truly exciting that so much work is being put into bringing modern development practices—even cutting edge ones—into WordPress. But in regards to WordPress moving to a Single Page Application, I want to remind that WordPress has had a single page admin application since WordPress 3.4: the Customizer. It has been evolving and improving a lot over the years, with a rich JS API and some of the most drastic improvements coming in this upcoming 4.9 release. So while I am really excited about the new developments coming with Gutenberg, I don’t want the existence of the Customizer to be overlooked or forgotten (since it wasn’t mentioned in this post). That being said, I am looking forward very much to integrating Gutenberg into a revamped Customizer v2 that builds on top of the solid foundation we already have in this part of WordPress while incorporating the new tools and processes that are being developed with Gutenberg.

    1. Thanks Weston for your comment, and you’re totally right! In addition to the customizer, we could consider the Media Library as an SPA too. Correct me if I’m wrong but, I especially wanted to emphasize the fact that Gutenberg is proving and using the Rest API extensively which has not been done before.

      Sorry, not my intention to tarnish the awesome work you all have been doing in the customizer and other different parts of WordPress, just put the light on what’s different with Gutenberg. I’m updating the post to clarify the sentence suggesting Gutenberg is the first SPA in WordPress.

      1. Thanks! I’d consider the Media Library to be a component more than an SPA, but I suppose the distinctions can be fuzzy.

        We also have a feature plugin for Customizer endpoints for the REST API, but we haven’t had a chance yet to use it yet. I’m looking forward to moving away from admin-ajax in Customizer v2!

Leave a Reply