Fixed wording in /v8-tips.

docs/v8-tips/float-number.md

@@ -2,13 +2,16 @@
 
 V8 uses tagging to represent values efficiently when types can change.
 
-V8 infers from the values that you use what number type you are dealing with. Once V8 has made this inference, it uses tagging to represent values efficiently, because these types can change dynamically.
+V8 infers from the values that you use which number type you are dealing with.
+Once V8 has made this inference, it uses tagging to represent values efficiently,
+because these types can change dynamically.
 
-However, there is sometimes a cost to changing these type tags, so it's best to use number types consistently, and in general it is most optimal to use **31-bit signed integers** where appropriate.
+However, there is sometimes a cost to changing these type tags, so it's best to
+use number types consistently and in general it is most optimal to use **31-bit signed integers** where appropriate.
 
 ```js
 var i = 42  // this is a 31-bit signed integer (whole).
 var j = 4.2 // this is a double-precision floating point number (float).
 ```
 
-If you don't need the extra information, avoid it, they are expensive.
+If you don't need the extra information, avoid it! They are expensive.

docs/v8-tips/freeing-memory.md

@@ -3,11 +3,11 @@
 If you want to delete a property of an `Object`, you can set the property to `null`:
 
 ```js
-// Inefficent way (Bad)
+// Inefficient way (bad)
 var foo = { bar: 'hello world' }
 delete foo.bar
 
-// Efficent way (Good)
+// Efficient way (good)
 var foo = { bar: 'hello world' }
 foo.bar = null
 ```

docs/v8-tips/hidden-class.md

@@ -1,6 +1,7 @@
 # Hidden class
 
-JavaScript has limited compile-time type information: types can be changed at runtime, so it's natural to expect that it is expensive to reason about JS types at compile time.
+JavaScript has limited compile-time type information: types can be changed at
+runtime. This is why it is expensive to reason about JS types at compile time.
 
 ```js
 function Point (x, y) {

docs/v8-tips/inline-initialization.md

@@ -16,7 +16,7 @@ In this example, the individual assignments are performed one after the other, a
 
 <br>
 
-A more inmediate solution is to attach all the information in one call:
+A more immediate solution is to attach all the information in one call:
 
 ```js
 var array = [ 77, 88, 0.5, true ]
@@ -28,7 +28,7 @@ Now, the compiler knows the types of all of the elements in the literal, and the
 
 Imagine that you want to have an `Array` of elements but you can't build it in one call. You need to build it dynamically. How do you do it?
 
-An inmediate solution would be:
+An immediate solution would be:
 
 
 ```js
@@ -46,7 +46,7 @@ for (var i = 0; i < 10; i++) array[0] |= i  // Much better! 2x faster.
 
 In the first piece of code you are accessing an element that doesn't exist in the array, and in this case the specs says that it wants to return `undefined` that later is converted into `0`, so you need to do this extra effort simply to compare with `0`.
 
-Nowadays could be a good idea combine this with  [`Array.prototype.fill()`](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Array/fill). Following the example before:
+Nowadays it may be a good idea to combine this with  [`Array.prototype.fill()`](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Array/fill). Following the example before:
 
 ```js
 var array = Array(10).fill(0)

docs/v8-tips/monomorphic.md

@@ -13,4 +13,4 @@ add(1, 2)      // + in add is monomorphic
 add('a', 'b')  // + in add becomes polymorphic
 ```
 
-**Monomorphic** types are more predictable for the compiler and therefore easier for them to generate good code, so the compile prefer it over polymorphic types.
+**Monomorphic** types are more predictable for the compiler and therefore easier for them to generate good code, so the compiler prefers these over polymorphic types.

docs/v8-tips/sparse-arrays.md

@@ -1,6 +1,6 @@
 # Sparse Arrays
 
-Internally, the V8 engine can represent `Array`s following one of two approaches:
+Internally the V8 engine can represent `Array`s following one of two approaches:
 
 - **Fast Elements**: linear storage for compact keys sets.
 - **Dictionary Elements**: hash table storage (more expensive to access on runtime).
@@ -9,7 +9,7 @@ If you want V8 to represent your `Array` in the `Fast Elements` form, you need t
 
 - Use contiguous keys starting at `0`.
 - Don't pre-allocate large `Array` (e.g. *> 64K* elements) that you don't use.
-- Don't delete elements, specially in numeric `Array`'s.
+- Don't delete elements, specially in numeric `Array`s.
 - Don't load uninitialized or deleted elements.
 
 Another consideration: any name used as property name that is not a string is stringified via `.toString()`, so: