DEV Community: Tobias Augenstein

Beyond Workarounds: A Journey to Refine Reactive Data Models

Tobias Augenstein — Tue, 14 Oct 2025 04:57:23 +0000

A long time ago, a small city in the beautiful South of Germany, an even smaller but innovative software company - that's where this journey started.

First Encounter

The company I worked for specialized in low-code business process automation. I had just been promoted to lead frontend product development and was in charge of creating a visual UI builder that would seamlessly integrate with the existing product ecosystem. Initially we thought building a custom reactivity system for dynamic UIs wouldn’t make sense - obviously we should build on top of something proven and stable rather than reinventing the wheel, right?

Back then Knockout seemed like a good choice and it worked well at the beginning. But over time, the more we built on top, the more we had to work around default behavior of the framework and ran into performance, stability and maintainability issues. At some point I figured it would be easier to replace it with a custom foundation that really fit our needs instead of continuing to add more workarounds. Eventually we developed a simple specialized core API and afterwards it actually worked fast and reliable with minimal maintenance.

History Repeats

Later in my career I was involved in building other complex products based on Angular and Vue. The experience with both of them was not much different. They work okay for standard web projects, but when you build highly-configurable products on top it becomes painful. The new APIs in Vue 3 and Signals in Angular finally support more flexibility and control, but working with them is still not really convenient from my perspective.

One of my IT teachers in high school once said: A good developer needs to be lazy. I took that to heart. :)
I'm too lazy to pass around additional meta-context all the time because the data model has no idea about itself. Too lazy to always explicitly initialize nested objects before access. Too lazy to map data to a different data-structure to do basic operations efficiently. I also don’t want to separately manage state tracking for validation and loading. And I don't want broken reactivity that’s a nightmare to debug because something was not created or tracked at the right time or in the right context.
But how can these issues be avoided? My go-to solution has been custom data wrappers.

Applied Lessons

While repeatedly building wrappers and proxies around reactive data, I noticed recurring patterns. In the following sub-chapters we'll have a look at some of the most useful concepts. The code examples use implementations with plain values that can be adapted across frameworks (just replace the plain values with reactive primitives like Vue Refs, Angular Signals, etc.). Later implementations extend previous ones and focus on relevant new aspects to keep things tidy.

Implicit Initialization

In nested object structures it can be quite tiresome and error prone to always make sure objects are initialized before accessing properties. Modern JS features and TS help, but it’s still not convenient. A custom wrapper that dynamically accesses properties can simplify that.

Plain optional initialization:

data.users ??= {};
data.users[userId] ??= {};

const user = data.users[userId];

user.contact ??= {};
user.contact.email = email;
user.location ??= {};
user.location.address = address;

Wrapper with implicit initialization:

const user = model.prop('users').prop(userId);

user.prop('contact').prop('email').set(email);
user.prop('location').prop('address').set(address);

With TS we can ensure that dynamic keys only support valid properties and that the child model inherits the correct type. Here’s a basic version of the prop() method.

prop<K extends keyof T>(key: K): Model<T[K]> {
  let prop = this.props.get(key) as Model<T[K]>;
  if (!prop) {
    prop = new Model();
    this.props.set(key, prop);
  }
  return prop;
}

Simplified initialization is nice, but the real value of this model approach shows when things get more complex. So let's move on to more advanced concepts.

Context-Awareness

Ever had this issue: You pass data to a function or child component and later you need the key or index of that data? Or you want to remove data but can’t do that without access to its parent. Sure, you can pass down the key, index, parent or whatever else you need. If it’s just one level that’s not a big deal, but in complex applications it can become very messy. Wouldn’t it be great if the data model just had this context information available?

This is how an example could look:

function performAction(user: Model<User>, action: UserAction): boolean {
  console.log('Perform action for user ', user.key, ': ', action);

  switch (action) {
    case 'duplicate':
      return duplicateProp(user, createId());
    case 'remove':
      return user.remove();
    default:
      throw new Error(`Unknown action: ${action}`);
  }
}

duplicateProp function

function duplicateProp<T>(prop: Model<T>, newKey: string): boolean {
  const parent = prop.parent as Model<Record<string, T>> | undefined;
  if (parent) {
    parent.prop(newKey).set(prop.get());
    return true;
  }
  return false;
}

Here’s a basic outline of the implementation (see full class in the collapsible below).

class Model<T> {

  readonly key?: string;
  readonly parent?: Model<unknown>;

  // ...

  remove(): boolean {
    const props = this.parent?.props;
    if (props && this.key) {
      return props.delete(this.key);
    }
    return false;
  }
}

Full Model class

type KeyOf<T> = keyof T & string;
type PropOf<T> = T[KeyOf<T>];

class Model<T> {

  protected props?: Map<string, Model<unknown>>;
  protected value?: T; // replace with reactive primitive

  constructor(data?: T, readonly key?: string, readonly parent?: Model<unknown>) {
    this.set(data);
  }

  get(): Partial<T> | undefined {
    if (!this.props) {
      return this.value;
    }
    const data: Partial<T> = {};
    for (const [key, prop] of this.props) {
      data[key as KeyOf<T>] = prop.get() as PropOf<T>;
    }
    return data;
  }

  set(data?: Partial<T>): void {
    if (typeof data === 'object' && data !== null) {
      this.clear();
      for (const [key, value] of Object.entries(data)) {
        this.prop(key as KeyOf<T>).set(value as PropOf<T>);
      }
    } else {
      this.value = data;
      this.props = undefined;
    }
  }

  clear(): void {
    this.value = undefined;
    this.props?.forEach(prop => prop.clear());
  }

  prop<K extends KeyOf<T>>(key: K): Model<T[K]> {
    this.props ??= new Map();
    let prop = this.props.get(key) as Model<T[K]>;
    if (!prop) {
      prop = new Model<T[K]>(undefined, key, this);
      this.props.set(key, prop);
    }
    return prop;
  }

  remove(): boolean {
    const props = this.parent?.props;
    if (props && this.key) {
      return props.delete(this.key);
    }
    return false;
  }
}

Consistent Access & Iteration

Another recurring challenge is deciding whether to store a collection as an array or a map. At first it seems easy - arrays for lists and maps for key-based lookup. But in many real-world cases you need both and then it gets complicated. A model that supports both internally and transparently keeps them in sync can be very useful for those cases.

const model = new Model({a: true, b: false, c: null});

log(model.prop('b').index); // → 1
log(model.item(1).key); // → b

log(model.child('b') === model.child(1)); // → true

model.forEach(child => log(child.index, child.key, child.get()));
// → 0 a true / 1 b false / 2 c null

If the base structure is a list, the model can automatically generate keys to allow the same kind of dual access. Let's dive deeper into that!

Stable (Deep) References

Using indexes for referencing list items can easily become inconsistent when the list changes. And using an ID to identify items leads to inefficient search in the list. With our combined model approach and generated keys, a stable and efficient lookup is fairly simple.

class ListSelection<Item> {

  protected key?: string; // replace with reactive primitive

  constructor(readonly list: Model<Item[]>) {
  }

  get selected(): Model<Item> | undefined {
    const {key} = this;
    return key ? this.list.child(key) : undefined;
  }

  select(index: number): void {
    this.key = this.list.item(index).key;
  }
}

And the implementation is also quite straightforward, although it should have better key/index validation than the following minimalistic example.
List Access Impl.

type ItemOf<T> = T extends Array<any> ? T[number] : unknown;

class Model<T> {
  // ...

  #items?: Model<ItemOf<T>>[];

  protected get items(): Model<ItemOf<T>>[] {
    return (this.#items ??= []);
  }

  get index(): number | undefined {
    // for better performance, cache the index when creating the item
    //   and update or mark as dirty when the list changes
    return this.parent?.items.indexOf(this);
  }

  child(key: string | number): Model<ItemOf<T>> {
    if (typeof key === 'string') {
      return this.prop(key as KeyOf<T>) as Model<ItemOf<T>>;
    }
    return this.item(key);
  }

  item(index: number): Model<ItemOf<T>> {
    if (index < this.items.length) {
      return this.items[index];
    }
    return this.add();
  }

  add(data?: ItemOf<T>): Model<ItemOf<T>> {
    return this.insert(this.items.length, data);
  }

  insert(index: number, data?: ItemOf<T>): Model<ItemOf<T>> {
    const key = this.createKey(); // creates a unique item key
    const item = new Model(data, key, this);
    this.items.splice(index, 0, item);
    this.props.set(key, item);
    return item;
  }
}

Now we have stable references for items of flat lists, but what if we have deep nested data structures and want to reference any entry there? With a few little extensions we can cover that too.

const node = tree.prop('nodes').item(3).prop('nodes').item(2);
const ref = node.ref; // stable deep reference

log(tree.resolve(ref) === node); // → true
log(node.resolve(ref) === node); // → true
log(node.resolve(SpecialKeys.root) === tree); // → true
log(node.resolve(SpecialKeys.parent) === node.parent); // → true

This provides us with a powerful way to reference any other entry within the same model hierarchy by relative or absolute (root-based) references. And the implementation for that is also no rocket science.
Deep Reference Impl.

class Model<T> {
  // ...

  get root(): Model<unknown> {
    return this.parent?.root || this;
  }

  get ref(): string {
    const base = this.parent?.ref || SpecialKeys.root;
    return this.key ? `${base}.${this.key}` : base;
  }

  resolve(ref: string): Model<unknown> | undefined {
    let model: Model<unknown> | undefined = this;
    for (const key of ref.split('.')) {
      model = model?.access(key);
    }
    return model;
  }
}

  access(key?: SpecialKeys | string | number): Model<unknown> | undefined {
    if (!key) return this;
    switch (key) {
      case SpecialKeys.root:
        return this.root;
      case SpecialKeys.parent:
        return this.parent;
      default:
        return this.child(key);
    }
  }

Internal Validation & Loading State

In most applications we need to be able to check whether data is currently loading and if changed data is valid. Logically, both of these state information are closely tied to the data - including them directly into the data model avoids inconsistencies and helps to keep the code simple.

submitTask(task: Model<Task>): void {
  if (task.isValid && !task.isLoading) {
    // ...
  }
}

The following code snippet shows a simple example for loading state integration.
Simple Loading State

export class Model<T> {
  // ...

  protected loading = 0; // replace with reactive primitive

  get isLoading(): boolean {
    return !!this.loading;
  }

  async updateAsync(promise: Promise<T | undefined>): Promise<boolean> {
    this.loading++;
    try {
      const data = await promise;
      this.set(data);
      return true;
    } catch (e) {
      // add error handling
      return false;
    } finally {
      this.loading--;
    }
  }
}

Depending on the context, you may want to use external libraries or track additional meta information, especially for validation. In the next chapter we will explore more advanced patterns to track different kinds of async state simple and reliable.

Generic Async State Management

For simple cases a boolean flag, status type or counter can be enough to track the state of async operations. But often we need more detailed state information, for example error messages. Plus we also want to be able to cancel pending operations and avoid race conditions. The following implementations solve those issues with a lightweight, unified wrapper class.
Loading

class Model<T> {
  // ...

  #request?: DynamicState;

  get request(): DynamicState {
    return (this.#request ??= new DynamicState());
  }

  get isLoading(): boolean {
    return this.request.isPending;
  }

  async updateAsync(promise: Promise<T | undefined>): Promise<boolean> {
    const update = this.request.update();
    try {
      const data = await promise;
      return update.ready(() => this.set(data));
    } catch (e) {
      console.error(e);
      update.fail('Request failed');
      return false;
    }
  }
}

Validation

class Model<T> {
  // ...

  #validation?: DynamicState;

  get validation(): DynamicState {
    return (this.#validation ??= new DynamicState());
  }

  get isValid(): boolean {
    return this.validation.isSuccess;
  }

  async validate(check: (model: Model<T>) => Promise<string | undefined>): Promise<boolean> {
    const validation = this.validation.update();
    const errorMsg = await check(this);
    if (errorMsg) {
      validation.fail(errorMsg);
      return false;
    }
    return validation.ready();
  }
}

Dynamic State

type StateValue = 'pending' | 'success' | 'failed' | 'canceled';

class StateUpdate {

  constructor(protected _ready?: (state: StateValue, message?: string) => void) {
  }

  ready(success?: () => void, message?: string): boolean {
    if (this._ready) {
      success?.();
      this._ready('success', message);
      return true;
    }
    return false;
  }

  fail(message?: string): void {
    this._ready?.('failed', message);
    this.destroy();
  }

  cancel(): void {
    this._ready?.('canceled');
    this.destroy();
  }

  destroy(): void {
    this._ready = undefined;
  }
}

class DynamicState {
  #state?: StateValue; // replace with reactive primitive
  #message?: string; // replace with reactive primitive
  #update?: StateUpdate;

  get isInitial(): boolean {
    return !this.#state;
  }

  get isPending(): boolean {
    return this.#state === 'pending';
  }

  get isSuccess(): boolean {
    return this.#state === 'success';
  }

  get isFailed(): boolean {
    return this.#state === 'failed';
  }

  get isReady(): boolean {
    return this.isSuccess || this.isFailed;
  }

  get message(): string | undefined {
    return this.#message;
  }

  update(): StateUpdate {
    this.#state = 'pending';
    this.#update?.destroy();
    this.#update = new StateUpdate((state, message) => {
      this.#state = state;
      this.#message = message;
    });
    return this.#update;
  }
}

Beyond Wrappers

As we have seen, many useful data model features can be realized by just wrapping reactive values of common frameworks. This approach can add convenience and help to maintain cleaner code, but it can’t overcome deeper limitations. Handling edge cases efficiently and reliably also becomes tricky. Let’s look at two more fundamental issues I’ve struggled with and concepts to address them.

Explicit Dependency Tracking

Sometimes there is side-effect logic within the code that’s executed by reactive bindings. If that logic accesses reactive data, a change of this data will also trigger an update, even though it’s not meant to be a dependency. Angular, for example, introduced an untracked function as part of Signals to avoid unwanted tracking. Explicit tracking inverts that approach, enables more flexible control and makes it more transparent which parts of an application depend on reactive values.

More importantly, it seamlessly works with async logic. Modern front-ends rely a lot on async logic, but reactive state tracking usually requires sync execution of dependencies. That means, all reactive values need to be resolved outside of async code and then be passed down through async call hierarchies, which limits architecture options and can easily lead to significantly more complex FE structures. Explicit dependency tracking provides more architectural freedom and, for example, enables us to organize main structures more in an OOP style. But it requires a fundamentally different approach to reactivity and can’t be done by just adding a wrapper for sync reactive systems.

Here’s a separate article on how it can be a game-changer for async reactive logic, in case you want to dive deeper:

Tobias Augenstein

Sep 4 '25

An Explicit Approach to Async Reactivity

#webdev #javascript #typescript #architecture

Comments

2 min read

Language-Agnostic Full-Stack Models

A big annoyance in full-stack applications is managing consistent data models between FE and BE. One solution is using JS for BE, but that’s not an option in many contexts for good reasons - while there have been many improvements, it’s still not well suited for building reliable and scalable business logic. The Google Web Toolkit tried another interesting approach to use a common language, but using Java for FE was too complex. And in general I don’t think it’s a good idea to become limited to one specific language. To me, the best solution for this issue seems to be a declarative abstraction layer that defines data structures and high-level validation logic. Standards like OpenAPI and GraphQL enable shared schemas, but they don’t support shared logic for computed data and advanced validation. I’d like to have a unified full-stack solution that defines data structures and their related logic in a consistent way. When such structures are based on a common format like JSON, it’s relatively easy to build interpreters in most major languages, which can provide a lot of technological flexibility. That’s what the next step of my journey is aimed at.

A New Foundation

Throughout my career I have come across all the above issues repeatedly and developed multiple solutions for most of them. Eventually I became tired of solving the same things over and over again, so I started to create one framework to solve them all. :)

If you want to learn more about it, here’s an overview on the general concepts:

Tobias Augenstein

Mar 5 '25

Bridging the Gap: Low-Code for Web Developers

#webdev #lowcode #nocode #architecture

Comments

5 min read

And Now?

Now you wait until my framework is released and all struggles will be gone! 😁

Jokes aside, of course these concepts don’t solve all issues with data models and obviously they also come with trade-offs. But I hope they can provide some help to work more efficiently with reactive data.

And if you’re interested to see my framework’s prototype in action or follow the further development, check out the website:
https://ontineo.com

An Explicit Approach to Async Reactivity

Tobias Augenstein — Thu, 04 Sep 2025 06:14:06 +0000

One of the biggest pain points I've experienced with modern web frameworks is the combination of async logic and reactive bindings. Working with async code that only depends indirectly on outer reactive data is manageable, although even that can be cumbersome. But once you try to track reactive dependencies nested inside async calls… you'll probably want to refill your coffee first.

Coffee may help ☕, but I’d rather rely on a more flexible technical approach 🧑‍💻.

Core Concept

A straightforward solution to track dependencies within async functions is passing an execution context. Typically reactive dependencies are tracked by implicit magic in the background. That's in general great for simplicity but provides limited control and does not work well with async logic. Requiring an explicit context is much less convenient for simple cases, but becomes valuable when things get complex.

Let’s see how that could work in a simple TS example:

class UserCalendar {

  readonly userId: ReactiveValue<string> = new ReactiveValue();
  readonly date: ReactiveValue<IsoDate> = new ReactiveValue();

  protected provider = new CalendarProvider();

  async getUserEvents(ec?: ExecutionContext): Promise<Event[]> {
    const id = this.userId.get(ec);
    const calendar = await this.provider.getUserCalendar(id);

    return this.provider.getEvents(calendar, this.date.get(ec));
  }
}

The explicit context provides full control over dependency tracking and works well with async execution. It can also define custom triggers to update bindings without workarounds like reactive counters.

I personally prefer to trade some convenience for additional clarity and control, but I understand that always having to pass the context can be considered too tedious. So let's solve that!

Another Layer

To really make this approach shine, we need an additional layer of abstraction. And while we’re at it, wouldn’t it be nice to simplify async execution more fundamentally by defining high-level functionality in a more declarative way?

I think there are many good reasons to use a low-code abstraction layer on top of JS, transparent async logic is one of them. When dealing with high-level features we shouldn’t have to worry whether a method is async or not. Changing from sync to async shouldn’t break anything, it should just work!

Let’s have a look at our previous example again, this time as a low-code service definition:

{
  "services": {
    "provider": {
      "service": "my-project:calendar-provider"
    }
  },
  "methods": {
    "getUserEvents": {
      "action": {
        "_action": "service",
        "service": "@provider",
        "method": "getEvents",
        "params": {
          "calendar": {
            "_bind": "action",
            "read": {
              "_action": "service",
              "service": "@provider",
              "method": "getUserCalendar",
              "params": {
                "userId": {
                  "_bind": "data",
                  "ref": "userId"
                }
              }
            }
          },
          "date": {
            "_bind": "data",
            "ref": "date"
          }
        }
      }
    }
  }
}

This kind of abstraction enables implicit dependency tracking while keeping the advantages of an explicit execution context under the hood.

Of course editing JSON directly would also require a lot of coffee ☕, but I believe with a good visual IDE 🧑‍💻 it can be a powerful alternative to code-based frameworks for many use cases.

What are your thoughts? Would you consider using this kind of low-code approach for simpler and transparent handling of async execution?

Here you can read more details about my vision for low-code web development:

Tobias Augenstein

Mar 5 '25

Bridging the Gap: Low-Code for Web Developers

#webdev #lowcode #nocode #architecture

Comments

5 min read

Freedom to Refactor: A Blessing or a Trap?

Tobias Augenstein — Thu, 24 Jul 2025 06:31:16 +0000

Last year I started working as an independent developer to create a project that I’ve dreamed of doing for many years. One key benefit I saw in being independent was that I could finally do as much refactoring as I wanted. :) Now here I am, reflecting on that freedom and my latest big refactoring.

Context

The project I’ve been working on is a framework for low-code web development. At some point it needed a visual IDE and I figured using the framework itself to develop the IDE would make the most sense - it tests the framework thoroughly with a real, complex use case and also avoids external dependencies. For the UI, initially defining the low-code JSON configurations without a visual editor seemed reasonable and worked quite well, but for the background logic of an IDE, not so much. So I needed a flexible integration between the low-code configurations and the code. I started with a relatively simple but hacky approach that worked well for a first prototype, but doesn’t scale well. Which leads us to the main story of this article.

The Struggle

As developers we often like to complain about management and customers, but no great software is truly great without real impact. I’m currently free from any kind of management or customers, but I’m still not really free. How I use my time now may determine my future freedom and how much impact my work will have. Having significant delays for new features due to refactoring is painful and often seeing little progress in the process can be frustrating. I’m convinced that real innovation can’t be forced, at least my brain is usually not the most creative under pressure. I’m also not able to fully plan complex changes in advance, I have to go step by step and see how things unfold. And there’s a real risk of just replacing one flawed approach with another, potentially even more problematic one. Knowing what’s not good is fairly simple, doing it better is often harder than it seems. What if a new approach also has significant issues? Do I push through and accept these issues or go a big step back, giving my brain the space and time to come up with a better solution?

I decided to go the hard, long way - now that I finally have the freedom I always wanted, I gotta make it count. At the beginning of this project I was determined not to create another “okay” framework. I’d either come up with something I’m really excited about or throw it away. But over time things became more complicated. The framework surpassed my boldest initial dreams, but the IDE architecture was too complex and inflexible. Changing that would require making the framework itself even more flexible, not just refactoring the IDE. My motivation was quite low, I wanted to build new features, not spend weeks or months defining new core architecture and rebuilding existing stuff. It was tempting to just polish my workarounds and move forward, but I didn’t want to betray my core principles for the project at this early stage.

The Gain

Reaching meaningful success after a difficult refactoring feels very rewarding. The gain of efficiency and clarity, being able to keep the same functionality with less code and based on more intuitive concepts. Imagining how it will simplify development moving forward.

Parts of my IDE refactoring are still in progress, but its base architecture is now worthy of the framework and it’s super exciting to see it unfold. The framework itself is not only more flexible but even a bit simpler than before. It now provides an easy way to build on low-code UI components within TypeScript code. That supports developing complex applications in code while maintaining most of the UI in the visual editor, which still enables a high level of customization and adaptation without touching code.

Let’s look at a simple example:

interface InputParams {
  label?: string;
  placeholder?: string;
}

class InputComponent extends CustomViewComponent<string, InputParams> {

  get viewRef(): PlainResourceRef {
    return 'forms:input';
  }
}

Related low-code JSON

The forms:input JSON can for example look like this:

{
  "_ui": "view",
  "view": "forms:input-wrapper",
  "params": {
    "label": {
      "_bind": "param",
      "ref": "label"
    }
  },
  "children": [
    {
      "_ui": "html",
      "props": {
        "element": "input",
        "value": {
          "_bind": "data"
        }
      },
      "params": {
        "attr": {
          "placeholder": {
            "_bind": "param",
            "ref": "placeholder"
          }
        }
      }
    }
  ]
}

The custom superclass in this example provides dynamic parameters to configure the linked low-code component, using a type-safe reactive data model.

abstract class CustomViewComponent<T, P> extends NativeViewComponent<T> {

  constructor(model: Model<T>, readonly config: Model<P>) {
    super(model);
  }

  protected createViewParams(): RecordType<DynamicProp> {
    return this.modelAsParams(this.config);
  }
}

Such code-based components can be combined to more complex structures, controlling hierarchies and core functionality from the code while leaving UI details to low-code.

abstract class SearchDialogComponent extends DialogComponent {

  readonly search: Model<string> = ModelFactory.text();

  protected abstract getContent(): ViewSlotContent;

  protected createSlots(): DialogSlots {
    return {
      header: () => [
        new InputComponent(this.search, ModelFactory.record({
          placeholder: 'Search',
        })),
      ],
      content: () => this.getContent(),
    };
  }
}

The JSON for the UI components can be provided from files, a database, local storage or whatever other source. Even within the same application it can be dynamically exchanged based on user or use case. For the IDE, this can enable different UI versions based on the user’s level of expertise or adjustments for embedded editing.

I believe this kind of flexible integration between code and low-code in both directions holds incredible potential for building advanced customizable web applications. In most cases, native services are likely still the better option to integrate code-based logic and keep flexibility on the low-code side. But where more control from code is desirable, the new approach creates a powerful alternative.

Worth it?

So is this refactoring worth the time and effort or should I have continued and published with the hacky solution? To be honest, I'm not sure, focusing on more features first and publishing faster might have been overall more beneficial. But it feels good to do things “the right” way, at least for now… :)

For more details on the core concepts of the project read this article:

Tobias Augenstein

Mar 5 '25

Bridging the Gap: Low-Code for Web Developers

#webdev #lowcode #nocode #architecture

Comments

5 min read

Or visit the website: https://ontineo.com

Is AI the new Low-Code? The Story of a Horse Cart

Tobias Augenstein — Thu, 20 Mar 2025 07:54:19 +0000

To me, using AI to develop applications based on traditional code feels like attaching a jet engine to a horse cart. But let’s start from the beginning.

AI Hype vs. Developer Reality

Recently I’ve repeatedly seen posts and articles claiming “AI is the new Low-Code/No-Code”. And since I’m currently working on a project that’s focused on low-code development, people keep asking me if that still makes sense considering AI can write code now. There seems to be a widespread sentiment that optimizing development concepts makes no sense anymore - apparently AI solves all development issues. At the same time I come across posts from many developers who are frustrated, because in their daily experience of working with AI, they don’t see it living up to the hype and the rising expectations that come with it. Maybe they are all just not good at writing prompts or use the wrong models, but I doubt it. To me it seems obvious that AI increases the need for better development concepts.

The Horse Cart

I’m from Germany and on the German Autobahn (highway) there’s no speed limit. If your car and the traffic allow it, you can drive 300 km/h or even faster. But for that to work well you not only need a good engine, the whole car needs to be designed appropriately. It needs good wheels, good brakes, good steering, …
You can’t just take a horse cart, replace the horse with a jet engine and then think you’ve got an awesome super fast vehicle. Even if you get it to work it will be very bumpy, hard to maneuver and most likely won't end well. It definitely wouldn’t be allowed to drive on the Autobahn. :)

A jet engine could make a horse cart much faster, but should it?
AI can generate lots of code very fast, but should it?

Back to Reality

To be fair, comparing modern programming languages to a horse cart might not be the best fit, perhaps they are more like cars. But attaching a jet engine to a car is still not a great idea. It could be a cool experiment, but not useful for daily life. In a similar way, I think AI coding can work well in some contexts, but for high-level features of most standard applications it’s probably not the best approach.

Current AIs lack real intelligence and creativity - they just do efficient pattern matching, which can be very effective with common patterns. But the more diverse, nested and unconventional the combinations of patterns are, the more insufficient are the results. To efficiently work with AI we still need simple ways to create and fix unconventional things ourselves. Our best source of intelligence and creativity is still our brain. As far as I understand, current AI architectures will always struggle to apply uncommon details. For that we need scalable low-code concepts, because reviewing, fixing and extending lots of AI-generated code is no fun. For AI it’s also not ideal to work with code, especially in an environment with dependencies across several different languages. With a higher level of abstraction and simpler logical structures, AI can work better and is less likely to make mistakes. At least that's what AIs told me. 😁

AI vs. Visual Tools

For many tasks, using specialized tools is more efficient than instructing an AI. AIs are awesome, but not for everything. Examples:

Moving an element in a UI is easier by drag and drop with a good WYSIWYG editor than telling an AI to do it.
Adding or removing a step in a workflow is easier with a visual workflow builder than doing it with AI in code. Especially if you don’t know the workflow by heart and first need to ask AI to explain or visualize it.

Ideally we should have good visual development tools and AI combined. For example, use AI to generate a workflow based on some high-level description and then modify details by drag and drop. Visual tools reduce the cognitive complexity for our brain. Often doing a task is the easiest part, figuring out what the system currently does and what needs to be changed can be much more challenging. Even if we end up mainly using AI to apply changes, consistent visual representations are still very helpful for the whole development process.

Conclusion

AI and low-code development shouldn’t be seen as competing approaches, they should complement each other. AI can do most of the groundwork while visual editors help us to efficiently review and modify the results. There are already numerous low-code platforms with AI integration available, but one of the key problems is a common lack of flexibility regarding technical concepts and licensing. I think moving forward we need a simple and flexible abstraction layer on top of code that overcomes the technical and legal limitations of established low-code platforms. In my opinion it's long overdue and with AI it has become even more important.

For more details, how I envision that abstraction layer, you can read this article:

Bridging the Gap: Low-Code for Web Developers

Tobias Augenstein ・ Mar 5

#webdev #lowcode #nocode #architecture

Or check out the related project page:
https://ontineo.com

Bridging the Gap: Low-Code for Web Developers

Tobias Augenstein — Wed, 05 Mar 2025 21:13:08 +0000

Since the early days of my software development career (~15 years ago), I’ve dreamed of a development approach that makes it easy to build and customize professional web applications. Many frameworks have promised to make development simple, but I personally never really found that to be true. While there have been lots of significant improvements (new web standards, TypeScript, SASS, npm, ...) and useful new frameworks, most professional web development still relies on the same languages. TypeScript extends JavaScript, SASS extends CSS and most web frameworks extend JS/TS & HTML. In addition, the setup, deployment and general tech-stack have become more complex. So the overall complexity has become higher, not lower. We keep building more and more on top with limited innovation regarding the fundamental development concepts.

On the other hand there has been a rise of low- and no-code platforms and some of them are really good for certain kinds of use-cases. Unfortunately they usually cause even more headache than web frameworks once you reach the limits of their built-in functionality. But why?
In code we can build core components for frameworks with the same technical concepts as high-level structures, why can’t we do that with low-code concepts? Why does low-code typically fall back to code templates for base components?

I believe it's time to combine the best of both worlds, enabling efficient low-code development based on a well-defined abstraction layer that offers similar flexibility as common web frameworks.

It’s all about trees...

For web UI components the solution is relatively simple. Low-code UI elements are usually defined by a component reference and component-specific attribute configurations. If we support native DOM elements as a special kind of component with generic attributes, we get the full flexibility of HTML directly within the low-code UI structure. We can also combine native DOM elements and higher level components within the same hierarchy. But that doesn't really help much if we still need JavaScript and CSS for logic and styling.

While thinking through more holistic approaches I realized that DOM/UI, scripts/actions and stylesheets have one thing in common - they are all trees. And the nodes of all those trees can be defined based on the following attributes:

Node type: Each tree type has its own set of node types defining different core node implementations. All other attributes depend on the chosen node type.
Properties: Dynamic attributes for the node’s primary/core implementation.
Parameters: Dynamic attributes for a secondary/linked node implementation (e.g. UI component or service method).
Events: Actions to be executed based on events triggered by the node.
Children: Default slot for child nodes.
Child slots: Named slots for child nodes.

With this generic structure we can support a wide variety of tree-based development concepts.

... and JSON

Next we need a technical format for our generic tree structure and luckily that decision is easy: JSON! It’s simple, safe, flexible and very widely supported as the dominant data format of the web.
Before diving deeper into conceptual aspects, let’s look at some examples.

Greet button & service example

Here's a button that calls a custom service method and passes a value from the UI's main data model:

{
  "_ui": "view",
  "view": "forms:button",
  "params": {
    "label": "Say Hello"
  },
  "events": {
    "click": {
      "_action": "service",
      "service": "my-project:user",
      "method": "greet",
      "params": {
        "name": {
          "_bind": "data",
          "ref": "fullName"
        }
      }
    }
  }
}

And this defines a basic implementation for the my-project:user service:

{
  "methods": {
    "greet": {
      "action":  {
        "_action": "script",
        "props": {
          "js": "alert(`Hello ${name}.`)"
        },
        "params": {
          "name": {
            "_bind": "param",
            "ref": "name"
          }
        }
      }
    }
  }
}

But using scripts for high-level logic is exactly what we are trying to avoid with a declarative low-code approach, so here's a more advanced and suitable service example, including validation and more abstraction:

{
  "methods": {
    "greet": {
      "action": {
        "_action": "condition",
        "props": {
          "if": {
            "_bind": "param",
            "ref": "name",
            "modifiers": ["trim"]
          }
        },
        "childSlots": {
          "then": [
            {
              "_action": "service",
              "service": "my-project:dialogs",
              "method": "alert",
              "params": {
                "message": {
                  "_bind": "operation",
                  "operator": "concat",
                  "children": [
                    "Hello ",
                    {
                      "_bind": "param",
                      "ref": "name"
                    },
                    "."
                  ]
                }
              }
            }
          ],
          "else": [
            {
              "_action": "service",
              "service": "my-project:validation",
              "method": "missingRequiredValue",
              "params": {
                "key": {
                  "_bind": "param",
                  "ref": "name",
                  "modifiers": ["key"]
                }
              }
            }
          ]
        }
      }
    }
  }
}

Dynamic emoji example

This example defines a native <span> element with a dynamic value binding using a URL hash parameter (e.g. #mode=unicorn). In this case the value property sets the text content of the element, for inputs and other editable elements it provides two-way data binding.

{
  "_ui": "html",
  "props": {
    "element": "span",
    "value": {
      "_bind": "choice",
      "props": {
        "by": {
          "_bind": "url-hash",
          "ref": "mode"
        },
        "cases": {
          "unicorn": "🦄",
          "dragon": "🐲",
          "ocean": "🐠"
        }
      }
    }
  },
  "params": {
    "attr": {}, // Native attribute bindings
    "class": [], // Dynamic class bindings
    "style": {} // Inline style bindings
  }
}

Here you can watch it in action with our IDE prototype:

These JSON trees are easy to parse and modify, by visual editors as well as automation tools. When necessary they are also not difficult to be reviewed and modified manually, e.g. to resolve merge conflicts. It’s also quite simple to build interpreters for actions/services with different back-end programming languages, which makes it a good foundation for technology-agnostic full-stack applications.

Dynamic Stylesheets

One of the most annoying aspects of web development in my opinion are static CSS stylesheets. If you need dynamic styling you either have to pre-define style rules for each case or apply inline style to all involved elements. For many use-cases both options are bad, either for performance or maintainability or even both.

Wouldn’t it be great if we could define dynamic stylesheets? Browsers offer JS APIs for stylesheet manipulation similar to the APIs we use all the time for DOM manipulation. With a dynamic format to define and generate stylesheets we can apply reactive bindings in the same way as reactive DOM bindings.
Let’s look at an example how that can be done with our generic tree structure, using a theme provider service to enable dynamic theme switching.

{
  "services": {
    "theme-provider": {
      "service": "my-project:theme-provider"
    },
    "theme-name": {
      "service": "data",
      "props": {
        "bind": {
          "_bind": "operation",
          "operator": "fallback",
          "children": [
            {
              "_bind": "param",
              "ref": "themeName"
            },
            "main"
          ]
        }
      }
    },
    "theme": {
      "service": "data",
      "props": {
        "bind": {
          "_bind": "action",
          "events": {
            "read": {
              "_action": "service",
              "service": "@theme-provider",
              "method": "getTheme",
              "params": {
                "name": {
                  "_bind": "data",
                  "ref": "@theme-name"
                }
              }
            }
          }
        }
      }
    }
  },
  "rules": {
    "input-field": {
      "_style": "style",
      "props": {
        "elements": [
          "input",
          "select"
        ]
      },
      "params": {
        "color": {
          "_bind": "data",
          "ref": "@theme.color"
        },
        "border-color": {
          "_bind": "data",
          "ref": "@theme.lightBorderColor"
        },
        "border-width": "1px",
        "border-style": "solid"
      },
      "children": [
        {
          "_style": "style",
          "props": {
            "selectors": [
              ":hover",
              ":focus"
            ]
          },
          "params": {
            "border-color": {
              "_bind": "data",
              "ref": "@theme.darkBorderColor"
            }
          }
        }
      ]
    }
  }
}

The result is equivalent to the following CSS rules, but adjusts dynamically if any theme value changes at runtime.

input.#{prefix}-input-field,
select.#{prefix}-input-field {
  color: $color;
  border-color: $lightBorderColor;
  border-width: 1px;
  border-style: solid;
}

input.#{prefix}-input-field:hover,
input.#{prefix}-input-field:focus,
select.#{prefix}-input-field:hover,
select.#{prefix}-input-field:focus {
  border-color: $darkBorderColor;
}

Conclusion

Now we can define UI, logic and styling based on a unified dynamic format, which makes it quite easy to provide consistent visual editors and other tooling for all of them. We can also access the same data and services in the same way in all of those contexts. In addition, we can combine different tree types seamlessly within the same tree structure, allowing simple context sharing between them. For example, bindings and event actions can consistently inherit context from their surrounding node, whether it's a UI, action or style node.
And so far we’re only scratching the surface... :)

What are your thoughts? Would you be interested in this kind of low-code development? Where do you see the biggest benefits or challenges?

PS: This article provides a brief introduction to the core concepts of Ontineo. Stay tuned for deeper dives into advanced technical aspects, architecture details of the prototype and more user-focused considerations.

For further information or to follow the project on social media, visit our website: https://ontineo.com