Switching to PHP-Rendered Blocks with SolidJS Enhancements Instead of React

I am a longtime WordPress user, but I’ve been aware of the disdain many developers outside of WordPress have for it, and I generally agree with much of it. As David Bushell points in his blog post, “Does WordPress Have A Gutenberg Problem?,” Gutenberg’s React-based UI tasked with parsing the HTML/JSON as transient in browser memory, is “a monumental hack.” The stored content is a mishmash of CSS-in-JSON-in-HTML-comments-in-a-PHP-file that was originally generated by React but has now been extended to templates and is meant to be coded by humans. Storing content as HTML within the post table mixes data with its presentation, making it harder to manipulate, query, or reformat specific pieces of content programmatically and is just asking for scalability and performance issues as a website grows in complexity, increasing the risk of data corruption. Modern CMS practices favor flexible, abstracted data structures that are easier access, transform, and reuse; and it reduces the risk of data corruption, and provides better performance and scalability. Not Gutenberg…

Yet, as the most popular CMS on the internet, WordPress has done wonders to make it possible for the average site owner to implement incredibly advanced features. I’m committed to finding solutions to address many of the issues that developers have with WordPress—particularly with Gutenberg.

I’ve discovered that ACF blocks avoid many these issues by not using React and storing data in JSON. The blocks are rendered using a PHP template file or callback function via the the_content filter, thanks to WordPress\’s backward compatibility efforts. Storing data in JSON-only aligns with modern CMS practices of more abstracted data models. ACF\’s PHP-based approach to developing blocks is a cleaner, more scalable, and fully-compatible alternative to React-based Gutenberg blocks… and that\’s coming from a longtime Meta Box user!

Given this, I propose using a similar approach as Advanced Custom Fields’ blocks to serve as the foundation for an alternative to React-based Gutenberg blocks, using SolidJS as the UI framework to add interactivity and advanced UI logic on the front end.

The choice of SolidJS is to leverage its fine-grained reactivity, direct DOM updates, and simplicity that offers benefits over React or PHP in the frontend layer. SolidJS is significantly smaller than React, and given that jQuery is commonly run alongside React without major issues, the key is to keep SolidJS and React separate and use SolidJS to enhance ACF blocks where it adds clear value. Introducing SolidJS purely for frontend interactivity would allow for a more streamlined approach, with fine-grained reactivity that can be less complex to implement and maintain without conflicting with Gutenberg’s React-based infrastructure.

ACF blocks allow for greater flexibility in data management through JSON storage and PHP rendering. SolidJS can offer better performance for highly dynamic interactions due to its fine-grained reactivity and smaller footprint. Although ACF blocks aren’t strictly necessary since PHP render functions are core to blocks and recent updates make PHP rendering even simpler. The idea is to manage block data in a flexible, abstracted data structure format that would *significantly* improve content management in WordPress, and then render the blocks via PHP in the editor to ensure compatibility. However, ACF’s extensive feature set positions WPEngine and its developers as the best suited to take on such an ambitious project. I believe the best way to achieve this would be to create a separate block library independent of ACF or ACF Pro, but following the same approach as ACF’s custom blocks.

Going with Headless WordPress may be the only way to completely avoid Gutenberg and I’m aware of WPEngine’s work in the headless WP space, but honestly, headless remains a niche approach within WordPress and is out of reach for the vast majority of WordPress’s user base. I am interested in experimenting with headless, but I would opt for Gato GraphQL to fetch the data and the Astro web framework with SolidJS as the UI framework to develop the frontend for reasons that I won’t get into here.

Returning to more approachable solutions, here are some possible block use-cases where ACF blocks – or a similar approach to PHP-rendered blocks with JSON for data storage – enhanced with SolidJS, would demonstrate clear advantages over native Gutenberg blocks:

1. Customizable Dashboards: ACF blocks allow data to be stored in a structured JSON format, making it easier to query and update dynamically. Enhanced with SolidJS, these dashboards can offer real-time updates and highly interactive components, without the overhead of React.
2. Complex Forms: Using ACF blocks for form data management ensures that content and presentation are separate, making forms easier to manage and more scalable. SolidJS can enhance user interactions with real-time validation and fine-grained reactivity, something harder to achieve with native Gutenberg blocks.
3. Interactive Data Visualizations: Data stored in JSON-only with ACF blocks can be easily manipulated and transformed into complex visualizations. SolidJS can efficiently render these visuals with direct DOM updates, ensuring smoother performance compared to React-based Gutenberg blocks.
4. E-Commerce Product Configurators: ACF’s JSON storage allows for the flexible management of product attributes and options. SolidJS can then provide a seamless, interactive UI for users to configure products, offering a more responsive experience than native Gutenberg blocks.
5. User-Generated Content Sections: ACF blocks can store and manage user submissions as JSON, making it easier to display, filter, and interact with this content. SolidJS can enhance the frontend experience by providing real-time updates and responsive interactions, which is more difficult with the React-based Gutenberg setup.

The advantages of React-based Gutenberg blocks is largely due to the fact that WordPress is built with React to begin with and where there is no current alternative functionality:

1. Deep Integration with the WordPress Editor: Gutenberg blocks are natively integrated into the WordPress editing experience, which allows for seamless, real-time previews and interactions directly within the editor. This deep integration leverages React’s strengths, making it easier to develop and manage content-rich pages.
2. Compatibility with Third-Party Plugins and Themes: Plugins and themes that are designed specifically for Gutenberg’s React-based architecture.
3. Reusable Blocks and Templates: Gutenberg’s system for creating reusable blocks and templates is built into its core, allowing users to easily save and reuse components across different parts of a site.

However, using ACF blocks or a similar approach does help to mitigate compatibility concerns in the following ways:

1. Flexibility and Compatibility: ACF blocks are rendered using PHP, which is a core technology in WordPress. This ensures that these blocks remain compatible with the broader WordPress environment, including third-party themes and plugins that rely on PHP.
2. Backward Compatibility: ACF’s approach to storing data in JSON and rendering via PHP aligns with WordPress\’s commitment to backward compatibility, making it easier to integrate these blocks with older systems or plugins not built with React.
3. Editor and FSE Integration: Although ACF blocks aren’t as deeply integrated as Gutenberg blocks, they can still function within the WordPress editor and Full Site Editing (FSE) environments. The use of PHP and JSON allows for the creation of flexible and modular content that can be managed effectively, even in complex WordPress setups.
4. Interoperability: Blocks created using PHP and JSON can interact with other WordPress features and third-party tools without the need for extensive modifications, ensuring a smoother experience when combining different technologies within a WordPress site.

Therefore, the biggest difference between ACF blocks enhanced with SolidJS, and React-based Gutenberg blocks, is the inconvenience of not being able to preview dynamic content and interactions powered by SolidJS directly within the WordPress editor without additional development work. However, this trade-off might be acceptable given the benefits of using JSON for data storage and SolidJS for highly dynamic interactions. ACF blocks that contain little or no dynamic interactions would not face the same inconveniences in the editor. For these types of blocks, the lack of real-time preview in the editor is less of an issue since the block\’s behavior is straightforward and doesn’t rely on complex, dynamic interactions.

It also conceivable to develop an alternative editor tailored to SolidJS that still aligns with the goals and objectives of the Gutenberg project—after all, page builders like Elementor are essentially alternative editors. An alternative editor tailored to SolidJS could address the deep integration advantage of React-based Gutenberg blocks. SolidJS\’s similarities to React mean that much of Gutenberg’s codebase could be translated into SolidJS as well, potentially reducing the development effort. This could be a great middle ground between the potential of headless WordPress with a modern web framework, and the convenience of Gutenberg. Offering a comparable user experience while leveraging the benefits of SolidJS, such as performance improvements and simpler state management. However, enhancing PHP-rendered blocks with SolidJS on the front end is a far more feasible and immediate step in the right direction for avoiding the issues with Gutenberg.