🚀 Avenx-JS

Avenx-JS is a lightweight, experimental frontend framework designed for simplicity and performance. It features a custom compiler-driven component system, Proxy-based reactivity, scoped CSS, and powerful CLI tooling—all with zero runtime dependencies.

✨ Why Avenx?

Modern frontend development often requires complex build chains and heavy runtime libraries. Avenx explores a different path by providing:

• ⚡ Zero Boilerplate: Logic, state, and template in a single unified component file.
• 🔄 Transparent Reactivity: Automatic UI updates via JavaScript Proxies without manual setState or ref calls.
• 🎨 Scoped Styling: CSS is automatically scoped to your component using hashed class generation.
• 🛠️ Integrated Tooling: A built-in CLI handles project scaffolding, component generation, and development servers.
• 📦 Lightweight Core: Minimal runtime footprint for fast loading and execution.
• 🗺️ Compiler Semantic Model: Ask the compiler what depends on a piece of state, before you change it.
• 🔍 Causal Tracing: Record why your app did what it did, then export that recording as a regression test.
• ↩️ Atomic Actions: Mark an action atomic and every state write it makes is undone if it fails.

⚡ Key Features

🔄 Proxy-based Reactivity

State management is built directly into the core. Changing a property on the state object automatically updates the DOM that reads it.

⚙️ Compiled Rendering

The compiler turns a template into a render program: a static HTML skeleton plus one binding operation per dynamic part. The skeleton is parsed once per component class; each binding becomes its own reactive effect. A state change wakes the bindings that read it and writes to their nodes — nothing is serialised, reparsed or diffed.

The cost of an update is therefore proportional to the change rather than to the template. Changing one text binding, measured in happy-dom:

The compiler reads the template through a typed intermediate representation, so <@if>, <@for>, <slot>, <@defer> and component tags arrive at the backend as the constructs they are rather than as markup a previous pass rewrote them into. Control flow compiles to a block: a skeleton parsed once for the life of the page and cloned per arm or per row, reconciled by key.

A template using a construct the IR does not model yet — a suspense or error boundary, a deadlock boundary, a transition, a template ref — renders through the previous string renderer instead, and avenx build says which and why (AVX_W47). There is no partial mode: a template is compiled entirely or not at all.

That renderer is only linked into a bundle when something in the build needs it, so an application whose every template compiles does not carry it. Measured on a scaffolded hello-world, production build: 366,780 → 320,431 bytes raw, 82,654 → 72,636 gzipped, with <@if>, compiled lists, compiled slots and compiled <@defer> added over the same period.

A keyed list update, measured against the same component on both paths (benches/list-rendering.bench.js, happy-dom — ratios, not milliseconds):

See the rendering guide.

🔒 Compiled Expressions — no eval, no new Function

Every template interpolation, computed value, directive binding, inline handler and <action> body is compiled to an ordinary JavaScript function at build time and linked into the bundle, so the browser's own engine compiles it.

count * 2                ->  ($s) => (axGet($s, "count") * 2)
if (!text) { return; }   ->  ($s) => { if (!axGet($s, "text")) { return; } … }

A production bundle contains no eval, no new Function and no with, so it runs under script-src 'self' — checked on the emitted bundle by the test suite, not asserted here. Earlier versions shipped this code as source text and interpreted it in the browser, which put a JavaScript parser and a tree-walking evaluator in every bundle and still fell back to new Function for any action using if, for, try or a declaration.

The security checks did not move, they are only called rather than interpreted: a member read still passes the key already resolved through one gate, so x['const'+'ructor'] and x.constructor meet the same check. Two checks moved earlier — naming a restricted global, or writing __proto__ / constructor / prototype, now fails the build with a file and a line.

A development build still carries the interpreter, so a template you are editing keeps rendering; AVX_W48 names anything the compiler could not compile.

See the template expressions guide and the deployment guide.

🔀 Conditional Rendering (<@if>)

<@if user.isAdmin>
  <AdminPanel />
<@elseif user.isMember>
  <p>Welcome back, {{ user.name }}.</p>
<@else>
  <a href="/signup">Create an account</a>
</@if>

Each arm is its own compiled block, so switching arms is the only thing that rebuilds DOM — an update that leaves the same arm selected touches nothing, and focus, selection and scroll position inside the branch survive.

Bracket a top-level comparison: <@if (count > 3)>, not <@if count > 3>. The > that means "greater than" and the > that ends the tag are the same character, so the compiler refuses the ambiguous form and names the one that works rather than silently testing count.

🧩 Declarative Components

Define your UI using standard HTML with added superpowers. Components support state, computed properties, and actions (methods) defined directly in the .component.js file.

🎨 Intelligent Scoped CSS

Styles defined in .component.css are automatically scoped to that specific component. Use the <@global> tag for global variables and the <@css> tag for component-specific styles.

🌐 Bridges (Shared State)

Shared state lives in Bridges — small modules created with bridge() and consumed by importing them. Because the import is the connection, the compiler can see every consumer: it drops unused bridges from the bundle and catches mistyped members before you run the app.

🌊 Declarative Async Data, Suspense & Error Boundaries

Fetch data seamlessly with <resource> declarations and handle loading & error states declaratively using <@suspense> and <@errorBoundary>:

<resource name="users">
  return fetch('/api/users').then(res => res.json());
</resource>

<@errorBoundary>
  <@fallback as="err">
    <div class="error">Failed to load users: {{ err.message }}</div>
  </@fallback>
  <@suspense>
    <@fallback>
      <div class="loading">Loading user list...</div>
    </@fallback>

    <div class="user-list">
      <@for user in users>
        <p>{{ user.username }}</p>
      </@for>
    </div>
  </@suspense>
</@errorBoundary>

🛡️ Reactive Deadlock Boundary (<@deadlock>)

Define a named fallback boundary for reactive-cycle recovery:

<@deadlock name="dashboard-boundary">
  <Sidebar />
  <Content />
  <Stats />
  <@fallback as="err">
    <div class="deadlock-alert">
      ⚠️ Reactive cycle intercepted in {{ name }}: {{ err.message }}
    </div>
  </@fallback>
</@deadlock>

• Global Detection: Scheduler and watcher guards stop runaway reactive work and log AVX_R18 diagnostics.
• Manual Recovery: Call $tripDeadlockBoundary('dashboard-boundary', error) to replace that boundary's active content with its fallback.
• Explicit Integration: Use onSchedulerDeadlock() when you want to connect global scheduler detection to a particular component boundary.

Detection does not automatically trip the nearest boundary. The compiled maxDepth, action, and isolated attributes are currently metadata rather than active per-boundary controls. See the reactive deadlock boundary guide for current behavior and limitations.

↩️ Avenx Rewind — an optimistic update that undoes itself

Mark an action atomic and every state write it makes is journaled. If the action throws, or returns a promise that rejects, the journal is played backwards and the state is what it was before the action ran.

<action name="incQty" atomic>
  busy = true; cart.addQty(props.id, 1);
  <!-- writes bridge state, through a bridge action -->
  return api.setQty(props.id, qty);
  <!-- if this rejects, none of the above stands -->
</action>

No catch, no snapshot, no inverse. Component state, bridge state, nested properties, array and Map/Set mutations, and keys the action created or deleted all come back — and because the restore goes through the same reactive machinery as an ordinary write, the DOM corrects itself.

Every framework can be made to do that much with a library. What a library cannot do is tell you, at build time, which of the action's effects a rewind will not undo:

[AVX_W43] session.save is atomic, but 2 effect(s) cannot be rewound:
  storage localStorage.setItem(  src/bridges/session.bridge.js:14
  emit emit('saved'  src/bridges/session.bridge.js:15

[AVX_W44] PostCard.like and PostCard.unlike are both atomic and both write
PostCard.likes — if they can be in flight at once, a rewind may find a value
it did not write.

[AVX_W42] cart.setField is atomic, but its write set could not be resolved
completely: dynamic-member "item[field]".

That last one is the house rule again: Avenx reports where its own analysis was incomplete rather than concluding from it. The rewind is unaffected — the journal watches the reactive proxies, not the prediction — but the two warnings above it are not to be trusted for that action.

Two optimistic updates racing on the same value is the case naive rollback gets wrong. The default safe policy restores a path only if the value there is still the one the transaction wrote, so the second click's increment survives the first click's rollback, and the conflict is reported rather than hidden.

With no transaction open, a write costs one boolean read — the same guard shape tracing uses. Measured over 100,000 writes: 89.24 ms idle, 89.89 ms inside a transaction.

See the Avenx Rewind guide.

🗺️ Avenx Atlas — ask the compiler what breaks before you break it

The compiler keeps a semantic model of your whole application: components, pages, bridges, individual state keys, computed values, actions, resources, template bindings, event handlers, routes and guards — and the relationships between them.

npx avenx atlas             # what is in this application
npx avenx impact cart.items # what can be affected if this changes
npx avenx why cart.total    # where this value comes from

What depends on: cart.items
   state  src/bridges/cart.bridge.js:5

├─ reads cart.total .reduce  src/bridges/cart.bridge.js:10
│  ├─ reads CartSummary {{ }} "cart.total"  src/components/cart-summary/cart-summary.component.js:14
│  └─ reads Checkout {{ }} "cart.total"  src/pages/checkout.page.js:7
│     └─ declares Checkout  src/pages/checkout.page.js
│        └─ routes-to /checkout  src/main.app.js:9
├─ reads CartList <@for> "cart.items"  src/components/cart-list/cart-list.component.js:9
├─ reads CartList {{ }} "item.qty" .[].qty  src/components/cart-list/cart-list.component.js:10
└─ writes cart.addQty .[].qty [possible]  src/bridges/cart.bridge.js:23
   └─ invokes CartItem.incQty  src/components/cart-item/cart-item.component.js:7
      └─ invokes CartItem @click="incQty()"  src/components/cart-item/cart-item.component.js:19

0 unresolved relationships in this answer.

This is a data-flow map, not a module graph. The loop variable inside <@for item in cart.items> resolves back to the state it iterates, so {{ item.qty }} is reported as a read of cart.items[].qty.

Every edge declares how much to trust it — certain when it follows from a declaration, possible when it does not — and everything the analyser could not follow is listed with its reason and location rather than silently dropped. Every answer prints that count, including when it is zero. An uncertain answer is better than a confidently wrong one.

Two diagnostics fall out of the model, and both refuse to fire when the analysis behind them was incomplete:

[AVX_W40] cart.discount is written by cart.applyCoupon but read nowhere.
[AVX_W41] CartSummary.neverCalled is never invoked from a template, action or guard.

Atlas is compile-time only. avenx build writes dist/bundle.atlas.json beside the bundle and never references it, so the runtime is byte-for-byte unchanged.

Atlas and Trace are two sides of one model: Atlas is what can happen, Trace is what did. A test in this repository checks that every causal step in a recorded trace corresponds to an edge Atlas predicted.

See the Avenx Atlas guide.

🔍 Avenx Trace — reproduce a bug once, get a test forever

Avenx records why your application did what it did — the click, the action, the bridge mutation, the state write, the watchers that woke, the DOM nodes that changed — and turns that recording into an executable regression test.

npx avenx serve --trace          # reproduce the bug in the browser
npx avenx trace view latest      # read why it happened
npx avenx trace export latest --out test/cart-qty.test.js

▸ click <button.qty-inc> CartItem
  └─ action CartItem.incQty()  src/components/cart-item/cart-item.component.js:3
     └─ bridge cart · addQty("a", 1)
        ├─ write cart.items.0.qty 2 → 3
        │  ├─ woke CartItem#render
        │  │  └─ patched <span.qty> text "2" → "3"
        │  └─ woke CartSummary#render
        │     ├─ getter cart.total 36 → 48
        │     └─ patched <strong.total> text "$36.00" → "$48.00"
        └─ emit cart:changed → 0 listeners

Determinism: deterministic — this trace can be exported as a regression test.

The exported test replays the recorded inputs through the real framework and compares every state and DOM change against the recording. When the code regresses you get the cause, not a bare mismatch:

Step 1 (click <button.qty-inc>) diverged at position 1:
  recorded: write count 0 -> 1
  replayed: write count 0 -> 2

Avenx can do this because every identifier an expression resolves — including Date and Math — passes through one substitution point, every state write through one Proxy trap, and every DOM change through one patcher. That is what lets a recorded session be replayed deterministically.

Expressions and action bodies are compiled to closures at build time, and that costs Trace nothing: a compiled expression naming Date emits a call to the same resolver the recorder substitutes. What compiling removes is the parser and the tree-walking evaluator from your production bundle, neither of which the recorder needed.

Recording is off by default and never reaches a production build — with tracing off, each instrumented site is a single boolean check. Determinism is verified by replay, not claimed by the recorder: a trace that says it is reproducible and is not fails loudly rather than passing for the wrong reason.

Configure redaction so a trace never captures what it should not:

{ "trace": { "redact": ["auth.token", "user.*", "*.password"] } }

See the Avenx Trace guide.

🛠️ CLI-First Workflow

Generate components, pages, and bridges with a single command. The built-in dev server provides hot-reloading for a seamless development experience.

📦 Production Builds

avenx build compiles your components to ES modules and links them with Avenx's own bundler. The runtime is an ordinary dependency in that graph, resolved through avenx-core/runtime — not a prebuilt file prepended to your application.

That means your imports are resolved, not rewritten: npm packages work from components, pages, bridges and guards, ES and CommonJS alike; local modules resolve by path, by extension-less path or through a directory index; and an import that names nothing fails the build with the specifier and the file that asked for it. Nothing is ever dropped silently.

It also means the build can leave things out. A module ships when something reaches it, so a production bundle does not carry the trace recorder — nothing in it can start a recording. A development build does, which is what avenx serve --trace uses. Testing helpers live behind avenx-core/testing and the ESLint tooling behind avenx-core/tooling, so neither can reach an application bundle, and an import of a Node built-in is a build error rather than a shim.

The bundle publishes globalThis.Avenx plus seven named globals for compatibility. Everything else is reached by importing it, because importing now works.

See the deployment guide.

🚀 Quick Start

Installation

npm install avenx-core

Scaffolding a Project

# Initialize project structure
npx avenx init

# Create a new component
npx avenx g counter

# Start development server
npx avenx serve

# Build for production
npx avenx build

Your app will be running at http://localhost:3000.

🧠 Core Concepts & Syntax

1. Component Structure

An Avenx component consists of two files: <name>.component.js and <name>.component.css.

JavaScript (.component.js)

<state count="0" title="Counter" />

<computed name="doubleCount" value="count * 2" />

<action name="increment"> state.count++; </action>

<div @css card>
  <h1>{{ title }}</h1>
  <p>Count: {{ count }} (Double: {{ doubleCount }})</p>
  <button @css button @click="increment()">Increment</button>
</div>

CSS (.component.css)

<@global>
    @def primary-color #646cff;
    @def bg-color #242424;
</@global>

<@css>
    card {
        padding: 2rem;
        border-radius: 8px;
        background: @bg-color;
    }

    button {
        background-color: @primary-color;
        color: white;
        border: none;
        padding: 0.6em 1.2em;
        cursor: pointer;
    }
</@css>

2. Bridges (Shared State)

A Bridge holds state that several components need, plus the actions that change it. You create one with bridge() and use it by importing it.

Creation

npx avenx g bridge auth

Definition (src/global/auth.bridge.js)

import { bridge } from 'avenx-core/runtime';

export default bridge({
  state: {
    user: null,
    status: 'anonymous',
  },

  get displayName() {
    return this.user ? this.user.name : 'Guest';
  },

  login(user) {
    this.user = user;
    this.status = 'authenticated';
    this.emit('login', user);
  },
});

Usage in Component

Import the bridge, then read it straight from the template. Reads are tracked, so the component re-renders when the data it uses changes — no subscription to write, and none to clean up.

import auth from '../global/auth.bridge.js';

<p>Welcome, {{ auth.displayName }}</p>

<action name="signIn"> auth.login({ name: 'John Doe' }); </action>

Because a bridge is reached through an import, the compiler knows exactly which components use it: unused bridges are left out of the bundle, mistyped members and unknown event names are reported at build time, and the whole surface is typed in TypeScript. State is read-only outside the bridge, so every mutation has one traceable origin.

3. Pages & Routing

Pages are special components designed for top-level routing. They reside in src/pages/.

Creation

npx avenx g page profile

Definition (src/pages/profile.page.js)

Pages use the same syntax as components (<state>, <computed>, <action>).

<state userId="123" />

<div class="profile-page">
  <h1>User Profile</h1>
  <p>Viewing ID: {{ userId }}</p>
</div>

Routing (src/main.app.js)

Avenx-JS projects built with the CLI automatically scan, compile, and register page components. In your main application entry point, you initialize the built-in router with the route mappings:

import { AvenxApp } from 'avenx-core/runtime';

const app = new AvenxApp({ target: '#app' });

// Initialize the router mapping paths to page component names.
// Note: Pages inside src/pages/ are automatically registered by the compiler.
app.initRouter({
  '': 'Home',
  '#/': 'Home',
  '#/profile/:userId': 'Profile',
});

4. Nesting Components

Components can be nested by using their name in PascalCase. Use <slot /> tags to define where transcluded child content should render:

<Navbar />
<main>
  <Sidebar />
  <slot />
</main>

5. Events

Use the @ prefix to bind event listeners:

<button @click="count++">Inline Action</button> <input @input="state.text = event.target.value" />

6. CSS Preprocessors (Sass, SCSS, PostCSS, Less)

Avenx-JS supports Sass/SCSS, PostCSS, and Less preprocessors inside .component.css or .page.css files.

To enable a preprocessor, add the style settings to your avenx.config.json file:

{
  "style": {
    "preprocessor": "scss"
  }
}

Available preprocessor options are "sass", "scss", "postcss", and "less".

When a preprocessor is enabled:

• You can write nested SCSS/Sass styles, variables, functions, and mixins directly inside your stylesheet.
• The compiler will automatically run your styles through the preprocessor module before applying Avenx-JS scoping logic.
• If the configured preprocessor package (e.g. sass) is not installed, the compiler gracefully falls back to raw CSS processing and logs a warning.

📁 Project Structure

A typical Avenx project looks like this:

my-avenx-app/
├── src/
│   ├── components/       # UI Components
│   │   └── counter/
│   │       ├── counter.component.js
│   │       └── counter.component.css
│   ├── pages/            # Application Pages (Routed)
│   ├── global/           # Shared Bridges & Styles
│   └── main.app.js       # App entry point & registration
├── dist/                 # Compiled bundle (generated)
├── index.html            # Main entry HTML
└── package.json

🛠️ CLI Reference

Options

🧪 Testing

Avenx-JS provides comprehensive testing support, from fast unit tests to full browser E2E test suites:

• Unit Tests: npm run test:unit
• Integration Tests: npm run test:integration
• System Benchmarks & CLI Tests: npm run test:system
• Playwright End-to-End (E2E) Browser Tests: npm run test:e2e
• Full Test Suite: npm test

The E2E suite compiles real Avenx applications with the CLI and drives the compiled bundle in a browser, so a test cannot pass unless the compiler and runtime both ran. Every pull request runs it on Chromium; Firefox and WebKit run nightly.

See test/e2e/README.md for the fixture-app layout, the conventions, what belongs in E2E rather than unit tests, and the framework gaps the suite currently pins.

📌 Status

This project is currently a proof-of-concept framework and actively evolving.

🤝 Contributing

We are actively looking for contributors! Avenx-JS is PR and first-time open-source friendly. Whether you are fixing a typo, updating documentation, or adding features, we welcome your help.

Check out our CONTRIBUTING.md to get started!

📄 License

Distributed under the MIT License. See LICENSE for more information.

⭐ Support

If you like what we're building, please give us a ⭐ on GitHub!

Built with ❤️ by the Avenx Team.