← Back home · Compare
StxScript vs writing Clarity directly
The baseline. Raw Clarity in a .clar file.
Writing Clarity by hand is the honest baseline. StxScript adds a source language on top. It is a fair trade when developer-experience savings beat the cost of an extra layer, and not when they do not.
| Feature | StxScript | writing Clarity directly | Advantage |
|---|---|---|---|
| Source language | StxScript (TS-flavored) | Clarity | Comparable |
| Runtime | Clarity on Stacks | Clarity on Stacks | Comparable |
| Build step | stxscript build | None | writing Clarity directly |
| Type checking | Static, ahead of deploy | Enforced at deploy | StxScript |
| Editor experience | LSP, VS Code extension, snippets | Clarity LSP (separate project) | StxScript |
| Generics / type aliases | Yes; compile away to monomorphic Clarity | Not in the language | StxScript |
| Match expressions | Yes, on Optional and Response | Manual if + unwrap | StxScript |
| Output auditability | Indented Clarity, reviewable line-by-line | You wrote it; you read it | Comparable |
| Dependency footprint | Python 3.10+ at build time | None | writing Clarity directly |
| Cost to switch back | The committed .clar is the deployable artifact | N/A | Comparable |
Pick StxScript when
- ▸You come from TypeScript, Rust, or Swift and the Lisp surface syntax is slowing you down
- ▸You want a checked type system surfacing errors in your editor (LSP) before deploy
- ▸You like generics, type aliases, and decorators as ways to communicate intent
- ▸You want match expressions for Optional and Response instead of nested if/unwrap
- ▸You value formatter + linter + watch-mode without assembling them yourself
- ▸Your team is growing and onboarding speed matters more than one less dependency
Pick writing Clarity directly when
- ▸You only ship one small contract and the build step is overhead
- ▸You are an experienced Clarity developer and the Lisp surface is muscle memory
- ▸Your audit pipeline strictly forbids any source-to-source translation
- ▸You want zero non-Stacks dependencies in your build chain
Still deciding?
The two tools are not in conflict. Most teams that adopt StxScript still keep the rest of their Stacks toolchain. Try one file in StxScript; ship the rest of the project unchanged.