incorporate John's feedback

Author: filipesilva

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

@@ -25,20 +25,20 @@ a#overview
 :marked
   ## Overview
 
-  After creating your brand new Angular app you'll want to put it online for the world to see.
+  After creating your new Angular app you'll want to deploy it.
 
   Your development setup is optimized for build speed and rapid iteration, but when
   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 
+  In this chapter you'll see how to deploy your app, techniques to reduce your 
   payload size, plus Angular and server configuration.
 
 .l-main-section
 :marked
   ## Simplest deploy possible
 
   The simplest possible way to deploy your app is to use your development environment.
-  It is already working locally after all, so it should work live.
+  It is working locally, so it will work when published to a web server, too.
 
   1. Copy over your local project folder to your server.
   2. On your server, edit `index.html` to have the correct `<base href="/">` tag. If you are
@@ -47,27 +47,35 @@ a#overview
   3. Configure your server to redirect requests for missing files to `index.html` instead.
   [More on this later](#server-configuration).
 
-  And this is all you need to publish your app!
+  This is all you need to publish your app!
 
-  It's not a very good production deploy though. 
+  You've deployed your app, but we can do better for production to optimize the app! 
+  Let's learn how.
 
   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. 
+  A good example is TypeScript, which most Angular projects use as in `devDependencies`.
+  You want it to compile your files, but there's no need to have it on the production server
+  after that.
+
   You could cut down the number of files by doing a production install (`npm install --production`),
-  but only *after* compiling your Typescript files.
+  but only *after* compiling your TypeScript files.
+  A production install will only contain the packages in `dependencies`, which should be the ones
+  your project needs at runtime.
 
   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.
+  Plus, there's more you can do to make our site fast for users.
 
 .l-main-section
 :marked
   ## Minimizing your payload
 
   One of the easiest optimizations you can do is to reduce the code users have to download.
 
-  There are several techniques for achieving a smaller payload for your app:
+  There are several techniques for achieving a smaller payload for your app,
+  which will reduce the load time and improve the user experience:
 
   - Bundling: concatenating several modules into a single file (bundle). 
   - Inlining: adding html and css as strings inside components.
@@ -79,6 +87,8 @@ a#overview
 
   Each of these do different things overall, but they all work together and their effects
   compound on each other.
+  Let's take a moment to better understand what each of these mean, 
+  and the value that each of these bring.
 
   ### Fewer files
   Bundling and inlining reduce your app's load time by serving fewer files and thus
@@ -104,7 +114,7 @@ a#overview
   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 perform all the optimizations shown here.
+  where you'll also find instructions on how 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).
@@ -161,17 +171,17 @@ code-example().
 
   The Angular Router allows you to configure NgModules as being 
   [Lazy Loaded](https://angular.io/docs/ts/latest/guide/router.html#!#asynchronous-routing),
-  which means that particular NgModule (and all it's code) is not loaded on the very first load.
+  which means that particular NgModule (and all its code) is not loaded on the very first load.
   This allows your app to have a smaller initial load time by not loading modules until they
   are needed.
 
   A common mistake to make while lazy loading a module is to *also* have that module imported via
-  a ES6 import. 
+  an ES import. 
   If you do that, the module will never really be lazy loaded since the import statement will cause
   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, bundlers don't know that they should also
+  Since there is no ES 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.
 
@@ -187,7 +197,8 @@ 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 a simple static HTML server.
-  No preprocessors required!
+  There is no need to have a server-side language composing the pages because
+  Angular will do it on the client-side.
 
   There is only one configuration item required of a server hosting an Angular app:
   it needs to fallback to `index.html` when being asked for a file the server does not have.