widget-js/widgets: a React desktop widget hub for Windows

What Widget Hub solves, and who it is actually for

Windows has never had a first-party widget story that developers could extend with ordinary web code. Widget Hub fills that gap: it is a desktop runtime that hosts widgets, and the widgets are React applications built with the same toolchain as a web front end. The topics list on the repository names the intended catalogue: clock, countdown, todo, reminder, water-reminder, clipboard-history, and AI-flavoured entries such as chatgpt and deepseek. That is a consumer desktop utility set, not an enterprise dashboard platform.

The audience is narrower than the topic list suggests. You need Windows, because the description says the project is desktop widgets for Windows and no other platform appears in the README. You need Node.js if you intend to build or generate widgets. And you need to accept that the repository you clone is the hub application itself, not a library you import into your own product. The package.json name is @widget-js/react-app and it is marked private, which is a clear signal about how the maintainers expect it to be consumed.

If you are a React developer who wants a small always-on desktop surface for a personal tool, the fit is direct. If you are looking for a cross-platform widget framework, this is the wrong repository, and the rest of this review explains why.

How the hub, the core packages and the MCP server fit together

The architecture visible in the repository is a Vite application with three layers. At the bottom sit the published packages @widget-js/core, @widget-js/react and @widget-js/web-api, which the app depends on. In the middle is the hub application itself: a React 19 and TypeScript front end built with Vite, styled with Tailwind CSS 4, routed with react-router-dom, and internationalised with i18next and react-i18next. On top are the widgets, each one a React component that the runtime mounts.

The AI path adds a fourth moving part. According to the README, the WidgetHub Desktop Client exposes an MCP server at http://127.0.0.1:3606/mcp using the streamableHttp transport. An AI coding tool connects to that endpoint, a skill installed from the widget-js/skills repository teaches the tool how widgets are structured, and the tool then writes a widget in response to a prompt. The data flow is local: the desktop client runs on your machine, the MCP endpoint is on the loopback address, and the coding tool is whatever you already use.

That design has a consequence worth naming. The MCP server is only reachable while the desktop client is running, so the AI workflow is not a headless build step you can put in CI. It is an interactive authoring loop, and the hub is the thing that keeps the loop alive.

Installing the client and generating a first widget with the MCP server

The README lays out the AI generation path in four steps. First install the prerequisites: an AI coding tool such as Claude Code, Trae or Codex, Node.js, and the WidgetHub Desktop Client from the releases page of the repository. The README does not give a package manager command for the desktop client, so the release artefacts are the documented route.

Second, install the skill that teaches your coding tool how widgets are written. The README gives this command:

npx skills@latest add widget-js/skills

Third, point your coding tool at the local MCP endpoint. The README provides this configuration block verbatim:

{
  "mcpServers": {
    "widgetjs": {
      "transport": "streamableHttp",
      "url": "http://127.0.0.1:3606/mcp"
    }
  }
}

After saving that, the coding tool should list a server named widgetjs. If it does not, the desktop client is probably not running, since the URL is a loopback address served by that client.

Fourth, invoke the skill and describe the widget. The README's example prompt is:

/widget Generate a stock widget, 4 by 4 in size, where users can select stock codes and the widget displays real-time prices and price changes.

The expected result is a generated widget project that the hub can load. The README shows a stock widget screenshot immediately after this prompt, and links to a full guide at widgetjs.cn/guide for anything beyond the four steps.

For working on the hub itself rather than generating widgets, the repository is a standard Vite project. The package.json scripts are dev, build, preview, lint and lint:fix, with build defined as tsc -b && vite build. The README does not document a separate widget-authoring CLI, so that distinction matters: the npm scripts build the hub, while the MCP path produces widgets.

The Windows-only boundary and other limits the README does not address

The single largest constraint is platform. The repository description says desktop widgets for Windows, the README's install step points at a desktop client release, and nothing in the README mentions macOS, Linux, iOS or Android. The related searches around iPhone, Android and CarPlay widgets describe a different subject entirely and have nothing to do with this project. If your team is mixed-platform, the Windows users get widgets and everyone else gets nothing.

A second limit is the licence. The repository metadata does not state one, and the README does not mention licensing at all. For a private desktop utility that may be acceptable. For anything you ship inside a company, an unstated licence is a blocker until someone checks the repository for a licence file, because the default position under copyright is that no rights are granted.

A third limit is the authoring model. The AI path depends on a running desktop client and a loopback MCP endpoint, and the README does not document what happens when the generated widget fails, how to roll one back, or how to pin a widget to a known-good version. The release cadence is fast (26.8.26, 26.8.31 and 26.9.3 all landed within about a week of each other in the published release list), which is good for fixes and less good if you need stability guarantees. The README does not describe a compatibility policy between hub versions and widget versions, even though the app depends on @widget-js/core, @widget-js/react and a beta-tagged @widget-js/web-api.

How this differs from Electron-based desktop widget tools

The obvious alternative category is a general Electron or Tauri shell where you write your own window and your own rendering. The difference in approach is real. With a bare Electron app you control the window, the packaging, the auto-update channel and the installer, and you pay for all of it. Widget Hub inverts that: the runtime, the window management, the widget catalogue and the desktop client are provided, and you supply React components that fit its model. You give up control over packaging and the release channel in exchange for not building them.

A second alternative is the operating system's own widget surface. Windows ships widgets of its own, and if your need is a weather tile or a news feed, the built-in surface costs nothing to adopt. Widget Hub's advantage there is extensibility: you can write a clipboard-history or water-reminder widget that the built-in surface will never offer. Its disadvantage is that you are depending on a third-party runtime with a fast release cadence and no stated licence.

A third alternative, for the AI generation angle specifically, is to skip the hub and have your coding tool scaffold a standalone React app. That works, and it removes the desktop client dependency, but you then own the desktop integration that the hub was providing. The MCP server is the part of this project that is hardest to replace, not the React rendering.

Maintenance cost, release cadence and licence exposure

The repository is not archived and the last push was on 2026-09-08, which is recent. Releases are frequent: the published list shows 26.8.26, 26.8.31 and 26.9.3, and the version scheme is date-based, so a 26.9.x release belongs to September 2026. For a widget author this cuts both ways. Bugs get fixed quickly, and the runtime you target can also move under you between two widget releases.

The dependency list is a maintenance signal in itself. The app pulls React 19, Tailwind CSS 4, framer-motion, gsap, radix-ui, i18next, Supabase client libraries and a beta-tagged @widget-js/web-api. That is a broad surface to keep current, and the private package name means the hub is not published for others to depend on. If you fork it, you inherit the upgrade work for all of it.

On licensing, there is nothing to analyse because the README does not state a licence. The practical step is to look for a LICENSE file in the repository root before you build anything on top of it. The top-level entries listed for this repository do not include one, which makes the question more pressing, not less.

Editorial conclusion

Adopt Widget Hub if you are on Windows, comfortable with Node.js and React, and want to write or generate widgets that live on the desktop rather than in a browser tab. Do not adopt it if you need macOS, Linux, or mobile widgets, or if you want a stable published API surface: the repository is a Vite app with a private package name and no documented versioning policy for widget authors. Before committing, verify three things in the repository itself: that the WidgetHub Desktop Client release for your Windows build installs, that the MCP server answers on http://127.0.0.1:3606/mcp after you configure it, and that the licence file matches what your organisation requires, because the repository metadata does not state one.

Frequently asked questions

Official sources

1. Issues
2. Project website
3. README
4. Releases
5. widget-js/widgets on GitHub