21–30 of 51 posts
Earlier quoted context omitted.
Many would frown upon polluting the global name space with functions corresponding to all known HTML tags.
If you end up wrapping your code in an immediately called lambda anyhow I'm sure it would be fine.
http://mg.to/2006/02/27/easy-dom-creation-for-jquery-and-pro...
It's based on Bob Ippolito's version from 2005. :-)
The comments on the post have a few other interesting implementations that others contributed.
At the time I got pretty excited about this idea, but I abandoned it after a while for performance reasons. I was building large DOM structures and it was really slow. I knew that innerHTML was faster, so I tried keeping the same syntax and generating HTML from it instead of DOM insertions - and it was almost as slow that way!
Then I realized that it was just the sheer amount of JavaScript code being run that was slowing it down. I changed my code to build HTML strings with array pushes and a join at the end and then innerHTML to insert, and it was much faster.
Of course, JavaScript has gotten a lot faster since then (at least in new browsers!), so the more code-intensive techniques may be more practical now.
You wouldn't embed database queries into your view controllers, so why would you couple your html to your javascript?
Earlier quoted context omitted.
While I don't entirely agree with your first statement, you could just grab the outerHTML instead of appending the element directly to the DOM: $.el.div($.el.span()).outerHTML
Seems like a reasonable solution. My first statement was certainly true in the previous generation of browsers, including IE 7. I'm not sure about more modern browsers. What basis do you have for disagreeing? Refer to: http://www.quirksmode.org/dom/innerhtml.html
This is pretty, but unfortunately the only performant way to generate dom elements in javascript is with HTML. HTML parsing is orders of magnitude faster in most browsers. How about a library like this to generate a string of HTML instead of dom elements?
Of course the performance tradeoff would be different in modern browsers.
This is fine for small, one-person projects, but if you generate DOM content in your JS views it will come back to bite you in the ass once you hit a certain size. The first time you need to bring in a designer, or integrate a static mockup from a designer, you'll be wishing you used a template engine. You wouldn't embed database queries into your view controllers, so why would you couple your html to your javascript…
This is fine for small, one-person projects, but if you generate DOM content in your JS views it will come back to bite you in the ass once you hit a certain size. The first time you need to bring in a designer, or integrate a static mockup from a designer, you'll be wishing you used a template engine. You wouldn't embed database queries into your view controllers, so why would you couple your html to your javascript…
Thanks for the tip, but I've had much success using this method on teams of 5+ developers and a full-time designer.
http://blog.fastmail.fm/2012/02/20/building-the-new-ajax-mai...
Used the CSS syntax to easily set class/id on a newly created tag.
Benchmarks included to show it's just as fast as innerHTML on modern browsers.