JESS // A NATIVE APPLICATION KERNEL FOR LUAU
Jess is the native kernel under a Luau application. It owns the operating system, the hardware, resource lifetimes, and the trust boundary, and nothing else. Everything that means something is a package, running with exactly the capabilities it asked for.
Nothing is special. Not the game, not the renderer, not the tooling. Not even the engine.
WHY JESS
Luau runs on L3i, with native code generated for the modules that ask for it and no others. jess run --profile prints call, sampling, and native-block statistics; --emit-asm writes the generated assembly and --disassemble the bytecode, from the same binary. A stable frame does no hidden Luau work. Native code is a privilege: it earns the boundary with a measurement, or it leaves.
Files, the environment, processes, and the network are named capabilities, denied by default and checked at the native seam. A package cannot grant itself one, and running from a source folder gives code no power the packed archive would lack. Exports are frozen. A script domain is one isolated authority, with its own contexts, workers, generation, and teardown. A Package Source and the JPK packed from it carry the same digest, and the tests ship inside.
One binary is the runtime, the test runner, the type checker, the package tool, the workspace tool, the type generator, and the style checker. A manifest, a lock file, workspaces, pack, sync, test, check. jess luau-types writes a strict type stub for every module, native or built-in, and jess init wires them into your editor before you've written a line.
SHOWN, NOT TOLD
jess runA script under jess run holds your terminal and the input devices in front of you. Everything else is a flag away, and the refusal names the function and the capability. A script you make executable and run as a program holds everything, as any program you chose to run does.
$ jess run read.jsl
error: dream.fs.readFileString: needs the 'filesystem.read'
capability, which this runtime does not grant
$ jess run --capability filesystem.read read.jslA package's command declares its capabilities in the manifest. Running it grants them only when the operator agrees, and the package never gets a vote.
[targets.greet]
kind = "command"
entry = "tools/greet.jsl"
capabilities = ["process.environment"]
$ jess package run greeter
error: cannot run target greet
required capability denied:
process.environment
$ jess package run --capability process.environment greeter
Hello, dave.Every module in a package is checked in strict mode, with each require resolved the way the runtime resolves it. The typo fails here, not in front of a user.
$ jess package check greeter
errors:
- file: tools/greet.jsl
line: 5
column: 7
message: 'Key ''gret'' not found in table
''{ read greet: (string) -> string }'''
error: 1 type errorNO PRIVILEGED PATHS
Whatever you build goes through the same package and capability boundary. There is no second, private framework for the first-party work, and nothing gets a native path merely because engines traditionally gave it one.
A target is a script with a package around it: an entry, the layers it activates, and the capabilities it declares. jess package run runs it with exactly those, and a workspace runs it by its command name with nothing wrapping it.
Managed modules loaded into one script domain, host callbacks per frame, named events routed between domains, and interfaces that later packages override on purpose. A game, an editor, and a launcher are all some packages, some callbacks, and some frames.
TCP, TLS, DNS, and UDP are capabilities, not engine features. The host runs frames without a window, so a server is an application that never asked for one, and a build pipeline is a command that reads and writes exactly the paths it was granted.
Markdown, templates, Sass, search, and static output, from a generator that is a package built on Jess. The dev server that rebuilds this page when a file changes is one Luau file over a TCP poller. Keep scrolling.
BUILT WITH ITSELF
The generator is a package. The build is a command target that activates it with the file capabilities it declares and nothing else. The dev server is another target with a TCP listener added. No Zola, no Node, no Python in the loop.
$ jess workspace run --trusted jess-site-build -- target/site
[jess] site complete: 66 pages, 8 sections, 1 search indexes -> target/site
$ jess workspace run --trusted jess-site-serve
[serve] http://127.0.0.1:63333/
[serve] watching site: config.toml, content, templates, sass, static, dataFINE. GIVE ME THE PRIMITIVES.
jess init my-appjess run my-app/main.jsljess check my-app/main.jsljess init greeter --package com.example.greeterjess package test greeterjess pack greeter -o greeter.jpk