NiralScript.

Its own language.
Not another component extension.

.nrs belongs to NiralScript. .niral remains Niral's component format, bringing together templates, styles and server code. They have different responsibilities.

The language core has its own directory, parser, scanner, type checker and diagnostics, with no imports from the Niral framework. Its standalone compiler emits JavaScript ES modules. A separate Niral adapter connects the language to Niral's fine-grained runtime.

Niral comes first. Other framework targets, including React for Next.js, are planned. They are not available integrations today.

State, then what follows.

state declares a reactive value. derive declares a value computed from it. Updating the count updates its doubled value through Niral's fine-grained runtime. Optional annotations check the values before JavaScript is emitted.

<script lang="niralscript">
  state count: number = 0
  derive doubled: number = count * 2
</script>

<button on:click={() => count += 1}>Increase</button>
<p>{count} doubled is {doubled}</p>

Scripts can live inside a .niral component or a separate .nrs file, with named imports from other .nrs modules. NiralScript remains experimental; these results do not establish a stable language release.

Explore Niral reactivity

Seven milestones.
One independent language.

Existing JavaScript, TypeScript and JSX/TSX support in Niral stays intact. NiralScript is an additional language direction, not a replacement for those workflows.

Catch the wrong value.
Before it reaches the array.

Statically named push, unshift, splice and fill calls now check every inserted value against a known array element type. Position arguments and required argument counts are checked too.

state items: number[] = []

items.push(1, 2)
items.unshift(0)
items.splice(1, 1, 3)
items.fill(4, 1)

items.push("bad")
// Compile error: Expected number, received string

Simple aliases, typed record fields, annotated parameters and returns, and literal bracket method names retain these checks. Unannotated arrays remain dynamic. Unknown host values remain permissive.

Verified locally on 4 November 2026: all 81 language tests and 258 framework tests pass, including real TypeScript checking and the release gate. Classes execute in standalone and both component emitters, with inline/external dev/production HTTP, SSR, RPC privacy and original-source exception checks. Nine actual VS Code host check groups pass. Browser tests were not rerun for these changes; the hosted benchmark below predates them.

A .nrs file.
An ordinary JavaScript module.

The standalone compiler does not need a Niral application. Its generated ES module exposes createInstance, with isolated inputs and state, value accessors and input updates. A small included reactive runtime caches derived values; hosts can supply their own compatible runtime.

input initial: number
state count: number = initial
derive doubled: number = count * 2

export function increment(): number {
  count += 1
  return doubled
}

Type annotations are erased. Version 3 source maps retain original module sources. The CLI checks import boundaries and refuses to overwrite existing output files.

Explicit runtime contracts

contract<Type>(value) generates runtime checks from the same type declaration. Valid data is copied and returned with that type. Invalid data throws NRS081 with a field path, without coercion.

type Order = { quantity: number, note?: string }

export function readOrder(candidate: unknown): Order {
  return contract<Order>(candidate)
}

const accepted = readOrder({ quantity: 2 })

Finite numbers, strings, booleans, literals, null, undefined, arrays, records, unions and concrete aliases are supported. Extra record fields and accessor-backed record fields or array elements are rejected. Extra non-index array properties are dropped. Unknown, class, function and promise schemas are compile errors. Ordinary annotations still do not validate external data.

Validation runs only at the explicit expression. Put a server-side guard before business logic; a client check cannot secure an RPC. Niral returns HTTP 400 with field errors for server contract failures. Contracts do not add integer ranges, business rules or automatic input-update validation.

Comparable execution.
Measured, not assumed.

GitHub Actions ran identical function bodies in JavaScript, TypeScript and NiralScript across four workloads. All correctness checks passed. These are direct language tests, without components or reactive operations.

Ubuntu 24.04 x64, TypeScript 5.7.3, 30 warmups and 12 rotated rounds per process. Compilation, module loading and instance setup are excluded from execution timings. NiralScript and TypeScript both emit JavaScript running on the same V8 engine.

The Node 22 runner used AMD EPYC 7763; Node 24 used AMD EPYC 9V74. Compare languages within each runner, not Node versions. These four workloads establish neither a universal speed winner nor complete TypeScript type-system or tooling parity.

Tested commit: 59d721b. All six hosted jobs passed: Node 22/24 language comparisons and Linux/Windows release checks. Hosted results predate the typed-array follow-up.