HumbleUI: Clojure desktop interfaces without Electron

HumbleUI targets JVM desktop applications without a browser runtime

HumbleUI addresses a specific mismatch: Clojure developers often work comfortably in a REPL-driven, declarative environment, but common desktop UI routes force them into JavaScript, Electron, or another language. The framework is intended for desktop applications written in Clojure, with access to the JVM and native code. The README explicitly excludes Electron and JavaScript, so HumbleUI is not a web-view wrapper or a ClojureScript UI library that happens to have a desktop target.

The intended users are developers who value Clojure's interactive development model and need desktop behaviors such as windows, file-system integration, notifications, and operating-system integration. The README says HumbleUI aims to retain the convenience of developing across platforms without insisting that every interface look native. That choice is important. A HumbleUI application can accept platform differences in controls and OS behavior instead of trying to imitate each native desktop style exactly.

The project also targets applications that benefit from Clojure's direct JVM access. Its motivation describes multithreading and interaction with the full computer as advantages, while the REPL is presented as a fast feedback loop. These are design goals rather than measured performance results. No benchmark, startup-time figure, memory profile, or comparison table is provided, so claims about responsiveness should be checked rather than inferred from the use of Clojure.

Skija rendering and JWM integration define HumbleUI's architecture

The documented architecture has two named foundations. Skija supplies GPU-accelerated graphics, while JWM, the Java Window Manager, supplies the common layer for operating-system integration. HumbleUI therefore separates interface drawing from the desktop windowing concerns. The README says the framework exposes both high-level and low-level APIs, allowing developers to use declarative components for ordinary interface structure and step into lower-level operations for unusual cases.

The examples show a component-oriented API. A component such as `app` returns nested UI forms using `ui/center` and `ui/label`. The application starts by passing a window reference to `ui/start-app!`. That data flow is visible in the example itself: define a Clojure component, create a window around it, and start the desktop application.

HumbleUI's stated stack uses JVM and native code, with Skia-based rendering and JWM for window integration, which is distinct from the web-oriented approach represented by Electron. It is also different from Flutter, whose README comparison is indirect: Flutter is cited as proof that a non-browser UI stack can support declarative cross-platform interfaces, but HumbleUI's documented implementation is a Clojure API backed by Skija and JWM, not Flutter's widget renderer.

The low-level API is attractive for specialized desktop work, but it also broadens the surface that an application may need to understand. The README does not document a complete widget inventory, layout contract, event model, accessibility layer, packaging process, or debugging interface.

The available first-use path is a source-tree demo, not a documented installation

The README does not provide installation instructions, a dependency snippet from `deps.edn`, a packaged application workflow, or commands for creating a distributable desktop executable. It says the project is a work in progress and that there are no docs. Consequently, this review does not present an invented install command or assume a released version. A reader must inspect the repository's `deps.edn` and source tree to determine how a new application is assembled.

The README does provide a development shortcut for starting the repository's REPL server. From the repository root, the documented command is:

./script/repl.py

This is intended for working with the project source rather than installing HumbleUI as a finished library. The README then says to reload the demo application using `clj-reload` by evaluating:

(user/reload)

After the REPL workflow is available, the smallest example in the README defines a component containing a centered label:

(require '[io.github.humbleui.ui :as ui])

(ui/defcomp app []
  [ui/center
   [ui/label "Hello, world"]])

The example starts that component in a window through the following call:

(defn -main [& args]
  (ui/start-app!
    (ui/window #'app)))

The README shows the shape of the API, but it does not say where this snippet belongs in a new project or how to launch the complete `-main` function. That missing boundary matters for a first real application.

HumbleUI's changing status is the central adoption limitation

The repository is not archived, and the last push was on 2026-06-17, but the README explicitly labels HumbleUI a work in progress and says everything changes every day. The repository has no GitHub releases. Those facts make upgrade planning harder than the project name alone suggests. A team cannot use the README to determine a stable API baseline, release cadence, migration notes, compatibility matrix, or supported operating-system versions.

The lack of documentation also shifts evaluation work toward source inspection. The repository contains `src`, `test`, `docs`, `dev`, and `deploy` directories, but the README does not identify a supported application template or explain how those directories relate to a consumer project. It also does not document rollback, release artifacts, native dependency installation, or packaging. Those omissions are not proof that the capabilities are absent. They are reasons for a prospective adopter to verify them in the repository before committing to the project.

HumbleUI is consequently a better fit for exploratory development and applications whose authors are prepared to work close to changing APIs than for teams that need a stable support boundary. The Apache-2.0 license provides the stated licensing framework, but license terms do not remove compatibility, maintenance, or migration risk. No legal interpretation of the license is made here.

Clojure's REPL model is useful, but native packaging remains unverified

Electron is the clearest comparison point for teams interested in web technologies, while HumbleUI explicitly excludes Electron and JavaScript from its stated stack. The trade-off is direct. Electron may fit teams with JavaScript and web-platform skills, while HumbleUI fits teams that want to write desktop UI logic in Clojure and accept an immature, native-dependent stack.

The README cites Flutter as evidence that a new UI stack is feasible. HumbleUI instead builds on Skija for drawing and JWM for OS integration, so the adoption decision is not simply between two declarative syntaxes. It also depends on whether the JVM and native components fit the deployment model, whether the team can debug platform-specific behavior, and whether the current API is sufficient for the required controls.

The repository's sample-app links show examples, including Wordle and several exploratory projects, but the README does not describe their support status, maintenance, or feature coverage. They should be treated as references for exploration rather than a substitute for production documentation.

HumbleUI adoption depends on source-level verification and platform testing

For Clojure developers investigating a native desktop stack, HumbleUI offers a clear architectural bet: Skija for graphics, JWM for desktop integration, and a declarative Clojure API that can expose lower-level controls when needed. The absence of Electron and JavaScript may be the central requirement for some applications, while the REPL-oriented workflow may appeal to teams accustomed to Clojure development.

It is not the safer choice for an application that requires documented releases, predictable migrations, or a clear path from prototype to packaged desktop software. The README itself says that there are no docs and that everything changes every day. The repository has no GitHub releases, so the practical first step is to inspect `deps.edn`, `src`, and the development scripts, then run `./script/repl.py` and confirm that the demo can reload. The final judgement is specific: HumbleUI is an experimental Clojure desktop framework with an explicit no-Electron architecture, not a documented release-ready platform.

Editorial conclusion

HumbleUI fits developers who already build in Clojure and want to investigate a JVM-based desktop stack with direct graphics and window-management access. It is a poor fit for teams requiring stable documentation, predictable upgrade procedures, or a mature release process right now. Before adoption, inspect the current public API in `src`, run the demo workflow with `./script/repl.py`, and verify that the required native Skija and JWM components work on every target operating system.

Frequently asked questions

Official sources

1. HumbleUI/HumbleUI on GitHub
2. Issues
3. License: Apache-2.0
4. README