What Makes a Block Different From a Component?
Modern JavaScript development revolves around components — self-contained pieces of code that combine HTML, CSS, and JavaScript to render a defined layout or feature, such as an image carousel or a calendar. Components stay reusable by receiving their data through props from an ancestor or fetching it on demand. A block takes that idea one step further. It's the outermost component in a given hierarchy, which gives it a top-down perspective on everything nested inside it.
A block is precisely defined content — a paragraph, a bulleted list, a table. A concept, not a technology: it can be implemented in JavaScript or in a server-side language, and it should not be confused with web components, a specific technology collection that can be used to build blocks but isn't required. In Notion's notebook UI, everything you insert into a page — from plain text to a database view — presents itself as a block:
Consider the MVP analogy: if a Minimum Viable Product is the smallest building block of a launchable project, a block works like a Minimum Usable Component — the smallest unit of work that gives an application its coherence and character. It's a model where the interface between the block and the app also defines its identity: not an internal implementation detail but a distinct, portable feature.
Blocks Have a Reusability Problem
Components travel well: searching for “react component” on npm yields plenty of libraries you can drop straight into your project. The block ecosystem doesn't share that portability. Blocks in WordPress, Medium, or Notion are designed against each application's particular initialization and rendering contract, as well as the shape of the data they require, so migration between systems means rebuilding them each time from scratch.
The Block Protocol attempts to address this by defining a shared contract for both blocks and the applications that host them.
WordPress's history makes it a centerpiece in this story. Version 5.0 in December 2018 introduced the block editor, and the recently released 5.9 release expanded blocks to full-site theming with Full Site Editing (FSE), so a modern WordPress site is now composed entirely of blocks.
In a January 2022 blog post introducing the Block Protocol, Joel Spolsky argued that blocks should be reusable web-wide. Matt Mullenweg (creator of WordPress) quickly indicated agreement. Whether that becomes reality depends on who sees the protocol as a win.
Who Might Join the Protocol
Spolsky’s motivation comes from reviewing how different apps implement blocks for their own use — “[the implementation is] completely proprietary and non-standard,” he notes, and users are “limited to the features and capabilities that we had time to re-implement.”
That argument likely carries less weight with the commercial platforms he mentions. If Notion or Medium open their proprietary block tech to a public protocol, another site could clone their core experience overnight and pull away traffic. Their incentive is to stay closed for as long as the tooling itself gives them an advantage.
Still, several categories could genuinely benefit from portable blocks:
- Budget-conscious teams: Rather than pay a dedicated team to engineer blocks in-house, smaller organizations can use battle-tested blocks out of the box and spend time only on customizing what doesn't fit, ideally giving back to the open-source code they depend on.
- Apps with a widening UX gap: Any site that wants to offer the fluid, modern content experience of a Medium or Notion can code it from scratch — or reuse what others have already polished. This isn’t only about the small websites of the world. Mailchimp experimented with a block-based newsletter editor, but when I tried it, the interface was unclear and I stuck with the older split-pane composer. It’s conceivable that the same effort moves forward smoothly by reusing what work had already been done.
- Other content management systems: The popular Drupal Gutenberg porting effort shows there’s real appetite to port the WordPress editor elsewhere; a protocol that transports the blocks rather than the entire editor is a much lighter lift.
- Open-source initiatives: The npm ecosystem confirms that once there’s a clear distribution channel (npm, the Block Hub, or GitHub), a community will start publishing reusable blocks for the benefit of all.
WordPress As the Key to the Protocol
The consequences snowball if it’s not just anyone joining, but WordPress specifically:
- Instant block libraries: Every block currently made for the WordPress editor and Full Site Editing becomes available to other applications — regardless of whether those applications run on WordPress.
- Community capacity for building blocks: WordPress development is an effort-intensive discipline: the Gutenberg project took five years to deliver Full Site Editing, and the latest release alone brought together over 600 contributors, with retrospective meetings to tune the process. Few organizations have the infrastructure to manage that scale of shared resource creation on their own.
- The network effect of a big adopter: The Block Protocol is barely released and still a draft. WordPress backing it sends a strong signal: standards need contributors, and the more stakeholders have already committed, the safer the bet for everyone else to follow.
Why WordPress Would Benefit From Joining
WordPress has been on a modernization path since version 5.0, shifting from PHP-template rendering on the server to a more data-driven approach that fetches content from a REST API and renders it through JavaScript blocks. Version 5.9 extended this to layouts. Still, the platform remains closer to static than dynamic: layouts are generated in advance inside the wp-admin and saved to the database, rather than being assembled client-side in response to user actions.
That trajectory began in earnest in 2015, when Matt Mullenweg urged the WordPress community to learn JavaScript deeply. Joining the Block Protocol would continue that push toward a more modern, more flexible architecture. Here is what stands to be gained.
Expanding WordPress’s Role Beyond the CMS
WordPress now powers roughly 43% of all websites, but Mullenweg has set his sights higher, expressing a desire to reach 85% market share. Whether that goal is realistic is open to debate, but the question of what counts as a WordPress site is becoming harder to answer anyway. A stack might combine a WordPress backend with a React frontend pulling data through the REST API — is that a WordPress site? The label may not matter. As long as WordPress remains one component in the stack, it keeps growing.
The Block Protocol could let WordPress take on a new role: supplying blocks that power the frontend of any application, not just sites built on WordPress itself. That would embed WordPress more deeply into the overall web development toolkit and make it harder for the platform to become peripheral.
A Larger Contributor Base and a Two-Way Block Economy
If developers who don’t normally use WordPress start consuming its blocks, they’ll become familiar with the platform and potentially contribute to its open-source codebase. The math is favorable: JavaScript boasts roughly three times as many professional developers as PHP. A larger, more varied contributor pool would bring skills that WordPress currently lacks.
The block hub would work in both directions. WordPress blocks would be available to other platforms, and blocks built elsewhere could power WordPress sites. Consider a hypothetical: if Mailchimp joined the protocol and improved the blocks it uses for its newsletter editor, those improvements would become available to WordPress plugins that handle newsletter creation and delivery.
Decoupling the Editor From Gutenberg
Gutenberg is the engine that powers the WordPress block editor. It orchestrates interactions with blocks, taking output from a block’s edit and save methods to render HTML in the editor and persist it to the database. But nothing says the editor has to be bound to Gutenberg specifically. A block is a concept; Gutenberg is one implementation of it. The Block Protocol can sit between the two, connecting the abstract notion of a block to whatever engine happens to implement it.
That decoupling carries an interesting consequence for WordPress itself: Gutenberg only exists in the wp-admin area. The public-facing site never runs Gutenberg; it simply prints the HTML that was produced on the backend. With the Block Protocol, a client-side application could render blocks directly and react to user interactions, making the frontend genuinely dynamic for the first time.
The same approach could apply inside wp-admin on pages where Gutenberg hasn’t yet reached — settings screens, for instance. Rather than waiting for Gutenberg to expand, plugin authors could use the Block Protocol to render configuration blocks (calendars, maps, sliders, dropdowns, and similar inputs) with React on the frontend, adding only light PHP logic to save the resulting data into the wp_options table.
Embedding Interactive Blocks on Public Sites
The Block Protocol also opens the door to embedding fully interactive blocks on the public-facing site, for visitors to manipulate directly. Use cases include:
- booking calendars like Calendly for scheduling meetings;
- drawing tools, games, and other playful interactions;
- image manipulation, as anticipated in the upcoming media experience tied to full-site editing.
The author’s own GraphQL API for WordPress plugin illustrates the potential. It ships a GraphiQL client block for composing persisted queries, and a version of that client is embedded on the documentation site so visitors can experiment with the GraphQL server live. Under the Block Protocol, plugin users could embed the same GraphiQL block on their own public-facing sites, letting their visitors query their GraphQL APIs directly.
This capability also aligns with phase 3 of the block editor, which targets collaborative, co-authoring experiences similar to Google Docs or Dropbox Paper. Those tools let anyone visualize a document without logging in. A client-side that can render and interact with blocks would extend that openness: unauthenticated visitors could view content and provide feedback without ever entering the wp-admin.
Toward a Truly Unified API
Blocks were introduced to unify the many ways content could be added to a WordPress site — replacing widgets, shortcodes, and the customizer with a single mechanism. That unification happened on the UI side. On the implementation side, though, blocks still require a dual codebase. Dynamic blocks must render the same output both in JavaScript and in PHP, doubling the work for developers and adding a barrier for newcomers.
Existing proposals to eliminate that duplication have been made, but none has gained broad acceptance. WooCommerce has tackled the same issue for interactive blocks, though its solution is convoluted. The Block Protocol could offer a cleaner path: instead of reimplementing block display logic in PHP for server-side rendering, developers could choose client-side rendering, reusing the exact same block code on the frontend. Rendering strategy would become a per-developer decision rather than a forced architectural compromise.
As a side benefit, that arrangement could attract more React developers to WordPress — a goal the Gutenberg team has already acknowledged.
Leveraging External Innovation and Better GraphQL Support
Shared protocols tend to breed ecosystems that no single vendor could build alone, as seen with GraphQL. SpectaQL, for example, generates API documentation automatically from a GraphQL schema with minimal developer effort. A similar outcome is plausible for the Block Protocol. Projects could extract metadata from block-metadata.json and produce static documentation sites for blocks automatically — a task Gutenberg contributors are currently working on themselves. If that work already exists within the Block Protocol ecosystem, the Gutenberg team could adopt it rather than reinventing it.
The protocol could also resolve a long-standing pain point for GraphQL integrations with WordPress. Gutenberg’s block.json schema doesn’t declare the actual type of object or array properties, which breaks GraphQL’s strict typing. A block might declare a property as an array, but GraphQL needs to know it’s specifically an array of String. The Block Protocol directly addresses this problem, encouraging blocks to include an entityTypes field with full type definitions for any entities they handle.
"Where available, blocks SHOULD expect and handle an entityTypes field containing entity type definitions for any entities sent to the blocks."
Should WordPress blocks conform to the Block Protocol, their JSON schemas would carry the typing information GraphQL requires, letting WordPress GraphQL servers — both WPGraphQL and the GraphQL API for WordPress — retrieve block data cleanly, without workarounds.
Open Questions And Community Input
Whether WordPress actually joins the Block Protocol is not just a question of desirability; it hinges on several unresolved technical and strategic issues.
- Feasibility: Is integrating the Block Protocol technically viable within WordPress's existing architecture?
- Backward compatibility: Can this be accomplished without disrupting the millions of sites and existing block ecosystem?
- Cost-benefit analysis: Does the engineering effort and potential migration risk justify the gains in interoperability?
- Fundamental design: Is a universal Block Protocol even a sound idea, or are the requirements of different applications so divergent that they cannot be unified at the block level?
These are the core questions that need answers before any commitment is made. Given that Matt Mullenweg has publicly voiced interest, the next move lies with the broader WordPress community. It is up to contributors and stakeholders to assess whether this represents a valuable port of call on WordPress's modernization path, or a detour that would be better left unexplored.
