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 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)
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.
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.
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.
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:
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.
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.
Gutenberg is also built with modularization in mind. Instead of writing a single big package, it's being split into smaller packages:
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:
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.
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) brining 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.
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.
--
Post originally posted on Riad's Blog
