DEV Community: Adalbertus Chris

Is React a good fit for the future of AI-generated UI?

Adalbertus Chris — Sun, 16 Nov 2025 14:39:03 +0000

Recently I’ve been thinking about where frontend development is heading — especially now that AI-assisted UI generation and design-code workflows are becoming more realistic.

React is one of the most popular frontend libraries, but its architecture raises an important question:

Is React the right tool for a future where UI and logic could be handled by different roles?

For example: designers (with help from AI tools) can generate the UI structure, while frontend developers can focus on the logic.

Unlike frameworks such as Angular, Vue, Svelte, and others that separate markup (html) and logic (ts/js), React mixes markup, logic, state, and behavior all into the same block of code. That’s convenient for developers, but it can introduces challenges for design-to-code AI tools.

Tools that generate only templates (HTML) and CSS can produce cleaner and more predictable output. But when markup and logic are tightly coupled, it becomes harder to:

keep code clean
track only logic or only template changes
automate UI generation

Is template, logic separation feels much more aligned with the direction automated UI generation heading? Designers or AI systems could generate clean templates, and developers could plug in the logic without responsibilities bleeding together. Could React’s architecture limit its effectiveness for future design-to-code workflows, generating messy code that’s difficult to maintain and forcing full-file reviews whenever designs change?

Frontend Evolution — Rethinking Frontend - part 3 - introduction to jModel

Adalbertus Chris — Sat, 29 Mar 2025 18:11:44 +0000

Overview

jModel is a prototype library designed for managing client-side models (business logic) in a simple, flexible, and efficient way. It offers built-in tools for dependency injection, state management, and validation. This article explores the core concepts of jModel and its role in building modern web applications.

Key Features

Minimalist API – Focused on simplicity and ease of use
Own Dependency Injection (DI) – Supports lazy initialization, allowing dependencies to be registered only when first used
Validation Tools – Built-in utilities to handle data validation (at the model level)
State Management – Reactive model management with efficient updates
Performance Optimization – Tree-shakable, ensuring only used code is included in the final bundle
Framework Agnostic – Can be integrated into different frontend frameworks/libraries through adapters
Cross-Platform Compatibility – Works on both browsers and Node.js without relying on browser-specific APIs
Data Management – Enables switching between various storage and caching solutions depending on the platform

Model Definition

Similar to writing traditional services for business logic, the first step is to define a model object. A typical setup includes a token for dependency injection, lifecycle option, providers, and a model function factory.

export const userSource = {
  [TOKEN]: Symbol('USER_SOURCE'),
  [LIFETIME]: Lifetime.scoped,
  [PROVIDERS]: {
    [USER_REPOSITORY]: userRepository,
    [USER_STORE]: userStore,
    [USER_MAP]: () => mapUserToString,
  },
  [FACTORY]: userSourceFactory,
};

Key elements

TOKEN: A unique identifier used for dependency injection
LIFETIME: Determines how long the model is retained in the dependency injection container (e.g., scoped, singleton).
PROVIDERS: Specifies dependencies, which can be other models or standalone functions like mapUserToString. It uses TOKENS as keys, allowing a single token (e.g., USER_REPOSITORY) to have different implementations across models.
FACTORY: Specifies how the model is created.

userRepository

export const USER_REPOSITORY = Token<UserRepository>('USER_REPOSITORY');

export const userRepository = {
  [TOKEN]: USER_REPOSITORY,
  [LIFETIME]: Lifetime.scoped,
  [FACTORY]: () => ({
    get: userGet,
    getUserNames: userNamesGetAll
  }),
};

userSourceFactory

export const userSourceFactory = ({ inject }: Context) => ({
  setRandomUsername,
  refs: inject(USER_STORE).refs,
});

The model factory function provides access to the execution context, allowing to inject dependencies. Also all methods defined within it, such as setRandomUsername, will execute within the model's context.

Execution Context

Execution context (Context) has two methods:

inject - it allow to inject dependencies available in the same scope or singletones
execute - it allow to execute different method in the same context

setRandomUsername

export async function setRandomUsername(this: Context): Promise<void> {
  const store = this.inject(USER_STORE);
  const randomUsername = await this.execute(getRandomUsername)

  store.setUserName(randomUsername);
}

export async function getRandomUsername(this: Context): Promise<string> {
  const repository = this.inject(USER_REPOSITORY);
  const mapUserDataToString = this.inject(USER_MAP);
  const userNames = await repository.userNamesGetAll();

  return mapUserDataToString(userNames[0]);
}

In the functions above, dependencies are injected from model providers such as USER_STORE, USER_REPOSITORY, and USER_MAP. The execute function is also used to call getRandomUsername within the same context as setRandomUsername

Reactive State Management

jModel supports reactive state management which can be created by calling createReactiveModel function.

userStoreFactory

function userStoreFactory() {
  const model = createReactiveModel({
    name: '',
    age: null
  });
  const name = model.getRef((schema) => schema.name);

  return {
    setUserName,
    refs: {
      name
    },
  };
}

The getRef method allows to select fields that need to be observed for changes.

Integration with UI Frameworks

jModel can be easily integrated with UI frameworks like Angular by using ngContextBuilder adapter.

@Injectable()
export class UserComponentContext extends ngContextBuilder({
  model: userSource,
}) {}

UserComponentContext usage

export class UserComponent {
  private readonly model = inject(UserComponentContext).model;
  userName = refToSignal(this.model.refs.name);

  setRandomUsername(): void {
    this.model.setRandomUsername();
  }
}

refToSignal is another adapter which transform jModel reactive field into Angular signal

Model Validation

jModel also includes built-in validation utilities.

export function userUpsertStoreFactory() {
  const userModel = createReactiveModel({
    firstName: $field('', { validators: [required] }),
    lastName: $field('', { validators: [required] }),
  });

  return { state: userModel.getRefs() };
}

export const USER_UPSERT_STORE =
  Token<ReturnType<typeof userUpsertStoreFactory>>('USER_UPSERT_STORE');

export const userUpsertStore = {
  [TOKEN]: USER_UPSERT_STORE,
  [LIFETIME]: Lifetime.scoped,
  [FACTORY]: userUpsertStoreFactory,
};

The $field method allow to add validators to model fields.

The getRefs method transforms all fields into observable fields, enabling them to be tracked for changes.

Model usage (with two way data binding)

@Injectable()
export class UserUpsertComponentContext extends ngContextBuilder({
  model: userUpsertSource,
}) {}

export class UserUpsertPageComponent {
  ctx = inject(UserUpsertComponentContext);
  form = this.ctx.model.state;

  // jModel library  provides special utilities such as: 
  // isFirstChange, isValid, disable, isDisabled etc.
  isTouched(ref) {
    return isFirstChange(ref);
  }
}

Model usage in HTML

  <input
    type="text"
    [(ngModel)]="form.firstName.$value"
    name="firstName"
  />
  Value: {{ form.firstName.$value }}
  <div *ngIf="isTouched(form.firstName) && form.firstName.$errors">
    Errors: {{ form.firstName.$errors | json }}
  </div>

Every ref field has $value field which allow to get current value or set new one and $errors field which allow to get all validation errors.

This is a brief introduction to the jModel library. Below, you'll find links to the project repository and an example application.

Project link: https://github.com/x-model/jmodel

App example: https://github.com/x-model/jmodel/tree/develop/apps/swapp

Would love to hear your thoughts!

Frontend Evolution — Rethinking Frontend - part 2

Adalbertus Chris — Sat, 15 Mar 2025 14:02:51 +0000

Introduction

Based on feedback, I have refined the goals to bring more clarity to the concept of frontend evolution. The primary objective is to restructure Frontend Developer responsibilities to reduce complexity and improve efficiency.

Why Change Frontend Development Responsibilities?

Currently, Frontend Developers handle too many responsibilities—UI implementation, business logic, state management, API handling, performance optimization, accessibility, and more. This overload increases complexity, slows down development, and blurs role boundaries.

Splitting Frontend Responsibilities: UI & Model

To simplify frontend work, we can split frontend responsibilities into two distinct layers:

UI Layer (Presentation & Interaction)
Model Layer (Business Logic & Data Handling)

Once we establish this separation, we can determine who should handle each part.

Who Should Handle the UI Layer?

The UI layer should remain simple, including HTML, CSS, and basic JavaScript for animations and data transformations. Since UI Designers already work on UI, their responsibilities can be slightly extended to include implementation (creating UI components).

Understanding HTML and CSS doesn’t require deep programming skills, making it feasible for Web Designers to handle this part, especially with the assistance of AI tools. This allows for a more efficient workflow, where designers can directly translate their designs into functional UI components without relying on additional Frontend Developers.

Who Should Handle the Model Layer?

The model layer includes business logic, state management, API communication, validation, caching etc. Backend Developers already work on business logic and have strong programming skills.
Since this layer is purely logic-based (no styling), Backend Developers can easily manage it, even in JS/TS (language has no big meaning when someone has programming skills).

Why Doesn't Splitting Layers Alone Solve the Problem?

Separating the model from the UI without redefining roles doesn’t simplify frontend development — it adds complexity and increases the workload for Frontend Developers. The key is not just separation but clear role definitions to ensure responsibilities are effectively distributed.

New Role Specializations in Web Development

By following this structure, we can introduce clearer role definitions:

UI/UX Developer
This role extends UI/UX Designers' responsibilities beyond just design, allowing them to implement components using HTML, CSS, and basic JavaScript. UI/UX Developers don’t need to worry about logic, they focus purely on UI implementation.

Responsibilities:

Create UI designs and UX workflows
Implement UI components using HTML, CSS, and minimal JavaScript (for animations, transformations)
Handle UI interactions (button clicks, transitions, hover effects, etc.)
Ensure accessibility, responsiveness, and usability
Integrate ready-made methods, services, and models provided by Model Developers

Benefits of this role:

Stronger collaboration between design & development – designers don’t just hand off static designs, they actively build UI components
Reduces miscommunication – eliminates the extra layer of frontend developers, making collaboration more direct
Faster development – UI/UX Developers work directly with Model Developers, reducing dependency on Frontend Developers
Improves AI-assisted UI generation – having logic-free UI components makes it easier to automate UI generation in the future

Model Developer
This role extends Backend Developers' responsibilities to include frontend business logic, state management, API handling, validations etc.

Responsibilities:

Focus on business logic (backend and frontend),
Handle API calls, data fetching, state management, data transformations, validations, caching etc.
Create services and utilities that UI components use
Collaborate with UI/UX Developers to define proper models
Manage frontend architecture, routing, and core features (with Frontend Developer support)
Ensure performance optimization and frontend security (with Frontend Developer support)

Benefits of this role:

Data consistency across backend & frontend – Model Developers define and maintain data structures (models) across both layers
Reduces miscommunication – eliminates the extra layer of Frontend Developers, making collaboration more direct
Faster development and easier API Integration, better synchronization - Model Developers work directly with UI/UX Developers reducing dependency on Frontend Developers
Having a single person who handle models ensures they stay in sync, API payloads are adjusted to UI requirements

Frontend Developer / Lead / Architect / Mentor
A Frontend Developer ensures that UI/UX Developers and Model Developers follow best practices in frontend development. Switching to new roles without prior expertise in certain areas can be challenging, so guidance from experts is essential for a smooth transition.

Responsibilities:

Provide guidance to UI/UX Developers on creating well-structured and maintainable components
Help Model Developers with frontend complexity (state management, reactivity etc.)
Review & optimize frontend logic for performance and best practices
Handle complex frontend scenarios (e.g., advanced state management, SSR, performance improvements)

In every team, we can have Backend Developers, Model Developers, UI/UX Developers, and a Frontend Developers. This specializations brings flexibility and scalability to Web Development.

Why Is This Role Specialization Better Than the Traditional Approach?

This role specialization allows teams to be more structured, efficient, and scalable. It reduces the workload on Frontend Developers, improves collaboration, and makes it easier to adopt new technologies
Improves team efficiency – reduces unnecessary communication and clarifies responsibilities
Enhances specialization – each team member focuses on their strengths, reducing cognitive load
Lighter UI frameworks – by removing logic from UI, frameworks can be leaner and focus only on rendering and interactions
Design-to-code workflow is more direct – UI/UX Developers can instantly apply design adjustments without delays
Ensure data consistency across the backend and frontend model layers with cleaner solutions
Reduces UI-Model mistakes – clearer role separation minimizes miscommunication

Challenges & Potential Issues

UI/UX Developers need some coding skills – HTML, CSS, and basic JavaScript should be part of their skill set. AI tools can assist in simplifying this learning curve.
Risk of tight coupling between UI & backend logic – a clear separation of concerns is necessary. Frontend Developers should review implementations to prevent coupling issues
Handling complex tasks – Frontend Developers still play a role in advanced scenarios

What's Next?

When the roles are defined, the next step is to focus on tools. UI Layer tools should be easy to use for UI/UX Developers, and Model Layer tools should be suitable for Model Developers. Currently I'm focusing on building Model tools (UI Model Library).

The next article will take a closer look at the UI Model Library, which trying to provide a simple, framework-independent way to manage models in frontend applications.

Would love to hear your thoughts! 🚀

Frontend Evolution - Rethinking Frontend

Adalbertus Chris — Mon, 24 Feb 2025 20:29:50 +0000

Introduction

Frontend development has evolved significantly over the years, becoming increasingly complex. Frontend developers must be familiar with various frameworks, libraries, tools, and solutions. They need expertise in multiple areas, including UI, business logic, design tools etc. This complexity leads to blurred boundaries between responsibilities, making development slower, more expensive, and harder to maintain.

This article explores the concept of frontend evolution, advocating for a clear separation between the UI and model layers to improve efficiency, maintainability, and scalability.

Current Frontend Challenges

Mixing Model with UI

Many frameworks tightly integrate logic, state management, validation, API handling within UI components. This coupling makes it difficult to refactor and adapt to new technologies efficiently.

Technology Stack Complexity

Developers must learn and work with numerous frameworks, libraries, and tools.

Redundant libraries exist across UI frameworks, each handling similar tasks e.g., state management (Zustand, Redux, MobX, VueX, Pinia, NGRX, NGXS, Akita etc.), validation, API communication.

We have one programming language but numerous solutions, with many UI frameworks differing in many cases only in syntax and coding style.

Too many solutions make slows down the progress of the frontend part.

Frontend Developer Skills and Responsibilities

Currently, frontend developers must be skilled in multiple areas: working with design tools, know frontend frameworks, know concepts like DI, reactivity, browser behavior, REST API principles, has knowledge about accessibility, responsive UI, security, performance optimization and more.

Inefficient Collaboration

Frontend developers constantly need to sync with designers and backend developers. Misunderstandings can happen—sometimes the backend doesn't provide exactly what's needed, or designs are missing details, leading to extra discussions.

Frontend developers often act as mediators, making sure designs are feasible while coordinating with backend teams to connect everything properly. This back-and-forth takes time, slows development, and reduces efficiency.

Goals

Separate model from UI – Clearly separate the data logic from how it's presented in the user interface.

Make frontend simpler – Reduce unnecessary complexity for easier development. Reduce reliance on multiple libraries that serve the same purpose.

More precise role specializations – Define clearer roles to reduce cognitive load. Make each role easier by reducing what they need to handle.

Improve collaboration – Make teamwork more efficient by reducing unnecessary communication, clarifying responsibilities, and ensuring smoother coordination between team members.

Proposed Solutions

Separate UI and Model

UI Layer (Frontend UI)

Focuses solely on rendering, styling, animations, and user interactions.
Handled by UI/UX developers with minimal programming expertise.
Can be AI-assisted to generate components and establish links with models.

Model Layer (Frontend Model + Backend)

Focuses on state management, validation, API interactions, caching, business logic.
Developed by model developers, ensuring consistency with backend logic.

New Role Specialization in Web Development

UX/UI Developer (Responsible for UI Layer)

Design preparation
Build views using HTML, CSS, basic JavaScript, and UI framework syntax
Ensure accessibility, responsiveness, and compliance with UX best practices
Link UI components with the application's model without implementing business logic
Can leverage AI-assisted tools

Model Developer (Responsible for Model Layer)

Focuses on business logic
Handles both backend and frontend model responsibilities - works on typical backend tasks and creates and manages the frontend application model including authorization, state management, validation, caching, data synchronization with the API
Ensures data consistency between frontend and backend
Troubleshoots issues with data flow and application performance

Frontend Developer (Optional)

Acts as a bridge between UI and model when needed in complex applications
Has advanced knowledge of frontend frameworks and integrations

Benefits of this approach

Separating the model (logic) from the UI makes the UI simpler, enhances maintainability
UI frameworks/libraries can become lighter and more focused on rendering and interactions
A separate model allows for creating a universal, reusable model that can work across different UI frameworks (React, Angular, Vue, Svelte) and platforms (e.g., web, mobile)
By separating the model from the UI, changing UI technologies is more straightforward, enabling easier adoption of new technologies or switching between UI frameworks without having to rebuild the entire application
It can reduce development time, enhance coordination and collaboration, improve productivity, and lower costs by eliminating the need for an additional role between the UI and model (no “mediator” between the UI and backend)
Teams can work more efficiently, when each member focusing on their strengths and specializations, which reduces cognitive load — UI Developers focus on design, appearance, and interactions, while Model Developers handle business logic and data management
Sometimes, designs are hard to turn into HTML and styles. If one person handles both, we avoid wasting time redoing things. Designs are usually static, but when the UI connects to data, style adjustments can be needed and UX/UI Developers can handle it at once
The Model Developer doesn’t have to worry about styling, responsiveness, or UX. They focus on tasks like data transformation and validation, which are more aligned with backend work. When one person handles specific tasks like endpoint models, authorization, and validation, there's no need for constant consultations on how to deliver data, coordination, or solution explanations. The only requirement is to establish a clear model contract with the UX/UI Developer
Backend developers can easily transition into the role of Model Developer thanks to their expertise in business logic
Clearer specializations enhance code quality and the final product—it's challenging for one person, like a frontend developer, to master all areas of web development. Specialists in each domain produce higher-quality code due to their deep expertise
A clearer role division reduces mistakes between the UI and model layers
It can reduce cognitive load and the learning curve for each developer
In some companies, there isn't enough full-time work for designers, but it’s great to have one. However, with a UI/UX developer, the company always has access to design expertise
Separating the model from the UI (browser APIs) opens the door for WASM adoption:
- The model can be written in any WebAssembly-compatible language (e.g., Rust, Go, C++, Python)
- This can improve performance, as the model runs natively in the browser
- Maybe there will be possibility to sharing logic between the backend and frontend, reducing code duplication (e.g., types, validations) and saving time spending on writing the same things

To make this separation I started prototyping UI Model Library in JS/TS for better visualization what Model Layer should include

UI Model Library - Basic requirements

Include built-in Dependency Injection, validation, state management, caching, API handling, reactivity
Universal solution that works with various UI frameworks
APIs should be standardized (e.g., method names, data consumption), similar to how web standards work for browsers

The next article will explore the UI Model library in more detail.

Fragments — incoming new feature for Angular Developers

Adalbertus Chris — Tue, 21 Nov 2023 22:40:36 +0000

What are fragments?

A fragment is an independent block of logic. In simpler terms, a fragment is just a method. Just like the service allows for the injection of dependencies, can maintain its own state, and has access to the executing context — such as other fragments and methods defined within that context. Let’s compare the standard approach using services with the use of fragments.

In picture above you can notice that approach with fragments is more granular, allowing us to split our code into smaller blocks for flexible use.

What are the benefits of using fragments?

Example 1

Let’s assume we have 3 services: Service A, Service B, and Service C as on picture below:

We received a new requirement to use our method C1 in the app component. Initially, the thought was to inject Service C into the app component. However, this would lead to a larger main bundle containing unnecessary code (such as method A1 and method B1), which is not desirable.

Another option is to move method C1 to new service and let’s assume that method C1 relies on method B2 from Service B. So this approach still require injecting Service B and would consequently include unnecessary code (specifically method B1) in the main bundle. Additionally, we cannot move method B2 to this new service, because we also use it in a different place.

Finally we decided to create 2 new services: Service D with method C1, Service E with method B2 (see picture below). We ended up with services, each having only a single method and subsequently, our next step is to properly register all services in the providers and ensure their correct injection.

This rebuilding process consumed a significant amount of time and posed a risk of introducing bugs.

We ended up with services, each having only a single method, so a more effective strategy would be to use fragments. This approach should prevents situations like the one mentioned above. When new logic is required, we simply add our new fragment to a specific context, leaving the remaining code untouched. If there’s a need for different behavior (logic) within a context, you have the option to replace fragments with others.

Example 2

Let’s consider the scenario where we have three services: Service A, Service B, and Service C, each with some repetitive code and we decided to introduce inheritance for them. We created base class with one method X and also we have few fields there, which every service use. However, we have to add new feature which requires the addition of two services: Service D and Service E. These services need a different method than method X, but also use the same fields from base class. What options are available to us? We’re unable to introduce a new base class due to the limitation of inheriting from only one class. An alternative possibility is introducing an additional base parent class (as shown in the picture below):

Let’s say we stick with this solution, but during our app’s development, we need to add two more services: F and G. These services operate with different logic and do not use all fields from the base class. We realize that inheritance wasn’t the most suitable choice and end up rewriting everything for example into separate base services, each with a single method. This process consumed again a significant amount of time and posed a risk of introducing bugs.

In the fragment-based approach, we’re able to define three distinct fragments and effortlessly include them in the Context. This eliminates the need to spend time contemplating a better solution such as inheritance or composition.

Example 3

Let’s assume that we wrote apiService as on picture below:

The code repeats, particularly in result mapping and it can be identical across all upcoming API services. Although a base class could resolve this, it might lead to a scenario similar to Example 2. Therefore, opting to use Fragments is a more preferable solution. The image below shows code using fragments:

Each new API file will contain only a few lines of code, and we can easily modify its implementation if needed.

You’ve seen the advantages of using fragments in the examples above, but there’s more to explore. Let’s take a deeper dive into fragments.

Fragment templates

Each fragment has to be created from a template. In Example 3, we created our fragment using the apiFragment template. Templates help us efficiently handle repetitive behaviors and activities. Currently, the fragments library contains a few predefined templates:

pureFragment — it executes the fragment function, if there’s a change in the fragment input
memoFragment — executes the fragment function once, remembers the result, and returns the memoized result for another executions
apiFragment — contains built-in tools for handling API communication
storeFragment — contains built-in tools for managing state, it shares similar behavior with memoFragment
formFragment — contains built-in tools for managing forms, it shares similar behavior with memoFragment

Currently, we have only a few predefined templates, but new ones, like debounceFragment, will be added in the future. The library also allows us to create custom templates using a dedicated builder API, providing the flexibility to construct templates tailored to our specific requirements.

In this example below, you can see how we can use the formFragment template to create our fragment

As mentioned before, the formFragment template comes with built-in tools necessary for creating and managing forms. This eliminates the need to create a service and inject all dependencies into it (such as formBuilder in this case). Additionally, it includes the _observe method allowing for subscription to form value changes, and it automatically unsubscribes it when the fragment is destroyed.

Context

The context is also a crucial element in fragments, as it acts as the connection between them. Let’s explore code below to see how context can be used:

As you can see above Context connects fragments. When different behavior is needed, it’s easy to replace fragments. Creating and using a Context is similar to services: adding it to providers, injecting it into components, and call actions.

In fragments, they can access the context where they’re executed. See the picture below:

In the draw$ fragment, we have access to the store$ fragment, compare method. The compare method may have different implementations based on the context it’s used within. Therefore, in fragments, we’re not limited to one specific type of context, we can use abstraction, as shown in the image above. For instance, within the draw$ fragment, we can use either PeopleComponentContext or StarshipComponentContext

Every context needs to be registered in providers. This allows us to manage the lifespan of the context and all the fragments included within it. By adding the context to component providers, both the context and its fragments will remain alive as long as the component exists.

Fragments is an open-source library that will soon be available in beta version on npm. You can find the entire code at https://github.com/webfragments. I encourage leaving feedback, opinions, or any other ideas in the comments section.

Summary

Working with fragments can be simpler than using the standard service approach. It eliminates complexities like classes and inheritance. This idea makes code more flexible, by splitting it into smaller parts can improve performance. We can create shareable fragments, build our libraries, and reuse them in various projects. Fragments are also tree-shakeable.