Thorm Roadmap

Overview

Thorm is a PHP-first UI framework built around a shared intermediate representation for UI, state, and behavior. The current platform supports three rendering modes from the same authoring model:

• CSR for browser-rendered applications
• SSR for server-rendered output with hydration
• hybrid rendering for client islands inside server-rendered pages

The roadmap now centers less on proving feasibility and more on product hardening: release packaging, verification, documentation, API discipline, and operational trust.

Current Platform Status

Core Capabilities Available Today

• PHP DSL for authoring nodes, expressions, state, actions, effects, routing, and components
• browser runtime with mount and hydrate flows
• routing, navigation, HTTP actions, effects, and component composition
• unified rendering model supporting CSR, SSR, and hybrid delivery
• example coverage across reactive UI, forms, routing, effects, and rendering modes

Current Maturity Assessment

• Developer Preview
• suitable for evaluation, prototyping, internal tooling, and framework validation
• not yet positioned as a stable public framework release

The remaining work is concentrated in consistency, verification, packaging, and documentation quality rather than in missing core concepts.

Strategic Priorities

1. Release Readiness

Primary objective:

• establish a coherent public release story for installation, examples, runtime assets, templates, and versioning

Key outcomes:

• consistent package identity
• documented installation and upgrade path
• reliable example generation workflow
• clear distinction between supported public APIs and internal implementation details

2. Verification and Stability

Primary objective:

• move from example-driven confidence to repeatable regression coverage

Key outcomes:

• automated coverage for the PHP DSL and IR generation
• runtime regression checks for interactive flows
• SSR and hydration verification across representative node types and rendering modes
• baseline CI for build, examples, and documentation-critical flows

3. API Consolidation

Primary objective:

• reduce legacy surface area and present a cleaner public framework model

Key outcomes:

• unified rendering API across rendering modes
• removal or deprecation of redundant renderer entry points
• documented rendering mode selection
• clearer public conventions for templates, output, and runtime bootstrapping

4. Documentation Quality

Primary objective:

• make Thorm understandable as a product, not only as a codebase

Key outcomes:

• concise getting-started path
• clearer rendering-mode documentation
• stronger API reference consistency
• production-oriented guidance for routing, forms, components, effects, and deployment

5. Security and Trust

Primary objective:

• align framework behavior, documentation, and release messaging around explicit safety boundaries

Key outcomes:

• documented security model for html() and dynamic attributes
• clearer expectations around HTTP actions and state mutation
• better validation of IR and runtime inputs
• release messaging that matches actual guarantees

Delivery Phases

Phase 1: Public Alpha

Objective:

• publish Thorm as a serious early-stage framework for evaluation and experimentation

Exit criteria:

• package metadata and branding are consistent
• examples are reproducible through one documented workflow
• unified rendering flow is reflected in examples and docs
• installation and runtime asset handling are documented clearly
• alpha scope and experimental areas are stated explicitly

Expected message:

• Thorm supports CSR, SSR, and hybrid rendering today
• the core authoring model is usable
• stability, compatibility, and verification are still in progress

Phase 2: Public Beta

Objective:

• make Thorm credible for sustained internal adoption and serious pilot use

Exit criteria:

• automated regression coverage exists for major primitives and runtime flows
• SSR and hydration behavior are regression-tested across representative scenarios
• public APIs are intentionally documented and scoped
• packaging and upgrade expectations are stable
• core documentation covers the primary development workflow end to end

Expected message:

• stable core development model
• documented limitations
• predictable beta-line upgrades

Phase 3: Version 1.0

Objective:

• establish Thorm as a stable framework release

Exit criteria:

• compatibility policy is defined
• SemVer discipline is in place
• rendering mode behavior is documented and supported intentionally
• browser support policy is explicit
• deployment, security, and performance expectations are documented
• SSR and hydration are treated as supported platform capabilities rather than experimental features

Execution Tracks

Track A: Product Surface

Focus:

• release packaging, naming, templates, runtime delivery, and installation

Near-term scope:

• finalize package identity in composer.json
• align runtime asset loading with the documented project layout
• standardize example output and template conventions
• simplify the public getting-started workflow

Track B: Verification

Focus:

• automated confidence across DSL, runtime, and rendering modes

Near-term scope:

• add smoke coverage for IR generation
• add browser checks for representative interactive examples
• add SSR and hydration checks for core node behaviors
• add CI for examples and release-facing paths

Track C: API and Rendering

Focus:

• renderer consolidation and public API clarity

Near-term scope:

• complete migration to the unified render surface
• retire or deprecate legacy renderer entry points
• document CSR, SSR, and hybrid usage with one consistent model
• tighten template and output conventions

Track D: Documentation and Adoption

Focus:

• framework comprehension, onboarding, and reference quality

Near-term scope:

• rewrite release-facing documentation around actual workflows
• expand reference pages for routing, effects, components, and forms
• align examples with documentation terminology
• improve roadmap, status, and release notes presentation

Track E: Security and Platform Trust

Focus:

• explicit boundaries for safe and unsafe behavior

Near-term scope:

• document escape hatches and unsafe APIs clearly
• improve runtime and IR validation
• align security documentation with actual renderer/runtime behavior
• define the minimum trust model required for broader adoption

Near-Term Milestones

Milestone A: Alpha Candidate

• unified rendering examples complete
• release-facing docs cleaned up
• package identity finalized
• coherent example generation path documented
• known limitations published

Milestone B: Beta Candidate

• regression harness in place
• browser interaction coverage for key examples
• documented public API surface
• SSR and hydration validation established

Milestone C: 1.0 Candidate

• compatibility policy published
• deployment and browser support documented
• stable rendering-mode guidance finalized
• core docs complete across authoring, runtime, and delivery

Scope Guidance

For the next release cycle, the priority is not feature expansion. The priority is operational maturity around what already exists.

Highest-priority work:

• release packaging
• verification
• renderer/API consolidation
• documentation quality
• security posture clarity

Lower-priority work:

• advanced tooling
• broader plugin ambitions
• additional host-language targets
• performance positioning beyond measured evidence

Summary

Thorm has reached the point where CSR, SSR, and hybrid rendering are all functioning within one framework model. The roadmap therefore shifts from architectural exploration to release discipline.

The next major outcome is a credible public alpha, followed by a beta focused on stability and regression safety, and then a 1.0 release built on explicit compatibility, documentation, and platform trust.