more edits

Author: i8ramin

_drafts/wework-com-is-going-static.markdown

@@ -9,14 +9,14 @@ categories:   engineering
 
 ### What is this "static" business all about?
 
-Static site generators have become a hot topic in the past few years. There are [whole sites](https://www.staticgen.com/) dedicated to tracking and rating them. Don't take my word
+Over the past few years, static site generators have become a hot topic, so much so that [entire sites](https://www.staticgen.com/) have emerged dedicated to tracking and rating them. Don't take my word
 for it, check out this graph from [Google Trends for "static site generator"][2]:
 
 [![Google Trends - Static Site Generator][1]][2]
 [1]: http://res.cloudinary.com/wework/image/upload/f_auto/v1448735896/engineering/static-site-generator.png
 [2]: https://www.google.com/trends/explore#q=static%20site%20generator
 
-The idea is actually quite simple. Whereas on a traditional *dynamic* site, each page is processed and generated on the server per request (let's ignore caching strategies for the sake of argument), a static site is processed and generated just **once** on each deploy and all the server has to do is serve up the resulting generated HTML. Of course, this is an overly simplified explanation of how it all works, and this process doesn't work on all web sites, but it does work really well for marketing and informational sites like [wework.com](https://www.wework.com). This very blog you are reading is actually a statically generated site using [Jekyll](http://jekyllrb.com/) and hosted on [Github pages](https://pages.github.com/)!
+The idea is actually quite simple. Whereas on a traditional *dynamic* site, each page is processed and generated on the server per request (let's ignore caching strategies for the sake of argument), a static site is processed and generated just **once** on each deploy and all the server has to do is serve up the resulting generated HTML. Of course, this is an overly simplified explanation of how it all works, and this process doesn't work as well on all sites, but it does work really well for marketing and informational sites like [wework.com](https://www.wework.com). Not to mention that this very blog you are reading is actually a statically generated site using [Jekyll](http://jekyllrb.com/) and hosted on [Github pages](https://pages.github.com/)!
 
 If you consider the amount of information that changes on a daily, or even weekly basis on a site like wework.com, it is actually quite wasteful to have a server process each and every request that comes through. One of the main reasons we even have a server-side component for wework.com is to allow us to easily add, update and manage information on the site. We can still achieve this with a statically generated site by utilizing an API to serve up the data and take the load off of our application server for serving up the html pages themselves.
 
@@ -25,7 +25,7 @@ If you consider the amount of information that changes on a daily, or even weekl
 
 One key requirement for us when evaluating different static site generators was the ability to hit an API endpoint and dynamically generate static pages based on the data returned. A real-world example of this is when we add new locations and markets. With a traditional web-app setup (like a Ruby on Rails project), as soon as you add a new location or update one, the new content is up and live on your website. With a statically generated site, this is not the case. You will need to rebuild the entire site and generate new HTML. The good news is, for a site that doesn't have a ton of content, this static site generation is actually really fast. Like in the tens of seconds fast. A couple of minutes if you consider the entire proecss of minifying assets, building and deploying your site.
 
-We played with and evaluated quite a few options, like pure jekyll, yeoman, Middleman, etc. The one we decided to go with is a very well thought out static site generator called [**Roots**](http://roots.cx/), developed by the fine folks at the Brooklyn based agency, [Carrot Creative](https://carrot.is/). Besides the many nice features that Roots gives you right out of the box (folder structure, asset management and minifcation, great extension and plugin system, etc), they also have a really nifty extension called [**roots-records**](https://github.com/carrot/roots-records). Like most well built things, roots-records serves one purpose and does an amazing job at it. It allows you to hit ANY endpoint that returns a JSON collection and use that collection in your templates to iterate over or if you pass in a template, it will also generate individual static HTML pages for each item in the collection. For example, here is all we had to define in our `app.coffee` file to hit our API endpoint for our market/location:
+We played with and evaluated quite a few options, like pure Jekyll, Yeoman, Middleman, etc. The one we decided to go with is a very well thought out static site generator called [**Roots**](http://roots.cx/), developed by the fine folks at the Brooklyn based agency, [Carrot Creative](https://carrot.is/). Besides the many nice features that Roots gives you right out of the box (folder structure, asset management and minifcation, great extension and plugin system, etc), they also have a really nifty extension called [**roots-records**](https://github.com/carrot/roots-records). Like most well built things, roots-records serves one purpose and does an amazing job at it. It allows you to hit ANY endpoint that returns a JSON collection and use that collection in your templates to iterate over or if you pass in a template, it will also generate individual static HTML pages for each item in the collection. For example, here is all we had to define in our `app.coffee` file to hit our API endpoint for our market/location:
 
 ```coffeescript
 extensions: [