Why a block needs to be registered in both the server and the client?

[juanmaguitar]

Why a block needs to be registered in both the server (PHP function register_block_type) and the client (JS function registerBlockType)
At Block API Reference / Registration it says

You can use the functions documented on this page to register a block with JavaScript only on the client, but the recommended method is to register new block types also with PHP on the server using the block.json metadata file.

Is it a recommendation or a requirement?

[juanmaguitar]

These are some comments from internal conversations:

By @ndiego

Technically, I believe this is a recommendation. You can register blocks just in the client, which goes back to the early days of the Editor. But I would never do this. IMO, blocks should always be registered in both places, which is the default approach for create-block.
Also, having a block registered on the server adds it to the WP_Block_Type_Registry, making it more "visible" to other developers.

By @gziolo

Many features activated with block supports require block registration on the server so it’s possible to process blocks correctly when rendering them on the front end.
Block Hooks is the most recent example of the feature that only works when blocks are registered on the server.
Block style variations would be another feature that when available on the server ensures that proper styles get enqueued on the front end.
Most features from Global Styles integrated with blocks need access to the block type on the server to generate CSS.

Any more thoughts?

PS: Once we have gathered updated info about this topic we could write a DevNote or a Developer Blog post

[gziolo]

There is a related discussion I started about Static vs Dynamic blocks:

• Static vs Dynamic blocks #35918

Another important consideration is that when the block is dynamic and has server-side rendering, then it is required to have it registered on the server with register_block_type so it's another point to keep in mind.

[juanmaguitar]

As per Block Editor Handbook / Reference Guides / Block API Reference / Metadata in block.json > Benefits using the metadata file

Furthermore, because the Block Type REST API Endpoint can only list blocks registered on the server, registering blocks server-side is recommended; using the block.json file simplifies this registration.

[juanmaguitar]

comment by @oandregal at #56334

"global styles" (styles generated from theme.json) require blocks to be registered in the server – otherwise, it's like they don't exist, and any styles assigned to them in theme.json will be ignored. This only matters if the block aims to be styled via theme.json, of course.
I presume the same would be true for all features that generate styles in the server (block supports, layout, style engine, etc.).