From d8c88e0568b08cfbbc24310e9cda7a825f238310 Mon Sep 17 00:00:00 2001
From: NullVoxPopuli <199018+NullVoxPopuli@users.noreply.github.com>
Date: Thu, 14 Aug 2025 12:37:06 -0400
Subject: [PATCH 1/5] Introduce Template-only Class Components

---
 text/0000-template-only-class-component.md | 259 +++++++++++++++++++++
 1 file changed, 259 insertions(+)
 create mode 100644 text/0000-template-only-class-component.md

diff --git a/text/0000-template-only-class-component.md b/text/0000-template-only-class-component.md
new file mode 100644
index 0000000000..58f4e7545c
--- /dev/null
+++ b/text/0000-template-only-class-component.md
@@ -0,0 +1,259 @@
+---
+stage: accepted
+start-date: 2025-08-14T00:00:00.000Z
+release-date: # In format YYYY-MM-DDT00:00:00.000Z
+release-versions:
+teams:
+  - framework
+  - typescript
+prs:
+  accepted: # Fill this in with the URL for the Proposal RFC PR
+project-link:
+suite: 
+---
+
+# Template-Only Class Components
+
+## Summary
+
+Add a new `TemplateOnly` base class to `@glimmer/component` that enables template-only components to be defined as classes, allowing them to support TypeScript generics for better type safety.
+
+## Motivation
+
+Currently, template-only components in Ember are defined using `const` declarations like this:
+
+```typescript
+export const Demo = <template>
+  {{@value}}
+</template>
+```
+
+However, this approach has a significant limitation: **it's not possible to specify generic type parameters** with `const` declarations in TypeScript. This prevents template-only components from having proper type safety when they need to work with generic data types.
+
+For example, consider a template-only component that should work with different types of values:
+
+```typescript
+import type { TOC } from '@ember/component/template-only';
+
+// This doesn't work - can't add generics to const declarations
+export const Demo<Value>: TOC<{ // ❌ Syntax error
+  Args: {
+    value: Value
+  }
+}> = <template>  
+  {{@value}}
+</template>
+```
+
+This limitation forces developers to either:
+1. Give up type safety and use `any` or `unknown` for component arguments
+2. Create unnecessary `@glimmer/component` Component classes to add TypeScript generics -- [these are slower][^template-only-faster]
+3. Create multiple duplicate components for different types
+
+Class-based components don't have the syntax limitation:
+
+```glimmer-ts
+interface ComponentSignature<Value> {
+  Args: {
+    value: Value;
+  };
+}
+
+class Demo<Value> extends Component<ComponentSignature<Value>> {
+  <template>
+    {{@value}}
+  </template>
+}
+```
+
+Creating a full component class when you only need a template feels like overkill and goes against the principle of template-only components [being lightweight][^template-only-faster].
+
+[^template-only-faster]: template-only components are 7 to 26% faster than the `Component` from `@glimmer/component` -- https://nullvoxpopuli.com/2023-12-20-template-only-vs-class-components
+
+## Detailed design
+
+### New `TemplateOnly` Export
+
+This RFC proposes adding a new `TemplateOnly` export to `@glimmer/component` that can be used as a base class for template-only components:
+
+```glimmer-ts
+import { TemplateOnly } from '@glimmer/component';
+
+class Demo<Value> extends TemplateOnly<{
+  Args: {
+    value: Value;
+  };
+}> {
+  <template>
+    {{@value}}
+  </template>
+}
+
+export default Demo;
+```
+
+At runtime, this is _functionally_ the same as the `const` template-only components today.
+In that the `TemplateOnly` class we re-export from `@glimmer/component` would be associated with a light-weight component manager, as template-only components are today.
+
+There is no `this`, so there will need to be a lint that forbids use of `this` in `TemplateOnly` classes.
+
+### Compilation
+
+Classes have a feature similar to functions, which is useful for defining more than one in the same file: hoisting.
+
+If we compiled to the `const` representation that we have today, we'd have a disagreement between editor expectations and runtime behavior.
+
+So compilation of these components should use `var` instead of `const`.
+
+Otherwise, all other aspects can be the same as existing compilation today:
+
+```glimmer-ts
+// Source
+class Demo<Value> extends TemplateOnly<{
+  Args: { value: Value };
+}> {
+  <template>
+    {{@value}}
+  </template>
+}
+
+// Compiled output (same as current template-only components)
+import { precompileTemplate } from '@ember/template-compilation';
+import { setComponentTemplate } from '@ember/component';
+import templateOnlyComponent from '@ember/component/template-only';
+
+export default setComponentTemplate(
+  precompileTemplate(`{{@value}}`, {
+    strictMode: true,
+    scope: () => ({}),
+  }),
+  templateOnlyComponent()
+);
+```
+
+Existing babel-based compnoent compilation occurs in [`babel-plugin-ember-template-compilation`](https://github.com/emberjs/babel-plugin-ember-template-compilation).
+But the `<template>` transforms occur in [`content-tag`](https://github.com/embroider-build/content-tag), and `content-tag`'s output would be:
+```typescript
+class Demo<Value> extends TemplateOnly<{
+  Args: { value: Value };
+}> {
+  static {
+    template(`{{@value}}`, { component: this, scope: () => ({}) })
+  }
+}
+```
+So `babel-plugin-ember-template-compilation` could optimze this to:
+```javascript
+var Demo = template(`{{@value}}`, { scope: () => ({}) });
+```
+
+However, because we also support compile-less environments, the `TemplateOnly` export would _work_ if it made it to the runtime.
+
+[Here is an example implementation of that fallback behavior in the Limber REPL]()
+
+### Usage Examples
+
+#### Simple Generic Component
+
+```typescript
+import { TemplateOnly } from '@glimmer/component';
+
+class ItemDisplay<T> extends TemplateOnly<{
+  Args: {
+    item: T;
+    displayProperty: keyof T;
+  };
+}> {
+  <template>
+    <div class="item">
+      {{get @item @displayProperty}}
+    </div>
+  </template>
+}
+```
+
+#### Component with Blocks
+
+```typescript
+import { TemplateOnly } from '@glimmer/component';
+
+class List<T> extends TemplateOnly<{
+  Args: {
+    items: T[];
+  };
+  Blocks: {
+    default: [item: T, index: number];
+    empty: [];
+  };
+}> {
+  <template>
+    {{#if @items.length}}
+      <ul>
+        {{#each @items as |item index|}}
+          <li>{{yield item index}}</li>
+        {{/each}}
+      </ul>
+    {{else}}
+      {{yield to="empty"}}
+    {{/if}}
+  </template>
+}
+```
+
+
+## How we teach this
+
+The feature introduces one new concept: **Template-Only Class Components**. These are components that use class syntax purely for TypeScript generic support while maintaining template-only semantics at runtime.
+
+> [!IMPORTANT]
+> More importantly though, our eslint plugin, should have a way to automatically flip between the component formats to reduce the amount of shuffling that developers have to do when they need to switch formats -- this may also make sense as a glint code-action.
+
+### Documentation Updates
+
+#### TypeScript Guide Updates
+
+The [TypeScript: Invokables](https://guides.emberjs.com/release/typescript/core-concepts/invokables/) guide should be updated to include:
+
+1. A new section explaining when and how to use `TemplateOnly` for generic template-only components
+2. Examples showing the above examples using generics
+3. Guidance on choosing between `const` and `class extends TemplateOnly`
+
+### Migration Path
+
+_There is no need for migration_.
+
+This feature is purely additive and doesn't affect existing template-only components. Developers can continue (and likely should prefer) using the current `const` syntax for simple cases and opt into the class syntax when they need generics.
+
+```typescript
+// Existing syntax still works
+const SimpleComponent = <template>
+  <p>Hello {{@name}}</p>
+</template>
+
+// New syntax for when you need generics
+class GenericComponent<T> extends TemplateOnly<{
+  Args: { data: T };
+}> {
+  <template>
+    <pre>{{json-stringify @data}}</pre>
+  </template>
+}
+```
+
+## Drawbacks
+
+### Learning Complexity
+
+Adding another way to define template-only components could be confusing for new users. However, this is mitigated by:
+- The feature is TypeScript-specific and optional
+- It follows familiar class extension patterns
+- Clear documentation about when to use each approach
+- Eslint and Glint tooling can reduce the switching costs (which we probably want anyway for our existing component format switching)
+
+## Alternatives
+
+n/a
+
+## Unresolved questions
+
+n/a
\ No newline at end of file

From 142772eb9ebdb93f845b0ebb77bbc77a1edd07cc Mon Sep 17 00:00:00 2001
From: NullVoxPopuli <199018+NullVoxPopuli@users.noreply.github.com>
Date: Thu, 14 Aug 2025 12:37:55 -0400
Subject: [PATCH 2/5] Update meta

---
 ...class-component.md => 1133-template-only-class-component.md} | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
 rename text/{0000-template-only-class-component.md => 1133-template-only-class-component.md} (99%)

diff --git a/text/0000-template-only-class-component.md b/text/1133-template-only-class-component.md
similarity index 99%
rename from text/0000-template-only-class-component.md
rename to text/1133-template-only-class-component.md
index 58f4e7545c..24bd6f39fa 100644
--- a/text/0000-template-only-class-component.md
+++ b/text/1133-template-only-class-component.md
@@ -7,7 +7,7 @@ teams:
   - framework
   - typescript
 prs:
-  accepted: # Fill this in with the URL for the Proposal RFC PR
+  accepted: https://github.com/emberjs/rfcs/pull/1133
 project-link:
 suite: 
 ---

From 1f67b4956d9d2fb77f02ceb5fea2e0d2f27e7ea0 Mon Sep 17 00:00:00 2001
From: NullVoxPopuli <199018+NullVoxPopuli@users.noreply.github.com>
Date: Thu, 14 Aug 2025 12:43:39 -0400
Subject: [PATCH 3/5] Add polyfill example

---
 text/1133-template-only-class-component.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/text/1133-template-only-class-component.md b/text/1133-template-only-class-component.md
index 24bd6f39fa..8f7fdf6970 100644
--- a/text/1133-template-only-class-component.md
+++ b/text/1133-template-only-class-component.md
@@ -149,7 +149,7 @@ var Demo = template(`{{@value}}`, { scope: () => ({}) });
 
 However, because we also support compile-less environments, the `TemplateOnly` export would _work_ if it made it to the runtime.
 
-[Here is an example implementation of that fallback behavior in the Limber REPL]()
+[Here is an example implementation of that fallback behavior in the Limber REPL](https://limber.glimdown.com/edit?c=JYWwDg9gTgLgBAbzjKBDAxgawKYBM4C%2BcAZlBCHAOQACA5gDagjZQD0KGmwAdrZQNwAoUJFiI4EboRJkKNbCABGLViAi5gxYCwHDw0eEnSowqRcEYxtAZwA0ca9hgBhcpG7ZuMALKpuqWhYiUnIqagVlNnQ3SU8YXREDcWt0AAs8AFd6bGkQuXClFSgM7noICDBdQXR6VGtrOAAVBTBamGwAeVKAT0QCQVZWOABlAFFRgC44VJgYMGsJwdpgGFSMxQA6aJBWBiYWACtrXcYQZigAWgA3HcUyxVYAZgA2dAAWACYATjeABlxfl9sMRsAB2YjPACMqEej1BqABz0ekI%2BAFZiNDUSjnr9iB9WKYsAFsMcAKR-PZnIolKzMViMB7bdxxdgtNrYC6SejdDYwawAYgAMh8PtVavU4M5xdZmuB2V1ub5-IEoIhBHAHDBUFZ0GqNRrsvAQH5iaqALxwDwAd0l0tlrW1nR6StNAAoAJRCfUOJyufQeLwulWuj1wM0APjgxuVLHs9vlPU9cHVhBTKeMpnMlhsYY1GbMFhWNldlEeG0hj0o9gQKY1uBJKAy6Bg0CmxFQ9EctlrcDq3W46EFmmw6G6NWwzg79EUnAWJA7XZ7GTAuEdAAlypg2wvsN2NQRPYJ01BsI6-cyvK7z7EvFK6nZe1BaNZ3Xr9SeYBkoFJrZKYgGXGlD0vVTFNAhcSR2gADxgUMa29D8vx-LJ6BA-p%2BkEbAoNEeB63bLJ4Bqe84DXbB6DKAB1aB6HwLD2m4XAGnjR0FV6eC4GiGlcw%2BECAB52jlR1wx7bgIDgAADVZgGscSAEIe14sBwwATQgDJplQK4chqYAsDwZB0jgRQMlmSREAQKTrC2NSvAIIhaRJDZeIJYSNWcgSHXaYT%2BiAA&format=gjs)
 
 ### Usage Examples
 

From 62b1eece30941d993281dcd5495ffbbd86ced25b Mon Sep 17 00:00:00 2001
From: NullVoxPopuli <199018+NullVoxPopuli@users.noreply.github.com>
Date: Thu, 14 Aug 2025 17:28:32 -0400
Subject: [PATCH 4/5] Automatic otpmization of class components

---
 text/1133-template-only-class-component.md    | 259 ------------------
 ...-automatic-class-component-optimization.md | 171 ++++++++++++
 2 files changed, 171 insertions(+), 259 deletions(-)
 delete mode 100644 text/1133-template-only-class-component.md
 create mode 100644 text/1134-automatic-class-component-optimization.md

diff --git a/text/1133-template-only-class-component.md b/text/1133-template-only-class-component.md
deleted file mode 100644
index 8f7fdf6970..0000000000
--- a/text/1133-template-only-class-component.md
+++ /dev/null
@@ -1,259 +0,0 @@
----
-stage: accepted
-start-date: 2025-08-14T00:00:00.000Z
-release-date: # In format YYYY-MM-DDT00:00:00.000Z
-release-versions:
-teams:
-  - framework
-  - typescript
-prs:
-  accepted: https://github.com/emberjs/rfcs/pull/1133
-project-link:
-suite: 
----
-
-# Template-Only Class Components
-
-## Summary
-
-Add a new `TemplateOnly` base class to `@glimmer/component` that enables template-only components to be defined as classes, allowing them to support TypeScript generics for better type safety.
-
-## Motivation
-
-Currently, template-only components in Ember are defined using `const` declarations like this:
-
-```typescript
-export const Demo = <template>
-  {{@value}}
-</template>
-```
-
-However, this approach has a significant limitation: **it's not possible to specify generic type parameters** with `const` declarations in TypeScript. This prevents template-only components from having proper type safety when they need to work with generic data types.
-
-For example, consider a template-only component that should work with different types of values:
-
-```typescript
-import type { TOC } from '@ember/component/template-only';
-
-// This doesn't work - can't add generics to const declarations
-export const Demo<Value>: TOC<{ // ❌ Syntax error
-  Args: {
-    value: Value
-  }
-}> = <template>  
-  {{@value}}
-</template>
-```
-
-This limitation forces developers to either:
-1. Give up type safety and use `any` or `unknown` for component arguments
-2. Create unnecessary `@glimmer/component` Component classes to add TypeScript generics -- [these are slower][^template-only-faster]
-3. Create multiple duplicate components for different types
-
-Class-based components don't have the syntax limitation:
-
-```glimmer-ts
-interface ComponentSignature<Value> {
-  Args: {
-    value: Value;
-  };
-}
-
-class Demo<Value> extends Component<ComponentSignature<Value>> {
-  <template>
-    {{@value}}
-  </template>
-}
-```
-
-Creating a full component class when you only need a template feels like overkill and goes against the principle of template-only components [being lightweight][^template-only-faster].
-
-[^template-only-faster]: template-only components are 7 to 26% faster than the `Component` from `@glimmer/component` -- https://nullvoxpopuli.com/2023-12-20-template-only-vs-class-components
-
-## Detailed design
-
-### New `TemplateOnly` Export
-
-This RFC proposes adding a new `TemplateOnly` export to `@glimmer/component` that can be used as a base class for template-only components:
-
-```glimmer-ts
-import { TemplateOnly } from '@glimmer/component';
-
-class Demo<Value> extends TemplateOnly<{
-  Args: {
-    value: Value;
-  };
-}> {
-  <template>
-    {{@value}}
-  </template>
-}
-
-export default Demo;
-```
-
-At runtime, this is _functionally_ the same as the `const` template-only components today.
-In that the `TemplateOnly` class we re-export from `@glimmer/component` would be associated with a light-weight component manager, as template-only components are today.
-
-There is no `this`, so there will need to be a lint that forbids use of `this` in `TemplateOnly` classes.
-
-### Compilation
-
-Classes have a feature similar to functions, which is useful for defining more than one in the same file: hoisting.
-
-If we compiled to the `const` representation that we have today, we'd have a disagreement between editor expectations and runtime behavior.
-
-So compilation of these components should use `var` instead of `const`.
-
-Otherwise, all other aspects can be the same as existing compilation today:
-
-```glimmer-ts
-// Source
-class Demo<Value> extends TemplateOnly<{
-  Args: { value: Value };
-}> {
-  <template>
-    {{@value}}
-  </template>
-}
-
-// Compiled output (same as current template-only components)
-import { precompileTemplate } from '@ember/template-compilation';
-import { setComponentTemplate } from '@ember/component';
-import templateOnlyComponent from '@ember/component/template-only';
-
-export default setComponentTemplate(
-  precompileTemplate(`{{@value}}`, {
-    strictMode: true,
-    scope: () => ({}),
-  }),
-  templateOnlyComponent()
-);
-```
-
-Existing babel-based compnoent compilation occurs in [`babel-plugin-ember-template-compilation`](https://github.com/emberjs/babel-plugin-ember-template-compilation).
-But the `<template>` transforms occur in [`content-tag`](https://github.com/embroider-build/content-tag), and `content-tag`'s output would be:
-```typescript
-class Demo<Value> extends TemplateOnly<{
-  Args: { value: Value };
-}> {
-  static {
-    template(`{{@value}}`, { component: this, scope: () => ({}) })
-  }
-}
-```
-So `babel-plugin-ember-template-compilation` could optimze this to:
-```javascript
-var Demo = template(`{{@value}}`, { scope: () => ({}) });
-```
-
-However, because we also support compile-less environments, the `TemplateOnly` export would _work_ if it made it to the runtime.
-
-[Here is an example implementation of that fallback behavior in the Limber REPL](https://limber.glimdown.com/edit?c=JYWwDg9gTgLgBAbzjKBDAxgawKYBM4C%2BcAZlBCHAOQACA5gDagjZQD0KGmwAdrZQNwAoUJFiI4EboRJkKNbCABGLViAi5gxYCwHDw0eEnSowqRcEYxtAZwA0ca9hgBhcpG7ZuMALKpuqWhYiUnIqagVlNnQ3SU8YXREDcWt0AAs8AFd6bGkQuXClFSgM7noICDBdQXR6VGtrOAAVBTBamGwAeVKAT0QCQVZWOABlAFFRgC44VJgYMGsJwdpgGFSMxQA6aJBWBiYWACtrXcYQZigAWgA3HcUyxVYAZgA2dAAWACYATjeABlxfl9sMRsAB2YjPACMqEej1BqABz0ekI%2BAFZiNDUSjnr9iB9WKYsAFsMcAKR-PZnIolKzMViMB7bdxxdgtNrYC6SejdDYwawAYgAMh8PtVavU4M5xdZmuB2V1ub5-IEoIhBHAHDBUFZ0GqNRrsvAQH5iaqALxwDwAd0l0tlrW1nR6StNAAoAJRCfUOJyufQeLwulWuj1wM0APjgxuVLHs9vlPU9cHVhBTKeMpnMlhsYY1GbMFhWNldlEeG0hj0o9gQKY1uBJKAy6Bg0CmxFQ9EctlrcDq3W46EFmmw6G6NWwzg79EUnAWJA7XZ7GTAuEdAAlypg2wvsN2NQRPYJ01BsI6-cyvK7z7EvFK6nZe1BaNZ3Xr9SeYBkoFJrZKYgGXGlD0vVTFNAhcSR2gADxgUMa29D8vx-LJ6BA-p%2BkEbAoNEeB63bLJ4Bqe84DXbB6DKAB1aB6HwLD2m4XAGnjR0FV6eC4GiGlcw%2BECAB52jlR1wx7bgIDgAADVZgGscSAEIe14sBwwATQgDJplQK4chqYAsDwZB0jgRQMlmSREAQKTrC2NSvAIIhaRJDZeIJYSNWcgSHXaYT%2BiAA&format=gjs)
-
-### Usage Examples
-
-#### Simple Generic Component
-
-```typescript
-import { TemplateOnly } from '@glimmer/component';
-
-class ItemDisplay<T> extends TemplateOnly<{
-  Args: {
-    item: T;
-    displayProperty: keyof T;
-  };
-}> {
-  <template>
-    <div class="item">
-      {{get @item @displayProperty}}
-    </div>
-  </template>
-}
-```
-
-#### Component with Blocks
-
-```typescript
-import { TemplateOnly } from '@glimmer/component';
-
-class List<T> extends TemplateOnly<{
-  Args: {
-    items: T[];
-  };
-  Blocks: {
-    default: [item: T, index: number];
-    empty: [];
-  };
-}> {
-  <template>
-    {{#if @items.length}}
-      <ul>
-        {{#each @items as |item index|}}
-          <li>{{yield item index}}</li>
-        {{/each}}
-      </ul>
-    {{else}}
-      {{yield to="empty"}}
-    {{/if}}
-  </template>
-}
-```
-
-
-## How we teach this
-
-The feature introduces one new concept: **Template-Only Class Components**. These are components that use class syntax purely for TypeScript generic support while maintaining template-only semantics at runtime.
-
-> [!IMPORTANT]
-> More importantly though, our eslint plugin, should have a way to automatically flip between the component formats to reduce the amount of shuffling that developers have to do when they need to switch formats -- this may also make sense as a glint code-action.
-
-### Documentation Updates
-
-#### TypeScript Guide Updates
-
-The [TypeScript: Invokables](https://guides.emberjs.com/release/typescript/core-concepts/invokables/) guide should be updated to include:
-
-1. A new section explaining when and how to use `TemplateOnly` for generic template-only components
-2. Examples showing the above examples using generics
-3. Guidance on choosing between `const` and `class extends TemplateOnly`
-
-### Migration Path
-
-_There is no need for migration_.
-
-This feature is purely additive and doesn't affect existing template-only components. Developers can continue (and likely should prefer) using the current `const` syntax for simple cases and opt into the class syntax when they need generics.
-
-```typescript
-// Existing syntax still works
-const SimpleComponent = <template>
-  <p>Hello {{@name}}</p>
-</template>
-
-// New syntax for when you need generics
-class GenericComponent<T> extends TemplateOnly<{
-  Args: { data: T };
-}> {
-  <template>
-    <pre>{{json-stringify @data}}</pre>
-  </template>
-}
-```
-
-## Drawbacks
-
-### Learning Complexity
-
-Adding another way to define template-only components could be confusing for new users. However, this is mitigated by:
-- The feature is TypeScript-specific and optional
-- It follows familiar class extension patterns
-- Clear documentation about when to use each approach
-- Eslint and Glint tooling can reduce the switching costs (which we probably want anyway for our existing component format switching)
-
-## Alternatives
-
-n/a
-
-## Unresolved questions
-
-n/a
\ No newline at end of file
diff --git a/text/1134-automatic-class-component-optimization.md b/text/1134-automatic-class-component-optimization.md
new file mode 100644
index 0000000000..4ac52e701b
--- /dev/null
+++ b/text/1134-automatic-class-component-optimization.md
@@ -0,0 +1,171 @@
+---
+stage: accepted
+start-date: 2025-08-14T00:00:00.000Z
+release-date: # In format YYYY-MM-DDT00:00:00.000Z
+release-versions:
+teams:
+  - framework
+  - typescript
+prs:
+  accepted: https://github.com/emberjs/rfcs/pull/1134
+project-link:
+suite: 
+---
+
+# Automatic class component optimization
+
+## Summary
+
+Enable `@glimmer/component` Component classes with no body (other than the template) to be automatically optimized at build time to the lighter template-only component format, allowing developers to use familiar class syntax with TypeScript generics while maintaining optimal runtime performance.
+
+This will only be available in applications as it will require a decision during compile time based on results of traversing the `template` contents.
+
+## Motivation
+
+Currently, template-only components in Ember are defined using `const` declarations like this:
+
+```glimmer-ts
+export const Demo = <template>
+  {{@value}}
+</template>
+```
+
+However, this approach has a significant limitation: **it's not possible to specify generic type parameters** with `const` declarations in TypeScript. This prevents template-only components from having proper type safety when they need to work with generic data types.
+
+For example, consider a template-only component that should work with different types of values:
+
+```glimmer-ts
+import type { TOC } from '@ember/component/template-only';
+
+// This doesn't work - can't add generics to const declarations
+export const Demo<Value>: TOC<{ // ❌ Syntax error
+  Args: {
+    value: Value
+  }
+}> = <template>  
+  {{@value}}
+</template>
+```
+
+This limitation forces developers to either:
+1. Give up type safety and use `any` or `unknown` for component arguments
+2. Create unnecessary `@glimmer/component` Component classes to add TypeScript generics -- [these are slower][^template-only-faster]
+3. Create multiple duplicate components for different types
+
+Class-based components don't have the syntax limitation:
+
+```glimmer-ts
+interface ComponentSignature<Value> {
+  Args: {
+    value: Value;
+  };
+}
+
+export class Demo<Value> extends Component<ComponentSignature<Value>> {
+  <template>
+    {{@value}}
+  </template>
+}
+```
+
+However, creating a full component class when you only need a template _feels like_ overkill when folks know that template-only components [are supposed to be more performant][^template-only-faster].
+
+[^template-only-faster]: template-only components are 7 to 26% faster than the `Component` from `@glimmer/component` -- https://nullvoxpopuli.com/2023-12-20-template-only-vs-class-components
+
+## Detailed design
+
+### Build-Time Optimization for Empty Component Classes
+
+This RFC proposes a build-time optimization that automatically compiles `@glimmer/component` Component classes with no body (other than the template) to the template-only component format.
+
+Developers can write components using familiar class syntax with TypeScript generics:
+
+```glimmer-ts
+import Component from '@glimmer/component';
+
+interface ComponentSignature<Value> {
+  Args: {
+    value: Value;
+  };
+}
+
+export class Demo<Value> extends Component<ComponentSignature<Value>> {
+  <template>
+    {{@value}}
+  </template>
+}
+```
+
+If the following criteria are met
+- no class body members (methods, properties, constructor)
+- no `this` identifier within `{{}}` in the template
+
+The `Demo` component would be converted to:
+
+```gjs
+export var Demo = template(`@value`);
+```
+
+### Why we must parse the template for `this`
+
+Consider:
+```gjs
+// has no class body members
+class A extends Component {
+  <template>
+     {{! but references `this` and passes it elsewhere}}
+     <B @state={{this}} />
+  </template>
+}
+
+class B extends Component {
+  get router() {
+    // that component instance from `A` is used here
+    return getOwner(this.args.state).lookup('...');
+  }
+  <template>
+    {{this.router.currentURL}}
+  </template>
+}
+```
+
+## How we teach this
+
+This feature introduces **automatic build-time optimization** for Component classes that only contain templates. Developers don't need to learn new APIs or change their mental model - they can continue writing Component classes as they always have, and get automatic performance benefits when appropriate.
+
+### Documentation Updates
+
+#### TypeScript Guide Updates
+
+The [TypeScript: Invokables](https://guides.emberjs.com/release/typescript/core-concepts/invokables/) guide should be updated to include:
+
+1. A new section explaining that Component classes with only templates are automatically optimized
+2. Examples showing generic Component classes that benefit from this optimization
+3. Guidance on when the optimization applies and when it doesn't
+
+There is little to no benefit to using this feature for JavaScript features unless folks think they might regularly switch between template-only and class components. This could be called out during initial component-authoring guides, but doesn't need much mention, since the goal of this compilation behavior is to be transparent to users (and always correct, so it is not noticed).
+
+#### eslint-plugin-ember
+
+we would disable this lint rule: [no-empty-glimmer-component-classes](https://github.com/ember-cli/eslint-plugin-ember/blob/master/lib/rules/no-empty-glimmer-component-classes.js)
+
+## Drawbacks
+
+## Alternatives
+
+### Alternative 1: New `TemplateOnly` Base Class
+
+Instead of optimizing existing Component classes, introduce a new `TemplateOnly` base class:
+
+```typescript
+class Demo<T> extends TemplateOnly<{ Args: { data: T } }> {
+  <template>{{@data}}</template>
+}
+```
+
+See: [RFC #1133](https://github.com/emberjs/rfcs/pull/1133)
+
+
+## Unresolved questions
+
+n/a
\ No newline at end of file

From 8ec9da7717e1cdbcaa746340a443d7de952567b9 Mon Sep 17 00:00:00 2001
From: NullVoxPopuli <199018+NullVoxPopuli@users.noreply.github.com>
Date: Thu, 14 Aug 2025 17:56:27 -0400
Subject: [PATCH 5/5] Rephrase

---
 text/1134-automatic-class-component-optimization.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/text/1134-automatic-class-component-optimization.md b/text/1134-automatic-class-component-optimization.md
index 4ac52e701b..a12df7e81e 100644
--- a/text/1134-automatic-class-component-optimization.md
+++ b/text/1134-automatic-class-component-optimization.md
@@ -143,7 +143,7 @@ The [TypeScript: Invokables](https://guides.emberjs.com/release/typescript/core-
 2. Examples showing generic Component classes that benefit from this optimization
 3. Guidance on when the optimization applies and when it doesn't
 
-There is little to no benefit to using this feature for JavaScript features unless folks think they might regularly switch between template-only and class components. This could be called out during initial component-authoring guides, but doesn't need much mention, since the goal of this compilation behavior is to be transparent to users (and always correct, so it is not noticed).
+For JavaScript users the benefit is of this compilation behavior is that they'll no longer need to worry about perf implications of "choosing the wrong style of component". TypeScript users also get this benefit, but there is also the genecis benefit for TypeScript.
 
 #### eslint-plugin-ember