diff --git a/src/frontend/src/content/docs/deployment/javascript-apps.mdx b/src/frontend/src/content/docs/deployment/javascript-apps.mdx
index 4afeaad3..2a343222 100644
--- a/src/frontend/src/content/docs/deployment/javascript-apps.mdx
+++ b/src/frontend/src/content/docs/deployment/javascript-apps.mdx
@@ -28,7 +28,7 @@ For deployment, `AddViteApp` and `AddJavaScriptApp` should be treated as fronten
 To deploy a JavaScript frontend, you must choose which other resource owns the public HTTP surface in production:
 
 - Use `PublishWithContainerFiles(...)` when your backend or web server will serve the built frontend files.
-- Use `PublishWithStaticFiles(...)` when your reverse proxy, gateway, or BFF will serve the built frontend files.
+- Use `PublishWithStaticFiles(...)` when your reverse proxy, gateway, or <abbr title="Backend for Frontend">BFF</abbr> will serve the built frontend files.
 
 If you only add a Vite or JavaScript app and reference backend services, Aspire still needs one of these production hosting patterns to know who serves the built frontend in deployment.
 
@@ -223,9 +223,9 @@ await builder.build().run();
 </Tabs>
 
 <Aside type="note">
-  `AddViteApp` is still fine in this model. The trap is not `AddViteApp` itself
-  — it is treating the Vite development server endpoint as a publish-time
-  dependency.
+  `AddViteApp` is still fine in this model but it's important to
+  understand that the Vite development server endpoint is not used at
+  publish-time.
 </Aside>
 
 ### Dev-only gateway wiring