update READMEs and tags for the 0.3 release

packages/core/README.md

@@ -13,7 +13,7 @@ dioxus-core is a fast and featureful VirtualDom implementation written in and fo
 - Error boundaries through the `anyhow` crate
 - Customizable memoization
 
-If just starting out, check out the Guides first.
+If you are just starting, check out the Guides first.
 
 # General Theory
 
@@ -21,7 +21,7 @@ The dioxus-core `VirtualDom` object is built around the concept of a `Template`.
 
 Each component in the VirtualDom works as a dedicated render loop where re-renders are triggered by events external to the VirtualDom, or from the components themselves.
 
-When each component re-renders, it must return an `Element`. In Dioxus, the `Element` type is an alias for `Result<VNode>`. Between two renders, Dioxus compares the inner `VNode` object, and calculates the differences of the dynamic portions of each internal `Template`. If any attributes or elements are different between the old layout and new layout, Dioxus will write modifications to the `Mutations` object.
+When each component re-renders, it must return an `Element`. In Dioxus, the `Element` type is an alias for `Result<VNode>`. Between two renders, Dioxus compares the inner `VNode` object and calculates the differences between the dynamic portions of each internal `Template`. If any attributes or elements are different between the old layout and the new layout, Dioxus will write modifications to the `Mutations` object.
 
 Dioxus expects the target renderer to save its nodes in a list. Each element is given a numerical ID which can be used to directly index into that list for O(1) lookups.
 
@@ -63,7 +63,7 @@ dom.wait_for_work().await;
 dom.render_with_deadline(tokio::time::sleep(Duration::from_millis(16)));
 ```
 
-If an event occurs from outside the virtualdom while waiting for work, then we can cancel the wait using a `select!` block and inject the event.
+If an event occurs from outside the VirtualDom while waiting for work, then we can cancel the wait using a `select!` block and inject the event.
 
 ```rust, ignore
 loop {
@@ -88,18 +88,18 @@ Dioxus-core builds off the many frameworks that came before it. Notably, Dioxus
 - React: hooks, concurrency, suspense
 - Dodrio: bump allocation, double buffering, and some diffing architecture
 
-Dioxus-core leverages some really cool techniques and hits a very high level of parity with mature frameworks. However, Dioxus also brings some new unique features:
+Dioxus-core hits a very high level of parity with mature frameworks. However, Dioxus also brings some new unique features:
 
 - managed lifetimes for borrowed data
 - placeholder approach for suspended vnodes
 - fiber/interruptible diffing algorithm
-- custom memory allocator for vnodes and all text content
+- custom memory allocator for VNodes and all text content
 - support for fragments w/ lazy normalization
 - slab allocator for scopes
-- mirrored-slab approach for remote vdoms
+- mirrored-slab approach for remote VirtualDoms
 - dedicated subtrees for rendering into separate contexts from the same app
 
-There's certainly more to the story, but these optimizations make Dioxus memory use and allocation count extremely minimal. For an average application, it is possible that zero allocations will need to be performed once the app has been loaded. Only when new components are added to the dom will allocations occur. For a given component, the space of old VNodes is dynamically recycled as new nodes are added. Additionally, Dioxus tracks the average memory footprint of previous components to estimate how much memory allocate for future components.
+There's certainly more to the story, but these optimizations make Dioxus memory use and allocation count extremely minimal. For an average application, no allocations may be needed once the app has been loaded. Only when new components are added to the dom will allocations occur. For a given component, the space of old VNodes is dynamically recycled as new nodes are added. Additionally, Dioxus tracks the average memory footprint of previous components to estimate how much memory allocate for future components.
 
 All in all, Dioxus treats memory as a valuable resource. Combined with the memory-efficient footprint of Wasm compilation, Dioxus apps can scale to thousands of components and still stay snappy.
 
@@ -112,5 +112,5 @@ The final implementation of Dioxus must:
 - Be concurrent. Components should be able to pause rendering to let the screen paint the next frame.
 - Be disconnected from a specific renderer (no WebSys dependency in the core crate).
 - Support server-side-rendering (SSR). VNodes should render to a string that can be served via a web server.
-- Be "live". Components should be able to be both server rendered and client rendered without needing frontend APIs.
-- Be modular. Components and hooks should be work anywhere without worrying about target platform.
+- Be "live". Components should be able to be both server-rendered and client rendered without needing frontend APIs.
+- Be modular. Components and hooks should work anywhere without worrying about the target platform.