How Gutenberg is changing WordPress Development?

Gutenberg WordPress Development – If you’re already familiar with WordPress, you’re undoubtedly familiar with the TinyMCE-based content editor. For many years, the process of creating content on WordPress has remained mostly unchanged. However, since new rivals like Medium, Ghost, Wix, and Squarespace have grown in popularity, WordPress decided to create a new editor called Gutenberg (After Johannes Gutenberg, the inventor of the printing press).

Gutenberg is a significant shift; it’s a whole new approach to content creation. Instead of writing in a single rich text input, you create your post’s content using blocks of various sorts (paragraphs, pictures, videos, embeds, quotations, lists, etc.).

This modification has a significant impact on WordPress users. Authors of plugins will develop unique blocks and templates, while theme authors will style blocks… There are numerous blogs out there discussing these changes and their impact on users, but few discuss how Gutenberg is fundamentally altering how we create WordPress (aside from the frameworks battle, VueJS VS React VS Preact).

Developing in GitHub (WordPress Development)

WordPress development is generally done through tickets and patches in WordPress Trac, whereas featured plugins are usually done in GitHub, with a distinct repository for each Featured Plugin. Once integrate into Core, this repository will be delete. On GitHub, Gutenberg is developing as a featured plugin. While this isn’t the first time GitHub has been use to develop for WordPress, some contributors are beginning to wonder if it’s better suited for long-term development rather than just featured plugins.

The WP-API was one of the final feature plugins to be integrate into Core. After the plugin was integrate, contributions to the project dropped dramatically, and Trac has proven to be a significant barrier to entry for numerous engineers who are already familiar with GitHub and its idioms.

Single Page Application?

WordPress is a traditional PHP program in which the majority of the UI rendering is done on the server. JavaScript is mostly utilize to perform DOM interactions with HTML generated on the server.

While it’s doubtful that WordPress will become a single-page application tomorrow (or in the next months), Gutenberg’s user interface is rendere in the client (similarly to the Customizer or the media library). It’s a Single Page Application embeds in the WordPress Admin Page. The browser in SPAs does not reload after each click. Interactions are flowing rather than abrupt. Interactions, in particular, might feel quicker.

The REST API is also use by Gutenberg to retrieve data from the server. It’s the first WordPress Core project to make use of the freshly integrated REST API. There will be a slew of others.

Modern JavaScript

Despite the fact that WordPress promotes PHP 7, it still supports PHP 5.2 and is thus code in PHP 5.2 compatible syntax. However, unlike PHP, JavaScript transpiling exists, which means that we can still create JavaScript code in the latest versions (ES2015+ or ESnext) and have it transpiled to ES5 code that is compatible with outdated browsers.

Gutenberg takes use of this by being built in ESnext + JSX, which has a significant influence on the JavaScript developer experience. WordPress already includes a JavaScript build configuration based on Browserify, which was recently upgrades to use WebPack. Gutenberg takes things a step further by adding babel compilation to this configuration (using the babel-env preset).

UI Framework

We can’t discuss contemporary JavaScript without mentioning the UI Framework debate going on in WordPress. Since its debut with the Media Library, Backbone has been the framework of choice for WordPress for some years. However, it has proven difficult to sustain and expand.

WordPress authors are researching alternatives, including a Framework agnostic approach that might be summarize as follows:

  • Choosing a user interface framework for WordPress Core. For the time being, Gutenberg is utilizing React, although this is not a final choice.
  • Provide an abstraction layer that allows plugin authors to expand WordPress UI using the UI framework that they are most familiar with.

Testing & Linting (WordPress Development)

Modern JavaScript also comes with a slew of additional features.

WordPress used QUnit for testing in the same way as jQuery did. While it is still feasible to use QUnit with ESnext JavaScript code, the setup would be difficult, and new players in the market are altering the way we create, execute, and debug tests, making QUnit feel like a relic of the past. Gutenberg makes use of one of these tools, Jest.

Linting and formatting are two more components of Modern JavaScript Development that have lately undergone significant modifications and upgrades. JSHint no longer fully supports ESnext features, therefore WordPress is switching to ESlint. The Gutenberg team and the JavaScript Core Contributors discussed utilizing Prettier to format code, but decided to postpone it for the time being. Using prettier might dramatically alter the JavaScript Style Guidelines.

Modularization (WordPress Development)

Gutenberg was design with modularization in mind as well. Instead of writing a single large package, it will be broken down into smaller ones:

  • @wordpress/components: UI components that may be use outside of the Gutenberg environment.
  • @wordpress/i18n: Internationalization utilities
  • @wordpress/element: Abstraction on top of the UI framework
  • @wordpress/date: Date formatting and manipulation utilities
  • @wordpress/blocks: Module that includes utilities for registering and constructing blocks.
  • @wordpress/editor: Module representing the WordPress Editor’s page

These Gutenberg modules have been test and confirm in both Gutenberg and WordPress. The new WordPress packages repository is the outcome of this strategy. The following are the objectives of this repository:

  • Provide reusable WordPress modules that may be use in a variety of WordPress Core Components and Featured Plugins.
  • Create self-contained packages that may be use outside of the WordPress environment.
  • Improve your interaction with the larger JavaScript community.
  • By reusing modules, you can provide uniformity to various areas of WordPress (The components module represents a WordPress pattern library).

One of the most essential elements of the modularization is how it enhances and simplifies WordPress contribution. WordPress is a large application with thousands of files; for novice contributors, it may be daunting, and it’s easy to get lost among all of these files and components. By dividing the application into smaller independent pieces with a clear and well-defined API, a modular approach tackles this issue. Contributors may more easily chime in and comprehend particular autonomous modules than they can in a single large application.

UI and styling

The WordPress user interface hasn’t been change in years. This may change with the introduction of Gutenberg. While it isn’t attempting to be a total UI update, it does open the way for lighter, more “modern” UI in other sections of WordPress by offering reusable UI elements.

Having a set of well-defined UI components may assist guarantee that accessibility is prioritized across WordPress. If one component is made accessible, that accessibility will be applied to all subsequent uses of that component.

Gutenberg also makes use of certain basic SASS capabilities (variables and mixins) to ensure that WordPress styles are consistent. Take a peek at WordPress’s codebase, for example, and you’ll see more than 50 colors of grey and dozens of shades of blue. Thresholds for media inquiries are the same way. Contributors to Gutenberg have worked to make this more uniform by narrowing down a standard color palette and a revised list of breakpoints.

Icons are also being updated. Gutenberg still uses WordPress Dashicons, however, due to recent changes in browser compatibility for WordPress, Gutenberg now uses SVG icons rather than Icon Fonts.

Documentation

While documentation is not yet a solved problem in the project, Gutenberg is attempting to include new concepts such as Documentation in Code and the ability to utilize and demo code from within the documentation. Gutenberg presently uses a bespoke documentation tool that is similar to React Storybook but more configurable to meet the WordPress Documentation Styling.

Conclusion

With major improvements coming to the WordPress Development Experience, these are exciting times for WordPress. We may argue that these changes will necessitate some investment in current WordPress developers in order to assist them to learn new technologies, but “what got us here won’t get us there.” The majority of these improvements assist modernize WordPress development, aligning with the larger Web development community, and, in general, are likely to attract new contributors to WordPress by lowering the entrance barrier.

That’s all for this article if you have any confusion contact us through our website or email us at [email protected] or by using LinkedIn

Leave a Comment