WordPress vs. No-Code /Low-Code Tools

The Low-Code/No-Code revolution is quickly becoming a hot trend in the tech world, with several channels and publications covering it extensively. As a (fairly) experienced WordPress developer, I was immediately drawn in and began reading articles on the subject. Then I started experimenting with a number of those tools and later embarked on a real-world project. However, as I read through all of these reviewers and project descriptions, something began to disturb me: why is WordPress “out of the picture?”

Why Isn’t WordPress a Low/No Code Tool?

As I followed the active discussions and statements by the various participants, I was amazed to see WordPress almost completely ignored, as if it did not have any relation to the trend. True, WordPress is not new, as most of the products discussed, so it does not have the same “hype.” Yet, in many cases, the functionality provided targets almost the same needs, typically achieved by adding one or more “plugins” (WordPress jargon for add-on software module).

Job board? You got it. Your small e-Shop? WooCommerce, and you are done. How about your own Udemy? Add TutorLMS, and a copy is running on your server. Zero coding. Configure the plugin, design the screen with a drag-and-drop builder, and your app is up and running. So what is this hidden factor that pushes WordPress, the world’s number one web platform, away from the Low-Code/No-Code domain?

It all depends on the definition

Things even get muddier when you inspect the leading Web builder of the Low-Code/No-Code domain — Webflow. I started using Webflow before I started my WordPress practice and was impressed with the tool immediately. The ease of building a complex web page. The performance, the responsiveness, and the ease by which I could create the exact design I had in mind. Yet Webflow was in its early days, with no CMS (then); even the most straightforward blogging needs could not be answered by the tool, so I had to move to WordPress and its built-in blogging framework. The clunky method by which WordPress pages were designed has been a great disappointment, so I had to adjust.

But then came the era of the Page Builders, especially Elementor, which changed the whole picture — elegant, complex pages could be designed in minutes, and you no longer had to resort to HTML and CSS to achieve your desired look. Then I started using plugins and later the extensions allowing dynamic field definition, and WordPress became my go-to platform for almost any type of application.

So what differentiates Webflow from WordPress as a leading No-Code Web design tool, aside from their excellent marketing, positioning them as the number one choice of the no-code community? Till recently, it was justified by its better support for modern HTML (the box model, specifically), but this is no longer the case, as most WordPress builders are now adopting the technology and basing the design on this powerful concept. So is it time to make WordPress part of the trend?

It’s the App Part that Makes the Difference

As I began to explore the app development space, I became aware of the significant difference between WordPress and the No-Code notion. Because of this critical difference, its exclusion from the no-code domain became clearer.

The Dynamic Data Issue

One of the critical parts of almost any Low-Code/No-Code app is the CRUD functionality, or the ability to manipulate data in its four forms — Create, Read, Update and Delete. In a dating app, it is the members’ data, created on sign-on and updated with preferences, and a job-matching app does the same for job data and candidates, and so on.

In the Low-Code/No-Code space, it is common to have a “data” section where you define these entities and their relationships. Once defined, the tool allows for the definition of forms through which data is entered and a display screen for various forms of presentation (“Read”) — single items, lists, etc.

WordPress has a rather unorthodox approach to CRUD operations. As it has been developed out of a blogging platform, the POST is the key data object and the dynamic data supported is simply the POST text. There is also a definition of a page, which is merely a simpler version of a post. It is not part of the POSTs list, but still holds static text and images added while constructing the site. Moreover, POST (and PAGE) editing is all done in the back-end — site users are readers, and only the site owner is publishing content.

This rather rigid scheme has been found limiting quite rapidly, and the initial answer was — coding! WordPress is an Open Source platform, and one can alter its PHP code at any level. Implementing other types of dynamic data, different lists, and so on was done in PHP. Then appeared a few products that (till now) provide a No-Code style solution, mainly ACF. This leading Dynamic Data plugin for WordPress allows adding Custom Fields holding dynamic data through the back-end interface and displaying these fields on the front end using No-Code methods supported by all page builders.

However, allowing site users (or “App Users”) to add data and edit it themselves on the front-end is way more complex, or for many users — impossible — all done through a back-end interface or through a specially coded screen.

The ACF back-end data updating screen:

The Automation Issue

A second important part of all newly developed Low-Code/No-Code platforms is the ability to create a programmatic-like sequence of actions, or “Automation.” You can instruct the app to go through a sequence of operations such as changing the presentation form, moving to a different page, etc., in response to a trigger — key pressed, the value entered, an so on. You may also initiate communications with an external entity, also known as support for APIs.

WordPress lacks all of these as a built-in feature, and the need for such functionality, emerging quite often in many projects, is typically covered by a Plugin — a piece of code performing the automation part or by (again) direct PHP coding of the core code.
The rich world of automation offered by tools such as Zappier, AirTable, and others is still missing, except for a few recent plugins that provide similar functionality (but way more limited) within WordPress.

The “Mobile First” Issue

A third part of the key limitation of WordPress when it comes to app development is the “Mobile-First” design required by many of the current projects. WordPress has been created as a Desktop app, and it still shows. Its support for mobile devices is done mainly via a responsive HTML, meaning that page elements fold into a mobile-optimized form once read on a mobile device (there is no concept of a “mobile version of the site”). It is, therefore, common to see a rather crippled version of the app on a mobile device, far from the standards of modern mobile UI design. Many of the Low-Code/No-Code tools, on the contrary, were built as mobile app development tools and offer excellent UI options, implemented through a drag-and-drop interface and truly mobile widgets set.

The FlutterFlow Mobile-First Design System:

Summary

WordPress is a great platform, and it still drives significant parts of the Web, including numerous innovative SaaS services built upon its reach presentation capabilities and an endless range of plugins complementing the missing functionality. However, the clean, flexible, and powerful app-oriented solution offered by the Low-Code/No-Code world is missing. Without a significant change in the leading platform developer, Automatic, towards resolving some of the above issues, its absence from the Low-Code/No-Code space will remain permanent.