4 ms·

Number 6 is terrible -- hacking together html from strings is just not the right away to do it. He should be generating the DOM elements and appending/nesting t

Number 6 is terrible -- hacking together html from strings is just not the right away to do it. He should be generating the DOM elements and appending/nesting the generated elements appropriately, not concatenating a messy string.

willwagner 17y ago
Unfortunately, if you are adding a lot of elements, your performance can really suffer by creating DOM elements. It helps if you "createDocumentFragment" but as far as I know, shoving a big string into the non-standard innerHTML member is still the fasted way to add a lot of content.
- pmichaud 17y ago
  That might be relevant if you want to continually add many elements to the DOM, but that's rarely the case in most web applications. The benefit of using strings to shave milliseconds is heavily outweighed by the unreadable, error-prone code created when one tries to shoehorn markup into a concatenated string.
- axod 17y ago
  That's true for IE, but not for good browsers. For firefox/safari/chrome it's negligable difference if not sometimes slightly faster to use the DOM methods. Also, using DOM methods allows you to easier attach listeners, save references to DOM elements for later updates/use etc. That means less getElementById()'s later. Writing HTML inside js code is just horrible (IMHO). Horrible ugly code. And obviously easier to have security issues if you're including non-sanitized user data. #6 is a horrible idea. As far as your JS code is concerned, HTML is a (horrible, ugly) serialization of the DOM. Manipulate the DOM programatically. Don't use HTML.
  - jedediah 17y ago
    Sadly, most of us have to code for IE, just as we have to code for the "good browsers".
    - axod 17y ago
      If you're in the 'webapp' area, where IE is a minority (20% or so), I think it's justifiable to program in a clean way and live with IE users having a slower experience. innerHTML is just the worst thing ever invented. Ugly ugly thing.
      - JeffJenkins 17y ago
        Where does that 20% stat come from?
Jasber 17y ago
One solution I've used for storing small templates in HTML: http://ejohn.org/blog/javascript-micro-templating/ http://ejohn.org/blog/javascript-micro-templating/ <script type="text/html" id="user_tmpl"> <% for ( var i = 0; i < users.length; i++ ) { %> <li><a href="<%=users[i].url%>"><%=users[i].name%></a></li> <% } %> </script> Quick tip: Embedding scripts in your page that have a unknown content-type (such is the case here - the browser doesn't know how to execute a text/html script) are simply ignored by the browser - and by search engines and screenreaders. This is quick and dirty, but much more elegant than writing HTML in JS.
- warp 17y ago
  For anything slightly more involved I really like Pure as a javascript template engine, http://beebole.com/pure/ http://beebole.com/pure/. Especially when working with something like json data generated elsewhere.

willwagner 17y ago

Unfortunately, if you are adding a lot of elements, your performance can really suffer by creating DOM elements. It helps if you "createDocumentFragment" but as far as I know, shoving a big string into the non-standard innerHTML member is still the fasted way to add a lot of content.

pmichaud 17y ago
That might be relevant if you want to continually add many elements to the DOM, but that's rarely the case in most web applications. The benefit of using strings to shave milliseconds is heavily outweighed by the unreadable, error-prone code created when one tries to shoehorn markup into a concatenated string.
axod 17y ago
That's true for IE, but not for good browsers. For firefox/safari/chrome it's negligable difference if not sometimes slightly faster to use the DOM methods. Also, using DOM methods allows you to easier attach listeners, save references to DOM elements for later updates/use etc. That means less getElementById()'s later. Writing HTML inside js code is just horrible (IMHO). Horrible ugly code. And obviously easier to have security issues if you're including non-sanitized user data. #6 is a horrible idea. As far as your JS code is concerned, HTML is a (horrible, ugly) serialization of the DOM. Manipulate the DOM programatically. Don't use HTML.
- jedediah 17y ago
  Sadly, most of us have to code for IE, just as we have to code for the "good browsers".
  - axod 17y ago
    If you're in the 'webapp' area, where IE is a minority (20% or so), I think it's justifiable to program in a clean way and live with IE users having a slower experience. innerHTML is just the worst thing ever invented. Ugly ugly thing.
    - JeffJenkins 17y ago
      Where does that 20% stat come from?

Jasber 17y ago

One solution I've used for storing small templates in HTML: http://ejohn.org/blog/javascript-micro-templating/ http://ejohn.org/blog/javascript-micro-templating/ <script type="text/html" id="user_tmpl"> <% for ( var i = 0; i < users.length; i++ ) { %> <li><a href="<%=users[i].url%>"><%=users[i].name%></a></li> <% } %> </script> Quick tip: Embedding scripts in your page that have a unknown content-type (such is the case here - the browser doesn't know how to execute a text/html script) are simply ignored by the browser - and by search engines and screenreaders. This is quick and dirty, but much more elegant than writing HTML in JS.

warp 17y ago
For anything slightly more involved I really like Pure as a javascript template engine, http://beebole.com/pure/ http://beebole.com/pure/. Especially when working with something like json data generated elsewhere.