finish guiding principles

docs/guide/src/en/contributing/guiding_principles.md

@@ -12,21 +12,19 @@ Dioxus is designed to be cross-platform by default. This means that it should be
 
 As Dioxus applications grow, they should remain relatively performant without the need for manual optimizations. There will be cases where manual optimizations are needed, but Dioxus should try to make these cases as rare as possible.
 
-The is one of the benefits of the core architecture of Dioxus. It is based on a Virtual Dom which performs diffing which should prevent unnecessary re-renders even when large parts of the component tree are rerun. On top of this, Dioxus groups static parts of the RSX tree together to skip diffing them entirely.
+One of the benefits of the core architecture of Dioxus is that it delivers reasonable performance even when components are rerendered often. It is based on a Virtual Dom which performs diffing which should prevent unnecessary re-renders even when large parts of the component tree are rerun. On top of this, Dioxus groups static parts of the RSX tree together to skip diffing them entirely.
 
 ## Type Safety
 
 As teams grow, the Type safety of Rust is a huge advantage. Dioxus should leverage this advantage to make it easy to build applications with large teams.
 
-To take full advantage of Rust's type system, Dioxus should try to avoid exposing public `Any` types and stringly typed APIs where possible.
+To take full advantage of Rust's type system, Dioxus should try to avoid exposing public `Any` types and string-ly typed APIs where possible.
 
 ## Developer Experience
 
 Dioxus should be easy to learn and ergonomic to use.
 
-- The API of Dioxus should try to remain close to React's API where possible
-
-  - This makes it easier for people to learn Dioxus if they already know React
+- The API of Dioxus attempts to remain close to React's API where possible. This makes it easier for people to learn Dioxus if they already know React
 
 - We can avoid the tradeoff between simplicity and flexibility by providing multiple layers of API: One for the very common use case, one for low-level control
 
@@ -35,5 +33,5 @@ Dioxus should be easy to learn and ergonomic to use.
 
 - Documentation:
   - All public APIs should have rust documentation
-  - Examples should be provided for all public features. These examples both serve as documentation and are checked by CI to ensure that they continue to compile
+  - Examples should be provided for all public features. These examples both serve as documentation and testing. They are checked by CI to ensure that they continue to compile
   - The most common workflows should be documented in the guide

docs/guide/src/en/contributing/index.md

@@ -41,7 +41,7 @@ cargo check --workspace --examples --tests
 cargo clippy --workspace --examples --tests -- -D warnings
 ```
 
-- Crates that use unsafe are checked for undefined behavior with [MIRI](https://github.com/rust-lang/miri). MIRI can be helpful to debug what unsafe code is causing issues. Only code that does not interact with system calls can be checked with MIRI. Currently this is used for the two MIRI tests in `dioxus-core` and `dioxus-native-core`.
+- Crates that use unsafe are checked for undefined behavior with [MIRI](https://github.com/rust-lang/miri). MIRI can be helpful to debug what unsafe code is causing issues. Only code that does not interact with system calls can be checked with MIRI. Currently, this is used for the two MIRI tests in `dioxus-core` and `dioxus-native-core`.
 
 ```sh
 cargo miri test --package dioxus-core --test miri_stress

docs/guide/src/en/contributing/walkthrough_readme.md

@@ -123,4 +123,4 @@ Here is what the diffing algorithm looks like for the root scope (red lines indi
 
 ## Conclusion
 
-This is only a brief overview of how the Virtual Dom works. There are several aspects not yet covered in this guide including how the Virtual Dom handles async-components, keyed diffing, and how it uses bump allocation to efficiently allocate VNodes. If need more information about the Virtual Dom, you can read the code of the [core](https://github.com/DioxusLabs/dioxus/tree/master/packages/core) crate or reach out to us on [Discord](https://discord.gg/XgGxMSkvUM).
+This is only a brief overview of how the Virtual Dom works. There are several aspects not yet covered in this guide including how the Virtual Dom handles async-components, keyed diffing, and how it uses [bump allocation](https://github.com/fitzgen/bumpalo) to efficiently allocate VNodes. If need more information about the Virtual Dom, you can read the code of the [core](https://github.com/DioxusLabs/dioxus/tree/master/packages/core) crate or reach out to us on [Discord](https://discord.gg/XgGxMSkvUM).