Overview
Understand Regor’s reactive state, expressive templates, and direct DOM updates.
Regor is a reactive UI library designed for engineers who want:
- Direct control over runtime behavior.
- A powerful template/directive model.
- TypeScript-friendly reactivity primitives.
- Freedom to optimize with plain JavaScript and DOM when needed.
Regor is intentionally practical. It does not force one rigid rendering architecture for every use case.
Choose your mount boundary, connect state to markup, and compose the interactions your interface needs.
Architecture Positioning
Regor is Vue-inspired in directive syntax, but different by architecture.
- Regor does not rely on a Virtual DOM layer.
- Regor can bind existing server-rendered/static markup in place.
- Regor supports runtime composition and reentrance across already-mounted regions.
- Regor keeps optimization escape hatches close to plain DOM and JavaScript.
Refs and computed
Store writable values and derive the values that depend on them.
Expressions and directives
Declare how state appears in HTML and SVG, and how events update it.
The actual DOM
Regor updates the bound nodes as their reactive dependencies change.
Why Teams Choose Regor
1. Runtime flexibility without lock-in
Regor can bind existing markup and progressively enhance real pages. You can adopt it incrementally instead of rewriting everything.
2. Reactivity that stays explicit
You get ref, sref, computed, watchEffect, observe, and batching primitives. State flows are explicit and composable.
Control APIs like pause, resume, and entangle help you shape update behavior intentionally in complex flows.
3. Directive model with real depth
Regor supports rich directive workflows:
- Conditional rendering (
r-if,r-else-if,r-else,r-show). - List rendering (
r-forwith keys, table use cases, nested structures). - Attribute/property/class/style/event binding (
r-bind,.prop,.camel,:class,:style,@event). - Form binding (
r-model) and dynamic components (:is,:context).
4. Excellent fit for mixed environments
Regor works well when part of your DOM is owned by other systems, or when performance-critical sections need custom handling.
5. TypeScript without framework-only indirection
Regor uses plain TypeScript code paths for app and component contexts (createApp<T>, ComponentHead<TProps>, interfaces/classes). You keep normal TS ergonomics without relying on custom file format compilers.
See the flow in action
- Subtotal
- $100.00
- Discount
- $0.00
Two inputs. Three computed values. One connected view.
import { batch, computed, html, ref } from 'regor'
export function createQuote(interactive = false) {
const quantity = ref(4)
const unitPrice = ref(25)
const discounted = ref(false)
const subtotal = computed(() => quantity() * unitPrice())
const savings = computed(() => (discounted() ? subtotal() * 0.1 : 0))
const total = computed(() => subtotal() - savings())
const money = (value: number) => `$${value.toFixed(2)}`
const reset = () =>
batch(() => {
quantity(4)
unitPrice(25)
discounted(false)
})
return {
interactive,
quantity,
unitPrice,
discounted,
subtotal,
savings,
total,
money,
reset,
}
}
export const quoteTemplate = html` <div class="guide-demo guide-demo--split">
<div class="guide-controls">
<label for="quote-quantity">Seats <strong>{{ quantity }}</strong></label>
<input
id="quote-quantity"
type="range"
min="1"
max="20"
r-model.number="quantity"
:value="quantity"
:disabled="!interactive"
/>
<label for="quote-price"
>Price per seat <strong>{{ money(unitPrice) }}</strong></label
>
<input
id="quote-price"
type="range"
min="10"
max="100"
step="5"
r-model.number="unitPrice"
:value="unitPrice"
:disabled="!interactive"
/>
<label class="guide-check"
><input type="checkbox" r-model="discounted" :disabled="!interactive" />
Apply a 10% team discount</label
>
<button type="button" @click="reset" :disabled="!interactive">
Reset quote
</button>
</div>
<div class="guide-readout">
<span class="guide-kicker">YOUR TEAM / MONTHLY</span>
<output class="guide-total" aria-live="polite">{{ money(total) }}</output>
<dl>
<div>
<dt>Subtotal</dt>
<dd>{{ money(subtotal) }}</dd>
</div>
<div>
<dt>Discount</dt>
<dd>{{ money(savings) }}</dd>
</div>
</dl>
<p>Two inputs. Three computed values. One connected view.</p>
</div>
</div>` import { createApp, useScope } from 'regor'
import { createQuote, quoteTemplate } from './quote'
import { createServices, servicesTemplate } from './services'
import { createProfile, profileTemplate } from './profile'
import { createLifecycle, lifecycleTemplate } from './lifecycle'
// Each guide mounts only its own island. Everything outside the root stays static.
function mount<T extends object>(
id: string,
create: (interactive: boolean) => T,
template: string,
) {
const element = document.getElementById(id)
if (element)
createApp(
useScope(() => create(true)),
{ element, template },
)
}
mount('guide-quote', createQuote, quoteTemplate)
mount('guide-services', createServices, servicesTemplate)
mount('guide-profile', createProfile, profileTemplate)
mount('guide-lifecycle', createLifecycle, lifecycleTemplate) Inputs update refs. Computed values derive the quote. Template bindings update the displayed totals. Explore reactivity and templates to follow the same example in detail.
Core Philosophy
Regor’s philosophy is:
- Keep defaults productive.
- Keep escape hatches available.
- Keep internals understandable.
- Keep control in developers’ hands.
What Regor Is Not Trying To Be
Regor is not built around artificial constraints to optimize only one benchmark shape. It is built for real product constraints where integration flexibility matters.
If your app needs:
- Existing-markup binding.
- Runtime composition.
- Context flexibility.
- Controlled optimization paths.
Regor is a strong fit.
Regor vs Vue (Practical Lens)
- Vue is a strong default for framework-owned SPA architecture.
- Regor is a strong default for progressive enhancement and static-first plus dynamic-island architectures.
- Vue commonly centers build tooling for peak DX/perf in SPA workflows.
- Regor keeps build-less and CSP-constrained runtime options first-class.
- Both are capable; pick based on rendering ownership and deployment constraints.
Practical Tradeoffs
Decide which region Regor owns, then measure the interactions that matter there. The mounting and performance guides explore these choices.
Regor favors flexibility and control. In very binding-dense paths, runtime cost can grow with total DOM + binding volume. This is normal for highly dynamic runtime systems.
The upside is that Regor keeps optimization options open:
- Reduce binding density where it matters.
- Use stable keying and list strategies.
- Drop to targeted custom logic in hot sections.
- Keep the rest of the app high-level and maintainable.