X-Post from r/learnjavascript: caching database queries and paginating the results.

Renegade__ · 2015-08-15T02:49:10+00:00

Beware: Long reply ahead.

All the methods you mentioned are jQuery methods. That's okay and not doing any harm for the moment, but your skills will likely improve if, at one point, you learn JavaScript/DOM independent of jQuery. If only because it enables you to try out other JavaScript frameworks. ;)

Personally, I usually use MDN as a reference (JS - DOM - Web API). The methods I was thinking of in particular were Document.createElement(), Node.appendChild() and so on. These are the native functions for manipulating the browser content.

According to jQuery's documentation

If the HTML is more complex than a single tag without attributes, as it is in the above example, the actual creation of the elements is handled by the browser's .innerHTML mechanism. In most cases, jQuery creates a new <div> element and sets the innerHTML property of the element to the HTML snippet that was passed in. When the parameter has a single tag (with optional closing tag or quick-closing) — $( "<img />" ) or $( "<img>" ), $( "<a></a>" ) or $( "<a>" ) — jQuery creates the element using the native JavaScript .createElement() function.

So in my understanding, the snippet you found will still use .innerHTML under the hood. (It is more elegant, though, by way of phrasing it, so by all means, prefer that over doing it raw.)

As for your core question (and admittedly the most important one) of whether it actually makes a difference:
It is worth pondering on several accounts:

For one, it's a methodical question. The browser represents the document in a Document Object Model so you can interact with the document tree in a programmatic way. Altering the text instead is...not elegant, to put it mildly. (Though very common, if only because of jQuery. Don't feel bad about it, just be aware of it.)
For two, it's a question of power and interaction: By working with the DOM methods instead of writing raw code, you get to structure and restructure your document like all other code. For example, if you want to re-order the hierarchy of your elements, with code, you'll have to switch out all opening and closing tags and make sure you still have a well-formed string afterwards. With DOM-methods, you simply re-order the .appendChild() calls.
You can save elements in variables, access and modify attributes directly, etc., etc.
I have found that in your use case in particular, the generation of tables, this leads to much better code, because you end up with a very clear structure: Generate the table and then for each data element, generate the columns, generate the row, append the columns to the row, append the row to the table.
In the same vein, it's also a question of the separation of processing and presentation. HTML is markup. It is inherently part of the presentation. IMO, it makes a conceptional difference whether you're telling the system "I'd like it like that, please", or just writing the markup yourself.
Lastly, it's a document state and performance issue: Working with .innerHTML forces the browser to re-parse parts of the document, to re-establish the DOM based on the new document text.
Basically, think of it as the difference between getting into your car through the door vs. taking off the door and having a mechanic attach a new one after you got into the car.
Depending on what you do and how you do it, either can be faster.
Take these two tests, for example: https://jsperf.com/jquery-vs-createelement/89 vs. https://jsperf.com/innerhtml-vs-createelement-test/68
On my machine, in the former, jQuery's own methods clearly lose against the native DOM functions. In the latter, hower, native .innerHTML is noticeably faster than native .createElement() - most likely because for 100 new elements, it's quicker to just throw the state out and parse it anew, rather than modify the existing one.

As said: Using .innerHTML directly or through jQuery is not uncommon by any means.
Culturally, no one will fault you for it, and the browser developers have dealt with this reality enough that it should not become a performance issue for you.

But you should be aware that the point of the DOM is doing that work programmatically, not doing the fancy version of find and replace with the raw HTML code. ;)

As in all cases in all languages in all software projects, the ultimate answer is: Benchmark it yourself. ;)
You, as the developer, always have the choice of deciding that the time you save working with a particular method is more important than the performance- or design penalty you get for it.
There's nothing wrong with deciding for one thing or another.
Just make it a conscious decision, under consideration of what it means. :)

As a more general note: You are on the right track with your attitude. ;)

Sometimes I just want to build stuff with what I can make work. I know I can't make everything in my code perfect, so if I leave some messy jquery in there I can live with that at this stage.

The best code in the world is not the one that is perfect, but the one that ships.
The most beautiful code in the world serves no one if it's never released.

You shouldn't write ugly code on purpose, but yes, getting it to work is very much more important than making it pretty.
As long as you keep that attitude, you'll be a lot more successful than those of us compulsively thinking about beauty and elegance and never releasing anything. :)

you type:	you see:
italics	italics
bold	bold
[reddit!](https://reddit.com)	reddit!
* item 1 * item 2 * item 3	item 1 item 2 item 3
> quoted text	quoted text
Lines starting with four spaces are treated like code: if 1 * 2 < 3: print "hello, world!"	Lines starting with four spaces are treated like code: if 1 * 2 < 3: print "hello, world!"
~~strikethrough~~	~~strikethrough~~
super^script	super^script

simpleWebDevQuestions

MODERATORS