Introducing Gea Stack.

I built an ahead-of-time compiler that turns TSX components and a healthy subset of CSS into native firmware through generated C++. There is no JavaScript VM or CSS interpreter running on the target device.

This demo renders a spinning 3D cube at roughly 60 FPS on a Waveshare ESP32-S3 board with a 410×502 AMOLED display.

Here is a breakdown of the compiler pipeline, rendering pipeline, and the hardware bottlenecks I ran into.

1. Build-Time CSS Compilation

Instead of shipping a CSS parser, our build tool compiles CSS selectors and rules directly into statically typed, pre-allocated C++ structures.

For example, this rule:

.cube-app {
  background-image: linear-gradient(135deg, #12130f 0%, #171b14 45%, #251a15 100%);
}

Is parsed at build-time and mapped directly to fields inside a ComputedStyle struct (which occupies roughly 320 bytes of memory on RGB565 targets):

style_color_t bg_gradient_from_color;  // Packed to the native pixel (RGB565 on most targets)
style_color_t bg_gradient_mid_color;
style_color_t bg_gradient_to_color;
uint16_t bg_gradient_mid_stop;         // 450 (45% stored as permille)
uint16_t bg_gradient_to_stop;          // 1000 (100%)
int16_t  bg_gradient_angle;            // 1350 (135.0 deg stored in tenths of a degree)

(style_color_t is a compile-time alias — uint16_t/RGB565 on standard embedded targets, uint32_t/RGBA8888 on GEA_PIXEL_RGBA8888 targets.)

At runtime, changing a style property like opacity is just a single uint8_t memory write. There are zero string-based lookups or per-property heap allocations in the hot path.

2. The Core Layout and Render Pipeline

To replicate web layout ergonomics on-device, I wrote a lightweight style and layout engine in ~6,000 lines of C++:

• Flexbox & Grid: A custom ~1,300-line engine handling standard features (grow, shrink, wrap, gap, justify-content) alongside a basic grid layout up to 8 tracks.
• Dirty Regions: The engine tracks up to 32 coalesced dirty rectangles to avoid repainting unchanged pixels.
• Reproject Path: For transform-only animation frames (like rotating a 3D cube), running a full layout and paint pass is too slow. If the display list commands are verified as re-projectable, the engine bypasses layout. It transforms the corner points through the updated 3D matrix and depth-sorts them in ~2.7 ms.

3. The Real Bottleneck: Memory Bandwidth

Initially, I assumed the 240 MHz CPU would struggle with the 3D matrix math and pixel alpha blending. I wrote SIMD-optimized blending loops and lookup tables, but they yielded almost zero performance gains over standard scalar loops.

The actual constraint is memory bus contention. A single 410×502 framebuffer at 16-bit color is 411 KB, which is too large to fit in internal SRAM alongside the OS and app memory. The framebuffers live in external PSRAM.

The CPU, cache, and the DMA engine (which streams pixels to the screen over an 80 MHz quad-SPI link at a hardware limit of ~40 MB/s) all compete for the same external bus. Because the hardware is heavily memory-bound, minimizing byte movement was the only way to hit acceptable frame rates.

4. Frame Budget Breakdown (~42 FPS with translucent cube faces)

Here is the exact rendering loop timing on the ESP32-S3 for a single frame of the 3D cube:

• Replay (Rasterizing translucent cube faces): ~13 ms
• Flush (DMA transfer over QSPI to panel): ~6 ms
• Reproject (Transform geometry-only path): ~2.7 ms
• Layout, dirty region tracking, overhead: ~2 ms
• Total Frame Time: ~24 ms (~42 FPS)

Hard Limitations

This is not a full browser engine, and I had to enforce strict structural constraints to keep the footprint low:

• No :hover states (I target touch screens where it's irrelevant).
• The UI tree is limited to a maximum of 512 nodes.
• Fonts are rasterized into grayscale coverage atlases at build-time (there is no runtime TTF parser).

I am working on a follow-up about how Gea handles TypeScript reactive state updates and state-store changes without a garbage collector. If you have questions about the layout compiler or the rendering pipeline, let me know in the comments.

I call this project Gea Stack, and the homepage is at https://geastack.com (admittedly heavily under construction).

Fun trivia: Gea Stack is an extension of Gea (https://geajs.com). After building a modern, no non-sense, performant UI framework, I thought it would be great if the same codebase could run on any device. After 3 months, here we are.

Finally, geatsc can compile Node.js applications to native binaries, too. I built additional libraries for targeting iOS and macOS applications in both JSX and importing and using native Apple UIKit/AppKit (and other native) classes in a TypeScript project.

Over the next couple of days I will be releasing more videos on different uses and examples of Gea, and in July I will be fully open sourcing the compiler and the targets/operating systems around it under our GitHub organization at https://github.com/geastack.

Looking forward to your comments!