add Deborah's review

Author: filipesilva

public/docs/ts/latest/cookbook/production-deploy.jade

@@ -9,7 +9,7 @@ a#toc
   * [Overview](#overview)
   * [Simplest deploy possible](#simplest-deploy-possible)
   * [Minimizing your payload](#minimizing-your-payload)
-    * [Less files](#less-files)
+    * [Fewer files](#fewer-files)
     * [Smaller files](#smaller-files)
     * [Template compilation](#template-compilation)
   * [Angular configuration](#angular-configuration)
@@ -28,7 +28,7 @@ a#overview
   After creating your brand new Angular app you'll want to put it online for the world to see.
 
   Your development setup is optimized for build speed and rapid iteration, but when
-  deployment to production you'll want to optimize for loading speed and payload size.
+  deploying to production you'll want to optimize for loading speed and payload size.
 
   In this chapter you'll see how to deploy your app right now, techniques to reduce your 
   payload size, plus Angular and server configuration.
@@ -41,7 +41,7 @@ a#overview
   It is already working locally after all, so it should work live.
 
   1. Copy over your local project folder to your server.
-  2. In your server, edit `index.html` to have the right `<base href="/">` tag. If you are
+  2. On your server, edit `index.html` to have the correct `<base href="/">` tag. If you are
   using a subfolder (e.g. `www.mysite.com/myapp/`) it should be `/myapp/` otherwise leave it as `/`.
   [More on this later](#angular-configuration).
   3. Configure your server to redirect requests for missing files to `index.html` instead.
@@ -50,6 +50,15 @@ a#overview
   And this is all you need to publish your app!
 
   It's not a very good production deploy though. 
+
+  For one, it has a lot of files that aren't even used when serving your site to users since it has
+  all the development only packages. 
+  You could cut down the number of files by doing a production install (`npm install --production`),
+  but only *after* compiling your Typescript files.
+
+  It also has a lot of small files. Each of those is going to take a whole round trip to get
+  delivered to the browser, so it's not going to be that fast to load.
+
   There's more you can do to make our site fast for users.
 
 .l-main-section
@@ -61,28 +70,27 @@ a#overview
   There are several techniques for achieving a smaller payload for your app:
 
   - Bundling: concatenating several modules into a single file (bundle). 
-  - Inlining: add html and css as strings inside components.
+  - Inlining: adding html and css as strings inside components.
   - Minification: removing all unnecessary whitespace and optional tokens.
   - Uglification: rewriting code to use shorter variable/function names.
-  - Dead Code Elimination: removing code/variables that will never used.
+  - Dead Code Elimination: removing code/variables that are not used.
   - Tree shaking: removing unused module exports.
   - Ahead-of-Time (AoT) Compilation: pre-compiling Angular templates.
 
   Each of these do different things overall, but they all work together and their effects
   compound on each other.
 
-  ### Less files
-  Bundling and inlining reduce your app's load time smaller by serving less files and thus
-  less round trips. 
+  ### Fewer files
+  Bundling and inlining reduce your app's load time by serving fewer files and thus
+  fewer round trips. 
   For small files, the overwhelming majority of time it takes to get it is not spent downloading,
   but rather communicating with the server and coordinating the transfer. 
   You can read more about resource timings in the 
   [Chrome DevTools Network Performance page](https://developers.google.com/web/tools/chrome-devtools/network-performance/understanding-resource-timing)   
 
   ### Smaller files
   Minification, Uglification and Dead Code Elimination all contribute to reduce the total size
-  of your code to the smallest possible amount of bytes, which will result in a smaller
-  transfer time.
+  of your code to the smallest possible amount of bytes, which results in a smaller transfer time.
 
   Tree shaking also reduces the total size but does so by removing whole exports from modules.
   It was popularized by [Rollup](http://rollupjs.org/) and you can read more about it in 
@@ -91,15 +99,19 @@ a#overview
   ### Template compilation
   AoT compilation reduces render time by pre-compiling Angular templates that otherwise would be
   compiled at runtime. 
-  It also reduces payload size since the Angular compiler itself is no longer needed, and nor are
-  directives that are never used in templates. This allows Tree-Shaking to further remove exports.
+  It also reduces payload size since the compiled app does not depend on the Angular compiler,
+  nor on declared directives that are never used in templates. 
+  This allows Tree-Shaking to further remove exports.
 
   You can read more about AoT Compilation in our [dedicated cookbook chapter](aot-compiler.html),
-  where you'll also find instructions on how to use Rollup to do all the optimizations shown here.
+  where you'll also find instructions on how to use Rollup to perform all the optimizations shown here.
+  
   Another great choice is [Webpack 2](https://webpack.js.org/) together with the 
   [Angular Ahead-of-Time Webpack Plugin](https://github.com/angular/angular-cli/tree/master/packages/%40ngtools/webpack).
+  Webpack is an easy to customize, high performance bundler, and the official AoT Webpack plugin 
+  makes it easier than ever to use AoT and lazy-loading.
 
-  You can use any build system you like however, the only important thing is to optimize your build.
+  You can use any build system you like; the only important thing is to optimize your build.
   Whatever build system you choose make sure to automate it so that you can make a production
   build in a single step.
 
@@ -112,26 +124,26 @@ a#overview
   There is an important configuration item in the Angular Router that needs to be adjusted for 
   different environments: 
   [the `base` tags `href` property](https://angular.io/docs/ts/latest/guide/router.html#!#base-href).
-  This property tells the router how what the app root URL is so that the router can match routes.
+  This property tells the router what the app root URL is so that the router can match routes.
 
   On your development server, your app is most likely served at the root: `http://localhost:3000/`.
   Here you use `<base href="/">`, since `/` is the root of your app.
 
-  But depending on the server setup that you use, it can also be served in a subfolder like
+  But depending on the server setup that you use, the app can be served from a subfolder like
   `http://localhost:3000/myapp/` or `http://www.mysite.com/myapp/`, where `/myapp/` is the subfolder.
   In this case you should use `<base href="/myapp/">`, since `/myapp/` is the root of your app and 
   not `/`.
 
-  When your `base` tag is misconfigured your browser console will show several console, from
-  missing files on wrong paths to router errors about missing routes.
+  When your `base` tag is misconfigured your browser console will show several errors in the console,
+  from missing files on wrong paths to router errors about missing routes.
 
   ### enableProdMode
 
   You can also configure your Angular app to start on 
   [production mode](https://angular.io/docs/ts/latest/api/core/index/enableProdMode-function.html), 
   which will make it faster by disabling development specific checks.
 
-  Angular apps default do development move, as you can see by the following message on the browser
+  Angular apps default to development mode, as you can see by the following message on the browser
   console:
 
 code-example(format="nocode").
@@ -159,13 +171,13 @@ code-example().
   it to be imported directly instead of being imported via the Router. 
 
   It's important to note that your bundling configuration must take lazy loading into consideration.
-  Since there is no ES6 import for that module, normal bundlers don't know that they should also
-  separately bundle to module listed in the router config.
-  You have to manually create additional bundles for each lazy loaded route.
+  Since there is no ES6 import for that module, bundlers don't know that they should also
+  separately bundle modules listed in the router config.
+  You have to manually create additional bundles for each lazy loaded Angular Module.
 
   If you are using Webpack, the 
   [Angular Ahead-of-Time Webpack Plugin](https://github.com/angular/angular-cli/tree/master/packages/%40ngtools/webpack)
-  will automatically recognize lazy routes.
+  will automatically recognize lazy loaded NgModules.
 
 
 .l-main-section
@@ -174,12 +186,11 @@ code-example().
 
   Angular apps are 
   [Single Page Applications](https://en.wikipedia.org/wiki/Single-page_application) (SPAs),
-  which makes them the perfect candidates to be served by simple static HTML server.
+  which makes them the perfect candidates to be served by a simple static HTML server.
   No preprocessors required!
 
   There is only one configuration item required of a server hosting an Angular app:
-  it needs to be able to fallback to `index.html` when being asked for a file the server
-  does not have.
+  it needs to fallback to `index.html` when being asked for a file the server does not have.
 
   ### Why fallback to `index.html`?
 
@@ -196,8 +207,8 @@ code-example().
   Then you click the link for `admin/` and the your address bar will change 
   to `www.my-awesome-app.com/admin/` and you're taken to the admin page.
 
-  But if you don't have fallback to `index.html` configured and refresh the page, you will
-  get a `404 - Not Found` page!
+  If you then refresh the page, you will get a `404 - Not Found` page unless you have the fallback 
+  to `index.html` configured!
   Which doesn't make a lot of sense since you just saw that the admin page was there.
 
   When you first clicked the link to `admin/` there was no server request for 
@@ -210,17 +221,17 @@ code-example().
 
   That is why the server needs to be configured to fallback to `index.html`.
   When a user asks the server for any route (that isn't a file), you want the server to *always*
-  return default page that boots up Angular.
-  After Angular is loaded and bootstrapped the router will look at the address bar and take
-  the user where he needs to go.
+  return the default page that boots up Angular.
+  After Angular is loaded and bootstrapped the router looks at the address bar and takes
+  the user to the appropriate route.
 
   ### Fallback configuration examples
 
   Different servers are configured in different ways so there is no single configuration that
   works everywhere.
 
   Following are configurations for some of the most popular servers. 
-  The list is by no means exhausting, but should provide you with a good starting point.
+  The list is by no means exhaustive, but should provide you with a good starting point.
 
   #### Development servers
 
@@ -310,7 +321,7 @@ code-example(format=".").
   These are not due to the SPA application itself but rather due to the configuration of APIs with
   which the SPA communicates.
 
-  These APIs need to send the `Access-Control-Allow-Origin: *` header on their HTTP responses,
-  otherwise the SPA will not be able to call them.
+  If these APIs are on different domains, they need to send the `Access-Control-Allow-Origin: *`
+  header on their HTTP responses otherwise the SPA will not be able to call them.
   You can read more about how to enable CORS for specific servers in 
   [enable-cors.org](http://enable-cors.org/server.html)