go-app is a Go framework for building progressive web applications entirely in Go via WebAssembly. The core package pkg/app implements a declarative component model (Composer/Compo) with lifecycle hooks, client-side routing, state management with observers and persistence, server-side pre-rendering, and a full PWA HTTP handler that serves the app shell, service worker, manifest, and static resources. The docs/ directory is itself a production go-app PWA that dogfoods the framework; docs/src contains the documentation site source code, and docs/web/documents contains the markdown content rendered at runtime by the wasm binary. Architecturally, the repository is a layered Go library rather than a monolith or microservice. pkg/app contains the runtime engine (engine.go, node.go, state.go, http.go) and uses build tags to separate server-side resource/HTTP handling from client-side wasm UI execution. pkg/cli is a struct-tag-driven CLI and environment configuration loader, pkg/cache provides reusable LRU and expiring cache implementations, pkg/errors adds typed and tagged error wrapping, and pkg/logs and pkg/analytics provide optional support utilities. Code generation in pkg/app/gen/html.go produces the strongly typed HTML element API and its generated tests. The primary data flow begins with Go component state and user events, which are dispatched through the engine and Context API to update the DOM via the node manager. State mutations can be persisted to localStorage, encrypted, and broadcast across browser tabs. On the server side, the Handler serves pre-rendered HTML, resolves static resources (local dirs, remote buckets, GitHub Pages), and caches proxied resources. External dependencies include Go modules for webpush, markdown parsing, UUID, and testing, plus browser APIs and Go's wasm_exec.js glue. There are no data pipelines, notebooks, or research artifacts; this is a pure application/framework repository.
Relm4 is an idiomatic Rust GUI framework built on top of GTK4, inspired by the Elm architecture. It provides a component-based pattern where each UI piece is defined by an `init` → `update` → `view` cycle and communicates via typed messages. The framework includes a declarative macro system (`view!`, `#[component]`, `menu!`) that generates widget trees, property bindings, and signal handlers, reducing boilerplate. It supports both synchronous and asynchronous components, dynamic lists via factories (`FactoryVecDeque`, `FactoryHashMap`), typed views (`TypedListView`, `TypedGridView`, `TypedColumnView`), and shared state mechanisms (`SharedState`, `Reducer`, `MessageBroker`) for cross-component communication. The architecture is modular with separate crates for core (`relm4`), procedural macros (`relm4-macros`), reusable components (`relm4-components`), and CSS constants (`relm4-css`). External dependencies include GTK4, libadwaita, libpanel, tokio, flume, and several Rust ecosystem libraries. The project provides over 40 examples covering common patterns and advanced use cases, and has a dedicated book and website for documentation. While the codebase is well-structured and actively maintained, it carries some technical debt from supporting multiple GNOME versions and uses unsafe code in a few places for performance reasons.
This repository demonstrates the implementation of the A2UI (Agent-to-UI) protocol for building AI-powered mobile applications. It provides a complete example consisting of: 1) A Python A2A agent server (stock_lookup) that uses Google ADK to process user queries and generate structured UI responses, 2) A Flutter client (GenUIDemo) that connects to the agent via A2A protocol, parses A2UI messages, and renders them as native Flutter UI, and 3) Supporting documentation explaining the A2UI protocol, MCP integration, and AI-assisted engineering practices. The core innovation is the separation of concerns where AI agents generate declarative UI JSON that clients render natively, enabling rich interactions without executing arbitrary code. The repository includes reusable base classes for building A2UI agents that handle schema validation, event processing, and response formatting.
tui-realm is a Rust library/framework for building terminal user interfaces (TUIs) using a component-based, event-driven architecture. It is not a standalone application but a reusable framework that wraps ratatui (formerly tui-rs) and provides an Application loop, Component/AppComponent traits, a Model/Update/View pattern, and a subscription system for routing events between components. The monorepo is organized as a Cargo workspace containing the core `tuirealm` crate, a `tuirealm_derive` procedural macro crate, a standard library of reusable components (`tui-realm-stdlib`: Input, Label, List, Table, etc.), and optional integration crates `tui-realm-textarea` and `tui-realm-treeview`. The framework is designed to reduce boilerplate by centralizing focus management, event routing, and state handling in the Application/View layer, while allowing developers to define custom components and event sources via Ports and Subscriptions.
FastUI is a Python/TypeScript framework for building web UIs declaratively from Python code, using React as the frontend renderer. The backend defines the entire UI as a list of Pydantic-validated component models, which are sent to the frontend via a REST API. The frontend (React) receives these component definitions and renders them using Bootstrap or custom components. The architecture enforces a strict separation of concerns: the backend describes the interface, the frontend implements the rendering. The project includes a Python package (fastui) with component models, form generation, authentication helpers, and a dev server; three npm packages (@pydantic/fastui, @pydantic/fastui-bootstrap, @pydantic/fastui-prebuilt) for the React frontend; and a demo application. The code is well-structured, fully typed, and includes comprehensive tests. However, the project has been officially declared inactive (see issue #368), so no further development is expected. The codebase remains functional and is a good example of declarative UI patterns, but reuse should account for the lack of ongoing maintenance.