Overview

Why GEA

Web and app developers know interfaces but can't reach the hardware without learning C and board SDKs, and embedded engineers who already ship device GUIs are stuck hand-building every widget in C, or locked into a proprietary GUI builder. The web solved this years ago: components, reactive state, CSS, a fast iteration loop. That solution just never reached the device. GEA takes it there.

The same GEA dashboard running on an ESP32 board, a watch, a phone, a tablet and a laptop
The promise

A better workflow, at native speed

GEA improves how you build for a device without costing you performance. The usual ways to make device development nicer slow the device down. GEA doesn't.

Developer experience

Build it the way you build for the web

You write the UI in TypeScript, JSX and CSS, and state lives in reactive stores. You iterate against a browser preview that runs the same engine as the device, so you see changes without reflashing. The code stays yours, in your repo, with no proprietary editor in the loop.

Native speed

As fast as hand-written native code, often faster

On GEA's own benchmark, the compiled TypeScript matches or beats hand-written C++ on 15 of 17 workloads. That is why an embedded engineer can move to the nicer workflow without paying a speed penalty for it.

The case

Why we built it

Good device interfaces are too hard to build
Two kinds of people could make device UIs good, and the tools fail both of them. An embedded engineer can already get pixels on a panel, but every widget, layout and style struct is hand-written in C, which is slow to author and miserable to change. A web or app developer is fluent in interfaces but is locked out of the hardware behind C, board SDKs and drivers. Both are stuck, and most small products ship a worse interface than they could.
Performance comes first
On hardware this small, speed decides whether an interface is usable at all. The fast path today is hand-written C, and most device GUIs run on it because anything heavier struggles on the chip. Performance can't be the thing you trade away for a nicer way to work; it has to come first. GEA starts from native speed, and improves the developer experience on top of that speed, so you get both at once.
Visual builders don't fit the age of agents
The other escape from hand-writing C is a visual builder: you drag widgets in a proprietary editor and ship the C it generates. That was a fair trade before agents could write code. The work an agent is best at is real code, like TypeScript and CSS, not a closed editor that emits C and locks you to one vendor's chips. With GEA the UI is ordinary TypeScript and CSS that you and your agents write and own.
One product shouldn't mean several codebases
Build the same product for a microcontroller, a Linux panel, a Mac and a phone and you usually end up maintaining a separate codebase, and often a separate team, for each one. That per-target rewrite is a tax you pay forever, and it is another reason devices ship worse interfaces than they could. With GEA one source tree compiles to microcontrollers, embedded Linux, macOS and iOS.
What you get

Why you should use GEA

Coming from the web

Use the skills you already have

You write TypeScript, JSX and CSS. That is all you need to put a real UI on a device.

  • It's not just the languages: the whole web model comes with you — components, reactive state, CSS layout, the dev loop you already know. No C or C++, no board SDK, no new DSL.
  • One codebase runs on the device and in the browser simulator, so you build and preview the way you already do.
  • You reach microcontrollers today, and embedded Linux, macOS and iOS, without becoming a firmware engineer first.
  • Because a widget is just code, you can package it, open-source it, and install someone else's the way you already do on the web. That kind of sharing and reuse is something embedded UIs have never really had.
Embedded GUI engineer

Keep your native output, change how you author it

You already ship native GUIs in C with LVGL or Qt. GEA keeps that native output and the small footprint, and changes the layer where you author it.

  • Write reactive TypeScript and CSS instead of hand-managing widgets and style structs.
  • Hold state in stores and let the UI update itself, instead of wiring every widget and invalidation by hand.
  • Get CSS layout, animations and a Canvas 2D API.
  • Move the same design from one board to another without board-specific changes. A different screen, resolution or pinout normally means editing the firmware; with GEA you point the build at another board and flash the same UI to it.
  • The browser preview runs the same engine as the device, so you iterate in the browser and stop reflashing just to see a change.
Head to head

How it compares

Honest comparisons against the closest tools, with the trade-offs named.

Comparison
GEA vs Slint
Slint is the closest thing to GEA out there, though you write its .slint DSL against a Rust or C++ host.
Comparison
GEA vs Qt
Qt is broad and genuinely native, but you write QML and C++, and the microcontroller story is commercial-only.
Comparison
GEA vs LVGL
LVGL is the standard for embedded displays, written in C with widgets you create and mutate by hand.