FAQ

Answers to common questions about Thorm.

Thorm FAQ

What is Thorm?

Thorm is a way to build real web interfaces using PHP, where your PHP code describes UI, state, events, and effects—and the browser runs it as a reactive app.

Why would I use Thorm instead of “just rendering HTML in PHP”?

Because most modern UIs need:

  • reactive state (live updates without full reloads),
  • event handling (clicks, forms, keyboard),
  • async actions (fetch, submit, navigate),
  • reusable components.

Thorm gives you those as part of one coherent model, instead of stitching together templates + ad-hoc JS.

Is Thorm “a framework”?

Think of it as an UI platform:

  • a PHP authoring layer (developer-friendly),
  • a runtime execution layer (the “engine”),
  • a stable interface between them that keeps things predictable and extensible.

It can be used inside a framework, or it can act as the UI layer of your project.

Does Thorm replace JavaScript?

It replaces the need to hand-write most UI JavaScript for typical app behavior.

But JavaScript still exists:

  • the browser runtime is JavaScript,
  • you may still integrate JS libraries when it’s worth it,
  • advanced “capabilities” can bridge to custom JS.

The point is: JS becomes an implementation detail, not the default workflow.

I heard Thorm uses an “IR.” Isn’t that extra overhead?

In practice, Thorm is not “PHP → HTML strings → hope for the best.”

Thorm produces a structured UI program, and the runtime executes it efficiently. That structure is what enables:

  • precise updates (change only what changed),
  • predictable behavior,
  • strong tooling (inspection, validation, debugging),
  • portability to other render targets later.

If someone says “that’s overhead,” a good response is:

“Compared to what? The alternative is an implicit model hidden across templates + JS. Thorm makes the model explicit and optimizable.”

Is Thorm “compiled”?

It’s best described as compiled-like:

  • you author in PHP,
  • Thorm produces a structured output,
  • a runtime executes it.

It’s closer to “bytecode + VM” than “native machine code,” but the mental model is very similar.

Will Thorm be faster than React/Vue/etc.?

Thorm’s goal is efficient, predictable updates, not hype.

Real speed depends on:

  • how much DOM you touch,
  • how often state changes,
  • how big your UI tree is,
  • how the app is structured.

What Thorm can do well is reduce unnecessary work by having a clean, structured execution model. Benchmarks should be earned, not claimed.

Is Thorm good for SEO?

Yes, if you lean into server-rendered pages (SSR) and progressively enhance. That’s also a very natural fit for PHP.

Even if you use rich interactivity, you can still serve meaningful HTML first, then hydrate/enhance.

Is Thorm a SPA framework?

It can be a SPA, but it hasn't been battle test it yet.

Thorm is compatible with:

  • traditional server routing + SSR pages,
  • hybrid apps (SSR + interactive islands),
  • Basic SPA (crude SPA navigation, early hydration).

The point is: you choose the mode, based on your product.

Is Thorm secure? What about “eval” concerns?

Thorm is designed so that userland code stays data-driven and “safe-by-default.”

The risky area in any UI runtime is “run arbitrary code in the browser.” A strong Thorm stance is:

  • prefer declarative actions/effects,
  • keep extensions behind explicit “capabilities,”
  • make powerful hooks opt-in and auditable.

Security is not a single feature—it’s an architecture choice. Thorm’s structured model makes it easier to enforce safe boundaries than string-based or ad-hoc approaches.

Can I still use third-party JS libraries?

Yes—ideally in a controlled way:

  • “capabilities” that wrap a library behind a clean PHP API,
  • components that integrate libraries without leaking spaghetti into the app.

The goal is: centralize integration, don’t scatter random JS across your project.

What’s the learning curve for PHP developers?

If you already write PHP, the main new concepts are:

  • reactive state (state changes drive UI),
  • components and composition,
  • effects/actions (events, timers, async flows),
  • thinking in “UI updates” rather than “render once.”

Most people should find it easier than learning a full JS framework stack, because the authoring language stays PHP.

What’s the biggest “mindshift” when adopting Thorm?

You stop thinking “template output” and start thinking:

  • “UI is a living program”
  • “state changes cause precise updates”
  • “events trigger actions”

It’s not harder—it’s just a more modern model.

Is Thorm production-ready?

A healthy way to position Thorm now is:

  • great for experiments, internal tools, prototypes, and early products,
  • production readiness increases as:
  • API stabilizes,
  • docs and examples grow,
  • testing and debugging tools mature,
  • edge cases get hammered.

If you’re in early adoption, you’re buying into a vision and helping shape it.

What will early adopters struggle with?

Common early pains for any new platform:

  • incomplete docs and missing examples,
  • fewer “recipes” than established frameworks,
  • occasional rough edges in tooling and error messages,
  • limited ecosystem (plugins/components) at first.

The win is: you get a simpler stack and can help define the “right patterns” early.

How does debugging work?

The best long-term story for Thorm debugging is:

  • inspect the rendered UI tree and bindings,
  • see why a node updated,
  • see which state changed,
  • trace event → action → effect chain.

A structured model makes this much more approachable than debugging “string output + scattered JS.”

What about accessibility (a11y)?

Not yet, for Thorm to become a net positive for a11y it needs to:

  • encourages semantic elements and ARIA best practices,
  • avoids common focus-trap mistakes,
  • includes accessible components by default.

The key is: treat accessibility as a first-class feature.

Can I migrate gradually?

That’s the ideal adoption story:

  • start with one page, one widget, or one area (admin panel, dashboard, docs UI),
  • keep the rest of the app conventional PHP,
  • expand as you gain confidence.

Thorm fits into existing PHP projects, it is not going to demand a rewrite.

What makes Thorm “different” in one sentence?

Thorm lets PHP developers build modern reactive UIs by authoring a structured UI program that the browser runtime executes—without living in JavaScript framework land.

On this page