Framework Comparison
How WildflowerJS compares with Vue, React, Svelte, and Solid, feature by feature.
Wildflower's authoring model is similar in style to Alpine and htmx, but its engine and feature set are in the class of Vue, Svelte, and Solid. It has a single dependency graph, keyed list reconciliation, router, SSR (via adoption not hydration), and a data query layer with optimistic writes. In the matrix below we're comparing with the latter group, since the feature sets are equivalent.
Feature Matrix
| Feature | WildflowerJS | Vue | React | Svelte | Solid |
|---|---|---|---|---|---|
| Authoring model | Attributes on plain HTML, no build step (as Alpine, htmx) | SFC or template strings, build optional | JSX, build required | Compiler required | Compiler required |
| No build step required | Yes | Optional | No | No | Optional (loses JSX) |
| Full reactivity system | Yes | Yes | Yes | Yes | Yes |
| SPA routing | Built-in | Plugin (Vue Router) | Plugin (React Router) | Plugin (SvelteKit) | Plugin (Solid Router) |
| Fine-grained DOM updates | Yes | No (VDOM) | No (VDOM) | Yes (compiled) | Yes (signals) |
| Large application capable | Yes | Yes | Yes | Yes | Yes |
| Standards-based (plain HTML/JS/CSS) | Yes | No (SFC, template DSL) | No (JSX, build required) | No (.svelte, compiler) | No (JSX, compiler) |
| Third-party library friendly | Yes | Mostly | Careful | Mostly | Yes |
| Web component interop | Yes (100% on the CEE suite) | Mostly | Partial | Yes | Yes |
| SSR / progressive enhancement | Yes | Yes | Yes | Yes (SvelteKit) | Yes (Solid Start) |
| Component state | Built-in | Built-in (ref/reactive) | Built-in (useState) | Built-in ($state) | Built-in (signals) |
| Global stores | Built-in | Plugin (Pinia) | External (Redux, Zustand) | Built-in (Svelte stores) | Built-in (createStore) |
| Store persistence (localStorage) | Built-in (storageKey + autoSave) | External (persistedstate plugin) | External (persist middleware) | External | External |
| Data queries (server state: cache, refresh, retry) | Built-in (data-query) | External (TanStack Query) | External (TanStack Query, SWR) | External (TanStack Query) | createResource (fetch only) |
| Optimistic updates with rollback | Built-in (field-level claims) | External | useOptimistic (basic) | External | External |
| Query cache persistence (instant reload paint) | Built-in (persist: true) | External (persister add-on) | External (persister add-on) | External (persister add-on) | External |
| Form validation | Built-in (native constraints + error binding) | External (VeeValidate) | External (React Hook Form) | External (Superforms) | External |
| Computed properties | Built-in (cached) | Built-in (cached) | useMemo | $derived (compiled) | createMemo (cached) |
| Async computed properties | Built-in (loading/error states) | External (VueUse computedAsync) | No | {#await} template blocks | createResource |
| Component system | Full | Full | Full | Full | Full |
| Dual list rendering modes (reactive + lightweight) | Yes (data-list + data-pool) | No | No | No | No |
| Transitions / animations | Built-in | Built-in | External (Framer Motion, etc.) | Built-in | External (solid-transition-group) |
| Portals | Built-in | Built-in | Built-in | No | Built-in |
| Error boundaries | Built-in (all builds) | onErrorCaptured hook | Class components only | <svelte:boundary> | Built-in |
| Strict CSP with no build step | Yes (data-csp-safe) | No (runtime needs unsafe-eval) | No (build required) | No (build required) | No (build required) |
| TypeScript support | Type definitions | Full | Full | Full | Full |
Key Comparisons
vs Solid
Solid and WildflowerJS both use fine-grained reactivity that updates the DOM precisely, without a virtual DOM. Solid does it through compiled JSX and signals, and WildflowerJS does it at runtime with standard HTML and data-* attributes. Both perform well. They differ in how you author a component. Solid usually requires a build step and a JSX compiler, though it can run buildless through tagged templates, which is not the standard path. WildflowerJS works with a single <script> tag and plain HTML.
vs Svelte
Svelte and WildflowerJS both achieve fine-grained DOM updates without a virtual DOM. Svelte requires a compiler that transforms .svelte files into JavaScript at build time. WildflowerJS gets the same precision at runtime with standard HTML and JavaScript, so there is no compilation step, custom file format, or build toolchain to set up.
vs Vue / React
Vue and React cover the same categories that WildflowerJS does, including reactivity, components, stores, routing, and SSR. They differ in how those capabilities reach the page. WildflowerJS delivers them without a build toolchain, without a virtual DOM, and without framework-specific file formats. You write standard HTML and standard JavaScript, include a script tag, and the framework binds to your markup via data-* attributes.
A few categories favor WildflowerJS. Data queries with optimistic updates and cache persistence, form validation, and store persistence are built in here and are third-party installs in the Vue and React ecosystems. The feature matrix above marks each one.
Two Reactivity Modes (Unique to WildflowerJS)
Every other framework on this list has exactly one rendering mode for collections, and it is the reactive one. Whether it's Vue's v-for, React's .map(), Solid's <For>, or Svelte's {#each}, every list item gets a proxy, dependency tracking, and change detection, whether it needs them or not.
WildflowerJS has two. data-list gives you automatic reactivity, and data-pool gives you explicit control with no proxy overhead. Both use the same template syntax and differ in performance profile. Pools handle full CRUD, selection, and bulk operations, all faster than the push-reactive path. They also scale to real-time data, large datasets, and per-frame animation.
No other framework offers this choice for collections. The closest alternatives are manual: React's useRef with requestAnimationFrame, Vue's toRaw() with shallowRef(), or dropping to canvas or WebGL. WildflowerJS makes it a declarative attribute that uses the same binding syntax as the reactive path.
Positioning Summary
If you need a framework that:
- Works with a single
<script>tag, with no npm, Webpack, or Vite - Uses valid HTML that any editor, any server, and any CDN can handle
- Plays nicely with jQuery, D3, Chart.js, and other third-party libraries (no VDOM conflicts)
- Scales from a single interactive widget to a full single-page application
- Provides fine-grained DOM updates without diffing a virtual tree
- Offers two list rendering modes, full reactivity or lightweight pools, so collections don't pay for overhead they don't need
- Keeps server data in sync without a data-fetching library, covering caching, optimistic writes, retry, and reload persistence
Then WildflowerJS is worth evaluating. Start with the Installation page or jump straight to the Quick Start Tutorial.