[Low-Code UI Architecture] How to design a UI layer that supports template injection and domain-specific extensibility?

[Phạm Đức Mạnh]

Hi everyone,

My friend and I are working on building a low-code UI platform.  
Our goal is to define a system that revolves around a few core dynamic concepts:

+ Addons  
+ Dynamic resources  
+ Frontend templates (defined via JSON or a specialized DSL)

These templates are responsible for declaring UI components, as well as the configuration needed to connect with dynamic resources and addons from the backend.

While I've managed to map and organize the data layer quite comfortably, I've encountered a challenge on the frontend side (which is built with Flutter). Specifically:

> In a low-code environment, the frontend needs to dynamically select and render appropriate view states and layout types based on template input.

This introduces a deeper level of abstraction than traditional modular frontend setups — where UI is often tightly coupled to concrete implementations, and modules mainly share datasources, not UI layers.

To support this complexity, I'm proposing a new abstraction I call `HyperView`.  
It will act as the main export of each module — a composable, declarative UI layer that abstracts over view logic.

Each module will follow this structure:

Data → Presenter → HyperView Layer

The frontend modules will try to expose only the HyperView layer, hiding internal details.  
This approach not only improves view reusability, but also aligns well with the principle:

+ "Deep module, narrow interface."

At the app entry point, we simply declare:
+ The set of HyperViews to use
+ A global Stylesheet (optional)
+ Routing configuration

From there, each app entry can assemble its own unique application — by composing different modules that export HyperViews and their related models.

I'm reaching out to seek guidance or best practices on designing this kind of UI architecture:
+ How to best structure modules around dynamic view types?
+ How to maintain scalability and testability?
+ Are there any frameworks or existing systems that approach UI this way?

Any insights or references would be greatly appreciated.

Thank you!  
Manh

[David Hess]

Generally speaking, you can look at this problem as dynamic deserialization of UI’s from their definitions. That problem has been solved before – you can check out XAML, XUL, XIB, etc which are all different approaches to it. And if you think about it, HTML + Javascript is the ultimate low-code platform based on dynamic UI deserialization. Yet, despite the existence of these various formats, I’ve seen a lot of platforms opt for their own proprietary approach that allows them to address their own unique needs.

So, there is plenty to learn from and study out there (including open source projects like https://nodered.org/ where you can study the source code) but don’t feel bad for rolling your own solution.

Re: testability, the main thing I would watch out for is when you build a system like this, by definition you have to support a very wide range of input from the user. So much so, that you can’t possibly write enough test cases to cover everything they could possible do. I.e. you are providing more of a visual programming language than you are a feature constrained product. You can solidly build out unit tests for individual components, but testing all the ways users can use and combine them is impossible. For that reason, I would employ some fuzz testing to help try and uncover corner cases.

Dave

On Jun 9, 2025, at 9:42 PM, Phạm Đức Mạnh <phamducma...@gmail.com> wrote:

Hi everyone,

My friend and I are working on building a low-code UI platform.  
Our goal is to define a system that revolves around a few core dynamic concepts:

+ Addons  
+ Dynamic resources  
+ Frontend templates (defined via JSON or a specialized DSL)

These templates are responsible for declaring UI components, as well as the configuration needed to connect with dynamic resources and addons from the backend.

While I've managed to map and organize the data layer quite comfortably, I've encountered a challenge on the frontend side (which is built with Flutter). Specifically:

> In a low-code environment, the frontend needs to dynamically select and render appropriate view states and layout types based on template input.

This introduces a deeper level of abstraction than traditional modular frontend setups — where UI is often tightly coupled to concrete implementations, and modules mainly share datasources, not UI layers.

To support this complexity, I'm proposing a new abstraction I call `HyperView`.  
It will act as the main export of each module — a composable, declarative UI layer that abstracts over view logic.

Each module will follow this structure:

Data → Presenter → HyperView Layer

The frontend modules will try to expose only the HyperView layer, hiding internal details.  
This approach not only improves view reusability, but also aligns well with the principle:

+ "Deep module, narrow interface."

At the app entry point, we simply declare:
+ The set of HyperViews to use
+ A global Stylesheet (optional)
+ Routing configuration

From there, each app entry can assemble its own unique application — by composing different modules that export HyperViews and their related models.

<hyper1.jpg>

<hyper2.jpg>

I'm reaching out to seek guidance or best practices on designing this kind of UI architecture:
+ How to best structure modules around dynamic view types?
+ How to maintain scalability and testability?
+ Are there any frameworks or existing systems that approach UI this way?

Any insights or references would be greatly appreciated.

Thank you!  
Manh

--
You received this message because you are subscribed to the Google Groups "software-design-book" group.
To unsubscribe from this group and stop receiving emails from it, send an email to software-design-...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/software-design-book/4b6e2932-eda9-49dd-9b95-aa47ee13a2a8n%40googlegroups.com.
<hyper1.jpg><hyper2.jpg>

[Phạm Đức Mạnh]

Thank you so much, Dave for your helpful response.

I wanted to ask a follow-up question:

In your opinion, at what scale of project (or at what level of reuse) does it make sense to introduce a dedicated **UI control language** — such as a custom XML/XIB-like format — or at least a declarative layer that extends the native UI SDK’s widget/view/component system?

I’ve seen large-scale products like Google Chat or Google Groups, and I imagine they must also have some internal UI abstraction layer, especially considering that views or modules from one app may need to be embedded into another.

Also, is it reasonable to say that in companies with a **cohesive app ecosystem** and a **shared design system**, it's naturally easier to invest in building shared UI layers — like a `HyperView` layer — that sit on top of existing widget frameworks ?

Around me, I’ve observed that some companies attempt to reuse common UI components like “post list view” or “province selector.” However, because these shared views were either too rigid or not well-designed, they often ended up violating the **Single Responsibility Principle** — becoming overly coupled and hard to maintain due to conflicting requirements from multiple apps.

I’m really grateful for your input so far, and would love to hear your thoughts on this.

[The Future of Programming]

Hello Manh

>> "Any insights or references would be greatly appreciated."

During PWCT (Programming Without Coding Technology 1.x) development, the system used a specific domain-specific language to create the visual components. This DSL uses its own interpreter. 

Documentation: doublesvsoop.sourceforge.net/pwcthelp/features/frameworkandextension.htm

Advantages: Easy/Fast way to create the visual components 

Disadvantages: 

1- Learning curve (Since it's a specific DSL and not a known language)

2- Limitations! --> Creating a custom DSL means it will not be powerful as other existing languages (in most cases)

During PWCT 2.0 development, the visual components are just written in the Ring language itself (same language used for creating the visual environment)

Parent classes for visual components controller/view: PWCT2/src/component at master · PWCT/PWCT2

Then each visual component contains sub classes (few lines of code): PWCT2/src/vpl/ringpwct at master · PWCT/PWCT2

Example (print component): PWCT2/src/vpl/ringpwct/print.ring at master · PWCT/PWCT2

Advantages: Huge flexibility (Each component could do anything that can be written in Ring language) 

Summary: Check each approach and see how much time you need to create a component and what you prefer, this way you will be in the situation of your future users, and you could have a better decision. 

For me, I prefer the PWCT2 approach.

Greetings,

Mahmoud

[David Hess]

On Jun 10, 2025, at 11:56 PM, Phạm Đức Mạnh <phamducma...@gmail.com> wrote:

Thank you so much, Dave for your helpful response.

I wanted to ask a follow-up question:

In your opinion, at what scale of project (or at what level of reuse) does it make sense to introduce a dedicated **UI control language** — such as a custom XML/XIB-like format — or at least a declarative layer that extends the native UI SDK’s widget/view/component system?

I’ve seen large-scale products like Google Chat or Google Groups, and I imagine they must also have some internal UI abstraction layer, especially considering that views or modules from one app may need to be embedded into another.

Also, is it reasonable to say that in companies with a **cohesive app ecosystem** and a **shared design system**, it's naturally easier to invest in building shared UI layers — like a `HyperView` layer — that sit on top of existing widget frameworks ?

I think you would run into some issues if you applied that approach broadly:

• UI definition formats tend to capture structure and not behavior.

  • UI definition formats usually are strongly tied to particular SDKs / runtimes. For instance NIB/XIB only makes sense when deserialized in an Apple API runtime.

To achieve your goal widely, you would need a component format that both captures UI structure and behavior and that can be used in many different runtimes. This is reminiscent of the big “component” push of the 1990s. Examples from that time are OLE/COM, OpenDoc, Corba, etc. These technologies were expected to create a new economy of runtime independent, object-oriented software components that could be acquired and assembled into applications.

It started out with much fanfare – and ended with a whimper. It turned out that trying to make that dream work was really complicated and the complexity kept spilling over onto developers who tried using it. Ultimately, they could not attract and keep enough adopters to sustain it.

What’s happened since then is more of a bottom up ecosystem approach based on open source. Within any particular environment, you have plenty of options that are native to that environment and can be integrated with much less effort.

Interestingly enough, more recent advances in this area include _UIRemoteView (Apple) / RemoteView (Android). Rather than integrating components in a single runtime, one process generates a UI natively and then the runtime supports displaying it (i.e. an image of it) within another process using interprocess communication. From one perspective it’s a bit clunky, but from another it has much better memory safety and runtime independence and it's much simpler for the developer.

Around me, I’ve observed that some companies attempt to reuse common UI components like “post list view” or “province selector.” However, because these shared views were either too rigid or not well-designed, they often ended up violating the **Single Responsibility Principle** — becoming overly coupled and hard to maintain due to conflicting requirements from multiple apps.

Well, I think this issue is independent of the UI discussion above. Any software component can suffer from over-specialization or over-generalization. It’s an age old problem that just reflects the reality that nothing can satisfy everybody all of the time.

I believe that developers need to define / discover their customers and then focus their software on adapting to the context that those customers use it in. It’s not about building the ultimate component - it's about cost-effectively building a component that does a good job of solving your customers problems.

I’d sum up all the discussion above as “ideals almost always yield to economics”. 

Dave

To view this discussion visit https://groups.google.com/d/msgid/software-design-book/5130fa75-5785-4381-babd-c67f97315bf9n%40googlegroups.com.

[Đức Mạnh Phạm]

Thank you again, Dave  

I’d like to share a reflection and follow-up thought:

In the past, I primarily worked with UI frameworks like JavaFX and mobile SDKs where object-oriented programming dominated. State was implicit — you interacted directly with views and controllers, and in my opinion, the state management often felt "invisible."

However, in newer declarative technologies like SwiftUI or Flutter, state management takes center stage. The UI instructions tend to becomes a pure function of state, and since views themselves are immutable declarations, the only mutable part left is the state they respond to. This shift made me realize: managing state becomes a form of managing side effects — just like in functional programming.

In this context, I found the rise of hooks (React, flutter_hooks) or effect systems (algebraic effects) quite fascinating (thought I admit I haven’t fully grasped their underlying principles yet).

But even then, I’ve noticed that state management mostly applies to data-bound logic. When it comes to non-data context, such as:

• Responsive layout
• Adaptive behavior    
• Routing 

It still feels hard to fully isolate those effects. These parts tend to bleed across components and force some degree of coupling or branching logic.

In practice, I often see teams just split the whole app by platform (web vs. mobile vs. desktop) and handle layout adaptivity independently within each project. But this feels less composable — and not ideal if we want a shared system across platforms.

I wonder if there are any UI patterns that allow child views to be "oblivious" to their platform, layout, or parent context — and yet still behave appropriately when composed into different containers ?

That is, how can we let parent views opt-in to control or constrain their children, without the children needing to understand their host environment ?

Thanks again for inspiring this line of thought — writing this helped clarify a lot of my own confusion too. I'd love to hear thoughts from others who’ve wrestled with these same concerns.

Still, I believe statefulness and side effects are inevitable; my aspiration is to find better ways to contain and isolate them — however hard it may be today, I see great potential. This belief stems from the idea that functional and structured programming are fundamentally equivalent in power, and in practice, pure functions tend to help developers avoid many common pitfalls.  

Vào lúc 22:35:32 UTC+7 ngày Thứ Tư, 11 tháng 6, 2025, David Hess đã viết:

[David Hess]

On Jun 14, 2025, at 10:37 AM, Đức Mạnh Phạm <manh...@gmail.com> wrote:

Thank you again, Dave  

I’d like to share a reflection and follow-up thought:

In the past, I primarily worked with UI frameworks like JavaFX and mobile SDKs where object-oriented programming dominated. State was implicit — you interacted directly with views and controllers, and in my opinion, the state management often felt "invisible."

However, in newer declarative technologies like SwiftUI or Flutter, state management takes center stage. The UI instructions tend to becomes a pure function of state, and since views themselves are immutable declarations, the only mutable part left is the state they respond to. This shift made me realize: managing state becomes a form of managing side effects — just like in functional programming.

This trend of “functional” UI programming style grew in popularity when React hit the scene. The problem is that this functional approach was based on React regarding itself as just a “view” library.

I believe the problem with that approach is that the reality is that any actual, useful UI is always going to fall into some variant of the Model, View, Controller (MVC) pattern. Maybe you can decompose just the View aspect into a functional solution but ignoring Model and Controller concerns doesn’t make them go away. They must be addressed or you don’t have a working UI. 

You can see the impact of this situation in the React world:

• Gun meet foot situations in React like opt-out on rerendering which leads to performance problems regularly.
• The emergence of now a React compiler to try and paper over the problems caused by this approach. 
• The somewhat odd notion that you have a functionally derived and driven UI - when the actual implementation under the covers is a diffing algorithm against an extremely stateful DOM.

I contend React is in this situation because functional is the wrong approach for UIs. 

In this context, I found the rise of hooks (React, flutter_hooks) or effect systems (algebraic effects) quite fascinating (thought I admit I haven’t fully grasped their underlying principles yet).

But even then, I’ve noticed that state management mostly applies to data-bound logic. When it comes to non-data context, such as:

• Responsive layout
• Adaptive behavior    
• Routing 

It still feels hard to fully isolate those effects. These parts tend to bleed across components and force some degree of coupling or branching logic.

I believe Vue does a much better job of this. It fully embraces the stateful nature of UIs with a component architecture and two-way data binding. Rather than trying to hide all of the state that can’t be prevented from leaking into a functional approach, it embraces it and has developed a compositional approach (ala hooks) that brings good aspects of functional programming to their stateful model. 

In practice, I often see teams just split the whole app by platform (web vs. mobile vs. desktop) and handle layout adaptivity independently within each project. But this feels less composable — and not ideal if we want a shared system across platforms.

I wonder if there are any UI patterns that allow child views to be "oblivious" to their platform, layout, or parent context — and yet still behave appropriately when composed into different containers ?

That is, how can we let parent views opt-in to control or constrain their children, without the children needing to understand their host environment ?

I think this goes back to my discussion of the component software push of the 90s. It’s a bit idealistic and the economics of the resulting complexity make it ultimately an unrealistic outcome. 

Thanks again for inspiring this line of thought — writing this helped clarify a lot of my own confusion too. I'd love to hear thoughts from others who’ve wrestled with these same concerns.

Me too! Indeed, wonderful discussion. I’ve always felt that UI / frontend craft gets neglected in academic settings despite there being a lot of really interesting and fertile ground to work with.

Still, I believe statefulness and side effects are inevitable; my aspiration is to find better ways to contain and isolate them — however hard it may be today, I see great potential. This belief stems from the idea that functional and structured programming are fundamentally equivalent in power, and in practice, pure functions tend to help developers avoid many common pitfalls.

I would temper your statement - functional and structured programming are equivalent in power - but not in application. The more stateful the actual nature of the problem you are attempting to solve is, the more difficulty you will have applying a functional approach to it. (React being the poster child for this perspective.)

Dave

To view this discussion visit https://groups.google.com/d/msgid/software-design-book/6bdd0d5b-68ee-4d88-8c8b-27beada08fdcn%40googlegroups.com.

[Manh Pham]

Dear Mahmoud,

Thank you so much for your comment.

Your description of PWCT 1.x and 2.0’s evolution gave me a lot to reflect on. I find the transition from a custom DSL to using the Ring language itself to define visual components particularly insightful — it reminds me of how Scratch enables users to create stories, games, and animations.

Your approach also made me think of several other technologies that pursue the vision of using a single expressive language to replace the traditional HTML/CSS/JS stack. For instance:

• Ur/Web – where the entire web app is written in UrML

• Imba – a DSL designed to replace the full web stack

• Elm UI – expressing UI in typed functional code, not HTML

• Revery – native UI in OCaml, no HTML/CSS

• Pollen and Scribble (Racket) – programmable documents

I see PWCT2 as part of this same lineage — where a strong DSL or core language defines not only logic, but also interface and structure, potentially enabling a new kind of hypertext that's purpose-specific and far more powerful than current HTML-based systems.

I’m honestly excited about the idea of building software whose core is a lightweight browser, but instead of interpreting HTML/CSS/JS, it reads a different kind of hypertext — one designed specifically for that domain, with a coherent and expressive syntax.

Thank you again for the inspiration and for sharing the resources. I really appreciate it.

Warm regards,
Manh

[The Future of Programming]

Hello Manh

You are welcome :D

Greetings,

Mahmoud