TSXLight / docsProject documentation

Explanation

Motivation

Understand the design decisions, alternatives, and limits.

TSXLight asks what a React-like programming model looks like if the server owns the component tree. The browser receives a rendered shell and a small callback bridge, while component instances, state, page transitions, and callbacks remain on the server.

The system defines a distinct rendering boundary from browser-owned React: state can live server-side, callbacks can be represented in generated markup, and separate users can interact with the same application code without sharing renderer state.

The motivation is easiest to understand by contrast. In React, the browser owns component instances and event handlers are client-side closures. In TSXLight, the browser is closer to a terminal: it displays generated markup and reports events, while the server decides which component object receives the event and what the next view should be. That inversion is unusual, but it makes identity, callback serialization, and per-user state isolation the central design problems.

  • Primary goal: render TSX-style component trees outside the React runtime.
  • Target surfaces: web and Electron shells.
  • Demo target: a callback-driven placeholder messenger application.