Various typos/grammar/rewording

Author: Alexandre Kirszenberg

README.md

@@ -161,11 +161,11 @@ Dioxus is heavily inspired by React, but we want your transition to feel like an
 Remember: Dioxus is a library - not a compiler like Svelte. Plus, the inner VirtualDOM allows Dioxus to easily port into different runtimes, support SSR, and run remotely in the cloud. VDOMs tend to more ergonomic to work with and feel roughly like natural Rust code. The overhead of Dioxus is **extraordinarily** minimal... sure, there may be some overhead but on an order of magnitude lower than the time required to actually update the page.
 
 
-### Isn't the overhead for interacting with the DOM from WASM too much?
-The overhead layer between WASM and JS APIs is extremely poorly understood. Rust web benchmarks typically suffer from differences in how Rust and JS cache strings. In Dioxus, we solve most of these issues and our JS Framework Benchmark actually beats the WASM Bindgen benchmark in many cases. Compared to a "pure vanilla JS" solution, Dioxus adds less than 5% of overhead and takes advantage of batched DOM manipulation.
+### Isn't the overhead for interacting with the DOM from Wasm too much?
+The overhead layer between Wasm and JS APIs is extremely poorly understood. Rust web benchmarks typically suffer from differences in how Rust and JS cache strings. In Dioxus, we solve most of these issues and our JS Framework Benchmark actually beats the Wasm Bindgen benchmark in many cases. Compared to a "pure vanilla JS" solution, Dioxus adds less than 5% of overhead and takes advantage of batched DOM manipulation.
 
-### Aren't WASM binaries too huge to deploy in production?
-WASM binary sizes are another poorly understood characteristic of Rust web apps. 50kb of WASM and 50kb of JS are _not_ made equally. In JS, the code must be downloaded _first_ and _then_ JIT-ted. Just-in-time compiling 50kb of JavaScript takes a while which is why 50kb of JavaScript sounds like a lot! However, with WASM, the code is downloaded and JIT-ted _simultaneously_ through the magic of streaming compilation. By the time the 50kb of Rust is finished downloading, it is already ready to go. Again, Dioxus beats out many benchmarks with time-to-interactivity.
+### Aren't Wasm binaries too huge to deploy in production?
+Wasm binary sizes are another poorly understood characteristic of Rust web apps. 50kb of Wasm and 50kb of JS are _not_ made equally. In JS, the code must be downloaded _first_ and _then_ JIT-ted. Just-in-time compiling 50kb of JavaScript takes a while which is why 50kb of JavaScript sounds like a lot! However, with Wasm, the code is downloaded and JIT-ted _simultaneously_ through the magic of streaming compilation. By the time the 50kb of Rust is finished downloading, it is already ready to go. Again, Dioxus beats out many benchmarks with time-to-interactivity.
 
 For reference, Dioxus `hello-world` clocks in at around 70kb gzip or 60kb brotli, and Dioxus supports SSR.
 
@@ -176,7 +176,7 @@ There are plenty Rust Elm-like frameworks in the world - we were not interested
 The `RSX` DSL is _barely_ a DSL. Rustaceans will find the DSL very similar to simply assembling nested structs, but without the syntactical overhead of "Default" everywhere or having to jump through hoops with the builder pattern. Between RSX, HTML, the Raw Factory API, and the NodeBuilder syntax, there's plenty of options to choose from.
 
 ### What are the build times like? Why on earth would I choose Rust instead of JS/TS/Elm?
-Dioxus builds as roughly as fast as a complex WebPack-TypeScript site. Compile times will be slower than an equivalent TypeScript site, but not unbearably slow. The WASM compiler backend for Rust is very fast. Iterating on small components is basically instant and larger apps takes a few seconds. In practice, the compiler guarantees of Rust balance out the rebuild times.
+Dioxus builds as roughly as fast as a complex WebPack-TypeScript site. Compile times will be slower than an equivalent TypeScript site, but not unbearably slow. The Wasm compiler backend for Rust is very fast. Iterating on small components is basically instant and larger apps takes a few seconds. In practice, the compiler guarantees of Rust balance out the rebuild times.
 
 ### What about Yew/Seed/Sycamore/Dominator/Dodrio/Percy?
 - Yew and Seed use an Elm-like pattern and don't support SSR or any alternate rendering platforms
@@ -193,7 +193,7 @@ In the future, we are interested in using Webrenderer to provide a fully native
 You shouldn't use Dioxus if:
 - You don't like the React Hooks approach to frontend
 - You need a no-std renderer
-- You want to support browsers where WASM or asm.js are not supported.
+- You want to support browsers where Wasm or asm.js are not supported.
 
 
 ## License

docs/src/README.md

@@ -2,7 +2,7 @@
 
 ![dioxuslogo](./images/dioxuslogo_full.png)
 
-**Dioxus** is a framework and ecosystem for building fast, scalable, and robust user interfaces with the Rust programming language. This guide will help you get up-and-running with Dioxus running on the Web, Desktop, Mobile, and more. 
+**Dioxus** is a framework and ecosystem for building fast, scalable, and robust user interfaces with the Rust programming language. This guide will help you get up-and-running with Dioxus running on the Web, Desktop, Mobile, and more.
 
 ```rust, ignore
 // An example Dioxus app - closely resembles React
@@ -24,7 +24,7 @@ The Dioxus API and patterns closely resemble React - if this guide is lacking in
 ### Web Support
 ---
 
-The Web is the most-supported target platform for Dioxus. To run on the Web, your app must be compiled to WebAssembly and depend on the `dioxus` crate with the `web` feature enabled. Because of the WASM limitation, not every crate will work with your web-apps, so you'll need to make sure that your crates work without native system calls (timers, IO, etc).
+The Web is the most-supported target platform for Dioxus. To run on the Web, your app must be compiled to WebAssembly and depend on the `dioxus` crate with the `web` feature enabled. Because of the Wasm limitation, not every crate will work with your web-apps, so you'll need to make sure that your crates work without native system calls (timers, IO, etc).
 
 Because the web is a fairly mature platform, we expect there to be very little API churn for web-based features.
 
@@ -88,7 +88,7 @@ Examples:
 ### LiveView Support
 ---
 
-The internal architecture of Dioxus was designed from day one to support the `LiveView` use-case, where a web server hosts a running app for each connected user. As of today, there is no out-of-the-box LiveView support - you'll need to wire this up yourself. While not currently fully implemented, the expectation is that LiveView apps can be a hybrid between WASM and server-rendered where only portions of a page are "live" and the rest of the page is either server-rendered, statically generated, or handled by the host SPA.
+The internal architecture of Dioxus was designed from day one to support the `LiveView` use-case, where a web server hosts a running app for each connected user. As of today, there is no out-of-the-box LiveView support - you'll need to wire this up yourself. While not currently fully implemented, the expectation is that LiveView apps can be a hybrid between Wasm and server-rendered where only portions of a page are "live" and the rest of the page is either server-rendered, statically generated, or handled by the host SPA.
 
 
 

docs/src/advanced-guides/custom-renderer.md

@@ -49,7 +49,7 @@ enum DomEdit {
 }
 ```
 
-The Dioxus diffing mechanism operates as a [stack machine](https://en.wikipedia.org/wiki/Stack_machine) where the "push_root" method pushes a new "real" DOM node onto the stack and "append_child" and "replace_with" both remove nodes from the stack. 
+The Dioxus diffing mechanism operates as a [stack machine](https://en.wikipedia.org/wiki/Stack_machine) where the "push_root" method pushes a new "real" DOM node onto the stack and "append_child" and "replace_with" both remove nodes from the stack.
 
 
 ### An example
@@ -60,7 +60,7 @@ For the sake of understanding, lets consider this example - a very simple UI dec
 rsx!( h1 {"hello world"} )
 ```
 
-To get things started, Dioxus must first navigate to the container of this h1 tag. To "navigate" here, the internal diffing algorithm generates the DomEdit `PushRoot` where the ID of the root is the container. 
+To get things started, Dioxus must first navigate to the container of this h1 tag. To "navigate" here, the internal diffing algorithm generates the DomEdit `PushRoot` where the ID of the root is the container.
 
 When the renderer receives this instruction, it pushes the actual Node onto its own stack. The real renderer's stack will look like this:
 
@@ -228,7 +228,7 @@ For example, the `div` element is (approximately!) defined as such:
 ```rust
 struct div;
 impl div {
-    /// Some glorious documentaiton about the class proeprty.
+    /// Some glorious documentation about the class property.
     #[inline]
     fn class<'a>(&self, cx: NodeFactory<'a>, val: Arguments) -> Attribute<'a> {
         cx.attr("class", val, None, false)
@@ -251,7 +251,7 @@ There are three opportunities for platform incompatibilities to break your progr
 
 The best hooks will properly detect the target platform and still provide functionality, failing gracefully when a platform is not supported. We encourage - and provide - an indication to the user on what platforms a hook supports. For issues 1 and 2, these return a result as to not cause panics on unsupported platforms. When designing your hooks, we recommend propagating this error upwards into user facing code, making it obvious that this particular service is not supported.
 
-This particular code _will panic_ due to the unwrap on downcast_ref. Try to avoid these types of patterns. 
+This particular code _will panic_ due to the unwrap on downcast_ref. Try to avoid these types of patterns.
 
 ```rust
 let div_ref = use_node_ref(cx);

docs/src/advanced-guides/liveview.md

@@ -1,12 +1,12 @@
 # Dioxus Liveview
-Liveview is a configuration where a server and a client work together to render a Dioxus app. Liveview monomorphizes a web application, eliminating the need for frontend-specific APIs. 
+Liveview is a configuration where a server and a client work together to render a Dioxus app. Liveview monomorphizes a web application, eliminating the need for frontend-specific APIs.
 
-This is a developer-friendly alternative to the JAM-stack (Javascript + API + Markdown), combining the WASM-compatibility and async performance of Rust.
+This is a developer-friendly alternative to the JAM-stack (Javascript + API + Markdown), combining the Wasm-compatibility and async performance of Rust.
 
 ## Why liveview?
 
-### No APIs necessary! 
-Because Liveview combines the server and the client, you'll find dedicated APIs unnecessary. You'll still want to implement a datafetching service for Live-apps, but this can be implemented as a crate and shared between apps. This approach was designed to let you model out your data requirements without needing to maintain a public versioned API.
+### No APIs necessary!
+Because Liveview combines the server and the client, you'll find dedicated APIs unnecessary. You'll still want to implement a data-fetching service for Live-apps, but this can be implemented as a crate and shared between apps. This approach was designed to let you model out your data requirements without needing to maintain a public versioned API.
 
 You can find more information to data modeling and fetching for LiveApps in the "Book of Dioxus Patterns".
 

docs/src/concepts/00-index.md

@@ -2,7 +2,7 @@
 
 In this chapter of the book, we'll cover some core topics on how Dioxus works and how to best leverage the features to build a beautiful, reactive app.
 
-At a very high level, Dioxus is simply a Rust framework for _declaring_ user interfaces and _reacting_ to changes. 
+At a very high level, Dioxus is simply a Rust framework for _declaring_ user interfaces and _reacting_ to changes.
 
 1) We declare what we want our user interface to look like given a state using Rust-based logic and control flow.
 2) We declare how we want our state to change when the user triggers an event.
@@ -12,7 +12,7 @@ At a very high level, Dioxus is simply a Rust framework for _declaring_ user int
 
 Dioxus is a *declarative* framework. This means that instead of manually writing calls to "create element" and "set element background to red," we simply *declare* what we want the element to look like and let Dioxus handle the differences.
 
-Let's pretend that we have a stoplight we need to control - it has a color state with red, yellow, and green as options. 
+Let's pretend that we have a stoplight we need to control - it has a color state with red, yellow, and green as options.
 
 
 Using an imperative approach, we would have to manually declare each element and then handlers for advancing the stoplight.

docs/src/concepts/06-subscription-api.md

@@ -6,7 +6,7 @@ Yew subscriptions are used to schedule update for components into the future. Th
 fn Component(cx: Component<()>) -> DomTree {
     let update = cx.schedule();
 
-    // Now, when the subscription is called, the component will be re-evaluted
+    // Now, when the subscription is called, the component will be re-evaluated
     update.consume();
 }
 ```

docs/src/concepts/10-concurrent-mode.md

@@ -56,7 +56,7 @@ async fn ExampleLoader(cx: Context<()>) -> Vnode {
 
     match name {
         Ok(name) => rsx! { <div> "Hello {something}" </div> },
-        Err(e) => rsx! { <div> "An error occured :(" </div>}
+        Err(e) => rsx! { <div> "An error occurred :(" </div>}
     }
 }
 ```

docs/src/concepts/11-arena-memo.md

@@ -53,4 +53,4 @@ fn test(cx: Context<()>) -> DomTree {
 }
 ```
 
-While the contents of the destructued bundle might change, not every child component will need to be re-rendered.
+While the contents of the destructured bundle might change, not every child component will need to be re-rendered.

docs/src/concepts/vnodes.md

@@ -1,6 +1,6 @@
 # VNodes and Elements
 
-At the heart of Dioxus is the concept of an "element" - a container that can have children, properties, event handlers, and other important attributes. Dioxus only knows how to render the `VNode` datastructure - an Enum variant of an Element, Text, Components, Fragments, and Anchors.
+At the heart of Dioxus is the concept of an "element" - a container that can have children, properties, event handlers, and other important attributes. Dioxus only knows how to render the `VNode` data structure - an Enum variant of an Element, Text, Components, Fragments, and Anchors.
 
 Because Dioxus is meant for the Web and uses WebView as a desktop and mobile renderer, almost all elements in Dioxus share properties with their HTML counterpart. When we declare our elements, we'll do so using HTML semantics:
 
@@ -27,8 +27,8 @@ And produce the corresponding html structure:
 <div>hello world</div>
 ```
 
-Our structure declared above is made of two variants of the `VNode` datastructure:
-- A VElement with a tagname of `div`
+Our structure declared above is made of two variants of the `VNode` data structure:
+- A VElement with a tag name of `div`
 - A VText with contents of `"hello world"`
 
 ## All the VNode types
@@ -49,7 +49,7 @@ To speed up the process of building our elements and text, Dioxus uses a special
 - Bumpalo: [https://github.com/fitzgen/bumpalo](https://github.com/fitzgen/bumpalo)
 - Dodrio: [https://github.com/fitzgen/dodrio](https://github.com/fitzgen/dodrio)
 
-In other frontend frameworks for Rust, nearly every string is allocated using the global allocator. This means that strings in Rust do not benefit from the immutable string interning optimizations that JavaScript engines employ. By using a smaller, faster, more limited allocator, we can increase framework performance, bypassing even the naive WasmBindgen benchmarks for very quick renders.
+In other frontend frameworks for Rust, nearly every string is allocated using the global allocator. This means that strings in Rust do not benefit from the immutable string interning optimizations that JavaScript engines employ. By using a smaller, faster, more limited allocator, we can increase framework performance, bypassing even the naive wasm-bindgen benchmarks for very quick renders.
 
 It's important to note that VNodes are not `'static` - the VNode definition has a lifetime attached to it:
 

docs/src/gettingstarted/fromjs.md

@@ -18,7 +18,7 @@ let val = 10;    // rust
 const val = 10;  // js
 ```
 
-However, `const` in JS does not prohibit you from modify the value itself only disallowing assignment. In Rust, immutable **is immutable**. You _never_ have to work about accidentally mutating data; mutating immutable data in Rust requires deliberate advanced datastructures that you won't find in your typical frontend code.
+However, `const` in JS does not prohibit you from modify the value itself only disallowing assignment. In Rust, immutable **is immutable**. You _never_ have to work about accidentally mutating data; mutating immutable data in Rust requires deliberate advanced data structures that you won't find in your typical frontend code.
 
 ## How do strings work?
 

docs/src/hello_world.md

@@ -78,7 +78,7 @@ If you plan to develop extensions for the `Dioxus` ecosystem, please use the `di
 Now, let's edit our `main.rs` file:
 
 ```rust
-use diouxs::prelude::*;
+use dioxus::prelude::*;
 
 
 fn main() {
@@ -97,7 +97,7 @@ Let's dissect our example a bit.
 This bit of code imports everything from the the `prelude` module. This brings into scope the right traits, types, and macros needed for working with Dioxus.
 
 ```rust
-use diouxs::prelude::*;
+use dioxus::prelude::*;
 ```
 
 This initialization code launches a Tokio runtime on a helper thread - where your code will run, and then the WebView on the main-thread. Due to platform requirements, the main thread is blocked by this call.
@@ -124,7 +124,7 @@ The closure `FC<()>` syntax is identical to the function syntax, but with lifeti
 fn App<'a>(cx: Context<'a>, props: &'a ()) -> DomTree<'a> {
     cx.render(rsx! {
         div { "Hello, world!" }
-    })    
+    })
 }
 ```
 

docs/src/platforms/00-index.md

@@ -2,14 +2,14 @@
 
 ## Running Examples
 
-We use the dedicated `dioxus-cli` to build and test dioxus web-apps. This can run examples, tests, build web workers, launch development servers, bundle, and more. It's general purpose, but currently very tailored to Dioxus for liveview and bundling. If you've not used it before, `cargo install --path pacakages/dioxus-cli` will get it installed. This CLI tool should feel like using `cargo` but with 1st party support for assets, bundling, and other important dioxus-specific features.
+We use the dedicated `dioxus-cli` to build and test dioxus web-apps. This can run examples, tests, build web workers, launch development servers, bundle, and more. It's general purpose, but currently very tailored to Dioxus for liveview and bundling. If you've not used it before, `cargo install --path packages/dioxus-cli` will get it installed. This CLI tool should feel like using `cargo` but with 1st party support for assets, bundling, and other important dioxus-specific features.
 
 Alternatively, `trunk` works but can't run examples.
 
 - tide_ssr: Handle an HTTP request and return an html body using the html! macro. `cargo run --example tide_ssr`
 - doc_generator: Use dioxus SSR to generate the website and docs. `cargo run --example doc_generator`
 - fc_macro: Use the functional component macro to build terse components. `cargo run --example fc_macro`
-- hello_web: Start a simple wasm app. Requires a web packer like dioxus-cli or trunk `cargo run --example hello`
+- hello_web: Start a simple Wasm app. Requires a web packer like dioxus-cli or trunk `cargo run --example hello`
 - router: `cargo run --example router`
 - tide_ssr: `cargo run --example tide_ssr`
 - webview: Use liveview to bridge into a webview context for a simple desktop application. `cargo run --example webview`

docs/src/platforms/02-wasm.md

@@ -1,3 +1,3 @@
-# The WASM Guide
+# The Wasm Guide
 
-This guide will help you build your first app that leverages WASM in the browser to display the user interface.
+This guide will help you build your first app that leverages Wasm in the browser to display the user interface.

docs/src/platforms/05-liveview.md

@@ -12,7 +12,7 @@ fn live_component(cx: &Context<()>) -> DomTree {
         #[cfg(target_arch = "wasm32")]
         || html! { <div> {"Loading data from server..."} </div> },
 
-        // Renderered on the server
+        // Rendered on the server
         #[cfg(not(target_arch = "wasm32"))]
         || html! { <div> {"Server Data Loaded!"} </div> },
     )