Framework capabilities and limits
This audit describes the repository at main after PR #173, reviewed on 2026-10-01. It covers source and existing verification paths, rather than certifying every application or deployment.
Implemented means the feature has an implementation and an exported API or generated application path. Linked tests describe the available coverage; their presence alone does not prove a particular checkout passes them. Browser evidence is limited to the fixtures, engines, and runs recorded in the linked guides.
Implemented features
| Area | What Purity provides | Evidence and limits |
|---|---|---|
| Reactivity | state, compute, watch, and batch on a custom push-pull graph. |
Signal implementation, tests. Inspired by the TC39 proposal; not a native engine API. |
| Templates | Direct DOM templates and optional build-time compilation with @purityjs/vite-plugin. |
Compiler, plugin tests. AOT compilation is optional; failed transformations can fall back to runtime compilation. |
| Lists | Keyed reconciliation, single-tag lists, and opt-in { virtual: true } rendering with framework-managed measurement and spacers. |
Control flow, list tests, windowing browser check. Virtualization is an application option, not evidence of a faster ordinary list. |
| Components | Custom Elements, Shadow DOM, slots, teleport, delegatesFocus, and form participation. |
Components, form tests, Shadow DOM guide. The automatic form bridge supports one native control; cross-boundary labels still require deliberate component markup. |
| SSR and hydration | String and streaming rendering, Declarative Shadow DOM, typed component-property restoration, and adoption of compatible server DOM. | SSR exports, hydration parity tests. Use @purityjs/ssr in server entries, not browser bundles. |
| SSG and mixed delivery | Static generation and CLI starters for client rendering, Node SSR, and mixed static/server pages. | Server rendering guide, static renderer. The --app starter uses document navigation; it does not automatically turn every route into a SPA. |
| Routing | Navigation primitives, file-route manifests, layouts, error/404 boundaries, loaders, typed route parameters, and route status/header responses. | Route tests, async route tests, SSR router tests. Applications still supply their route views and server entry points. |
| Server actions and forms | Native POST submission and opt-in data-purity-enhance forms with pending state, duplicate-submit prevention, field errors, input preservation, and timeout/teardown cancellation. |
Form guide, enhancement tests, packaged app browser check. Enhancement applies to supported same-origin forms; cancellation cannot undo an accepted server write. |
| Query refresh | Cached queries and successful-action invalidation, with optional same-origin redirects. | Query implementation, form guide. Application-specific write consistency and idempotency remain the application's responsibility. |
| Request lifecycle | Node disconnect signals, loader/resource cancellation, independent Suspense boundary deadlines, and bounded streaming output buffering. | SSR guide, route cancellation tests, backpressure tests. External operations must honor the supplied abort signal; output limits do not cap all application memory. |
| Islands | Per-subtree hydration with load, idle, visibility, first-interaction, and media-query triggers. | Islands guide, browser check. Only explicitly marked regions use island hydration. |
| Debugging | A console graph hook and an opt-in development panel showing nodes, previews, and dependencies. | Debugging guide, DevTools browser check. No source locations, component hierarchy, or time travel. The panel is excluded from production builds and preview. |
| Memory regression checks | Browser mount/unmount checks, SSR stream retention checks, and built ESM/CJS inspector registry checks with cleanup-disabled controls. | Inspector check, SSR check, browser check. These detect regressions in selected workloads; they are not a universal leak detector. |
Accessibility evidence
The accessibility audit records keyboard, form, axe-core, text-size simulation, and emulated forced-colors checks for its fixtures in Chromium, Firefox, and WebKit. It also records an incomplete WebKit contrast result for a native multiple-select.
NVDA, VoiceOver, actual browser zoom, and operating-system high-contrast behavior remain unverified. Automated checks do not establish application-wide accessibility. Enhanced forms manage error focus and status announcements; their actual screen-reader behavior still needs those acceptance runs.
Browser and deployment limits
The proposed 1.0 browser matrix is a source-derived target, not a promise that every listed minimum browser version was tested. Recent engine checks do not verify those old minimum versions.
The Node SSR path documents project creation, production builds, and server startup. Adapter examples exist for other hosts, but their presence does not prove a live deployment. The public docs site exercises Purity's own SSR/SSG and client runtime; it does not establish production adoption across arbitrary applications.
Performance and bundle measurements
No universal bundle-size figure or cross-framework ranking is certified by this audit. The production feature measurements cover counter, keyed list/conditional, enhanced form, and SSR hydration fixtures with and without AOT, record raw/gzip/Brotli sizes and direct Function constructor sites, and enforce budgets in CI. Optional Chromium/Firefox/WebKit checks verify all eight outputs, including SSR node identity. The expanded reference finds controls and hydration AOT payloads larger than runtime, despite smaller counter/form AOT payloads. Those results describe these fixtures and toolchain, not every application. Build mode, imports, application markup, data generation, browser version, hardware, and sampling can change the result. The benchmark harness provides measurement paths, not a permanent framework ranking.
For a new comparison:
- Record the exact Purity commit, package versions, build mode, browser, and sampling settings.
- Resolve the latest stable or explicitly selected prerelease versions at measurement time; distinguish the two.
- Match native framework workloads, markup, and data. Any additional runtime helper changes the scope of the comparison.
- Measure ordinary lists separately from opt-in windowing, and runtime timings separately from instrumented profiles or heap checks.
- Compare the same application's production bundles with and without AOT before attributing size savings to the plugin.
Historical figures need their original run artifacts and methodology before reuse. This page makes no universal speed or size claim; use the versioned counter reports for its specific bundle measurements.
Remaining work
- Verify the declared minimum browser versions, or revise the proposed matrix with recorded evidence.
- Complete the specified screen-reader, actual zoom, and operating-system contrast acceptance runs.
- Add debugging source locations and component context if required by real debugging journeys.
- Record deployment evidence for each supported host and refresh controlled performance measurements. Production feature profiles and CI budgets are implemented. Unused each/match hydration registration was removed from the counter payload; controls/hydration profiles still retain JIT fallbacks and have larger AOT payloads, requiring further dependency separation. Broader application profiles remain open.
- Review and adopt the 1.0 policy and checklist; this audit does not mark that Proposed ADR accepted.
Execution checklist
| Work | Acceptance evidence | State |
|---|---|---|
| Production feature bundle baseline | Same source in runtime/AOT builds, complete chunk totals, versioned reports, enforcing budgets, and three-browser counter/control/form/hydration verification. | Automated measurement and CI checks implemented. |
| Minimum browser support | Actual runs on each declared minimum engine, or a revised matrix with feature and engine evidence. | Open. |
| Assistive technology and visual behavior | Recorded NVDA/VoiceOver, actual zoom, and operating-system contrast acceptance runs. | Criteria exist; not verified. |
| Debugging context | A real application stack/source location and component relationship can be followed from the inspector. | Open. |
| Host deployment | A built application starts and serves the documented SSR/action paths on each claimed host. | Node local checks exist; per-host live evidence remains open. |
| Performance comparisons | Fresh matched workloads, exact current package versions, reproducible settings, and paired run artifacts. | Refresh required. |
| 1.0 policy | Explicit adoption decision plus evidence for the release checklist. | Proposed; not adopted. |