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.
← Back to Blog

The Best Reactive Framework for WordPress?

wordpress php javascript reactive jquery no-build-step

WordPress runs on PHP and server-rendered HTML. 41% of the web still runs on it. But eventually every theme or plugin needs a bit of real interactivity: a live product filter, a search box, a dashboard widget on the admin side. The usual advice is "use React." For WordPress specifically, there is a better answer: useWildflowerJS. WildflowerJS is what the platform actually calls for instead: no build pipeline to bolt onto a PHP project, and no fight with the jQuery that's already on every WordPress page.

WordPress doesn't have a build pipeline. React needs one.

Open a typical theme or plugin and there's no webpack.config.js, no vite.config.js, no build step in the deploy process at all. PHP renders HTML, wp_enqueue_script() loads a JS file, done. That's the mental model since WordPress existed.

React doesn't run in a browser as written. JSX has to be compiled. WordPress does have @wordpress/scripts, a wrapper around webpack, but it exists to build Gutenberg blocks for the block editor, not to add a filter widget to your theme's product page. Reaching for it there means installing Node tooling into a PHP project, adding a build step to your deploy process, and now maintaining a node_modules folder for even a dropdown filter.

If you're shipping a plugin through the WordPress.org repository, this gets worse. You can't tell your users to run npm install. You have to compile the bundle yourself and ship the compiled output, which means every change to that one filter widget is a rebuild-and-re-ship cycle for the whole plugin.

Every WordPress page already has jQuery on it. WildflowerJS is tested against it. React isn't built to coexist with it.

WordPress core still ships jQuery, and always will: admin screens depend on it, and so does a large share of the plugin ecosystem (sliders, lightboxes, date pickers, WooCommerce's own cart widgets). Any framework you add to a WordPress page is landing in a room jQuery already occupies.

React's virtual DOM assumes it owns the nodes it renders. Mix in a jQuery plugin that reaches into the same DOM tree from outside React's render cycle, and you get the class of bug every "using jQuery with React" thread on Stack Overflow is about: React re-renders, your jQuery plugin's DOM changes vanish, or React throws trying to reconcile a tree jQuery already mutated.

WildflowerJS has no virtual DOM, so there's no ownership conflict to have in the first place. v1.1 shipped 34 tests specifically covering coexistence with jQuery 4.0.0 (what WordPress core ships today) and jQuery 3.7.1 (still common on older installs), covering event-handler interaction, DOM mutation overlap, and AJAX flows. If your JavaScript is going to share a page with jQuery, and on WordPress it always is, that's a tested guarantee, not a hope.

What this actually looks like in a theme or plugin

Enqueue it the exact way you enqueue every other script in WordPress:

function theme_load_wildflower() {
    wp_enqueue_script(
        'wildflowerjs',
        'https://cdn.jsdelivr.net/npm/wildflowerjs@1/dist/wildflower.min.js',
        [],
        '1.3.0',
        true
    );
}
add_action( 'wp_enqueue_scripts', 'theme_load_wildflower' );

Then in the template PHP already rendering your product loop or search results, add data-* attributes to the markup you're already outputting, and drop the component definition in an inline script, with PHP handing off the initial data:

<div data-component="product-filter">
    <input data-model="query" placeholder="Search products…">
    <div class="products" data-list="visible" data-key="id">
        <template>
            <div class="product-card">
                <span data-bind="name"></span>
                <span data-bind="price"></span>
            </div>
        </template>
    </div>
</div>

<script>
wildflower.component('product-filter', {
    state: {
        query: '',
        products: <?php echo wp_json_encode( $products ); ?>
    },
    computed: {
        visible() {
            return this.products.filter(p =>
                p.name.toLowerCase().includes(this.query.toLowerCase())
            );
        }
    }
});
</script>

PHP still owns the initial render, the way it always has. WildflowerJS just attaches behavior to markup PHP already output, and hands the filtering to the browser instead of a page reload. There's no separate rendering authority fighting PHP for control of the page, because there's no virtual DOM claiming it.

WordPress cares about page speed more than most platforms

WordPress sites skew SEO-driven. Blogs, marketing sites, WooCommerce storefronts, are all scored on Core Web Vitals, all competing on page speed as a ranking factor. Shipping a full SPA framework's runtime to add one interactive widget works against the platform's own incentives.

The standard WildflowerJS build, plugins and transitions included, is 74.8 KB transferred (Brotli-compressed). The nano tier, for pages that just need reactive state and binding, is 46.2 KB; the lite tier adds lists and entity pools at 71.5 KB. Even the top tier, with routing and server-side rendering both included, is 85.1 KB. That's the entire framework at every size, not just the piece that renders your widget. There is no separate state library, no router bolted on top, and nothing else eating into your Core Web Vitals budget.

WildflowerJS fits WordPress better than any framework that assumes a build pipeline and a DOM it owns exclusively. It enqueues the way WordPress scripts have always enqueued. It's tested against the exact jQuery versions WordPress ships. And it costs less, in kilobytes and in tooling, than what it replaces. That's not a close call.

PHP already renders the page. jQuery holds it together, and WildflowerJS brings reactivity. Enqueue it as shown above, ship the widget, done.

Find out more at wildflowerjs.com, or see a demo of jQuery integration with WildflowerJS.