What is GEA · Overview

One TypeScript codebase, compiled to native binaries — from microcontrollers to macOS

GEA compiles one codebase — TypeScript, JSX and real CSS — ahead of time to native code for each target: MCU, embedded Linux, macOS and iOS. No invented language, no interpreter on the device, no per-platform rewrite.

The GEA stack · overview
A GEA energy-analytics dashboard running on macOS
Energy analytics · macOS. Written once, compiled native for the target it runs on.

A connected product gets built two or three times over

A product that spans an MCU, a Linux device and a phone is, in practice, three products — three toolchains, two or three languages, and a UI that rarely behaves the same across them.

The web settled the interface years ago: components, state, reactivity. That model stops at the browser. Cross into native code and the work starts over.

A GEA smart-home dashboard running on iOS
Home · iOS. The same component model the web made familiar, running as a native app.

One model, compiled native on every surface

GEA takes that model — the components and stores the web made familiar — and compiles it to native code on each target, from a microcontroller to a Mac. No DSL in between, no interpreter on the device. One codebase reaches every surface without giving up the native binary.

Code in, native binaries out

geatsc is a compiler, not a bundler. Components, stores and host calls are lowered to native code per target — C++ on the MCU, native bindings on Apple, object code on embedded Linux.

App.ts geatsc MCU C++ firmware.bin Linux object code .o / .so iOS UIKit .ipa macOS AppKit .app
One source, four targets. App.ts compiles through geatsc to a native binary for each platform.

The UI is real CSS — flexbox, keyframes, 3D transforms and more — rendered natively on the device, never in a browser.

No interpreter on the device. The binary is the app.

The principles GEA holds itself to

Six commitments that guide every design decision. Each is checkable: a feature that violates one does not ship.

01
One model everywhere
Components and stores behave the same on an MCU as on a Mac. Patterns, lifecycles and reactivity do not change with the target.
02
Compile, don't interpret
geatsc emits native code for every target. Nothing on the device carries an interpreter, a JIT or a script engine.
03
No new language
You write TypeScript, JSX and real CSS — the languages of the web, not a proprietary DSL.
04
An honest matrix
A target enters the matrix only after CI builds and tests it. If it is listed, it works today, on a tagged release.
05
Small by default
A hello-world ships with near-zero overhead on every target. You pay only for the features you use.
06
Targets are first-class
Every example, doc and host API is indexed by target. The toolchain is built around the matrix.

GEA, next to the usual suspects

How GEA compares to the incumbents — the honest trade-offs, and the path off them.

  • GEA vs Slint — the closest peer: MCU to mobile, but you write a .slint DSL on a Rust host.
  • GEA vs Qt — broad and genuinely native, but it's C++/QML and the licensing weighs on you.
  • GEA vs LVGL — the embedded-display standard, but it's C and it stops at the MCU.
  • Full comparison & Why GEA — every incumbent, the honest trade-offs, and the path off them.

The stack, in three parts

The compiler, the layout engine and the canvas API each get a full write-up — how they work, and what they cost.

The compiler The layout engine The canvas API