arantius.com

As some have said a clone of an element is faster than creating a new one. So I have created a replacement for document.createElement and document.createDocumentFragment which caches the first call to create and element then all future calls use its clone. I also use a ref to the 'document' object becuase thats faster than working with the straight document object. Your use of document.createElement is not altered and should work great with the $E shortcut.

//CODE IS BELOW

var doc = document;

doc._elementCache = {};
doc._createElement = doc.createElement;
doc._createDocumentFragment = doc.createDocumentFragment;

doc.createElement = function(elementName){
	elementName = elementName.toLowerCase();

	if(doc._elementCache[elementName+'Element'] == null){
		doc._elementCache[elementName+'Element'] = doc._createElement(elementName.toUpperCase());
	}
	
	return doc._elementCache[elementName+'Element'].cloneNode(false);
};

doc.createDocumentFragment = function(){
	if(doc._elementCache.documentFragment == null){
		doc._elementCache.documentFragment = doc._createDocumentFragment();
	}
	return doc._elementCache['documentFragment'].cloneNode(false);
};

Say MIT or similar. ;)

I've been working on a similar function for some time. My own version is newEl(tag,id,classname,innerText). I assign the id to both el.id and el.name (to take care of inputs and such). The code can be seen here: http://borderaction-new.webworkstest.com/j/js.js

IE, as usual, throws up gotchas. For instance, if you create an iframe with the newEl() method (and presumably with your $E() method), IE ignores the .name set, making it tricky to target iframes with generated forms. To get around that, I keep an ie-specific version in a separate file: http://borderaction-new.webworkstest.com/j/js-ie.js

I hope this is useful to you. I'm really considering using your code in future - it looks much cleaner than mine!

The Mochikit way is even more elegant, cutting away some of your property names and object nestings, making your example look like this (created attribute-less nodes getting a null first parameter instead of the attributes objects passed here):

DIV({id:"toolGroup_1",class:"toolGroup"},
DIV({class:"roundBarTop"},
DIV({class:"leftEdge"}),
DIV({class:"rightEdge"}),
DIV({class:"heading"},A({class:"collapser"}),"Group Heading")))

Nice function, I've hacked it into prototype in a more prototypish way, adding it to Element.Methods as "create":

Element.Methods = {
  create: function(data) {
  	var el;
  	if (typeof data == 'string') {
  	  el = document.createTextNode(data);
  	  return el;
  	}
  	el = document.createElement(data.tag);
  	delete(data.tag);
  	if (typeof data.children != 'undefined') {
  	  if (typeof data.children == 'string' || typeof data.children.length == 'undefined') {
  	  	el.appendChild($E(data.children));
  	  } else {
  	  	data.children.each(function(child) {
  	  	  el.appendChild($E(child));
  	  	});
  	  }
  	  delete(data.children);
  	}
  	data.each(function(attr) {
  	  el[attr] = data[attr];
  	});
  	return el;
  },

  ...
}

And then adding, after Object.extend(Element, Element.Methods):

var $E = Element.create;

Thus integrating it into Prototype in a nicer way.
Thanks a lot :-D

It seems to me kinda counterintuitive to delete the attributes of the object that is passed in to $E. I think some programmers might be very surprised when they pass in what is supposed to be a persistant object they have saved somewhere and its properties get deleted. Javascript will do GC for you and if the user doesn't want that object in the future it will be collected (I don't think there are memory leak issues in just this simple case) so why delete the properties?

Also it would seem best to support calls of the kind (tag, classname, id) or perhaps (tag, id, classname). This could be implemented with a quick arguments.length and typeof check at the begining of the function.

As for the poster who wanted to cache the created DOM elements (though the code the posted doesn't seem to apply the class/id attributes) I'm not so sure what you did here is a good idea. For one it leaves a reference to that DOM element lying around so it won't get GCed. If it is just one object this isn't a big deal but what if if has a huge list of child nodes (maybe someone is using it to parse data from the server into the DOM). Also you need to count in the time of changing the id/classname/attributes as well as the overhead of all the caching functions.

It is quite possible that this will screw up the GC in more subtle ways as well. It can be really amazing what small changes in reference circularity/type can have on the memory footprint. Since it is far more important to avoid the worst case where you slow the browser to a crawl because of the memory usage than it is to save milliseconds in the $E function it seems overall to me to be a bad idea.

<script type='text/javascript'>
var el, el2, start, end;

start=new Date();
for (var i=0; i<9999; i++) { 
	el=document.createElement('div');
}
end=new Date();
alert('createElement: '+ (end-start) );

start=new Date();
el=document.createElement('div');
for (var i=0; i<9999; i++) { 
	el2=el.cloneNode(false);
}
end=new Date();
alert('cloneNode: '+ (end-start) );
</script>

Hi anthony,

Nice piece of code. Nice enough to inspire me to blog about it. The guts of my post is disagreeing with ecmanaut that the mochikit way is more elegant, though i think this is just a matter of personal preference. Cheers for the code snippet.

Thanx arantius. (this is Mario, i forgot my password, wierd?)

I do remember when I made it that there was some time differences between the browsers. Moz is genrally speaking faster than IE in lots of things. For example try creating table elements (with and without using innerHTML to make them). Moz smokes IE for that. Also if you are interested... here is a faster 'each' method for prototype. It uses a reverse while loop (at least it hsould be faster hehe 8P)

Array.prototype._each = function(iterator, thisVal){
//using a faster reverse while loop instead of a for loop
var i = this.length,l=i;
if( i > 0 ) {do {
    var iIndex = l-i;
    iterator.call(thisVal, this[iIndex], iIndex, this); //(this[iIndex] || this.charAt && this.charAt(iIndex))
}while( --i );};
};

I had to change:

for (attr in data) {
    el[attr]=data[attr];
}

to:

for (attr in data) {
    el.setAttribute(attr, data[attr]);
}

Hi, this is the closest I have seen to solving my "template" problem with newer versions of Javascript. I'm not very good at Javascript, but it would be nice to see it solved.

Basically, I want to go from a template html string to adding it via createElement and appendChild. With firefox, I don't have to worry about it because it just lets me insert html. However, other browsers are sticklers. The reason behind the html string is that my backend php scripts can access it too. I outlined the problem better on google groups but no one could help me there.

I guess this is an open challenge to anyone who wants to solve it because it would be really, really helpful. I imagine the usage would be something like appendComplexElement(newEl,parentEl);

My post on google groups - the formatting on the template string looks better there.

My template file would be inserted into a table. As you can see, the second layer of table rows presents a problem in just getting the table element, followed by tr and td.

<tr> <td>{var1}</td> <td>{var2}</td>

<td> <table> <tr> <td>Name: {name3}</td> <td>Age: {age3}</td> </tr> </table> </td>

</tr>

-- Thanks! Lee

hi. Thanks for all your efforts first of all ... The problem I am having is that when I use the sample code provided - nothing happens. Nothing is written to the document at all, though my efforts to alert my way through your $E function seem to indicate that things are clicking right along.

I have taken this example into many different sandboxes with simpler and simpler implementations...but the result is the same. Nothing.

Is there something I am doing wrong (remember...I am copy/pasting your code verbatim...)

forgot about appendChild() as well. Very good work sir!

I changed this line:

for (attr in data) {

to this:

for (var attr in data) {

to avoid warnings from Rhino about attr being out of scope. Thanks for the useful code!