[
https://issues.apache.org/jira/browse/CAMEL-24202?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18097731#comment-18097731
]
Omar Atie commented on CAMEL-24202:
-----------------------------------
h2. Research Summary — CAMEL-24202: camel-tui in the browser via WebAssembly
h3. Context
This ticket asks whether camel-tui could run in a web browser via WebAssembly,
inspired by [Hardwood dive-web|https://hardwood.dev/experiments/dive-web/] — a
browser-based TUI for exploring Parquet files locally (drag-and-drop, no
server, data stays on the client).
Important precedent: Hardwood {{dive}} is built on TamboUI — the same terminal
UI framework camel-tui uses. Camel TUI depends on TamboUI 0.4.0
({{{}tamboui-tui{}}}, {{{}tamboui-jline3-backend{}}}, widgets, CSS, markdown,
image). Hardwood proved the pattern: compile a Java TamboUI app to WASM and
host it as a static web page.
----
h3. What camel-tui does today
{{camel tui}} ({{{}CamelMonitor{}}}) is a live monitoring dashboard for running
Camel integrations. It is not a standalone route editor — it connects to real
processes.
||Capability||How it works||
|Discovery|Scans {{~/.camel/*-status.json}} and local PIDs via
{{ProcessHandle}}|
|Live data|Polls status JSON, trace files, error logs, OTel spans from disk|
|Diagrams|Renders route topology via {{camel-diagram}} from live status JSON|
|Actions|Launches {{{}camel run{}}}, {{{}camel infra{}}}, Docker/Podman via
{{ProcessBuilder}}|
|HTTP probing|Calls {{localhost}} endpoints on running integrations|
|AI / MCP|Embedded MCP server on {{localhost:8123}} for agent control|
The plugin is large (~150+ Java source files) and deeply tied to OS APIs:
process management, filesystem, signals ({{{}sun.misc.Signal{}}}), Docker, and
localhost networking.
----
h3. Feasibility matrix
h4. Feasible in browser WASM (similar to dive-web)
These features analyze static input and do not need a running Camel JVM:
* Route file exploration — upload/drop a {{{}.camel.yaml{}}}, {{{}.java{}}},
or exported route JSON
* Topology / diagram rendering — {{{}DiagramSupport{}}},
{{{}RouteDiagramHelper{}}}, {{TopologyAsciiRenderer}} work from parsed route
definitions
* Route tree preview — processor structure via {{RouteTreePreview}} /
{{camel-diagram}}
* Component catalog hints — metadata from {{camel-catalog}} (component names,
options)
* Documentation / help overlays — markdown viewer, built-in help screens
* Snapshot replay — load exported {{{}*-status.json{}}}, trace files, or demo
tapes for offline inspection
* UI itself — TamboUI rendering (tabs, tables, popups, themes) if a web
backend exists
h4. Not feasible in pure browser WASM
These require a local OS/runtime and cannot run inside a sandboxed browser tab
alone:
* Live monitoring of locally running integrations (no {{{}ProcessHandle{}}},
no {{~/.camel/}} scan)
* Starting/stopping/restarting integrations or routes
* Docker/Podman infra management
* Real-time log tailing from local files
* {{{}camel cmd send{}}}, HTTP calls to {{localhost}} (CORS + no local network)
* MCP server and AI agent integration against live processes
* Running a full Camel integration inside WASM (entire Camel runtime is far
too heavy)
Conclusion (aligned with Claus’s original note): A browser WASM build cannot
replace the full live monitor, but it can deliver a valuable offline
exploration / analysis mode — the same split Hardwood made between CLI {{dive}}
(full terminal) and {{dive-web}} (browser, file upload only).
----
h3. Recommended solution — phased approach
h4. Phase 0 — Spike / validation (this ticket)
# Confirm how Hardwood built dive-web (likely TeaVM {{WEBASSEMBLY_GC}} + a
TamboUI web/canvas backend).
# Check TamboUI upstream for a web backend — current docs list JLine 3,
Panama, and Aesh only; Devoxx 2026 slides mention “SSH & Web” as roadmap, not
yet released.
# Build a minimal “Hello TamboUI in browser” prototype to validate:
** WASM GC + exception handling (Chrome/Edge/Firefox/Arc; Safari not yet
supported — same constraint as dive-web)
** Bundle size with {{camel-diagram}} + JSON parsing
** File upload via JS interop (drag-and-drop {{{}.camel.yaml{}}})
h4. Phase 1 — {{camel-tui explore}} (browser, static mode)
A static site (e.g. {{camel.apache.org/experiments/tui-web/}} or similar) where
users:
# Drop a route file ({{{}.camel.yaml{}}}) or status export JSON
# See diagram topology, route tree, component info
# Browse exported traces/errors if provided
# No Camel runtime, no server, data stays client-side
Reuse from existing code:
* {{{}DiagramSupport{}}}, {{{}RouteTreePreview{}}}, {{StatusParser}}
(read-only parsing)
* {{{}camel-diagram{}}}, {{camel-catalog}}
* TUI chrome: tabs, help overlay, theme CSS
Extract / isolate:
* New module e.g. {{camel-jbang-plugin-tui-web}} with zero dependencies on
{{{}ProcessHandle{}}}, {{{}ProcessBuilder{}}}, Docker, MCP, {{sun.misc.Signal}}
h4. Phase 2 — Hybrid live mode (optional, separate ticket)
Browser UI + local bridge agent:
Browser (WASM UI) ←→ local camel-tui MCP/REST bridge ←→ running integrations
Same pattern as Kaoto, Chrome DevTools, or VS Code remote: rich web UI, thin
local agent for OS access. Enables live monitoring without compiling Camel into
WASM.
h4. Phase 3 — Not recommended
Compiling/running full Camel integrations in WASM — impractical due to
dependency size, networking, threading, and component ecosystem.
----
h3. Technical dependencies and blockers
||Blocker||Impact||Mitigation||
|No TamboUI web backend in Maven Central yet|Cannot render TUI in browser
without terminal|Coordinate with TamboUI project; Hardwood may have a
private/experimental backend|
|TeaVM WASM GC browser support|Safari unsupported; needs recent
Chrome/Firefox/Edge|Document browser requirements (same as dive-web)|
|Large dependency tree|Slow load, big WASM binary|Strict module split; only
pull diagram + catalog + parsing|
|OS-coupled code throughout plugin|Won’t compile under TeaVM|Extract
analysis-only subset behind interfaces|
|Live features need localhost|CORS blocks browser → localhost|Phase 2 bridge
agent, not pure WASM|
----
!image-2026-07-20-19-54-00-724.png!
----
h3. Suggested next steps
# Contact Hardwood / TamboUI maintainers — learn how dive-web was built and
whether a web backend can be contributed upstream.
# Create a spike branch — TeaVM + minimal TamboUI screen + file upload.
# Identify the “analysis-only” API surface — list classes safe to extract
without OS dependencies.
# Split follow-up tickets:
** CAMEL-24202a: TamboUI web backend (upstream or Camel contrib)
** CAMEL-24202b: Static route explorer WASM app
** CAMEL-24202c: Local bridge for live monitoring (optional)
----
h3. Bottom line
||Question||Answer||
|Can camel-tui run fully in the browser like the terminal version?|No — live
monitoring needs OS/process access|
|Can something _like_ dive-web be built for Camel routes?|Yes — same TamboUI +
TeaVM pattern, static analysis of uploaded files|
|Is it worth doing?|Yes — route exploration, education, demos, and sharing
topology without installing Camel|
|What should this ticket deliver?|Research spike + prototype scope definition,
not full implementation|
> camel-tui - Run in web browser via web assembly
> -----------------------------------------------
>
> Key: CAMEL-24202
> URL: https://issues.apache.org/jira/browse/CAMEL-24202
> Project: Camel
> Issue Type: New Feature
> Components: camel-jbang
> Reporter: Claus Ibsen
> Priority: Major
> Attachments: image-2026-07-20-19-54-00-724.png
>
>
> [https://hardwood.dev/experiments/dive-web/]
> Research if something like this could eventually be possible for camel tui -
> it may not able to run the camel app - but it may be able to do other stuff.
> Analyze the code / help with transformation / or whatever.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
