hyperfixi and _hyperscript

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: upstream's grammar and
semantics, in a typed engine made of modules, so a bundle can carry only the
commands a page uses.

When _hyperscript fits

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.

When hyperfixi fits

hyperfixi exists for situations where the packaging matters:

Compatibility

Since 4.0, hyperfixi's engine is written against upstream's source, and its
acceptance test is upstream _hyperscript's own test suite: it passes
1401 of the 1467
tests in _hyperscript 0.9.93. The rest are
listed, one by one, in the
engine's known failures,
and CI fails if that list changes in either direction.

The 164-pattern reference library
is a second test bed. A few of its patterns use upstream extensions the engine
does not bundle (web workers, sockets, event sources, components); the Pattern
Browser's engine filter shows which side of the line each one is on. If you
find hyperscript code that behaves differently on hyperfixi,
that's a bug — please report it.