editorial

archive/v0.1.14/compiling-templates.html

@@ -47,7 +47,7 @@
 							<h2 id="compiling-templates">Compiling Templates</h2>
 <p>You can optionally pre-compile templates that use <code>m()</code> by running the <a href="tools/template-compiler.sjs"><code>template-compiler.sjs</code></a> macro with <a href="https://github.com/mozilla/sweet.js">Sweet.js</a>. This step isn&#39;t required in order to use Mithril, but it&#39;s an easy way to squeeze a little bit more performance out of an application, without the need for code changes.</p>
 <p>Compiling a template transforms the nested function calls of a template into a raw virtual DOM tree (which is merely a collection of native Javascript objects that is ready to be rendered via <a href="mithril.render.html"><code>m.render</code></a>). This means that compiled templates don&#39;t need to parse the string in <code>m(&quot;div#foo&quot;)</code> and they don&#39;t incur the cost of the function call.</p>
-<p>It&#39;s worth mentioning that Mithril has built-in mechanisms elsewhere that take care of real bottlenecks like browser repaint management and DOM updating. This optional compilation tool is merely &quot;icing on the cake&quot; that speeds up the javascript run-time of templates (which is already fast even without compilation - see performance test in the homepage).</p>
+<p>It&#39;s worth mentioning that Mithril has built-in mechanisms elsewhere that take care of real bottlenecks like browser repaint management and DOM updating. This optional compilation tool is merely &quot;icing on the cake&quot; that speeds up the Javascript run-time of templates (which is already fast, even without compilation - see the <a href="http://lhorie.github.io/mithril/index.html#performance">performance section on the homepage</a>).</p>
 <p>The macro takes regular Mithril templates like the one below:</p>
 <pre><code class="lang-javascript">var view = function() {
     return m(&quot;a&quot;, {href: &quot;http://google.com&quot;}, &quot;test&quot;);