Wibble JS: Because AI Can Write The PR, But You Still Have To Review It

Frontend code has a strange failure mode: it can work perfectly in the browser and still be hard to trust.

You open a pull request and see a familiar shape: some state moved here, a fetch moved there, a custom hook grew a second branch, a component now forwards five props through three levels, and the important part of the change is somewhere in the middle of it all. The app runs. The tests pass. But the review is still slow, because the code does not tell you what kind of change you are looking at.

AI has turned the volume knob on this problem all the way up.

The bottleneck is no longer only writing code. It is reviewing it. A human reviewer may now receive a large PR that touches many files, adds a new screen, wires data loading, updates state, adds form behavior, and changes routing. The code may be mostly correct. It may even be better than what a tired person would have written late at night. But it is still a lot of surface area to inspect.

Large AI-assisted PRs can quietly tax a repository. Not because AI is uniquely dangerous, but because volume changes the failure mode. Small inconsistencies become easy to miss. One-off patterns become normalized. State moves to convenient places. API calls appear where they happen to work. Reviewers start approving by vibe because reading every line with full attention is expensive, and apparently we all needed another way to feel guilty in a code review.

Wibble is my experiment in making that part explicit.

It is a TypeScript-first frontend framework with .wib component files, a compiler, official stores, browser resources, forms, routing, and a small fine-grained DOM runtime. The idea is not just to make UI updates fast. The idea is to make frontend changes easier to read before they ever run.

The code is on GitHub at github.com/vudodov/wibble, and the core runtime package is published on npm as @wibble/core.

That matters for humans. It matters even more when an AI agent is doing a large part of the coding, because the framework should make the PR easier to audit, not merely easier to generate.

The Shape Problem

Most mature frontend frameworks give you a lot of expressive power. That is useful, but it also means the same feature can be written in many different shapes.

API reads can happen in a component body, an effect, a hook, a route loader, a store, a utility module, or a callback. State can live in local component state, context, a cache, a reducer, a global store, or a custom abstraction. Rendering can be mixed with data transformation and event workflows.

Flexibility is not always bad. But it creates review work.

When the codebase is small, you can keep the conventions in your head. When the codebase grows, the conventions become tribal knowledge. When AI-generated code enters the loop, vague conventions become a bigger problem: the agent can produce code that is technically valid, but not in the shape the team expects.

That missing shape is where review time goes.

If an AI agent changes a React component, the reviewer often has to answer several questions at once. Did it fetch in the right place? Did it create a new state model? Is this effect safe? Is this derived value actually pure? Is this prop being forwarded because it is needed, or because the agent took the shortest path through the tree? Should this be route state, store state, context, or local state?

None of those questions are impossible. But they are tiring, especially across a big PR.

Wibble is deliberately more constrained.

A component is split into named sections:

component Counter

state
  count: number = 0

derived
  doubled: number = count * 2

actions
  increment()
    count = count + 1

view
  section class "counter"
    h1 text "Counter"
    p text "Count {count}"
    p text "Doubled {doubled}"
    button on click -> increment
      text "Increment"

There is not much mystery about where things belong.

state is local mutable state. derived is pure computed data. actions are where mutations and workflows live. view describes the UI. If the component loads data, that goes into a resource block. If it needs shared feature state, that goes into a store.

That is the central tradeoff of Wibble: less freedom in exchange for easier review.

That tradeoff is especially useful for AI-written code. The agent still writes the feature, but the feature lands in predictable compartments. Reviewers can inspect the resource block for data loading, the actions block for behavior, the state block for local state, and the view block for rendered structure. A big PR becomes less of a pile of code and more of a set of categorized changes.

Why A DSL?

The obvious question is why Wibble uses .wib files at all.

Why not just TypeScript functions?

The answer is that Wibble wants the compiler to understand the intent of the file. If everything is arbitrary TypeScript, the compiler can type-check it, but it cannot easily enforce framework rules.

In Wibble, the compiler can say:

• API reads belong in resource blocks.
• State writes belong in actions.
• Derived values must be synchronous and pure.
• Lists must have stable keys.
• Form bindings must be attached to compatible elements.
• Long static class lists should probably become named classes or variants.

Those rules are not decoration. They are part of the framework.

The file becomes closer to a small manifest for the component. That makes it easier for a person to skim and easier for an AI agent to edit without inventing a new local pattern.

This is the part I care about most. The compiler is not just checking syntax. It is defending the codebase against drift. If an agent tries to add a fetch in a view branch, that should be rejected. If state is mutated outside an action, that should be rejected. If a list is unkeyed, that should be rejected. Some of the review burden should move from human attention into framework rules, because human attention is not an infinitely scalable CI system.

Rendering Without A Virtual DOM

Wibble does not use a virtual DOM.

The compiler emits DOM creation code and fine-grained reactive bindings. When a signal changes, Wibble schedules the affected bindings and updates the DOM nodes that actually depend on the changed value.

This component:

component Greeting

props
  name: string

view
  h1 text "Hello {name}"

turns into a small piece of DOM code with a reactive text binding. If name changes, the text node updates. Wibble does not need to re-run a component tree just to discover that one text node changed.

This model is useful for product screens where the UI is dense: tables, filters, forms, side panels, dashboards, and internal tools. You want many small values on the page to update independently without requiring every component to become a performance puzzle.

API Reads Are Resources

Data loading is one of the places where frontend code gets messy quickly.

Wibble gives it one official shape: resources.

component UserPanel

use
  import { api } from "../api"

props
  userId: string

resource user
  key: ["user", userId]
  load: api.users.get(userId, abortSignal)
  staleTime: 30000
  retry: 1

actions
  async rename(name: string)
    await api.users.rename(userId, name)
    invalidate user

view
  if user.loading
    p text "Loading user"
  else if user.error
    p text "{user.error}"
  else
    section
      h2 text "{user.data.name}"
      p text "{user.data.email}"

This makes the data contract visible.

The key is right there. The load function is right there. The refresh policy is right there. The mutation invalidates the resource explicitly.

At runtime, resources handle the boring parts that people often get wrong:

• stable cache keys
• in-flight request dedupe
• aborting stale requests
• ignoring late responses
• stale-time reads
• retries
• explicit invalidation

The practical benefit is simple: a reviewer can look at a resource block and understand how the component talks to the server without spelunking through effects, callbacks, and helper hooks.

Actions Are The Mutation Boundary

Wibble keeps writes in actions.

state
  editing: boolean = false
  draftName: string = ""

actions
  startEditing()
    draftName = user.data.name
    editing = true

  cancelEditing()
    editing = false

  async save()
    await api.users.rename(userId, draftName)
    invalidate user
    editing = false

That is not just stylistic.

When state can be written from anywhere, it becomes harder to know what user actions can change the screen. Wibble puts those workflows in one section. If a pull request changes behavior, the actions section should usually show it.

It makes diffs easier to read.

It also gives AI agents a clear target. If the task is "make the save button refresh the user after saving", the edit belongs in actions, not somewhere in a render branch or effect.

Shared State Without Prop Tunnels

Props are still the right tool for direct parent-child data. But once data is shared across a feature, prop forwarding becomes noise.

Wibble uses stores for feature state.

store CartStore

state
  items: CartItem[] = []

derived
  count: number = items.length
  total: number = sum(items.map((item) => item.price * item.quantity))

actions
  add(item: CartItem)
    items = append(items, item)

  remove(id: string)
    items = items.filter((item) => item.id != id)

  clear()
    items = []

A store is not an atom graph. It is a feature module.

It groups state, derived values, resources, and actions behind a typed boundary. Components can consume the store explicitly:

component CartButton

use
  import { CartStore } from "../state/CartStore.wib"

state
  cart: CartStoreInstance = CartStore.use()

view
  button text "Cart {cart.count.get()}"

This keeps shared state searchable. You can find the store. You can find the action. You can find the component that consumes it. That sounds boring, which is exactly the point.

Wibble also supports context, but it is meant for stable dependencies: stores, services, clients, and feature-level providers. It is not meant to become a hidden global state bucket.

Forms Are First-Class

Forms tend to accumulate small mistakes: a dirty flag here, touched state there, validation that runs too early, error text that is not wired to the input, submit state that races with navigation.

Wibble ships form primitives so common form work has one shape.

component SearchPanel

use
  import { createField, createForm } from "@wibble/forms"
  import type { Field, Form } from "@wibble/forms"

state
  query: Field<string> = createField("")
  includeArchived: Field<boolean> = createField(false)
  form: Form<{ query: Field<string>, includeArchived: Field<boolean> }> = createForm({ query, includeArchived })

actions
  submit()
    search(form.values())

view
  section
    input bind value query placeholder "Search"
    label
      input type "checkbox" bind checked includeArchived
      text "Include archived"
    button on click -> submit
      text "Search"

The framework understands the binding target. bind value works on inputs, textareas, and selects. bind checked works on checkboxes. Radio groups and file inputs have explicit bindings too.

That gives the compiler something useful to validate.

Native HTML Still Matters

Wibble is not trying to hide the platform.

Native elements are supported directly:

view
  select bind value region
    option value "iad" text "Ashburn"
    option value "phx" text "Phoenix"

  input type "radio" value "compact" bind group density
  input type "radio" value "comfortable" bind group density

  input type "file" bind files attachments

That matters because a frontend framework should not make ordinary HTML feel exotic. Dropdowns, checkboxes, radios, file inputs, buttons, forms, dialogs, and tables are normal application work.

Wibble can also wrap third-party UI components, but the idiomatic boundary is explicit: adapt the external component once, expose a Wibble-shaped component, and keep application .wib files readable.

What A Pull Request Looks Like

The strongest argument for Wibble is not a benchmark. It is a pull request.

Imagine a change that adds weather data to a city page:

component CityWeather

use
  import { weatherApi } from "../api/weather"
  import WeatherMetrics from "../components/WeatherMetrics.wib"

props
  city: string

resource forecast
  key: ["forecast", city]
  load: weatherApi.forecast(city, abortSignal)
  staleTime: 60000

actions
  refresh()
    invalidate forecast

view
  section class "weatherPanel"
    header
      h2 text "Weather in {city}"
      button on click -> refresh
        text "Refresh"

    if forecast.loading
      p text "Loading forecast"
    else if forecast.error
      p text "{forecast.error}"
    else
      WeatherMetrics data forecast.data

A reviewer can read that quickly:

• The component takes city.
• It loads forecast by city.
• It caches fresh data for a minute.
• Refresh invalidates the resource.
• The view has loading, error, and ready branches.

There is still real code here. But the shape of the code reduces the amount of guessing.

This is where Wibble feels different in an AI-assisted workflow.

An AI agent can still produce a large change. Wibble does not magically make the PR small. What it can do is make the large change more inspectable. The reviewer can scan the sections and ask narrower questions:

• Did the new resources have stable keys?
• Did mutations stay inside actions?
• Did shared state move into a store instead of being tunneled through props?
• Did the view add the right branches for loading, error, and ready states?
• Did the form bindings attach to the right native elements?

That is a better review loop than reading a thousand lines of flexible component code and trying to reconstruct the architecture from scratch with a tiny brush and a haunted expression.

Where Wibble Fits

Wibble is a good fit for apps where consistency is more valuable than maximum local freedom:

• internal tools
• admin panels
• dashboards
• data-heavy product screens
• workflow UIs
• apps with typed API clients
• codebases where AI agents will make routine changes
• teams that expect larger PRs and want review structure to survive them

It is less interesting for tiny static pages or highly experimental visual work where every component wants to be its own invention.

The framework is opinionated on purpose. The goal is to make the common path clear enough that most code can stay boring.

That is not a small thing.

Boring frontend code is easier to review. Easier to review means safer to change. Safer to change means you can let tools, teammates, and agents do more work without turning every pull request into an archaeology session.

This is the quality argument for Wibble. It is not only trying to prevent bugs at runtime. It is trying to prevent entropy during review.

Try It

The project lives at github.com/vudodov/wibble. The runtime starts with @wibble/core, with companion packages for the compiler, Vite, router, stores, forms, HTTP, UI helpers, testing, and devtools.

pnpm add @wibble/core @wibble/compiler @wibble/vite

The repository includes docs and a playground app, so the easiest way to understand the framework is to read a few .wib files and look at the generated behavior.

The Short Version

Wibble is a frontend framework built around one idea:

The source code should explain what kind of change is being made.

Resources explain data loading. Actions explain behavior. Stores explain shared feature state. Views explain the DOM. The compiler enforces the boundaries. The runtime updates the page with fine-grained bindings.

That combination is what makes Wibble interesting.

Not because it lets you write less code at any cost, but because it tries to make the code you do write easier to trust.

In the age of AI-generated pull requests, that may be the more important optimization.