A JavaScript Framework With No Build Step

There is no npm install, bundler config, or compiler between your code and the browser. Seven tiers, from a 51 KB interactive-widget build up to a full build with SSR and routing, and every one of them is still just a script tag.

What "No Build Step" Actually Means

A lot of frameworks say they're lightweight and still hand you a package.json. WildflowerJS doesn't. There is no compilation stage between the code you write and the code the browser runs:

No npm install

Using WildflowerJS in a page requires zero packages. Point a <script> tag at the file, self-hosted or from a CDN, and it runs.

No compiler

There is no JSX, .vue single-file component, or template-to-render-function step. What you write in the HTML file is what the browser parses.

Works from a plain file

Double-click the HTML file and it runs in the browser. There is no dev server to start, port to remember, or terminal to keep open.

No config files

No vite.config.js, no webpack.config.js, no .babelrc. There's nothing to configure because there's nothing to build.

The Complete Setup

This is the entire toolchain, not a simplified excerpt.

<!DOCTYPE html>
<html>
<head>
    <script src="https://cdn.jsdelivr.net/npm/wildflowerjs@1/dist/wildflower.min.js"></script>
</head>
<body>
    <div data-component="hello">
        <p>Hello, <span data-bind="name">World</span>!</p>
        <input data-model="name" placeholder="Enter your name">
    </div>

    <script>
        wildflower.component('hello', {
            state: { name: 'World' }
        });
    </script>
</body>
</html>

Save that as a .html file and open it. Typing in the input updates the greeting live. There's no second step where this code gets transformed into different code before it runs. This is the code that runs.

What You Don't Give Up

Most script-tag libraries earn "no build step" by staying small in scope, offering a bit of DOM sugar and maybe two-way binding. Add routing, server-side rendering, or shared state across components, and you are back to a bundler.

WildflowerJS scales up instead of switching approaches. Every tier below is still a single <script> tag, and the largest one includes server-side rendering:

Components and stores, with the full lifecycle (init, destroy, update hooks), computed properties, props-based composition, error boundaries, and shared state, in every tier, starting from the smallest
Forms and events, including native browser validation and cross-field rules on data-model, plus a directive and hook system for extending the framework itself, in every tier
Lists with keyed reconciliation, including nested lists, from the mini tier up
Entity pools for high-throughput, per-frame workloads like simulations and games, in the mini-pool tier and from the lite tier up
Plugins, portals, and transitions from the standard tier up
Routing for multi-page single-page apps, in the spa and full tiers
Server-side rendering and live data queries, so the same markup can be rendered ahead of time and hydrated in the browser, in the full tier

None of it requires a compilation step at any tier. Every feature is already in the file you link.

The Real Numbers

The table below gives what actually crosses the network, compressed, for every tier.

Build	What it adds	Transferred (Brotli)
`wildflower.nano.min.js`	Reactive state, computed properties, binding, forms, components, stores	50.5 KB
`wildflower.mini-pool.min.js`	+ Entity pools, and nothing else: the lean tier for games and simulations that render through `data-pool` and never use `data-list`	55.0 KB
`wildflower.mini.min.js`	+ Lists, with keyed reconciliation (in place of pools)	73.8 KB
`wildflower.lite.min.js`	+ Entity pools, for per-frame and high-throughput rendering	78.0 KB
`wildflower.min.js`	+ Plugins, portals, transitions	81.7 KB
`wildflower.spa.min.js`	+ Routing	86.1 KB
`wildflower.full.min.js`	+ Server-side rendering, live data queries	98.8 KB

Each tier is the whole framework at that size, not a render layer with the rest bolted on separately. There is nothing else to add for state management or forms at any tier. Use spa or full only when you need routing or server-side rendering.

Why This Matters Beyond Convenience

Skipping the build step isn't just faster to start. It changes what can go wrong later:

No supply chain to inherit

There is no node_modules and no transitive dependency graph
No postinstall scripts running on your machine or in CI
Nothing to audit but the one file you already chose to trust

Nothing to come back and fix

A project you open in a year still runs; there's no toolchain to have gone stale
No dependency bump breaks the build, because there's no build
What you shipped is what's still running

Try It Now

Nano Tip Splitter

One HTML file, one script tag, nothing compiled. Computed totals, two-way inputs, reactive styling, and a conditional message.

Demo Code

Nano HTMX Integration Lab

A swapped-in fragment initializes itself with no wildflower.scan() call. hx-get and data-bind on the same page.

Demo Code

The example above is the complete quickstart. From here:

Quick Start Guide Why WildflowerJS?

Previous Why WildflowerJS?

Next Coming From...