The hyperscript language was created by the
_hyperscript project, and that remains its home.
hyperfixi is not a competing language and is not positioned against
_hyperscript — we work in the same hypermedia ecosystem, on the same idea:
UI behavior that reads like a description of what it does.
hyperfixi is a different build of that idea: the same syntax and
semantics, packaged as a modular, tree-shakeable runtime.
If _hyperscript serves you well, keep using it. It is the canonical
implementation: one script tag, no toolchain, mature, and maintained by the
people who designed the language. For most sites that want hyperscript, it
is the obvious choice.
hyperfixi exists for situations where the packaging matters:
@hyperfixi/* packages, TypeScript types,$count), live blocks, component definitions, and ahyperfixi-extensions and reactivity categories in thehyperfixi parses and runs standard hyperscript syntax. Our
164-pattern reference library is the working test bed: every
pattern on this site renders and executes through hyperfixi in your browser,
and we're not aware of a hyperscript pattern hyperfixi can't handle.
Per-pattern engine verification is tracked in the corpus (visible in the
Pattern Browser's engine filter) and is ongoing. If you find hyperscript
code that behaves differently on hyperfixi,
that's a bug — please report it.