Advantages of CoffeeScript When Working with jQuery Templates(bloggemdano.blogspot.com)
bloggemdano.blogspot.com
Advantages of CoffeeScript When Working with jQuery Templates
http://bloggemdano.blogspot.com/2011/09/advantages-of-coffeescript-when-working.html
4 comments
> 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.
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.
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.
"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.
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.
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.