The myth of the generic UI

I am not sure about you, but I heard that idea a thousend times: "let's build a genetic frontend". The plan usually goes like this—we create a meta-language to describe the UI, which is generated somewhere in the backend.

The supposed benefits of this architecture sound impressive:

• More flexibility: We can change the system’s behavior without having to redeploy the frontend.
• Simple customization: We can put the description of our UI in a database or excel file. Our business users can than change the system on there own.
• Support more use cases: By building our UI generically, we can support different use cases just by configuring various UI setups in the backend.

So, clearly, this is the right architecture, right? Let's make everything work this way! Well…not so fast. There are some major issues with this approach, even if it seems like the perfect solution at first.

The Problems with a Backend-Driven UI

• Lackluster UX: When the UI lives in the backend, every user input has to trigger a backend request—for validation, conditional fields, etc. This leads to sluggish pages. Plus, it's harder to use the right HTML input types, so the browser can’t help the user as much with things like autofill or number pads.
• Unnecessary complexity: By adding this abstraction, we pile on complexity, making the system harder to understand and more prone to subtle bugs. It also complicates testing, especially automated frontend tests, which become trickier to set up and maintain.
• You actually don't save any time: It turns out, HTML is already a pretty good language to describe simple UI. So every meta-language you create that is expressive enough to make an usable UI will be about as complex to use as HTML. So everything you have done is create a more complicated and less documented way for you users to create user interfaces.

So, What’s the Alternative?

How can we get some of the benefits we’re aiming for without all these drawbacks?

• Configure from available fields: If you need to support numerous use cases that are essentially similar but require a few different fields for user input (e.g., for different countries or companies), it may be beneficial to predefine a set of fields that a business user can configure. This approach balances usability with a degree of configurability.
• Look at low code platforms: If you genuinely need a high level of UI customization for business users, consider a low-code platform like Ohmyform or Strapi. These can let users create interfaces without the pain of a full-on backend-driven UI setup.