Authored by Rive CTO and co-founder Luigi Rosso
Any software tool that claims to help you build real interfaces eventually runs into the same wall: no matter how far you push visual abstractions — state machines, data bindings, parameterized components — there’s always one more edge case, one more “could we make this path emit lightning only when the car’s battery drops under 7%” that doesn’t fit cleanly into a finite menu of checkboxes.
At some point, you need a real programming layer.
We also knew two things:
A scripting layer without a serious graphics and animation engine is a toy. 1.
A scripting layer that takes over everything defeats the point of Rive.
We built the hard parts first: the Rive Renderer, the animation system, the State Machine, the file format, and the …
Authored by Rive CTO and co-founder Luigi Rosso
Any software tool that claims to help you build real interfaces eventually runs into the same wall: no matter how far you push visual abstractions — state machines, data bindings, parameterized components — there’s always one more edge case, one more “could we make this path emit lightning only when the car’s battery drops under 7%” that doesn’t fit cleanly into a finite menu of checkboxes.
At some point, you need a real programming layer.
We also knew two things:
A scripting layer without a serious graphics and animation engine is a toy. 1.
A scripting layer that takes over everything defeats the point of Rive.
We built the hard parts first: the Rive Renderer, the animation system, the State Machine, the file format, and the runtimes. Only when Rive could express full flows, not just isolated animations, did it make sense to give you a general-purpose language inside that universe.
This is the story of how we chose that language and why we landed on Luau.
What we actually needed
Dropping a generic language VM into Rive would have been easy.
Dropping the *right *language into a real-time, cross-platform, design-led tool was not.
Our requirements list looked roughly like this:
Embedded first. The language has to live inside the Rive Editor and every runtime: mobile, web, desktop, game engines, automotive, etc. 1.
Fast and tiny. We ship into performance-sensitive environments. The VM can’t be a multi-megabyte science experiment. It has to be closer to “rounding error in your build size.” 1.
Deterministic enough. We need predictable behavior, tight control over execution, and the ability to sandbox, profile, and kill misbehaving scripts without taking down the editor or host app. 1.
Gradual typing and strong tooling. Designers and developers should see errors before they hit a device. Static analysis, autocomplete, and structural understanding of code are non-negotiable. 1.
**Simple semantics. **The language should be learnable by designers, if they so choose to learn it. 1.
**Mature and maintainable. **We are already a design editor, graphics engine, animation engine, runtime suite, and now a code editor. We don’t have time to become a bespoke language research lab. 1.
**License and governance that won’t bite us later. **Permissive, open, actively maintained.
We explored WebAssembly-based approaches, classic Lua, JavaScript VMs, newer niche languages, and writing our own. Some were powerful, but huge. Some were elegant, but missing tooling. Some were promising, but immature. Some would have required us to effectively maintain a parallel universe of compilers and debug tools.
Why not WebAssembly?
WebAssembly (WASM) was tempting as an abstraction layer. However, to make it viable for Rive, we’d need to:
Layer a designer-friendly language on top.
Ship full tooling inside the Editor.
Provide tight sandboxing, debugging, and profiling across all platforms.
Keep pace with a fast-moving ecosystem
WASM’s linear memory model also complicates exposing rich C++ structures such as paths, transforms, and view models efficiently and safely. You either copy them (slow), pin them (dangerous), or build custom host APIs (brittle). Without incremental GC and mature debugging. We’d be fighting the VM more than using it.
Why not JavaScript?
The major engines are large; deterministic control is tricky; and out of the box you don’t get the kind of structured typing and editor-grade static analysis we need. There are projects that improve this, but none that fits the constraints we care about.
So we went back to a familiar friend.
Lua, upgraded
Lua kept reappearing in our notes. It’s tiny, battle-tested in games and embedded systems, and famously easy to integrate.
But it also shows its age: modern teams expect better tooling, static guarantees, and editors that understand code structurally.
Luau, Roblox’s fork of Lua, closes that gap.
It keeps Lua’s strengths (small VM, simple syntax, predictable performance) and adds the things production teams need: a gradual type system, a first-class type checker, and richer static analysis.
It stays small and embeddable, ships under a permissive MIT license, and is actively developed in the open.
When we integrated and stress-tested it, several pieces fell into place.
Protocols: the shape of scripts
Scripting in Rive starts before you write a line of code.
It starts with Protocols, structured categories of scripts that tell the Editor what you’re trying to make.
Rive currently ships with five — more to come:
Converter
Node
Layout
Test
PathEffect
Each protocol represents a different kind of script the Editor can generate: a converter that shapes data, a custom drawing function, a layout helper, a testing harness, a path effect you can attach to strokes, and so on.
Selecting a protocol generates a typed scaffold that defines the surface area you’re allowed to operate on. From there, you work with Rive-native concepts — paths, shapes, view models, artboards, state machines, timelines — but always through the lens of the protocol you picked. It keeps scripts specific and prevents “do anything anywhere” chaos.
Types: the connective tissue
This is where Luau’s type system stops being “nice to have” and becomes the backbone of the whole experience.
Rive generates Luau type definitions directly from its C++ engine APIs — paths, shapes, transforms, artboards, view models, and so on. The Editor uses those definitions to build a typed AST of your script in memory, then hands that to Luau’s type checker.
The result is a scripting environment that is:
Statically understood — protocol methods must be implemented; return values must match.
Structurally safe — you can only access fields and APIs that exist.
Toolable — autocomplete and warnings work because the Editor has real types.
Synchronized with the runtime — if a C++ API changes, the Luau types update automatically.
We don’t maintain our own parallel inference system. We simply give Luau the complete, engine-accurate model of Rive (generated from C++) and the type checker does the rest.
Protocols give scripts shape; Luau’s types give them integrity.
Tiny VM, big ambitions
Luau’s implementation is compact, on the order of a couple of hundred kilobytes once built and tuned for our use cases, while still providing a modern runtime and tooling surface. That footprint lets us keep Rive Runtimes lean, spin up multiple script contexts safely, and maintain predictable performance and memory characteristics.
This is the spirit of classic Lua, now with modern analysis layered on top.
First-class in the editor, identical in the runtimes
Another non-negotiable: scripts in Rive should behave the same in the Editor as they do in your app.
The Editor runs the same scripting engine as the runtimes. That gives us constant dogfooding, real-time feedback, and safer experimentation.
Because scripts are understood structurally, our upcoming profiling tools can tell you where your frame budget is going — whether it’s a heavy layout, an overcomplicated State Machine, or a script doing something heroic in the worst possible way.
Why not “bring your own language?”
We seriously considered “meta” solutions: build around WebAssembly, let people target whatever language and toolchain they like, and stay neutral.
However, that would mean:
Every Rive user who wants scripting has to become a language/runtime integrator.
Designers get a wall of configuration instead of a cursor and blinking caret.
We spend our time building a general-purpose VM platform instead of better creative tools.
Picking Luau is an opinionated choice for a tight, well-behaved runtime we can understand and, if needed, fork, as well as shipping a great built-in experience instead of a theoretical ecosystem.
Will someone be upset we didn’t pick their favorite language? Absolutely.
What matters is what this choice unlocks: safety, performance, ergonomics, longevity
What this means for you
Luau in Rive isn’t about turning designers into backend engineers overnight.
It’s about making niche behaviors possible without bloating the core product. You implement the specific effect you need; nobody else pays for it.
It lets designers orchestrate the final experience instead of throwing specs over the wall. Scripts produce reusable, parameterized building blocks that slot into the same workflows they already know. It helps developers feel at home with real code, real types, and real control over integration, while still working in a tool built for motion and UI. And it provides a gentle on-ramp: your “hello world” can be a real interactive object wired to artboards and data.
And yes, AI will help here too.
Because Luau and Lua have a long history and a lot of public code, modern language models are already quite good at generating and explaining Luau snippets. That means designers can ask an assistant, “Give me a path effect that animates like X,” get something workable, and learn from it.
~
Choosing Luau is less about following Roblox or being contrarian and more about aligning language, tooling, and constraints with the kind of product we’re building: a place where drawing, motion, logic, and data belong to the same artifact, and creators can push all of it further without asking permission from their tech stack.
Authored by Rive CTO and co-founder Luigi Rosso
Any software tool that claims to help you build real interfaces eventually runs into the same wall: no matter how far you push visual abstractions — state machines, data bindings, parameterized components — there’s always one more edge case, one more “could we make this path emit lightning only when the car’s battery drops under 7%” that doesn’t fit cleanly into a finite menu of checkboxes.
At some point, you need a real programming layer.
We also knew two things:
A scripting layer without a serious graphics and animation engine is a toy. 1.
A scripting layer that takes over everything defeats the point of Rive.
We built the hard parts first: the Rive Renderer, the animation system, the State Machine, the file format, and the runtimes. Only when Rive could express full flows, not just isolated animations, did it make sense to give you a general-purpose language inside that universe.
This is the story of how we chose that language and why we landed on Luau.
What we actually needed
Dropping a generic language VM into Rive would have been easy.
Dropping the *right *language into a real-time, cross-platform, design-led tool was not.
Our requirements list looked roughly like this:
Embedded first. The language has to live inside the Rive Editor and every runtime: mobile, web, desktop, game engines, automotive, etc. 1.
Fast and tiny. We ship into performance-sensitive environments. The VM can’t be a multi-megabyte science experiment. It has to be closer to “rounding error in your build size.” 1.
Deterministic enough. We need predictable behavior, tight control over execution, and the ability to sandbox, profile, and kill misbehaving scripts without taking down the editor or host app. 1.
Gradual typing and strong tooling. Designers and developers should see errors before they hit a device. Static analysis, autocomplete, and structural understanding of code are non-negotiable. 1.
**Simple semantics. **The language should be learnable by designers, if they so choose to learn it. 1.
**Mature and maintainable. **We are already a design editor, graphics engine, animation engine, runtime suite, and now a code editor. We don’t have time to become a bespoke language research lab. 1.
**License and governance that won’t bite us later. **Permissive, open, actively maintained.
We explored WebAssembly-based approaches, classic Lua, JavaScript VMs, newer niche languages, and writing our own. Some were powerful, but huge. Some were elegant, but missing tooling. Some were promising, but immature. Some would have required us to effectively maintain a parallel universe of compilers and debug tools.
Why not WebAssembly?
WebAssembly (WASM) was tempting as an abstraction layer. However, to make it viable for Rive, we’d need to:
Layer a designer-friendly language on top.
Ship full tooling inside the Editor.
Provide tight sandboxing, debugging, and profiling across all platforms.
Keep pace with a fast-moving ecosystem
WASM’s linear memory model also complicates exposing rich C++ structures such as paths, transforms, and view models efficiently and safely. You either copy them (slow), pin them (dangerous), or build custom host APIs (brittle). Without incremental GC and mature debugging. We’d be fighting the VM more than using it.
Why not JavaScript?
The major engines are large; deterministic control is tricky; and out of the box you don’t get the kind of structured typing and editor-grade static analysis we need. There are projects that improve this, but none that fits the constraints we care about.
So we went back to a familiar friend.
Lua, upgraded
Lua kept reappearing in our notes. It’s tiny, battle-tested in games and embedded systems, and famously easy to integrate.
But it also shows its age: modern teams expect better tooling, static guarantees, and editors that understand code structurally.
Luau, Roblox’s fork of Lua, closes that gap.
It keeps Lua’s strengths (small VM, simple syntax, predictable performance) and adds the things production teams need: a gradual type system, a first-class type checker, and richer static analysis.
It stays small and embeddable, ships under a permissive MIT license, and is actively developed in the open.
When we integrated and stress-tested it, several pieces fell into place.
Protocols: the shape of scripts
Scripting in Rive starts before you write a line of code.
It starts with Protocols, structured categories of scripts that tell the Editor what you’re trying to make.
Rive currently ships with five — more to come:
Converter
Node
Layout
Test
PathEffect
Each protocol represents a different kind of script the Editor can generate: a converter that shapes data, a custom drawing function, a layout helper, a testing harness, a path effect you can attach to strokes, and so on.
Selecting a protocol generates a typed scaffold that defines the surface area you’re allowed to operate on. From there, you work with Rive-native concepts — paths, shapes, view models, artboards, state machines, timelines — but always through the lens of the protocol you picked. It keeps scripts specific and prevents “do anything anywhere” chaos.
Types: the connective tissue
This is where Luau’s type system stops being “nice to have” and becomes the backbone of the whole experience.
Rive generates Luau type definitions directly from its C++ engine APIs — paths, shapes, transforms, artboards, view models, and so on. The Editor uses those definitions to build a typed AST of your script in memory, then hands that to Luau’s type checker.
The result is a scripting environment that is:
Statically understood — protocol methods must be implemented; return values must match.
Structurally safe — you can only access fields and APIs that exist.
Toolable — autocomplete and warnings work because the Editor has real types.
Synchronized with the runtime — if a C++ API changes, the Luau types update automatically.
We don’t maintain our own parallel inference system. We simply give Luau the complete, engine-accurate model of Rive (generated from C++) and the type checker does the rest.
Protocols give scripts shape; Luau’s types give them integrity.
Tiny VM, big ambitions
Luau’s implementation is compact, on the order of a couple of hundred kilobytes once built and tuned for our use cases, while still providing a modern runtime and tooling surface. That footprint lets us keep Rive Runtimes lean, spin up multiple script contexts safely, and maintain predictable performance and memory characteristics.
This is the spirit of classic Lua, now with modern analysis layered on top.
First-class in the editor, identical in the runtimes
Another non-negotiable: scripts in Rive should behave the same in the Editor as they do in your app.
The Editor runs the same scripting engine as the runtimes. That gives us constant dogfooding, real-time feedback, and safer experimentation.
Because scripts are understood structurally, our upcoming profiling tools can tell you where your frame budget is going — whether it’s a heavy layout, an overcomplicated State Machine, or a script doing something heroic in the worst possible way.
Why not “bring your own language?”
We seriously considered “meta” solutions: build around WebAssembly, let people target whatever language and toolchain they like, and stay neutral.
However, that would mean:
Every Rive user who wants scripting has to become a language/runtime integrator.
Designers get a wall of configuration instead of a cursor and blinking caret.
We spend our time building a general-purpose VM platform instead of better creative tools.
Picking Luau is an opinionated choice for a tight, well-behaved runtime we can understand and, if needed, fork, as well as shipping a great built-in experience instead of a theoretical ecosystem.
Will someone be upset we didn’t pick their favorite language? Absolutely.
What matters is what this choice unlocks: safety, performance, ergonomics, longevity
What this means for you
Luau in Rive isn’t about turning designers into backend engineers overnight.
It’s about making niche behaviors possible without bloating the core product. You implement the specific effect you need; nobody else pays for it.
It lets designers orchestrate the final experience instead of throwing specs over the wall. Scripts produce reusable, parameterized building blocks that slot into the same workflows they already know. It helps developers feel at home with real code, real types, and real control over integration, while still working in a tool built for motion and UI. And it provides a gentle on-ramp: your “hello world” can be a real interactive object wired to artboards and data.
And yes, AI will help here too.
Because Luau and Lua have a long history and a lot of public code, modern language models are already quite good at generating and explaining Luau snippets. That means designers can ask an assistant, “Give me a path effect that animates like X,” get something workable, and learn from it.
~
Choosing Luau is less about following Roblox or being contrarian and more about aligning language, tooling, and constraints with the kind of product we’re building: a place where drawing, motion, logic, and data belong to the same artifact, and creators can push all of it further without asking permission from their tech stack.
Authored by Rive CTO and co-founder Luigi Rosso
Any software tool that claims to help you build real interfaces eventually runs into the same wall: no matter how far you push visual abstractions — state machines, data bindings, parameterized components — there’s always one more edge case, one more “could we make this path emit lightning only when the car’s battery drops under 7%” that doesn’t fit cleanly into a finite menu of checkboxes.
At some point, you need a real programming layer.
We also knew two things:
A scripting layer without a serious graphics and animation engine is a toy. 1.
A scripting layer that takes over everything defeats the point of Rive.
We built the hard parts first: the Rive Renderer, the animation system, the State Machine, the file format, and the runtimes. Only when Rive could express full flows, not just isolated animations, did it make sense to give you a general-purpose language inside that universe.
This is the story of how we chose that language and why we landed on Luau.
What we actually needed
Dropping a generic language VM into Rive would have been easy.
Dropping the *right *language into a real-time, cross-platform, design-led tool was not.
Our requirements list looked roughly like this:
Embedded first. The language has to live inside the Rive Editor and every runtime: mobile, web, desktop, game engines, automotive, etc. 1.
Fast and tiny. We ship into performance-sensitive environments. The VM can’t be a multi-megabyte science experiment. It has to be closer to “rounding error in your build size.” 1.
Deterministic enough. We need predictable behavior, tight control over execution, and the ability to sandbox, profile, and kill misbehaving scripts without taking down the editor or host app. 1.
Gradual typing and strong tooling. Designers and developers should see errors before they hit a device. Static analysis, autocomplete, and structural understanding of code are non-negotiable. 1.
**Simple semantics. **The language should be learnable by designers, if they so choose to learn it. 1.
**Mature and maintainable. **We are already a design editor, graphics engine, animation engine, runtime suite, and now a code editor. We don’t have time to become a bespoke language research lab. 1.
**License and governance that won’t bite us later. **Permissive, open, actively maintained.
We explored WebAssembly-based approaches, classic Lua, JavaScript VMs, newer niche languages, and writing our own. Some were powerful, but huge. Some were elegant, but missing tooling. Some were promising, but immature. Some would have required us to effectively maintain a parallel universe of compilers and debug tools.
Why not WebAssembly?
WebAssembly (WASM) was tempting as an abstraction layer. However, to make it viable for Rive, we’d need to:
Layer a designer-friendly language on top.
Ship full tooling inside the Editor.
Provide tight sandboxing, debugging, and profiling across all platforms.
Keep pace with a fast-moving ecosystem
WASM’s linear memory model also complicates exposing rich C++ structures such as paths, transforms, and view models efficiently and safely. You either copy them (slow), pin them (dangerous), or build custom host APIs (brittle). Without incremental GC and mature debugging. We’d be fighting the VM more than using it.
Why not JavaScript?
The major engines are large; deterministic control is tricky; and out of the box you don’t get the kind of structured typing and editor-grade static analysis we need. There are projects that improve this, but none that fits the constraints we care about.
So we went back to a familiar friend.
Lua, upgraded
Lua kept reappearing in our notes. It’s tiny, battle-tested in games and embedded systems, and famously easy to integrate.
But it also shows its age: modern teams expect better tooling, static guarantees, and editors that understand code structurally.
Luau, Roblox’s fork of Lua, closes that gap.
It keeps Lua’s strengths (small VM, simple syntax, predictable performance) and adds the things production teams need: a gradual type system, a first-class type checker, and richer static analysis.
It stays small and embeddable, ships under a permissive MIT license, and is actively developed in the open.
When we integrated and stress-tested it, several pieces fell into place.
Protocols: the shape of scripts
Scripting in Rive starts before you write a line of code.
It starts with Protocols, structured categories of scripts that tell the Editor what you’re trying to make.
Rive currently ships with five — more to come:
Converter
Node
Layout
Test
PathEffect
Each protocol represents a different kind of script the Editor can generate: a converter that shapes data, a custom drawing function, a layout helper, a testing harness, a path effect you can attach to strokes, and so on.
Selecting a protocol generates a typed scaffold that defines the surface area you’re allowed to operate on. From there, you work with Rive-native concepts — paths, shapes, view models, artboards, state machines, timelines — but always through the lens of the protocol you picked. It keeps scripts specific and prevents “do anything anywhere” chaos.
Types: the connective tissue
This is where Luau’s type system stops being “nice to have” and becomes the backbone of the whole experience.
Rive generates Luau type definitions directly from its C++ engine APIs — paths, shapes, transforms, artboards, view models, and so on. The Editor uses those definitions to build a typed AST of your script in memory, then hands that to Luau’s type checker.
The result is a scripting environment that is:
Statically understood — protocol methods must be implemented; return values must match.
Structurally safe — you can only access fields and APIs that exist.
Toolable — autocomplete and warnings work because the Editor has real types.
Synchronized with the runtime — if a C++ API changes, the Luau types update automatically.
We don’t maintain our own parallel inference system. We simply give Luau the complete, engine-accurate model of Rive (generated from C++) and the type checker does the rest.
Protocols give scripts shape; Luau’s types give them integrity.
Tiny VM, big ambitions
Luau’s implementation is compact, on the order of a couple of hundred kilobytes once built and tuned for our use cases, while still providing a modern runtime and tooling surface. That footprint lets us keep Rive Runtimes lean, spin up multiple script contexts safely, and maintain predictable performance and memory characteristics.
This is the spirit of classic Lua, now with modern analysis layered on top.
First-class in the editor, identical in the runtimes
Another non-negotiable: scripts in Rive should behave the same in the Editor as they do in your app.
The Editor runs the same scripting engine as the runtimes. That gives us constant dogfooding, real-time feedback, and safer experimentation.
Because scripts are understood structurally, our upcoming profiling tools can tell you where your frame budget is going — whether it’s a heavy layout, an overcomplicated State Machine, or a script doing something heroic in the worst possible way.
Why not “bring your own language?”
We seriously considered “meta” solutions: build around WebAssembly, let people target whatever language and toolchain they like, and stay neutral.
However, that would mean:
Every Rive user who wants scripting has to become a language/runtime integrator.
Designers get a wall of configuration instead of a cursor and blinking caret.
We spend our time building a general-purpose VM platform instead of better creative tools.
Picking Luau is an opinionated choice for a tight, well-behaved runtime we can understand and, if needed, fork, as well as shipping a great built-in experience instead of a theoretical ecosystem.
Will someone be upset we didn’t pick their favorite language? Absolutely.
What matters is what this choice unlocks: safety, performance, ergonomics, longevity
What this means for you
Luau in Rive isn’t about turning designers into backend engineers overnight.
It’s about making niche behaviors possible without bloating the core product. You implement the specific effect you need; nobody else pays for it.
It lets designers orchestrate the final experience instead of throwing specs over the wall. Scripts produce reusable, parameterized building blocks that slot into the same workflows they already know. It helps developers feel at home with real code, real types, and real control over integration, while still working in a tool built for motion and UI. And it provides a gentle on-ramp: your “hello world” can be a real interactive object wired to artboards and data.
And yes, AI will help here too.
Because Luau and Lua have a long history and a lot of public code, modern language models are already quite good at generating and explaining Luau snippets. That means designers can ask an assistant, “Give me a path effect that animates like X,” get something workable, and learn from it.
~
Choosing Luau is less about following Roblox or being contrarian and more about aligning language, tooling, and constraints with the kind of product we’re building: a place where drawing, motion, logic, and data belong to the same artifact, and creators can push all of it further without asking permission from their tech stack.