WildflowerJS Logo WildflowerJS

WildflowerJS Reactive JS, No BS*

A no-build reactive JavaScript framework as fast and robust as compiled frameworks.

Latest release: v1.5.1 · see what's new
<script src="wildflower.min.js"></script> ...and start building.

Back to Basics

With WildflowerJS, you write 100% standard code. HTML stays HTML. JavaScript stays JavaScript. CSS stays CSS. There's no JSX, templating language, or custom syntax to learn. If you know the standards, you already know how to use WildflowerJS.

WildflowerJS extends the web platform. It doesn't replace it.

Your Development Simplified

Because you develop with 100% web standards, every tool in your existing chain already understands the code: IDE, browser DevTools, linter, formatter, screen reader, SEO crawler. There's nothing to install, and no custom file types or sourcemaps. Save the file, refresh, and your change is live.

Just be a web developer.

Batteries Included: One Mental Model

Router, SSR, queries, stores, computed properties, two-way binding, event modifiers, data pools, and TypeScript types, all built in, all using the same API. Learn data-bind once and you know binding everywhere: in lists, pools, stores, plugins. There's no five-library stack to keep in sync.

One script tag. Everything you need.

<div data-component="counter">
  <span data-bind="count"></span>
  <button data-action="increment">
    +1
  </button>
</div>

<script>
wildflower.component('counter', {
  state: { count: 0 },
  increment() { this.count++ }
})
</script>

How It Works

data-bind connects state to the DOM.

data-action connects events to methods.

this.count++ triggers a precise DOM update.

Mutate state. The DOM updates.

Two Reactivity Modes

data-list is for automatic reactivity: mutate state, the DOM updates. data-pool is for explicit control: plain objects, zero proxy overhead, you say what changed.

Both use the same template syntax and differ in performance profile, from interactive forms to per-frame particle systems. You choose the tradeoff that fits the job.

Try it. Right-click, inspect this demo. Every dot is a real DOM element.

See full demo →

Get Started View Demos
* Build Step

No Compromise

WildflowerJS doesn't compromise performance for ease-of-use. Even with no build step, WildflowerJS performs at the level of frontier frameworks on the official js-framework-benchmark board, where its data-pool entry outpaces every major framework and its standard entry sits with the fastest signal-based compilers. And for per-frame workloads, data pools lead every framework we tested in our Lorenz attractor simulation demo.

The charts here are the overall geomean standings and the operation breakdown from the official September 2026 run, plus the sustained frame rate from our per-frame animation sweep. Click any chart to see it full size.

Delivery is fast too, because there's less to deliver. It ships as one file, with no runtime split across chunks and no hydration pass. Lighthouse scores hold their own against compiled frameworks without a single build artifact.

WildflowerJS doesn't trade simplicity of interface for performance of implementation.

Benchmark setup: the two js-framework-benchmark charts show the official September 2026 run (Chrome 152; MacBook Pro 14, M4 14/20 cores, 48 GB RAM, macOS 26.6.2; puppeteer driver), operations 1 through 9, total-duration medians, lower is better. The frame-rate chart is our own sweep: each framework's fastest variant on the Lorenz attractor for 8 seconds per particle count, fullscreen on a 120 Hz panel, higher is better; Apple M5 Pro, 24 GB RAM, macOS 26.5.2, Google Chrome 150 (stable, headed).

Bar chart of the official weighted geometric mean slowdown versus the fastest implementation per operation, Chrome 152: WF-pool 1.09, Vue Vapor 1.12, Solid 1.13, WF 1.16, Svelte 1.17, Vue 1.31; vanilla 1.04 and React 1.58 not shown. Lower is better.
Geomean slowdown vs fastest per operation. Lower is better.
Grouped bar chart of all nine js-framework-benchmark operations for Solid, Svelte, Vue, Vue Vapor, WF, and WF-pool from the official Chrome 152 run, with per-operation rankings. WF-pool is fastest on most operations.
All nine operations, side by side. Stars mark the fastest.
Line chart of sustained FPS versus particle count on the Lorenz attractor for Solid, Svelte, Vue, Vue Vapor, WF, and WF-pool. WF-pool holds the highest frame rate at every count, staying above 60 FPS past 4500 particles.
Per-frame animation. Sustained FPS as particle count grows; higher is better.

Precise Reactivity

When you write this.count++, WildflowerJS updates the single DOM node bound to count. Nothing else is touched. There's no tree diffing or reconciliation pass to figure that out.

You get fine-grained updates and a simple mental model. Change a property, the bound element updates. That's the entire reactivity model.

Other frameworks ask you to learn signals, accessors, memos, effects, and subscription lifecycles to achieve what WildflowerJS does with a standard JS property assignment.

wildflower.component('dashboard', {
  state: {
    users: 1420,
    status: 'healthy'
  },
  computed: {
    summary() {
      return this.users + ' users, ' + this.status;
    }
  },
  refresh() {
    this.users = 1421;
    // Only the elements bound to 'users'
    // and 'summary' update. Everything
    // else on the page is untouched.
  }
})

One Reactivity Model. Everywhere.

Components, Stores, and Plugins, Pools, and now Data Queries all share the same reactive foundation. State, computed properties, and methods work identically no matter where they live. Learn it once, it works the same way across all of those entities.

Other frameworks make you learn a different system for each layer. React components use hooks, but stores need Redux or Zustand, which are completely different APIs. Vue components use reactive data, but Pinia stores have their own patterns. Every layer is a new mental model.

In WildflowerJS, there's one model. A store is a component without a template. A plugin is an entity that extends the framework itself, adding directives, lifecycle hooks, and services. The same this.count++ triggers the same reactivity everywhere.

This makes patterns possible that other frameworks cannot express. A store can run headless physics simulations with tick(), feeding data into a component that renders it through a pool, all using the same reactive primitives, no glue code required.

// Component: reactive UI
wildflower.component('cart', {
  state: { items: [] },
  computed: {
    total() { return this.items.length; }
  }
})

// Store: global shared state
wildflower.store('user', {
  state: { name: '', role: 'guest' },
  computed: {
    isAdmin() { return this.role === 'admin'; }
  }
})

// Plugin: extends the framework
wildflower.plugin({
  name: 'notifications',
  state: { items: [], unreadCount: 0 },
  computed: {
    hasUnread() { return this.unreadCount > 0; }
  },
  add(msg) { this.items.push(msg); this.unreadCount++; }
})
// Access globally: wildflower.$notifications.add(...)

// Same state. Same computed. Same methods.

Live Server Data: Built In, Stays True

With WildflowerJS SSR, the page arrives with its data already in the HTML. The server (your server, whatever back-end you prefer) renders your data into real HTML, so the first paint is real content, indexable and readable before a line of JavaScript runs. And because the markup is genuine HTML, hydration reads the page's state straight back out of the document. Server-rendered components end up exactly equivalent to client-rendered ones.

v1.3 brings data-query, which does for the rest of the page's life what SSR does for first load. Most frameworks hand you fetch() and leave the rest to you. There's an entire ecosystem of client data libraries that exists to fill that gap. WildflowerJS makes it a declaration instead. Name a source, point an element at it, say how fresh it should stay. Loading and error states, refresh on demand, request racing, and the whole refresh ladder (poll, conditional GET, focus, reconnect, server push) come with it. There is also no query language. Refinement is an ordinary computed property, and filtering happens client-side without a network round trip.

v1.5 completes the shape with writes. A query that declares where its rows come from can declare where changes go: to: is the transport, write() applies the change on screen immediately, and confirmation: decides what the server's answer means. If the server refuses, only the fields that write still owns revert, so two writes to the same row never clobber each other and you write no cancellation logic to get it. Computed properties may also return a promise now, holding the last settled value while the next one resolves.

Together, Wildflower's SSR and data-query cover one job at two different times. The server renders the page with real data. Because hydration reads the page itself, there's no flash of empty content, no loading spinner over data the user can already see, and no hydration scripts locking up the main thread. The server's render is the actual UI. When paired with data-query, your SSR becomes the first result of a standing query. The query adopts that markup and keeps it updated from there.

In the example above, the markup is 100% HTML.

<div data-component="product-board">
  <p data-show="$products.isLoading">
    Loading…
  </p>
  <p data-show="$products.error">
    Failed.
    <button data-action="retry">Retry</button>
  </p>

  <span data-bind="$products.count"></span>
  products

  <tbody data-query="products">
    <template>
      <tr>
        <td data-bind="name"></td>
        <td data-bind="stock"></td>
      </tr>
    </template>
  </tbody>
</div>
// The entire data layer:
wildflower.query('products', {
  from: '/api/products',
  key: 'id',
  refresh: ['focus', 'etag:60'],

  // v1.5: where changes go
  to: '/api/products/:id',
  body: (item) => item,
  confirmation: (d) => d.product
});

// The key plus only what changed. On screen
// at once; if the server refuses, only those
// fields revert.
getQuery('products')
  .write({ id: 42, stock: 40 });

// Server-rendered page? Add data-ssr="true"
// and the markup the server sent becomes the
// query's first result. Live from there.

Data Pools

Every framework wraps collection items in reactive proxies, whether the item needs it or not. WildflowerJS gives you a choice: data-list for push reactivity (automatic), data-pool for pull reactivity (explicit control, zero proxy overhead).

Pools render plain objects with the same template syntax as lists. Mutate the object, call markDirty(), and only that item updates. Full CRUD, selection, bulk operations, all faster than the push-reactive path.

And because pools use pull-based rendering, they scale to simulations, games, particle systems, and data visualizations at native frame rate, which a virtual DOM cannot sustain. No other framework offers this choice.

<div data-component="user-table">
  <tbody data-pool="users" data-key="id">
    <template>
      <tr>
        <td data-bind="name"></td>
        <td data-bind="status"
            data-bind-class="status === 'active'
              ? 'badge success'
              : 'badge inactive'"></td>
      </tr>
    </template>
  </tbody>
</div>
wildflower.component('user-table', {
  pools: { users: {} },

  init() {
    // Populate: plain objects, no proxies
    data.forEach(u => this.pools.users.add(u));
  },

  // Optional: add tick() and the same pool
  // renders every frame. Same template, same
  // data, different rendering frequency.
  // That's the only difference between a
  // display table and a particle system.
})

No Toolchain

Modern frameworks ask you to install a compiler, a bundler, a package manager, hundreds of fragile transitive dependencies, and a framework-specific file format, before you write a single line of your application.

WildflowerJS was built starting from a single principle: no build step, no tooling. Ever.

WildflowerJS asks you to add a script tag.

There's no CLI scaffolding step, config file, or .vue/.jsx/.svelte source format. You don't debug through sourcemaps or wait on a build pipeline. Your project has zero dependencies.

Performance isn't a tradeoff. Build steps optimize bundle delivery, not the runtime work that follows it. WildflowerJS writes directly to the DOM, with no virtual DOM or reconciliation pass between state change and update, so it doesn't need a build step to be fast.

The framework is full-featured without the toolchain, including router, SSR, stores, computed properties, transitions, and pools.

my-app/
  index.html
  app.js
  style.css
  wildflower.min.js

That's the entire project. No package.json, no node_modules, no config files. NONE of that.

No Install. No Attack Surface.

Every dependency you install lets a maintainer you have never met run scripts on your dev machine and in your CI. A typical React + Vite + UI‑lib setup pulls in 300+ transitive packages before you write a feature.

Each one is a potential intrusion vector. NPM worms, OAuth chains compromising deploy platforms, postinstall hijacking: the supply chain is now where production code gets compromised, not the deploy. And signing isn't a backstop: Mini Shai‑Hulud (May 2026) compromised 170+ packages whose malicious versions carried valid SLSA Build Level 3 provenance, because the attestation came from build infrastructure the worm had already taken over.

A WildflowerJS project has none of that surface. There is no npm install, postinstall script, or transitive package graph. The framework is one file you copy or pin by hash.

As of v1.1, the same holds for building the framework itself. WildflowerJS bundles with a vendored rollup and terser pipeline pulled as three SHA‑512‑pinned tarballs, with no npm install and no transitive packages in the build path. The entire toolchain is three files verified by hash.

A typical React/Vue project:

  npm install
  ├── hundreds of packages
  ├── from hundreds of maintainers
  ├── postinstall scripts run on install
  └── tens to hundreds of MB of transitive code

WildflowerJS:

  <script src="wildflower.min.js"></script>
  └── 1 file.
      No transitive dependencies.

No Lock-in

WildflowerJS works with the DOM, not instead of it. There's no virtual DOM intercepting your code and no compiler rewriting your markup. The render cycle is yours alone.

That means Leaflet, DataTables, Chart.js, D3, Three.js, any library that touches the DOM, just works. There are no wrapper packages or framework-specific escape hatches required. Drop in a script tag, it's ready to go.

Because your code is standard HTML and JavaScript, you're never locked in. Your skills transfer and your code is more portable. If you outgrow the framework, your knowledge doesn't expire.

This also means your "ecosystem" is the whole of vanilla JS, with no compromises or hacks.

<!-- Use any library directly -->
<div data-component="map-view">
  <div id="map" style="height: 400px"></div>
</div>
wildflower.component('map-view', {
  state: { lat: 51.505, lng: -0.09 },
  init() {
    // Leaflet works as-is. No wrappers.
    this._map = L.map('map')
      .setView([this.lat, this.lng], 13);
    L.tileLayer('https://{s}.tile.osm.org'
      + '/{z}/{x}/{y}.png').addTo(this._map);
  }
})

Built for AI-Assisted Development

Because WildflowerJS is standard HTML and JavaScript, AI code assistants already know how to write it. There's no custom syntax to hallucinate or compiler quirks to work around. The code an AI generates runs exactly as written, with no build step between generation and execution.

WildflowerJS ships an AI-optimized reference page with patterns, anti-patterns, and examples designed for code generation context windows. Our llms.txt file follows the llms.txt convention for machine-readable documentation.

You: "Build me a todo app with
WildflowerJS"

AI reads llms.txt or ai-assistant.html
     ↓
Generates standard HTML + JS
     ↓
<div data-component="todo-app">
  <input data-model="newItem">
  <button data-action="addItem">
    Add
  </button>
  <ul data-list="items">
    <template>
      <li data-bind="text"></li>
    </template>
  </ul>
</div>
     ↓
Open in your browser. It works, and you can read and understand the code.

Tutorial: Build Reusable Panels

Four steps build one settings page with three collapsible panels that share a header and toggle mechanism but show completely different content each. By the end, one small component definition drives all three, plus a fourth piece that renders data it doesn't own.

Sandbox Examples: every example on this page runs in an isolated iframe, so it can't interfere with this documentation site's own components. Each is also a complete, self-contained file. Open it directly to read every line.

Step 1: One Component, Two Instances

Writing data-component="panel" a second time really does give you a second, fully independent instance. One wildflower.component('panel', {...}) registration; every element that names it gets its own state.

<div data-component="panel" data-title="Profile">...</div>
<div data-component="panel" data-title="Notifications">...</div>
Live Example Two panels, one definition, independent state Open Full Example ↗
Toggle "Profile" closed. "Notifications" stays open. That's the whole mechanism. No special tag syntax, no registry to configure. If you've been reaching for JSX-style frameworks, this is the same thing <Panel/><Panel/> gives you. It just doesn't look like a stamp the way a repeated component tag does, because it's an attribute, not a tag. It behaves identically anyway.

Step 2: Different Content Per Instance

The panel's body was hardcoded text in step 1. Real panels need real content, different per instance. A data-slot-container in the component's own layout marks where content goes; a data-slot at each usage site supplies it. The panel never sees an input, a checkbox, or a button, just a hole labeled "body."

<div class="panel-body" data-show="expanded">
    <div data-slot-container="body"></div>
</div>

<!-- at the usage site, a sibling of the component element -->
<div data-slot="body">
    <label>Name <input id="name-input" type="text"></label>
</div>
Live Example Three panels, three different bodies, one component Open Full Example ↗
The component definition at the bottom of the file is identical to step 1's. Nothing changed there. Everything new happened at the three usage sites. See Slots for named slots, fallback content, and reactive slot content.

Step 3: Multiple Named Slots

Slots aren't all-or-nothing. Add a second named container (a badge next to the title) and every instance decides independently whether to fill it. The component definition doesn't grow to accommodate the new slot; it just names it in its own layout.

<span class="panel-header-left">
    <span data-bind="title"></span>
    <span data-slot-container="badge"></span>
</span>

<!-- Notifications fills it: -->
<div data-slot="badge"><span class="badge">3</span></div>
<!-- Profile and Danger Zone don't. Nothing to opt out of. -->
Live Example An optional second slot, filled by one instance out of three Open Full Example ↗
Only "Notifications" shows a badge. An unfilled data-slot-container is simply empty. There's no error, no warning, no default to override.

Step 4: When the Child Owns the Data

Slots project static content the parent already has fully formed. Sometimes it's the other way around. The child owns a list of data it computes or fetches itself, and the parent wants to control how each item looks, without the child knowing anything about icons, classes, or layout. That's Configurable Templates. A parent declares a named <template data-item-template="...">; any descendant can render its own list through it with data-use-template.

<!-- settings-page (parent) declares the template, anywhere in its
     own markup, not necessarily right next to where it's used -->
<template data-item-template="logEntry">
    <div class="log-entry" data-bind-class="type === 'warning' ? 'warn' : ''">
        <span data-bind="icon"></span>
        <span data-bind="message"></span>
    </div>
</template>

<!-- activity-feed (child) renders ITS OWN data through it -->
<div data-component="activity-feed">
    <div data-list="entries">
        <template data-use-template="logEntry"></template>
    </div>
</div>
Why the class expression is inline. A named computed referenced from a list item (data-bind-class="entryClass") resolves against whichever component actually renders the list (activity-feed here), not the component that defined the template. An inline expression like type === 'warning' ? 'warn' : '' evaluates directly against the item's own fields, so it works no matter which component's markup the template lives in. That's what lets settings-page decide what "warning" looks like without activity-feed ever needing to expose a class name.
Live Example A child's own data, styled by the parent's template Open Full Example ↗
activity-feed's three log entries are hardcoded here for the example, but they could just as easily come from a store or a data-query. It decides what happened, and settings-page decides how a warning-type entry looks different from an info-type one. Neither component could do the other's job without the split.

What You Built

One component definition ended up driving three independent, differently-configured instances. Two named slots, one always filled and one optional, controlled what each panel showed. A fourth component rendered its own data through a template it never had to know existed, with no duplicated markup and no parallel state fields typed out three times.

Where to go deeper: