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

Six 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 26 October 2026: 45 language tests, all nine JS/TS/NRS diagnostic probes and the full standard release suite pass. This array-checking change is newer than the hosted benchmark run below.

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.

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.