README.md

@@ -27,11 +27,11 @@ The ultimate state manager for any kinds of applications.
 
 ### Comparison
 
-**Redux**: Reatom was heavily inspired by Redux and does share many design principles with it. But it has many flaws that are hard or impossible to fix. Absence of action batching, non-atomic selectors and linear state update complexity, to name a few. Reatom solves all of them, implements much more features and [reduces the amount of boilerplate code](https://github.com/artalar/RTK-entities-basic-example/pull/1/files#diff-43162f68100a9b5eb2e58684c7b9a5dc7b004ba28fd8a4eb6461402ec3a3a6c6) a lot.
+**Redux**: Reatom was heavily inspired by Redux and does share many design principles with it. But it has many flaws that are hard or impossible to fix. Absence of action batching, non-atomic selectors and `O(n)` state update complexity, to name a few. Reatom solves all of them, implements much more features and [reduces the amount of boilerplate code](https://github.com/artalar/RTK-entities-basic-example/pull/1/files#diff-43162f68100a9b5eb2e58684c7b9a5dc7b004ba28fd8a4eb6461402ec3a3a6c6) a lot.
 
-**MobX**: MobX bundle size is too huge to use it in small embedded widgets, it uses getters/Proxies for change detections and has mutable nature, which eventually leads to confusing debugging sessions. [It has no atomicity as well](https://github.com/artalar/state-management-specification/blob/master/src/index.test.js#L60).
+**MobX**: MobX bundle size is too big, making it a poor choice for small embedded widgets. It also tracks dependencies through getters or Proxies, which eventually leads to confusing debugging sessions. [There is no atomicity as well](https://github.com/artalar/state-management-specification/blob/master/src/index.test.js#L60).
 
-**Effector:** Effector encourages the description of processes through custom operators like `sample`, making the code really confusing and unaccessible for those unfamiliar with the "DSL". It also lacks the laziness of reactive computations, automatic dependency tracking, and is less performant compared to Reatom.
+**Effector:** Effector encourages the description of procedures through sophisticated primitives like `sample`, making the code really confusing and unaccessible for those unfamiliar with the "DSL". It also lacks the laziness of reactive computations, automatic dependency tracking, and is less performant compared to Reatom.
 
 In the modern front-end tooling landscape, there are lots of other solutions including **zustand**, **jotai**, **nanostores**, **xstate** [and many others](https://gist.github.com/artalar/e5e8a7274dfdfbe9d36c9e5ec22fc650), but we find them either less efficient than Reatom, or lacking in features.
 
@@ -43,7 +43,7 @@ Our team currently consists of 4 people: [@artalar](https://github.com/artalar)
 
 ### What about build targets and browser support?
 
-All packages are shipped transpiled [Browserslist's "last 1 year" query](https://browsersl.ist/#q=last+1+year). If you need to support older environments, you should handle transpilation by yourself.
+Transpilation target of all packages is [Browserslist's "last 1 year" query](https://browsersl.ist/#q=last+1+year). If you need to support older environments, you should transpile applications by yourself.
 
 Packages include CommonJS and ESM entrypoints. See `package.json` files for more details.