docs: Update components/tasks index.mdx verbiage and phrasing

packages/docs/src/routes/docs/(qwik)/components/tasks/index.mdx

@@ -18,6 +18,7 @@ contributors:
   - julianobrasil
   - adamdbradley
   - aendel
+  - jemsco
 updated_at: '2023-10-18T07:33:22Z'
 created_at: '2023-03-31T02:40:50Z'
 ---
@@ -35,7 +36,7 @@ Tasks are meant for running asynchronous operations as part of component initial
 > - Task run on server and browser.
 > - Tasks run before rendering and can block rendering.
 
-`useTask$()` should be your default go-to API for running asynchronous (or synchronous) work as part of component initialization or state change. It is only when you can't achieve what you need with `useTask$()` that you should consider using `useVisibleTask$()` or `useResource$()`.
+`useTask$()` should be your default go-to API for running either synchronous or asynchronous work as part of component initialization or state change. It is only when you can't achieve what you need with `useTask$()` that you should consider using `useVisibleTask$()` or `useResource$()`.
 
 The basic use case for `useTask$()` is to perform work on component initialization. `useTask$()` has these properties:
 - It can run on either the server or in the browser.
@@ -49,14 +50,16 @@ Sometimes a task needs to run only on the browser and after rendering, in that c
 Sometimes a task should fetch data asynchronously and produce a signal (and not block rendering), in that case, you should use [`useResource$()`](/docs/components/state/#useresource).
 
 ## Lifecycle
+Resumability is "Lazy execution", it's the ability to build the "framework state" (component boundaries, etc) on the server, and have it exist on the client without re-executing the framework again.
 
-Thanks to [Resumability](/docs/(qwik)/concepts/resumable/index.mdx), component lifetime and its lifecycle extend across server and browser runtime. Sometimes the component will first be rendered in the server, and other times it could be rendered in the browser. However, in both cases, the lifecycle (order) will be the same, only its execution location will be in different environments (server vs browser).
+The application environment—whether client-side or server-side—is determined by user interactions. In server-side rendering, the application initially renders on the server.
+When the user interacts with the application, it resumes on the client-side, continuing from the state left by the server. This approach ensures efficient and responsive user experiences by leveraging both environments based on interaction.
 
-> **Note**: For systems that use hydration the execution of the application happens twice. Once on a server (SSR/SSG) and once on the browser (hydration). For this reason, many frameworks have "effects" which only execute on the browser. That means that the code that runs on the server is different than the code that runs on the browser. Qwik execution is unified, meaning if the code has already been executed on the server it does not re-execute it on the browser.
+> **Note**: For systems that use hydration the execution of the application happens twice. Once on a server (SSR/SSG) and once on the browser (hydration). This is why many frameworks have "effects" which only execute on the browser. That means that the code that runs on the server is different than the code that runs on the browser. Qwik execution is unified, meaning if the code has already been executed on the server it does not re-execute it on the browser.
 
 **In Qwik, there are only 3 lifecycle stages:**
 
-- `Task` - run before rendering and also when tracked state changes. (Tasks run sequentially, and block rendering.)
+- `Task` - run before rendering and when tracked state changes. `Tasks` run sequentially, and block rendering.
 - `Render` - runs after `TASK` and before `VisibleTask`
 - `VisibleTask` - runs after `Render` and when the component becomes visible
 
@@ -72,7 +75,7 @@ Thanks to [Resumability](/docs/(qwik)/concepts/resumable/index.mdx), component l
 
 > **Notice** that because the component was mounted in the server, **only useVisibleTask$() runs in the browser**. This is because the browser continues the same lifecycle, that was paused in the server right after the render and resumed in the browser.
 
-**BROWSER**: Sometimes a component will be first mounted/rendered in the browser, for example when the user SPA navigates to a new page, or a "modal" component first appears in the page. In that case, the lifecycle will run like this:
+**BROWSER**: When a component is first mounted or rendered in the browser, for example when a user navigates to a new page in a Single Page Application (SPA) or when a "modal" component initially appears on the page, the lifecycle will proceed as follows:
 
 ```bash
   useTask$ --> RENDER --> useVisibleTask$
@@ -107,7 +110,7 @@ Additionally, this task can be reactive and will re-execute when **tracked** [st
 
 > If `useTask$()` does not track any state, it will run **exactly once**, either in the server **or** in the browser (**not both**), depending where the component is initially rendered. Effectively behaving like an "on-mount" hook.
 
-`useTask$()` will block the rendering of the component until after its async callback resolves, in other words, tasks execute sequentially even if they are asynchronous. (Only one task executes at a time / Tasks block rendering).
+`useTask$()` will block the rendering of the component until after its async callback resolves, in other words, tasks execute sequentially even if they are asynchronous. (Only one task executes at a time).
 
 Let's look at the simplest use case of the task to run some asynchronous work on component initialization.
 
@@ -142,22 +145,23 @@ const delay = (time: number) => new Promise((res) => setTimeout(res, time));
 >   - The `useTask$()` executes on the server as part of the SSR (the result may be cached in CDN.)
 >   - Because the `useTask$()` blocks rendering, the rendered HTML page takes 4 seconds to render.
 > - Because this task has no `track()` it will never rerun, making it effectively an initialization code.
->   - Because this component only renders on the server, the `useTask$()` will never run on the browser. (code will never download to browser.)
+>   - Because this component only renders on the server, the `useTask$()` will never be downloaded or run on the browser.
 
-> Notice that `useTask$()` runs **BEFORE** the actual rendering and on the server. Therefore if you need to do DOM manipulation, use [`useVisibleTask$()`](#usevisibletask) instead, which runs on the browser after rendering.
+> Notice that `useTask$()` runs on the server **BEFORE** the actual rendering. Therefore if you need to do DOM manipulation, use [`useVisibleTask$()`](#usevisibletask) instead, which runs on the browser after rendering.
 
 Use `useTask$()` when you need to:
 - Run async tasks before rendering
 - Run code only once before the component is first rendered
 - Programmatically run side-effect code when state changes
 
-> Note, if you're thinking about loading data (like using `fetch()`) inside of `useTask$`, consider using [`useResource$()`](/docs/components/state/#useresource) instead. This API is more efficient in terms of leveraging SSR streaming and parallel data fetching.
+> Note, if you're thinking about loading data using `fetch()` inside of `useTask$`, consider using [`useResource$()`](/docs/components/state/#useresource) instead. This API is more efficient in terms of leveraging SSR streaming and parallel data fetching.
 
 ### On mount
 
-Qwik does not have a specific "on-mount" hook because useTask$() without track() effectively behaves like a mount hook.
+In Qwik, there isn't a specific "mount" step like in some other frameworks. Instead, components just start up directly where they're needed, either on a web server or in your browser. 
+This is without the the inner track function, which is used to monitor specific pieces of data.
 
-This is because `useTask$` runs always at least once when the component is first mounted.
+`useTask$` runs always at least once when the component is first mounted.
 
 ```tsx {5-8}
 import { component$, useTask$ } from '@builder.io/qwik';
@@ -173,11 +177,11 @@ export default component$(() => {
 });
 ```
 
-One unique aspect of Qwik, is that components are mounted only ONCE across the server and client. This is a property of resumability. What it means, is that if `useTask$` runs during SSR it will not run again in the browser because Qwik does not hydrate.
+One unique aspect of Qwik, is that components are mounted only **once** across the server and client. This is a property of resumability. What this means is that if `useTask$` is executed during Server-Side Rendering (SSR), it will not run again in the browser because Qwik does not perform hydration.
 
 ### `track()`
 
-There are times when it is desirable to re-run a task when a component state changes. This is done by using the `track()` function. The `track()` function allows you to set up a dependency on a component state on the server (if initially rendered there) and then re-execute the task when the state changes _on the browser_ (the same task will never be executed twice on the server side).
+There are times when it is desirable to re-run a task when a component state changes. This is done by using the `track()` function. The `track()` function allows you to set up a dependency on a component's state when initially rendered on the server, and then re-execute the task when the state changes in the browser.  The same task will never be executed twice on the server.
 
 > **Note**: If all you want to do is compute a new state from an existing state synchronously, you should use [`useComputed$()`](/docs/components/state/#usecomputed) instead.
 
@@ -215,16 +219,16 @@ const delay = (time: number) => new Promise((res) => setTimeout(res, time));
 
 > On the server:
 >
-> - The `useTask$()` runs on the server and the `track()` function sets up a subscription on `text` signal.
+> - The `useTask$()` runs on the server and the `track()` function sets up a subscription on the `text` signal.
 > - The page is rendered.
 >
 > On the browser:
-> - The `useTask$()` does not have to run (or be downloaded) eagerly because Qwik knows that the task is subscribed to the `text` signal from the server execution.
+> - The `useTask$()` does not have to run or be downloaded eagerly because Qwik knows that the task is subscribed to the `text` signal from the server execution.
 > - When the user types in the input box, the `text` signal changes. Qwik knows that the `useTask$()` is subscribed to the `text` signal and it is at this time that the `useTask$()` closure is brought into the JavaScript VM to be executed.
 >
 > The `useTask$()`
 >
-> - The `useTask$()` blocks rendering until it completes. If you don't want to block rendering (as in this case) make sure that the task is resolved, and run the delay work on a separate unconnected promise. (In our case we don't await `delay()`. Doing so would block rendering.)
+> - The `useTask$()` blocks rendering until it completes. If you don't want to block rendering, make sure that the task is resolved, and run the delay work on a separate unconnected promise. In this example, we don't await `delay()` because it would block rendering.
 
 > Sometimes it is required to only run code either in the server or in the client. This can be achieved by using the `isServer` and `isBrowser` booleans exported from `@builder.io/qwik/build` as shown above.
 
@@ -272,15 +276,15 @@ function delay(time: number) {
 ```
 </CodeSandbox>
 
-> In this example the `track()` takes a function that not only reads the signal but also transforms its value to uppercase/lowercase. The `track()` is doing subscription on multiple signals and computes their value.
+> In this example the `track()` takes a function that not only reads the signal but also transforms its value to uppercase/lowercase. The `track()` subscribes to multiple signals and computes their value.
 
 ### `cleanup()`
 
-Sometimes when running a task cleanup work needs to be performed. When a new task is triggered, the previous task's `cleanup()` callback is invoked. (Also when the component is removed from the DOM then the `cleanup()` callback is also invoked.)
+Sometimes when running a task, cleanup work needs to be performed. When a new task is triggered, the previous task's `cleanup()` callback is invoked. This callback is also invoked when the component is removed from the DOM.
 
 > - The `cleanup()` function is not invoked when the task is completed. It is only invoked when a new task is triggered or when the component is removed.
 > - The `cleanup()` function is invoked on the server after the applications are serialized into HTML.
-> - The `cleanup()` function is not transferable from server to browser. (Cleanup is meant to release resources on the VM where it is running. It is not meant to be transferred to the browser.)
+> - The `cleanup()` function is not transferable from server to browser. Cleanup is meant to release resources on the VM where it is running. It is not meant to be transferred to the browser.
 
 This example shows how to implement a debounce feature using the `cleanup()` function.
 
@@ -321,7 +325,7 @@ Sometimes a task needs to run only on the browser and after rendering, in that c
 - runs after initial rendering.
 - does not block rendering.
 
-> **Caution**: The `useVisibleTask$()` should be used as a last resort, because it eagerly executes code on the client. Qwik through [resumability]() goes out of its way to delay the execution of code on the client, and `useVisibleTask$()` is an escape hatch that should be used with caution. See [Best Practices](/docs/(qwikcity)/guides/best-practices/index.mdx#dont-register-events-eagerly-with-usevisibletask) for more details.
+> **Caution**: The `useVisibleTask$()` should be used as a last resort, because it eagerly executes code on the client. Qwik, through [resumability](), goes out of its way to delay the execution of code on the client, and `useVisibleTask$()` is an escape hatch that should be used with caution. See [Best Practices](/docs/(qwikcity)/guides/best-practices/index.mdx#dont-register-events-eagerly-with-usevisibletask) for more details.
 > If you need to run a task on a client consider `useTask$()` with a server guard.
 >
 > <CodeSandbox src="/src/routes/demo/tasks/track-server-guard/index.tsx" style={{ height: '6em' }}>
@@ -358,8 +362,8 @@ Sometimes a task needs to run only on the browser and after rendering, in that c
 > ```
 > </CodeSandbox>
 >
-> In the above example the `useTask$()` is guarded by `isServer`. The `track()` is before the guard which
-> allows the server to set up the subscription but does not execute any code on the server. The client
+> In the above example the `useTask$()` is guarded by `isServer`. The `track()` function is placed before the guard, which
+> allows the server to set up the subscription without executing any code on the server. The client
 > then executes the `useTask$()` once the `text` signal changes.
 
 This example shows how to use `useVisibleTask$()` to initialize a clock on the browser only when the clock component becomes visible.
@@ -401,11 +405,11 @@ const Clock = component$<{ isRunning: Signal<boolean> }>(({ isRunning }) => {
 ```
 </CodeSandbox>
 
-> Notice how the clock's `useVisibleTask$()` does not run until the `<Clock>` component became visible. The default behavior of `useVisibleTask$()` is to run the task when the component becomes visible. This behavior is implemented through [intersection observers](https://developer.mozilla.org/en-US/docs/Web/API/Intersection_Observer_API).
+> Notice how the clock's `useVisibleTask$()` does not run until the `<Clock>` component becomes visible. The default behavior of `useVisibleTask$()` is to run the task when the component becomes visible. This behavior is implemented through [intersection observers](https://developer.mozilla.org/en-US/docs/Web/API/Intersection_Observer_API).
 
 ### Option `eagerness`
 
-At times it is desirable to run `useVisibleTask$()` eagerly as soon as the application is loaded in the browser. In that case the `useVisibleTask$()` needs to run in eager mode. This is done by using the `{ strategy: 'document-ready' }`.
+At times it is desirable to run `useVisibleTask$()` eagerly as soon as the application is loaded in the browser. In that case, the `useVisibleTask$()` needs to run in eager mode. This is done by using the `{ strategy: 'document-ready' }`.
 
 <CodeSandbox src="/src/routes/demo/tasks/use-visible-task-eager/index.tsx" style={{ height: '6em' }}>
 ```tsx
@@ -451,7 +455,7 @@ const Clock = component$<{ isRunning: Signal<boolean> }>(({ isRunning }) => {
 
 ### Advanced: Time of running, and managing visibility with CSS
 
-Internally, `useVisibleTask$` is implemented by adding an attribute on the first rendered component (either the returned component or in case of a Fragment, its first child).  With the standard `eagerness`, this means that if the first rendered component is hidden, the task will not run.
+Internally, `useVisibleTask$` is implemented by adding an attribute to the first rendered component (either the returned component or in the case of a Fragment, its first child).  With the standard `eagerness`, this means that if the first rendered component is hidden, the task will not run.
 
 This means that you can use CSS to influence when the task runs. For example, if the task should only run on a mobile device, you can return a `<div class="md:invisible" />` (in the case of Tailwind CSS).