Overview
Most of TeamHUD’s UI is overlay widgets — a draggable hub button that opens a panel. There are two ways to build one; pick by what your widget needs.
Two authoring paths
Section titled “Two authoring paths”- Custom widget — a drop-a-folder UI (
index.html+widget.json). No build step, hot-reloaded, and locked down by default: it gets a limited set of capabilities declared in its manifest (and can run a restricted Node.js backend), but it can’t extend TeamHUD’s internals or reach native code. Best for standalone panels, tools, and dashboards. - Plugin — a TypeScript package (
BasePlugin) that provides a widget and runs in-app with full trust. A widget is one of the things a plugin can add; reach for a plugin when your widget needs to extend TeamHUD’s internals rather than run in the locked-down tier.
| Custom widget | Plugin | |
|---|---|---|
| You write | index.html + widget.json | a TypeScript package (BasePlugin) |
| Build step | none (hot-reloaded) | tsc / bundle build |
| Backend | optional, Node.js w/ limited access to TeamHUD internals | full Node, in-process |
| Capabilities | limited, granted per manifest — locked down by default | full trust; extends TeamHUD internals |
| Start here | Build your first custom widget | Build your first plugin |
Rule of thumb: start with a custom widget — it’s minutes to a running panel and locked down by default. Build a plugin when the widget needs to extend TeamHUD’s internals or run with full trust.
- Quickstart — see a widget on screen in five minutes.