Can anyone explain to me why having the dropdowns and other items in JavaScript is better than the DOM? Seems like we fixed this approach on the web 10 years ago.
In what way is this better than writing HTML? And just using innerHTML, outerHTML etc?
It's a serious question. What benefit is there to doing this?
The only thing that came to mind is now you have the dom node so you can bind events to it. But you're not going to be doing that everywhere. So why make things more complicated?
Yes, it's faster to create DOM elements in string form rather than one-by-one, attribute-by-attribute.
However, creating DOM structure in code sucks. It's far better (and faster) to create markup and deal with templates by compiling HTML files into strings in JavaScript files and then turn those strings into DOM structure when needed.
Once you create DOM fragments from singular, compiled strings, you can perform data binding.
So, instead of this (from your benchmark):
var $dropdown = $('<select class="s">');
$u.find('a').each(function() {
var $a = $(this);
$('<option>').html($a.text()).attr('value', $a.attr('href')).appendTo($dropdown);
});
Interesting 'innerHTML' is mentioned as a crappy native equivalent. In theory, I agree. But last time I compared innerHTML vs DOM fragments, innerHTML was much much faster across the browsers I tried (this was just before JITs for JS became common place).
The tradeoff it seems is the browsers native HTML parser and serialization vs holding a DOM tree in JS, and for large sets at least, innerHTML won handily.
Fascinating article. I had always perceived DOM elements in JavaScript as proxies. They let you do things to that DOM element, but it’s still just a javascript object that you can assign to and do whatever, in addition to using the functions for interacting with the actual element.
What exactly is so difficult about DOM manipulation? I honestly don't get why people see it as a problem that warrants zillion badly written frameworks, while other critical language issues are pretty much ignored.
The DOM isn't a language issue, it's an API issue. That issue has gotten much better in recent times, but jQuery became popular because those API issues were so big. Today, you look at caniuse and see that almost every new feature is not implemented or partially implemented by at least one browser.
That's bad when talking about something like the File API, but that used to be the case for DOM primitive operations. Instead of one browser, every browser implemented almost every feature in an incompatible way. For example sizzle (the selector that's the foundation of jQuery) came into existence because there wasn't a unified way to do something as simple as selecting a node from the DOM.
Things like querySelectorAll have made life easier for most of us, but the DOM is still a maze of barely compatible implementations. I don't dislike it to the degree I used to, but I still don't like it.
totally understand that. i'm just wondering why the authors would want to write methods for DOM manipulation in the first place when they could piggyback off jQuery for that and concentrate on the other stuff.
I like it. We have seen a significant difference in performance in holding objects in our JS but not putting them in the DOM until the user needs to see them. I think the more you can remove from the DOM, the better.
I have no idea why people don't do this so much any more. JS templating is crazy. Everyone knows JS DOM manipulation is slow on most current and all legacy browsers. Whereas string manipulation on the server is stupidly easy and fast.
There was no DOM back in the early days of Javascript. The page was rendered in a single pass, you could inject text and markup via document.write() and anything "dynamic" was accomplished by reloading an IFRAME. Remember, these were the days when too many tables would crash your browser; I recall the early demos of Gecko showing deeply nested tables, and all styling was with font tags still.
Netscape was still trying to sell a browser, and they wanted a common language on the frontend and backend, so Javascript was also on Netscape Server.
This is similar to what React.js or Vue.js does on the browser. I always thought of this, very nice to see it running.
I worry about the following..
1. How we do complex objects like Trees and Tables?
2. How efficient are these Native nodes over DOM nodes in Browser?
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.
reply