From 30d255c5a6f4aa11bf08f2c15628ac6d333a4abb Mon Sep 17 00:00:00 2001
From: Paulus Schoutsen <paulus@paulusschoutsen.nl>
Date: Sun, 12 Jul 2015 23:23:06 -0700
Subject: [PATCH] README: name ES2015 consistent

---
 README.md | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/README.md b/README.md
index cea95a24af..ff56929348 100644
--- a/README.md
+++ b/README.md
@@ -23,7 +23,7 @@ One of the big advantages of webcomponents is that you can ship all your HTML re
 
 Before the release of Polymer 0.8, you would define all parts of your webcomponent inside a `<polymer-element>`. With the introduction of Polymer 0.8 the structure of a webcomponent has been split up into a `<dom-module>` for the CSS and HTML template and a `<script>` calling the `Polymer` object to register your element.
 
-The JavaScript ecosystem is evolving at a rapid pace and most projects have been embracing the next generation of JavaScript, EcmaScript 2015. Home Assistant did too and our [JavaScript backend](https://github.com/balloob/home-assistant-js) has been written in ES2015 for a while now. To get our webcomponents to interface with the backend, we would expose objects on the window object. This lead to pollution of the global namespace and messy component code.
+The JavaScript ecosystem is evolving at a rapid pace and most projects have been embracing the next generation of JavaScript, ES2015. Home Assistant did too and our [JavaScript backend](https://github.com/balloob/home-assistant-js) has been written in ES2015 for a while now. To get our webcomponents to interface with the backend, we would expose objects on the window object. This lead to pollution of the global namespace and messy component code.
 
 For Polymer, it does not matter if the file that registered the webcomponent is the same file that embeds the webcomponents CSS and HTML template. We used this to our advantage and created a JavaScript module for each webcomponent. Just like the HTML-based webcomponents, it will import the webcomponents it depends on. We now have one tree of HTML webcomponents that include all required HTML-webcomponents and a tree of JavaScript webcomponents that include all required JavaScript webcomponents. The downside of this approach is that we express each relationship between webcomponents twice, but for a good reason: we are now able to use all the popular JavaScript tools with Polymer!
 
@@ -31,7 +31,7 @@ For Polymer, it does not matter if the file that registered the webcomponent is
 
 ## Building the app
 
-The Polymer team has developed [Vulcanize](https://github.com/polymer/vulcanize) to help you prepare your webcomponents app. It takes an HTML file and recursively embeds referenced HTML, JavaScript and CSS files. There are similar approaches available for JavaScript that will resolve all referenced JavaScript modules and output a single file. For Home Assistant we have chosen to use WebPack. Babel is a plugin for WebPack to allow it to translate EcmaScript 2015 syntax into JS5 syntax.
+The Polymer team has developed [Vulcanize](https://github.com/polymer/vulcanize) to help you prepare your webcomponents app. It takes an HTML file and recursively embeds referenced HTML, JavaScript and CSS files. There are similar approaches available for JavaScript that will resolve all referenced JavaScript modules and output a single file. For Home Assistant we have chosen to use WebPack. Babel is a plugin for WebPack to allow it to translate ES2015 syntax into JS5 syntax.
 
 Instead of having each webcomponent reference its own JavaScript file, we now have the root webcomponent of the web app refer to the compiled JavaScript after all HTML templates have loaded. The final vulcanized output of our app will contain all the CSS and HTML templates first, and then all the JavaScript.