Update pitch and anti-pitch docs

Author: satya164

versioned_docs/version-7.x/limitations.md

@@ -4,20 +4,25 @@ title: Pitch & anti-pitch
 sidebar_label: Pitch & anti-pitch
 ---
 
-It's useful when considering whether or not to use a project to understand the tradeoffs that the developers of the project made when building it. What problems does it explicitly try to solve for you, and which ones does it ignore? What are the current limitations of the project and common problems that people encounter? These are the kinds of questions that we believe you should have answers to when making an important technology decision for your project, and so we have documented answers to these questions as best we can here, in the form of a "pitch" (why you should use it) and "anti-pitch" (why you should not use it). Please [submit a pull request](https://github.com/react-navigation/react-navigation.github.io) if you believe we have omitted important information!
+Choosing a navigation library means choosing its tradeoffs. This page summarizes the problems React Navigation is designed to solve, as well as cases where it may not be the right fit. Please [submit a pull request](https://github.com/react-navigation/react-navigation.github.io) if you believe we have omitted something important.
 
 ## Pitch
 
-- React Navigation doesn't include any native code in the library itself, but we use many native libraries such as [Screens](https://github.com/software-mansion/react-native-screens), [Reanimated](https://software-mansion.github.io/react-native-reanimated/), [Gesture Handler](https://software-mansion.github.io/react-native-gesture-handler/) etc. to implement performant animations and gestures. Depending on the navigator, many UI components are written in JavaScript on top of React Native primitives. This has a lot of benefits:
-  - Easy OTA updates
-  - Debuggable
-  - Customizable
-- Most apps heavily customize navigation, to do this with an API that wraps native navigation you will need to write a lot of native code. In React Navigation, we provide navigators written fully with JavaScript (e.g. [Stack Navigator](stack-navigator.md)) and navigators implemented on top of platform navigation primitives (e.g. [Native Stack Navigator](native-stack-navigator.md)). This lets you pick the navigators suitable for your use case, depending on whether you want native platform behavior or full customizability.
-- It's possible to write your own navigators that integrate cleanly with standard navigators, or to fork the standard navigators and create your own version of them with the exact look and feel you want in your app.
+- **Explicit navigation graph** - Routes, nesting, groups, and navigator options are declared in code, making the navigation structure directly inspectable and independent of the filesystem.
+- **Simple setup with flexible configuration** - [Static configuration](static-configuration.md) provides automatic TypeScript type inference from the navigator configuration and can generate paths for deep linking. It can also [conditionally include screens and groups](static-configuration.md#if) based on application state. For navigation structures defined at runtime, you can use [dynamic configuration](static-vs-dynamic.md) or [combine both approaches](combine-static-with-dynamic.md).
+- **State-based navigation with advanced control** - The state model supports nested histories and high-level operations such as [reset](navigation-actions.md#reset), [persistence](state-persistence.md), and [preload](navigation-object.md#preload), while [actions](navigation-actions.md) and [custom routers](custom-routers.md) provide deeper control when needed.
+- **URLs independent of UI structure** - Navigator nesting can change without changing public URLs, allowing the navigation UI to evolve without breaking existing links.
+- **Flexible linking** - The [linking configuration](configuring-links.md) supports custom path patterns, parameter parsing, regular expressions, catch-all routes, and fully custom conversion between paths and navigation state.
+- **Choice of native or JavaScript implementations** - [Native Stack](native-stack-navigator.md) and [Native Bottom Tabs](native-bottom-tab-navigator.md) use platform navigation primitives. JavaScript implementations provide more control over UI, animations, and gestures, and are easier to debug, customize, and update over the air.
+- **Extensible building blocks** - [Custom navigators](custom-navigators.md) and [custom routers](custom-routers.md) integrate with the same navigation actions, deep linking, state persistence, and nesting used by built-in navigators.
+- **React Native and Web** - The same navigation model works across React Native and [Web](web-support.md). On Web, React Navigation integrates with URLs, browser history, links, and accessibility features.
+- **Works with Expo and Community CLI** - React Navigation doesn't require Expo or a particular project structure.
 
 ## Anti-pitch
 
-- Improvements may require breaking changes. We are working to make ["easy things easy and hard things possible"](https://www.quora.com/What-is-the-origin-of-the-phrase-make-the-easy-things-easy-and-the-hard-things-possible) and this may require us to change the API at times.
-- Some navigators don't directly use the native navigation APIs on iOS and Android; rather, they use the lowest level pieces and then re-creates some subset of the APIs on top. This is a conscious choice in order to make it possible for users to customize any part of the navigation experience (because it's implemented in JavaScript) and to be able to debug issues that they encounter without needing to learn Objective C / Swift / Java / Kotlin.
-  - If you need the exact platform behavior, you can choose to use the navigators that use native platform primitives (e.g. [Native Stack Navigator](native-stack-navigator.md)), or use a different navigation library which provides fully native navigation APIs (e.g. [React Native Navigation](https://github.com/wix/react-native-navigation)).
-- There are other limitations which you may want to consider, see [Limitations](limitations.md) for more details.
+- **No file-based routing** - Routes are configured in code rather than generated from the filesystem. React Navigation doesn't provide automatic route discovery.
+- **Not a full-stack framework** - As a navigation library, React Navigation doesn't provide application framework features such as API routes, server middleware, or bundler integration for automatic code splitting.
+- **Limited web rendering infrastructure** - Web support is primarily designed for client-rendered apps and PWAs. [Server rendering](server-rendering.md) requires manual setup and has limitations, and static rendering isn't built in. A web-focused framework may be a better fit when rendering infrastructure and SEO are primary requirements.
+- **JavaScript navigators don't exactly reproduce native behavior** - Their transitions, gestures, and lifecycle behavior may differ from the platform's native navigation components. If exact platform behavior is required, use a navigator backed by native primitives or consider a library with fully native navigation APIs, such as [React Native Navigation](https://github.com/wix/react-native-navigation).
+- **Native navigators have customization constraints** - Their behavior and customization are limited to what the underlying platform components expose. Features available to JavaScript navigators may not be available to their native counterparts.
+- **Native dependencies may require native builds** - Some navigators depend on native libraries such as [Screens](https://github.com/software-mansion/react-native-screens), [Reanimated](https://docs.swmansion.com/react-native-reanimated/), and [Gesture Handler](https://docs.swmansion.com/react-native-gesture-handler/). Installing or updating their native code requires a new app build and cannot be delivered over the air.

versioned_docs/version-7.x/pitch.md

@@ -4,20 +4,25 @@ title: Pitch & anti-pitch
 sidebar_label: Pitch & anti-pitch
 ---
 
-It's useful when considering whether or not to use a project to understand the tradeoffs that the developers of the project made when building it. What problems does it explicitly try to solve for you, and which ones does it ignore? What are the current limitations of the project and common problems that people encounter? These are the kinds of questions that we believe you should have answers to when making an important technology decision for your project, and so we have documented answers to these questions as best we can here, in the form of a "pitch" (why you should use it) and "anti-pitch" (why you should not use it). Please [submit a pull request](https://github.com/react-navigation/react-navigation.github.io) if you believe we have omitted important information!
+Choosing a navigation library means choosing its tradeoffs. This page summarizes the problems React Navigation is designed to solve, as well as cases where it may not be the right fit. Please [submit a pull request](https://github.com/react-navigation/react-navigation.github.io) if you believe we have omitted something important.
 
 ## Pitch
 
-- React Navigation doesn't include any native code in the library itself, but we use many native libraries such as [Screens](https://github.com/software-mansion/react-native-screens), [Reanimated](https://software-mansion.github.io/react-native-reanimated/), [Gesture Handler](https://software-mansion.github.io/react-native-gesture-handler/) etc. to implement performant animations and gestures. Depending on the navigator, many UI components are written in JavaScript on top of React Native primitives. This has a lot of benefits:
-  - Easy OTA updates
-  - Debuggable
-  - Customizable
-- Most apps heavily customize navigation, to do this with an API that wraps native navigation you will need to write a lot of native code. In React Navigation, we provide navigators written fully with JavaScript (e.g. [Stack Navigator](stack-navigator.md)) and navigators implemented on top of platform navigation primitives (e.g. [Native Stack Navigator](native-stack-navigator.md)). This lets you pick the navigators suitable for your use case, depending on whether you want native platform behavior or full customizability.
-- It's possible to write your own navigators that integrate cleanly with standard navigators, or to fork the standard navigators and create your own version of them with the exact look and feel you want in your app.
+- **Explicit navigation graph** - Routes, nesting, groups, and navigator options are declared in code, making the navigation structure directly inspectable and independent of the filesystem.
+- **Simple setup with flexible configuration** - [Static configuration](static-configuration.md) provides automatic TypeScript type inference from the navigator and linking configuration and generates paths for deep linking by default. It can also [conditionally include screens and groups](static-configuration.md#if) based on application state. For navigation structures defined at runtime, you can use [dynamic configuration](static-vs-dynamic.md) or [combine both approaches](combine-static-with-dynamic.md).
+- **State-based navigation with advanced control** - The state model supports nested histories and high-level operations such as [reset](navigation-actions.md#reset), [persistence](state-persistence.md), and [preload](navigation-object.md#preload), while [actions](navigation-actions.md) and [custom routers](custom-routers.md) provide deeper control when needed.
+- **URLs independent of UI structure** - Navigator nesting can change without changing public URLs, allowing the navigation UI to evolve without breaking existing links.
+- **Flexible linking** - The [linking configuration](configuring-links.md) supports custom path patterns, parameter parsing, [Standard Schemas](configuring-links.md#using-standard-schema) for validation, regular expressions, catch-all routes, and fully custom conversion between paths and navigation state.
+- **Choice of native or JavaScript implementations** - [Native Stack](native-stack-navigator.md) uses platform navigation primitives, while [Bottom Tabs](bottom-tab-navigator.md#native-vs-custom-implementation) supports both native and custom implementations. JavaScript implementations provide more control over UI, animations, and gestures, and are easier to debug, customize, and update over the air.
+- **Extensible building blocks** - [Custom navigators](custom-navigators.md) and [custom routers](custom-routers.md) integrate with the same navigation actions, deep linking, state persistence, and nesting used by built-in navigators.
+- **React Native and Web** - The same navigation model works across React Native and [Web](web-support.md). On Web, React Navigation integrates with URLs, browser history, links, and accessibility features.
+- **Works with Expo and Community CLI** - React Navigation doesn't require Expo or a particular project structure.
 
 ## Anti-pitch
 
-- Improvements may require breaking changes. We are working to make ["easy things easy and hard things possible"](https://www.quora.com/What-is-the-origin-of-the-phrase-make-the-easy-things-easy-and-the-hard-things-possible) and this may require us to change the API at times.
-- Some navigators don't directly use the native navigation APIs on iOS and Android; rather, they use the lowest level pieces and then re-creates some subset of the APIs on top. This is a conscious choice in order to make it possible for users to customize any part of the navigation experience (because it's implemented in JavaScript) and to be able to debug issues that they encounter without needing to learn Objective C / Swift / Java / Kotlin.
-  - If you need the exact platform behavior, you can choose to use the navigators that use native platform primitives (e.g. [Native Stack Navigator](native-stack-navigator.md)), or use a different navigation library which provides fully native navigation APIs (e.g. [React Native Navigation](https://github.com/wix/react-native-navigation)).
-- There are other limitations which you may want to consider, see [Limitations](limitations.md) for more details.
+- **No file-based routing** - Routes are configured in code rather than generated from the filesystem. React Navigation doesn't provide automatic route discovery.
+- **Not a full-stack framework** - As a navigation library, React Navigation doesn't provide application framework features such as API routes, server middleware, or bundler integration for automatic code splitting.
+- **Limited web rendering infrastructure** - Web support is primarily designed for client-rendered apps and PWAs. [Server rendering](server-rendering.md) requires manual setup and has limitations, and static rendering isn't built in. A web-focused framework may be a better fit when rendering infrastructure and SEO are primary requirements.
+- **JavaScript navigators don't exactly reproduce native behavior** - Their transitions, gestures, and lifecycle behavior may differ from the platform's native navigation components. If exact platform behavior is required, use a navigator backed by native primitives or consider a library with fully native navigation APIs, such as [React Native Navigation](https://github.com/wix/react-native-navigation).
+- **Native navigators have customization constraints** - Their behavior and customization are limited to what the underlying platform components expose. Features available to JavaScript navigators may not be available to their native counterparts.
+- **Native dependencies may require native builds** - Some navigators depend on native libraries such as [Screens](https://github.com/software-mansion/react-native-screens), [Reanimated](https://docs.swmansion.com/react-native-reanimated/), and [Gesture Handler](https://docs.swmansion.com/react-native-gesture-handler/). Installing or updating their native code requires a new app build and cannot be delivered over the air.

versioned_docs/version-8.x/limitations.md

@@ -187,7 +187,6 @@
         "glossary-of-terms",
         "troubleshooting",
         "pitch",
-        "limitations",
         "used-by",
         "contributing",
         "llms"

versioned_docs/version-8.x/pitch.md

@@ -194,7 +194,6 @@
         "glossary-of-terms",
         "troubleshooting",
         "pitch",
-        "limitations",
         "used-by",
         "contributing",
         "llms"