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

What's new in WildflowerJS 1.1

javascript webdev framework release devtools performance wildflowerjs
The WildflowerJS project manager demo, showcasing components, stores, and pool entities working together in a real app.
The project manager demo showcases new features in v1.1.

WildflowerJS 1.1 is out! Browser DevTools, jQuery coexistence, item-level computed properties in every binding type, a smaller build for apps that don't need pools, and a build pipeline that runs zero npm install. Performance gains in the 2.7–6x range for cross-store rendering. Two breaking changes, both with one-line migrations.

Upgrading from v1.0? Two attribute renames. Action handlers no longer stop event propagation by default. If you relied on that, add data-event-stop to the affected element. data-model-debounce is gone. Migrate to data-event-debounce on the same element with a paired action. Details in the breaking-changes section below.

DevTools

WildflowerJS now exposes window.__WF_DEVTOOLS_GLOBAL_HOOK__ for runtime introspection, and v1.1 ships with two ways to consume it:

  • A standalone @wildflowerjs/devtools drop-in script you can include in any app for a built-in debugging panel.
  • An MV3 browser extension for Chrome and Firefox, headed for the official extension stores.

Both surface the same panels:

  • Components: live tree of mounted components with their state, computed values, props, and the stores they subscribe to. State and store values are editable in place for quick what-if poking.
  • Stores: every registered store with its current state and the methods it exposes.
  • Pools: pool name, owning component, current entity count, recycle-pool size, and target FPS for tick scheduling. Useful for catching pool-leak regressions before they hurt.
  • Bindings: every active binding on the page by type (data-bind, data-bind-html, data-show, data-model, data-list, data-pool) with the path it's bound to and which component owns it.
  • Routes: current route, full route tree, navigation state, guard counts.

The hook also emits lifecycle events (componentInit, componentDestroy, store-ready, routeChange) so third-party integrations can subscribe to framework activity without monkey-patching.

Build pipeline now runs no npm install

This one might be the most distinctive thing about v1.1. The framework distribution itself has always had no runtime dependencies. As of v1.1, the process that builds the framework also has no install-time dependencies. The whole pipeline runs on three SHA-512-pinned tarballs (rollup, terser, acorn) fetched and verified on first build, then reused. There is no npm install, transitive dependency tree, postinstall script, or lock file to audit.

The relevance is uncomfortably current. Seven days before this release, on May 11, 2026, the Mini Shai-Hulud worm compromised 170+ npm packages in a 6-minute window - the entire @tanstack ecosystem, Mistral AI's SDK, UiPath's automation suite (65 packages), OpenSearch (1.3M weekly downloads). OpenAI was among the named affected companies. The malicious versions were attested at SLSA Build Level 3: the cryptographic "safe-to-trust" signal didn't help, because the signal came from the same GitHub Actions infrastructure the worm had already compromised.

Framework users who consume WildflowerJS via <script> tag or npm install wildflowerjs have always been immune-by-construction to this entire class of attack: WF has no transitive npm dependency tree to compromise, no postinstall hooks to hijack. With v1.1, the framework's own build pipeline now matches that posture. Three SHA-512-pinned tarballs, with no npm install and no GitHub-Actions trust boundary for an attacker to exploit. Anyone auditing WildflowerJS for use in security-sensitive contexts can verify the entire build with three tarball hashes.

Output bundles are identical to the previous rollup pipeline, and are still subject to and passing the full Vite/Chromium test suite across all 15 build variants.

Performance

Two changes worth calling out:

  • Cross-store computed cache-hit fast path: if your app reads from multiple stores in components, this is the headline win. End-to-end render speedups of 2.7–6x in read-heavy cross-store scenarios. The fast path skips redundant graph traversal when a computed's dependencies haven't changed.
  • Batch change-detection rebuild around the proxy: brings improvements to the krausest benchmark suite, and let us delete around 600 lines of legacy diff code in the process. Smaller surface area, faster updates.

Pools

Pools now accept an entity block, bringing them in line with the shape components, stores, and plugins already use:

wildflower.component('dust', {
    pools: {
        particles: {
            entity: {
                state:    { x: 0, y: 0 },
                computed: { faded() { return this.x > 800; } },
                methods:  { wrap() { this.x %= 800; } }
            }
        }
    }
});

If you've worked in any other part of the framework, the entity block will be immediately familiar. state, computed, and methods behave the same way they do in components and stores. The unification continues a theme: one mental model across every reactive surface.

Pools also gained array-like methods and properties: push, pop, length, at(i), find, filter, map, forEach, some, every, reduce, and Symbol.iterator, layered on top of the existing add / remove / size APIs. There is no splice, indexOf, or slice. Pools use swap-with-last removal, so positional indices are not stable across mutations. Use remove(key) for keyed removal and at(i) for DOM-ordered positional reads.

Finally, pools now support pool-level props: shared, reactive state on the pool itself. The owning component can read and update props at any time, and every entity's methods and computeds see the current value without it being duplicated per-entity.

jQuery coexistence

WildflowerJS now coexists cleanly with jQuery on the same page. v1.1 ships with 34 tests across jQuery 4.0.0 (which WordPress core now ships) and jQuery 3.7.1 (still common in legacy WordPress installs) covering event-handler interaction, DOM mutation overlap, AJAX flows, and the surprises that show up when both frameworks try to listen on the same element.

The headline interaction is event handling. In v1.0, action handlers stopped event propagation by default, which silently swallowed events that jQuery's $(document).on(…) delegation expected to receive. v1.1 lets events bubble naturally past action handlers (see Breaking Changes below), which restores the cooperative behavior most apps expect.

If your app sits inside a WordPress theme, a Drupal site, a Shopify page, or anywhere else jQuery-style delegation is already in play, v1.1 should slot in without a fight.

Item-level computed properties in every binding type

This one surfaced when we tried using Claude Design (the new AI prototyping tool) to build a UI from nothing but the WildflowerJS website's llms.txt and the AI-assistant page. Claude kept reaching for item-level computed properties inside list bindings ("show this row in red if the item is overdue," for example), and v1.0 silently evaluated those references as undefined rather than erroring, leading to hacky workarounds and (warranted) complaints from the AI.

v1.1 supports item-level computed properties in every binding type: data-bind, data-bind-class, data-bind-style, data-bind-attr, data-show, and data-render. Inside a list, the binding expression sees both the item's own state and any computed properties defined on the item shape, with the same precedence rules as component-level bindings.

This is a feature most reactive frameworks have, and now so does WildflowerJS.

New mini build variant

v1.1 adds a fifth build variant: mini. It's the lite build minus the pools subsystem, for apps that don't use high-throughput rendering and want a smaller bundle.

The full lineup is now mini → lite → core → spa → full, with mini at the smallest end and full at the largest. Each variant ships in dev, raw, and minified flavors with brotli + gzip pre-compression.

Breaking changes

Two breaking changes, both with one-line migrations.

Action handlers no longer stop event propagation by default

In v1.0, click events (and other events dispatched via data-action) had their propagation stopped after the action ran. This silently consumed events that external delegation systems (jQuery, vanilla event delegation, third-party widgets) expected to receive on the document.

In v1.1, events bubble naturally past the action handler. Internal nested-component double-fire is still prevented via a per-event marker, without relying on stopPropagation. Most apps will see no behavioral change.

If you specifically relied on action handlers stopping the bubble chain (modal click-outside guards, dropdown dismissal logic, anywhere you'd otherwise call event.stopPropagation()), add data-event-stop to the element to opt back in to the v1.0 behavior on that element only:

<button data-action="open" data-event-stop>Open menu</button>

The data-model-debounce attribute is removed

Debouncing belongs on the action that receives the input, not on the model binding. The v1.0 attribute's semantics collided with list re-render timing and produced occasional stale-value hazards.

Migrate data-model-debounce="300" to data-action="input:handleInput" paired with data-event-debounce="300" on the same element:

<!-- v1.0 -->
<input data-model="query" data-model-debounce="300">

<!-- v1.1 -->
<input data-model="query" data-action="input:handleInput" data-event-debounce="300">

The action layer is the right place for debouncing because it sits at the boundary where user intent enters the system, and it composes cleanly with the rest of the event-handling pipeline.

Security

v1.1 closes the single exploitable finding from a recent security audit, plus a related hardening:

  • xlink:href is now in the URL-attribute sanitizer. Previously, an attacker-controlled value bound to xlink:href on an SVG <a> or <use> could carry a javascript: URI past the existing checks.
  • The data:image/ allowlist is narrowed to raster formats only. data:image/svg+xml is no longer permitted, since inline SVG can carry scripted content.

A 16-test regression suite has been added to lock both fixes in place.

Better dev-mode error messages

Every WF-NNN warning in dev mode now prints a clickable docs link pointing at the canonical fix recipe, along with suggestion text where the framework can pin down the right next move. Several scattered [WF-XXX] console calls were also migrated through the unified error path so all warnings get the same treatment. Example for the new data-bind-class shape warning:

[WF WF-505] Class binding shape mismatch (coerced): computed returned an object; coercing truthy keys to a class string
  ↳ Suggestion: A computed should return a string. For inline expressions, write `data-bind-class="{'is-active': cond}"`.
  ↳ Docs: https://www.wildflowerjs.com/docs/error-codes?code=WF-505

Notable fixes

  • Memory leak on destroyComponent: effects scoped to internal RSM stub instances were leaking past component teardown. The destroy path now sweeps them along with the rest of the component's effect set.
  • List actions shadowed by ancestor data-action: when an ancestor element carried a data-action and the row's own action was stripped at scan time, the click would route to the ancestor instead of the row. Click delegation now falls through to the row's metadata.
  • Item-level computeds reacting to external store mutations: computeds defined on a list-item shape now invalidate correctly when the data they read from a store changes.
  • Nested data-list hydration timing: inner lists rendered before the outer store had hydrated would render empty. They now wait for hydration and render correctly on the next flush.
  • Portal binding performance: _renderPortalBindings now uses a per-component context index instead of a full traversal, removing a hot-path bottleneck at high portal counts.
  • Validation false-positives: the binding-expression validator no longer flags legitimate property accesses (e.g. state.foo.bar) as undefined state references.
  • Same-name field/computed leak in list bindings: when an item field and a component-level computed shared the same name inside a list (e.g. a component had a teamColor computed, and each row in a sub-list also had a teamColor field), the component-level computed was winning the lookup and overwriting per-row values across rows. Per-row item fields now take precedence as documented. Affects data-bind-style and data-bind-class with object syntax.
  • In-list effect race with component-level writers: component-level object/class-binding effects were registering against elements inside data-list rows, racing with the list's own per-row writers and producing intermittent visual glitches. Effect registration now skips in-list elements; per-row updates own those elements exclusively.
  • Internal: a documented lifecycle invariant set and a 15-scenario race harness are now part of the regression suite, locking the framework's init/destroy contract against future drift.

Try it

Install via npm:

npm install wildflowerjs@1.1

Or drop in via CDN:

<script src="https://cdn.jsdelivr.net/npm/wildflowerjs@1/dist/wildflower.lite.min.js"></script>

→ Installation guide
→ Documentation
→ GitHub

WildflowerJS reaches new developers exactly one way: someone who tried it tells someone else. If you checked out WildflowerJS and find it interesting, please pass on a link to friends. Thanks!