Deprecate isInteractive and hasDOM from the renderer and boot options (some big cleanup internal in ember-source)

[NullVoxPopuli]

I'm proposing these be removed in v8

Appendix

• Vite SSR Docs:
  • https://vite.dev/guide/ssr
• Example SSG without fastboot/prember:
  • https://limber.glimdown.com/docs/embedding/
• PR removing these features:
  • Drop isInteractive and hasDOM from the renderer -- declaring we only support "browser-like" environments with the current renderer ember.js#21348
• Example modernization of infrequently maintained repo:
  • https://github.com/ember-cli/ember-page-title/commits/master/?since=2026-03-01&until=2026-05-01

Propose <GH PR Title> />

Rendered

Summary

This pull request is proposing a new RFC.

To succeed, it will need to pass into the Exploring Stage, followed by the Accepted Stage.

A Proposed or Exploring RFC may also move to the Closed Stage if it is withdrawn by the author or if it is rejected by the Ember team. This requires an "FCP to Close" period.

An FCP is required before merging this PR to advance to Accepted.

Upon merging this PR, automation will open a draft PR for this RFC to move to the Ready for Released Stage.

Exploring Stage Description

This stage is entered when the Ember team believes the concept described in the RFC should be pursued, but the RFC may still need some more work, discussion, answers to open questions, and/or a champion before it can move to the next stage.

An RFC is moved into Exploring with consensus of the relevant teams. The relevant team expects to spend time helping to refine the proposal. The RFC remains a PR and will have an Exploring label applied.

An Exploring RFC that is successfully completed can move to Accepted with an FCP is required as in the existing process. It may also be moved to Closed with an FCP.

Accepted Stage Description

To move into the "accepted stage" the RFC must have complete prose and have successfully passed through an "FCP to Accept" period in which the community has weighed in and consensus has been achieved on the direction. The relevant teams believe that the proposal is well-specified and ready for implementation. The RFC has a champion within one of the relevant teams.

If there are unanswered questions, we have outlined them and expect that they will be answered before Ready for Release.

When the RFC is accepted, the PR will be merged, and automation will open a new PR to move the RFC to the Ready for Release stage. That PR should be used to track implementation progress and gain consensus to move to the next stage.

Checklist to move to Exploring

• The team believes the concepts described in the RFC should be pursued.
• The label S-Proposed is removed from the PR and the label S-Exploring is added.
• The Ember team is willing to work on the proposal to get it to Accepted

Checklist to move to Accepted

• This PR has had the Final Comment Period label has been added to start the FCP
• The RFC is announced in #news-and-announcements in the Ember Discord.
• The RFC has complete prose, is well-specified and ready for implementation.
  • All sections of the RFC are filled out.
  • Any unanswered questions are outlined and expected to be answered before Ready for Release.
  • "How we teach this?" is sufficiently filled out.
• The RFC has a champion within one of the relevant teams.
• The RFC has consensus after the FCP period.

[alexkahndev]

Strong agreement on the underlying stance and worth saying that we've watched four other frameworks land in the same place from different angles, which is some signal that the principle is sound.

Quick tour through what AbsoluteJS sees across our existing adapters:

React's SSR is string-based (renderToReadableStream). The "is this SSR?" question is bounded to a single boundary in the user's mental model: effects don't run on the server. Render code is identical on both sides. Users essentially never write if (typeof window !== 'undefined') for anything outside an effect and even there, the convention is to put it inside useEffect/useLayoutEffect which only fires client-side. The split is in when things run, not what code runs.

Vue lands almost the same way string-based via renderToWebStream, lifecycle hooks like onMounted are client-only by contract. Vue's small improvement on the React shape is onServerPrefetch, an additive primitive ("do this on the server") rather than a defensive check ("am I on the server?"). Better posture against the virus problem because it inverts the polarity. Svelte moves the boundary to compile time entirely. The Svelte compiler emits components twice, once as a string-concatenating function (SSR), once as DOM-mutating code (client). User-written .svelte files are identical for both; the compiler picks the
codegen. From a user's perspective, "am I in SSR or browser?" basically doesn't exist there's nothing to ask. The cost is the build pipeline knows about both modes; the user doesn't.

Svelte moves the boundary to compile time entirely. The Svelte compiler emits each component twice once as a string-concatenating function (SSR mode), once as DOM-mutating code (client mode). User-written .svelte files are identical for both; the
compiler picks the codegen. From a user's perspective, "am I in SSR or browser?" basically doesn't exist there's nothing to ask.

Angular is the one that maps closest to where this RFC takes Ember.
@angular/platform-server wraps Domino internally, so when user code does inject(DOCUMENT) or reads el.nativeElement it gets a real Document / Element instance regardless of side. There is no isFastBoot / isInteractive flag visible to component authors. Angular's user code is server-agnostic because the platform owns the simulated DOM, not the user.

The common thread every framework that successfully kept the "this is SSR" virus out of library code did it by eliminating the runtime question, not by exposing a flag for it. React/Vue split it on lifecycle phases. Svelte splits it at compile time. Angular pretends the DOM is always there. None of them ask user code or addon code "are you
running on the server?" at runtime, and none of them have the FastBoot-style ecosystem fragmentation.

Ember post-RFC ends up on Angular's branch of that tree happy-dom (or any DOM) installs Element/Node/Document, the renderer always assumes interactive mode, and user/addon code stops needing to ask. From outside Ember, that looks like the framework finally adopting the same architectural answer the rest of the ecosystem converged on years ago just by removing the affordance to ask the question, rather than by adding a new abstraction layer.

The empirical evidence across React, Vue, Svelte, and Angular is consistent: the runtime "am I in SSR?" question is the source of the virus. Removing the question by whichever mechanism a framework can is what stops the spread. That seems like a strong technical case for the direction even outside the specifics of isInteractive / hasDOM.