title: Why don't I just build the whole web app in Javascript and Javascript HTML Templates?
body: <p>I'm getting to the point on an app where I need to start caching things, and it got me thinking...</p>
  
  <ol>
  <li>In some parts of the app, I render table rows (jqGrid, slickgrid, etc.) or fancy div rows (like in the New Twitter) by grabbing pure JSON and running it through something like Mustache, jquery.tmpl, etc.</li>
  <li>In other parts of the app, I just render the info in pure HTML (server-side HAML templates), and if there's searching/paginating, I just go to a new URL and load a new HTML page.</li>
  </ol>
  
  <p>Now the problem is in caching and maintainability.</p>
  
  <p>On one hand I'm thinking, if everything was built using Javascript HTML Templates, then my app would serve just an HTML layout/shell, and a bunch of JSON.  If you look at the Facebook and Twitter HTML source, that's basically what they're doing (95% json/javascript, 5% html).  This would make it so my app only needed to cache JSON (pages, actions, and/or records).  Which means you'd hit the cache no matter if you were some remote api developer accessing a JSON api, or the strait web app.  That is, I don't need 2 caches, one for the JSON, one for the HTML.  That seems like it'd cut my cache store down in half, and streamline things a little bit.</p>
  
  <p>On the other hand, I'm thinking, from what I've seen/experienced, generating static HTML server-side, and caching that, seems to be much better performance wise cross-browser; you get the graphics instantly and don't have to wait that split-second for javascript to render it.  StackOverflow seems to do everything in plain HTML, so does Google, and you can tell... everything appears at once.  Notice how though on <a href="http://twitter.com" rel="noreferrer">twitter.com</a>, the page is blank for .5-1 seconds, and the page chunks in: the javascript has to render the json.  The downside with this is that, for anything dynamic (like endless scrolling, or grids), I'd have to create javascript templates anyway... so now I have server-side HAML templates, client-side javascript templates, and a lot more to cache.</p>
  
  <p>My question is, is there any consensus on how to approach this?  What are the benefits and drawbacks from your experience of mixing the two versus going 100% with one over the other?</p>
  
  <p>Update:</p>
  
  <p>Some reasons that factor into why I haven't yet made the decision to go with 100% javascript templating are:</p>
  
  <ul>
  <li><strong>Performance</strong>.  Haven't formally tested, but from what I've seen, raw html renders faster and more fluidly than javascript-generated html cross-browser.  Plus, I'm not sure how mobile devices handle dynamic html performance-wise.</li>
  <li><strong>Testing</strong>.  I have a lot of integration tests that work well with static HTML, so switching to javascript-only would require 1) more focused pure-javascript testing (<a href="https://github.com/pivotal/jasmine" rel="noreferrer">jasmine</a>), and 2) integrating javascript into capybara integration tests.  This is just a matter of time and work, but it's probably significant.</li>
  <li><strong>Maintenance</strong>.  Getting rid of HAML.  I love HAML, it's so easy to write, it prints pretty HTML...  It makes code clean, it makes maintenance easy.  Going with javascript, there's nothing as concise.</li>
  <li><strong>SEO</strong>.  I know google handles the ajax <code>/#!/path</code>, but haven't grasped how this will affect other search engines and how older browsers handle it.  Seems like it'd require a significant setup.</li>
  </ul>