<br><br><div class="gmail_quote">On Wed, Feb 22, 2012 at 11:16 PM, OvermindDL1 <span dir="ltr"><<a href="mailto:overminddl1@gmail.com">overminddl1@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

/* snip */<br>
<br>
I do not really have to 'remember' anything on the server side, I just<br>
send what is requested.  Only thing that I really have to remember on<br>
the browser side is the order and entries and such that the json has<br>
when it is sent back.  I just make heavy use of jquery.  All my code<br>
on both the server and the client is *very* simple (practically<br>
stupid-simple for all the 'ooo's and 'ahh's it is getting), very<br>
self-contained, and very easy to modify, as well as it would be easy<br>
to modify the html/css/js/whatever by someone other than me (of which<br>
I have already done by having someone add in jquery ui themes, which<br>
added like 6 lines to each support html file).  Plus I could always<br>
write something to access the servers API directly if I wanted.<br>
<br>
But really, why templates?  Just let the server do what it does best,<br>
server dumb files and processing of data to give to those dumb files.<br>
Leave the dumb files to process the data as they wish, there is so<br>
much javascript code and so many pure javascript html templating<br>
languages out there, just let the UI people work their magic on that,<br>
they know that stuff, and they know how to parse json with a jquery<br>
call, that is all they need.  There is even a jquery for mobile<br>
devices.  If you really want to make javascript-less pages, well, then<br>
fall back to the old stuff that no one really uses anymore.  ;)<br></blockquote><div><br></div><div>You may work with government agencies or just have public websites where regulation forces you to support things like text readers and other tools for disabled users. These can't easily work with JS-only methods. This is also the case of some phone browsers that just won't support Javascript, or won't support it well. Knowing your public is also rather important. For Learn You Some Erlang, you'd be surprised how many comments about 'please add syntax highlighting' I had before I added a <noscript> tag telling users syntax highlight was done with JS. Some tech crowds seem quite fond of noscript and other JS blockers. Different audiences have different requirements.</div>

<div><br></div><div>Another reason might be a question of speed and/or efficiency. The things that often cost the most for a client making a call to a server aren't the processing time on the server, but generally the connection itself (and the roundtrips), downloading visual assets, reading and running Javascript. As such, it is entirely logical for some sites to prefer to have the text sent as part of a template in a single trip that requires no additional logic client-side than have it done in many calls then rendered afterwards. This also reduces the costs required for serving data in most cases and reduces the bandwidth; everyone wins.</div>

<div><br></div><div>Then you might have other things, like translations. Many templating systems allow you to have different templates or sub-templates that can be configured and have filters (custom or not) to help with different page translations, a thing that as far as I know, isn't very well supported in Javascript tools (or if it is, it is a recent development).</div>

<div><br></div><div>You could do it for ideological purity: HTML is for markup, CSS is for styling, Javascript is only for more interactive parts and shouldn't be about the structuring of the text or the styling itself. This kind of thing is less and less common nowadays I think, though, and people tend not to give a crap about that one as much anymore.</div>

<div><br></div><div>Things are also simpler to test using templates: you can just remove (or later add in) the place-holders and variables and there is no need for you to have a server or data coming from a mock server to be able to work on your files. It is likely simpler to develop the front-end and the back-end in parallel working with templates than requiring the backend guys to set-up fake data sending (or yet, real data sending) to work with a javascript set-up. Although it is in both cases possible to build the whole HTML and then fit them into the final system, there is less change required to do it from HTML -> Template than HTML -> JSON-pulling-thing-that-pushes-it-back-inside-the-DOM.</div>

<div><br></div><div>Lastly, there is no need to encrypt, filter, format, or even transmit what could be sensitive information that might be used to decide how to display content. This is often dependent to how clever you want your templates to be (very dumb vs. more powerful ones), but it's easy to think of a use case for this. Maybe you profile information coming from the database contains the hash and salts of passwords (or if you're better geared up, your <a href="https://github.com/ferd/erlpass">bcrypt or scrypt-based</a> hashes ;) ). Although this information is somewhat safe to have around, forwarding it to the browser is often a bad idea. Using templates, you could just push the whole 'profile' record and let the designers not use it and the filtering is implicit. This is usually much simpler and a general no-brainer.</div>

<div><br></div><div>I'm sure there are more reasons out there that support the idea of templates, but I figure this sample is enough to prove a point?</div></div>