

Advantages of CoffeeScript When Working with jQuery Templates - dmohl
http://bloggemdano.blogspot.com/2011/09/advantages-of-coffeescript-when-working.html

======
Pewpewarrows
No. No. No no no no no. You lose syntax highlighting and error correction in
basically every editor that I can think of. Trying to manage real-world
application templates as multi-line javascript strings (that quickly balloon
into hundreds of lines) is an absolute nightmare. Save yourself the headache
and make a <script> tag with an id, and type=text/html (or x-jquery-tmpl, if
you're using the templating features built-in to jQuery).

Fetch the element using whatever, grab its innerHtml, and pass that string
along to the templating library of your choice. The browser doesn't render the
initial template markup because it's in a script tag, and it doesn't interpret
it as javascript because of the non-standard type attribute. So for all
intents and purposes it completely ignores it, but it's fully accessible for
your use. Win-win.

~~~
TrevorBurnham
> Save yourself the headache and make a <script> tag with an id

That's not always efficient. Suppose you want the same lengthy template to be
available across several pages which share the same JavaScript. Then it makes
a lot more sense to put the template in the JS and serve it once than to put
it in the DOM and serve it repeatedly. Also, with the DOM approach, you have
to insert data into the template using regex rather than simple str1 + data +
str2.

If syntax highlighting is really your major concern, write a simple script
that compiles your .html to .coffee (sandwiched with """). Best of both
worlds.

~~~
Pewpewarrows
I was only describing the initial idea. In production I use an intermediary
step where all of my templates are actually re-processed back into raw
javascript strings and served inside my minified/compressed/cached js file. I
use a central access point that knows to grab the templates from a javascript
object namespace instead of the innerHTML of an id when not in DEBUG mode. So
while it still technically uses javascript strings at the end of the day,
that's not how I develop them. For the average developer that's just looking
to get easier maintenance over javascript templates, script tags with ids is
the way to go.

"Simple" str1 + data + str2 might fly for a trivial one to two page website,
but quickly devolves into an unmaintainable mess of spaghetti code as project
sizes increase. I don't know of any modern programmer that would ever advocate
for string concatenation over string interpolation via sprintf/templating/etc.
I should also hope you're not trying to parse the strings yourself manually,
regex'ing variables into it. There are tons of fast and efficient template
libraries to choose from instead.

------
jeffesp
The key thing that it looks like he is doing is using heredocs and string
interpolation to change the way the HTML for the template is written. This is
cool, but in my opinion the wrong place for HTML. I think the support of
script tags with type=text/x-jquery-tmpl and an id are a better option than
HTML in a string variable (<http://api.jquery.com/template>). At least then I
feel like I am writing HTML in the right spot.

