LCUI puts a CSS engine and a React layer on top of hand-written C widgets

A C library that treats the browser stylesheet as its layout model

Most C GUI toolkits hand you a widget tree, a callback per event, and hardcoded geometry. LCUI takes a different route: style moves out of the code and into a stylesheet that a selector engine resolves against the component tree. That decision is visible in the repository layout rather than in prose. `lib/css` is a CSS parser and selector engine sitting beside `lib/ui`, which does style computation and drawing, and `lib/ui-xml`, which builds components from XML. The split matters because it means a designer and a C programmer can work on the same application without sharing a header file.

The cost of that split is that you now own two languages' worth of tooling to debug. A layout bug can come from the C draw code in `lib/ui` or from a selector that matched the wrong node in `lib/css`, and the failure looks the same on screen. Components are fully custom-drawn, so appearance does not vary with the host platform's widget theme, which is a genuine advantage for consistency and a genuine loss if you expected native title bars and system fonts for free.

The stack under the widgets: PandaGL, ptk, thread and worker

LCUI does not sit on a native toolkit. Under `lib/ui` sits PandaGL, the project's own graphics library, handling font management, text layout, image processing and rendering. Below that, `lib/ptk` supplies the platform layer: message loops, window management, timers, worker threads and input methods behind one API. `lib/thread` and `lib/worker` add cross-platform threading and a simpler worker wrapper on top.

Read this as the project's real risk surface. Every one of those layers is written by the same project rather than delegated to a system widget set, so a rendering or input bug lands inside this repository rather than in a platform library someone else maintains. Two consequences follow. Cross-platform consistency improves, because the same drawing code runs everywhere. And platform-specific edge cases, IME composition, for instance, have exactly one implementation to fix.

TypeScript and JSX compile down to C, not to a runtime

The `lcui` command-line tool is the sharpest part of the design. You write UI configuration in TypeScript, use JSX syntax, and the tool preprocesses the app directory and generates C source code plus resource files. Nothing from TypeScript survives into the shipped binary; the output is C that a normal C toolchain compiles. That is a different bargain from an embedded JavaScript engine, where a scripting language becomes a permanent part of your attack surface and your memory budget.

The generator sits on the critical path, though. If `lcui build` mis-handles your data binding or event binding, the defect is already baked into generated C before you compile anything, and you are reading compiler output rather than a runtime stack trace. The router is file-system based: pages are directories and the directory path is the route, so there is no route table to keep in sync by hand.

Getting to a first window needs Git, XMake and Node.js before any C toolchain

The install path is not a single library download. Git fetches the example source, XMake builds it, and Node.js runs the command-line tool. With those three present, two commands produce a project skeleton:

npm install -g @lcui/cli
lcui create my-lcui-app

The prompts after `lcui create` walk you through the rest. From there the loop is the same on every change: edit the TypeScript UI files, then run the build step again so the C sources and resources are regenerated.

lcui build

Stylesheets can be written as Tailwind CSS, CSS Modules, Sass or global CSS, so the styling choice does not lock you into one authoring style. Icons come from Microsoft's fluentui-system-icons with partial customization for LCUI, which is a practical shortcut for anyone who does not want to draw an icon set.

The 2.x to 3.x gap is the adoption decision, not the feature list

The repository is not archived and the last push landed on 2026-10-19. Tag history runs the other way: v2.2.0 shipped on 2021-06-01, the next tag is v3.0.0-alpha.0 from 2025-01-10, and `package.json` still reads that alpha version, so the public API could have moved across a four-year gap with no stable tag recording it.

Pin your dependency exactly, because a minor bump inside 3.x may cross a generator change. And check whether the CSS parser and selector engine in `lib/css` behave the same in the 2.x API and the 3.x one before committing to a design that leans on selectors.

Where the design breaks: one platform pair, one rendering path, one author

The README states cross-platform support for Windows and Linux. macOS is absent from that list. For a team with any Apple hardware in its development loop, that is a stop-and-ask item rather than a minor gap.

Second, the ptk library supplies the cross-platform system APIs, so it is where platform work concentrates.

Third, custom-drawn components buy you platform-independent appearance at the cost of native behaviour.

Where Microui and GuiLite differ in approach

Microui takes the opposite route from the CSS engine: it is an immediate-mode GUI with no retained widget tree, no stylesheet and no separate build step. You draw every frame and keep no scene graph, which means less machinery and no codegen, at the cost of per-frame redraw and manual state.

Neither alternative compiles TypeScript into C.

Choose LCUI when layout belongs in a stylesheet and component structure belongs in files. Choose Microui when you want one header and no toolchain. The real difference is not rendering quality but how much of your interface lives in data and how much lives in code.

Editorial conclusion

Adopt LCUI if you are writing a desktop tool in C and want CSS, a filesystem router and React-style components without shipping a scripting runtime. Do not adopt it if you need a stable API surface to pin against, or if your target platform is macOS, which the README does not list among the supported systems. Before anything else, run `lcui build` on a scratch project and read the C it generates: the entire development path depends on that step, and a generator that mis-handles your data binding shows up as compiler output rather than a runtime error.

Frequently asked questions

Official sources

1. lc-soft/LCUI on GitHub
2. License: MIT
3. Project website
4. README
5. Releases