_hyperscript is a small scripting language for the web, designed to be embedded directly in HTML attributes. It is the sister project of htmx — same author (Carson Gross / Big Sky Software), same philosophy: put the code on the thing that does the thing ("locality of behaviour"). BSD 2-Clause, dependency-free, ~38 KB over the wire for the entire language — parser, runtime, async engine, event system.

Where Alpine.js gives you JavaScript in attributes, _hyperscript gives you a different language in attributes. It belongs to the xTalk family descending from HyperTalk, HyperCard's scripting language, so it reads like English. Two practical advantages for something living inside an HTML attribute: it avoids noisy punctuation, and it reads top-to-bottom so behaviour is visible from source.

The project is pre-1.0 and under active development.

Also ships as an ES module (_hyperscript.esm.min.js) and on npm as hyperscript.org — the full domain is the package name. import 'hyperscript.org' auto-initialises; there is nothing to call.

Scripts go in the _ attribute (script and data-script also work), or in <script type="text/hyperscript"> blocks for anything shared.

The language is deliberately readable. The word the can be inserted almost anywhere — the parser ignores it:

Property access has three forms, in rough order of preference: possessives (#output's innerHTML, my innerHTML, its name), of expressions (the children of the closest <ul/> — binds more loosely, so it avoids parentheses), and plain dot notation (fine for method calls and deep access). Comments are --.

:x is what you use for component state — plain locals reset every time the handler runs, which is a common beginner trap. ^x searches up the DOM for the nearest element defining it, giving shared state for a region of the page without globals.

The most distinctive feature. The runtime resolves Promises internally, so asynchronous code is written linearly — there is no await keyword and none is needed. This effectively decolours functions: every function and handler is async-transparent.

wait is not just a timer — it waits on events, which pulls event-driven control flow into ordinary linear code:

Same idea in toggle .red until mouseleave — a command whose duration is bounded by an event.

The top-level constructs in a script.

Plain on queues handlers and the last one wins; on every runs them concurrently — worth knowing before debugging a handler that seems to be dropped.

Assignment and DOM insertion — note set assigns, put is DOM-aware:

DOM manipulation reads as instructions rather than API calls:

add, remove, show and hide take a when clause evaluated per element, and afterwards the result holds the matched elements — which is the whole filter-with-fallback pattern:

Control flow uses end rather than braces; there is no single-line if:

Others: send/trigger custom events, halt (with halt bubbling / halt default variants), throw, call/get, transition ... over 500ms and settle for animation, measure, pick first 3 of arr, scroll to, go to /page, log, make a <div/>, start a view transition, and the HyperTalk holdovers ask (prompt), answer (alert/confirm) and speak (Web Speech, waits for the utterance to finish).

CSS selectors are first-class syntax rather than strings passed to querySelector:

Operators are words: is/is not, and/or/not, mod, contains, matches, exists, is empty, is a String, plus an ignoring case postfix on comparisons. no x and some x test emptiness.

Collection expressions chain postfix, using it/its for the current element:

Conversions use as, pipeable with |:

Positional expressions do DOM traversal in English: first <li/> in #list, next <input/> from me, previous <li/> from me within #list, next <li/> with wrapping, closest <form/>, closest @data-id. Times and CSS units are literals: 500ms, 2 seconds, 10px, 2em.

The runtime tracks reads and writes of reactive variables — $x, :x, ^x, attributes, and in-place array mutations. Plain locals are not reactive.

Use live for derived values and DOM sync, when for side effects, bind for form inputs — and plain on handlers when you know exactly what changes.

fetch is async-transparent and throws on 4xx/5xx by default (configurable via _hyperscript.config.fetchThrowsOn):

Server-Sent Events and WebSockets are declarative features from extensions:

Loaded as separate scripts after the core:

Components are <template component="..."> elements. Each instance gets an isolated DOM scope, ${} expressions re-render reactively on ^var changes, and rendering goes through morphing so focus and handlers survive:

Custom commands, expressions and features can also be added in plain JavaScript.

Any JS function can be called directly (call alert('hi')), and js ... end blocks embed inline JavaScript with parameters and return values, exposed globally at top level. Inline JS is also the escape hatch for performance, since the runtime prioritises flexibility over speed, and it is how you ship an implementation across to a worker.

Because hyperscript is interpreted and does not use eval (except for inline js features), a CSP that forbids inline scripting has no effect on it — which is almost certainly not what a security team intends when they set one.

The real control is escaping. Any untrusted content injected into the page must have _, script and data-script attributes filtered, exactly as you would filter <script> tags. As a backstop, disable-scripting (or data-disable-scripting) on an enclosing element prevents hyperscript from executing anywhere inside it:

No configuration needed — when htmx is on the page, hyperscript processes scripts on htmx-swapped content (listening for htmx:load and htmx:after:process) and calls htmx.process() on content it inserts itself. Under htmx 4+, the hs-include extension serialises element-scoped variables (:count) into htmx requests as flat form fields, like hx-vals.