Comment by Jason Knight on "Generating Elements With JS"

ImportNode is too new and poorly documented, I can't use it yet since I still have clients using IE8/earlier... and even if I could I'm not sure I even understand what it's for.

cloneNode often loses/drops properties on elements, and you have to HAVE a node to clone in the first place, meaning you're using createElement anyways -- that our you're putting scripting only markup in the static markup where it doesn't belong.

innerHTML is right out since if you're going to use the DOM, USE THE BLOODY HUFFING DOM! InnerHTML means the live DOM has to be reverse engineered back into markup, edited, then reparsed back into a news DOM with a complete re-render. It introduces excess overhead for no reason and WORST of all? It's insecure since you can put code into it. Unless you create your own JavaScript equivalent of PHP's htmlspecialchars you're just begging to create XSS expliots by using it! For the most part I view innerHTML as being in the same class as document.write, you REALLY shouldn't use it in production code unless there's no other choice. It just feels to me like the same idiocy as using string addition to put variables into a query string when using PHP. We have prepare/execute now, use it.

... so that leaves document.createElement and document.createTextNode, and that's what I use. Admittedly I build helper functions to simplify it in a manner where I can actually create a JSON structure that is turned into markup -- and since it bypasses innerHTML it renders faster.

My own little library (under 8k once minified and gzipped) does exactly this using a format I'm calling DOM-JON... which I'm still documenting and separating from the reference pages for the make and write methods.

elementalsjs.com/reference/DOM_JON

It uses a selector style creation where you have:

tagName#id.class.class~textContents

The outer array can contain a selector of the above format, or an array where the first element is a selector and the second element is attribute style instructions of both attributes and commands for appending to the DOM. Which using elementals _.make ends up like this:

// element using content command attribute
var divTest = _.make('div#test', {
    content : [
        // element + text
        [ 'h2~This is a DOM created subsection' ],
        // element + innerHTML
        [ 'p', { innerHTML : 'A child paragraph <strong>that can use markup!</strong>' } ],
        // element + multiple children
        [ 'p', [
            // text only
            'A child paragraph',
            // tag + text, markup is escaped to entities
            [ 'strong', 'that directly assigns the <strong> tag.'],
            // text only passed via selector
            [ '~ Note that markup is escaped when you pass a normal string!' ]
        ] ],
        // element using content "command attribute"
        [ 'div.details' , { content : [
            // tag + text
            [ 'span', '13 November 2017' ],
            // just text
            ' Jason M. Knight'
        ] } ]
    ],
    // instruction on where to add the new element
    last : document.body
});

If I were implementing this as vanilla.js, I'd probably end up creating a similar set of handlers for quickly creating markup and content in a similar manner.

Notice that it DOES allow for innerHTML, using innerHTML on a element you created with document.createElement BEFORE you append it to the live document DOM removes most of the overhead woes of parsing. It's still there but greatly reduced since it only applies to that little piece. Still has the lack of sanitation woe though which is why I would use that technique with a eye-dropper, not the paint-roller most people slather it on with. I actually just added a couple days ago (will be in tonight's update) an object .madeCollection that will contain all elements created with ID's by .make and _.write with the ID as the property name. (I may end up trying to make it a legitimate iterable collection)

Bottom line if you're going to use the DOM, USE IT! ...and that means createElement, createTextNode, appendChild and insertBefore!

Steven Ventimiglia it runs deeper than that too, look at all the times people use innerHTML to do textContent's job. Or how when working with a form people will document.getElementsByTagName('input') to do form.element 's job. Or will waste queryAll or one of the various getElementsByxxx functions _(or jQuery's equivalents) _to do what a single getElementById followed by "Node Walking" should be handling.

OR CONSTANTLY accessing an element by ID instead of getting it once and storing it for later use... or using any of the above techniques inside a event handler when they could just simply access the node they want via Event.currentTarget and something like parentNode , nextSibling , previousSibling , firstChild , lastChild , etc, etc, etc...

Or even just dicking around with window.onload or DOMContentLoaded to do what could simply be handled by placing all your scripts right before</body> so it runs after the markup DOM is built.

... and you really hit upon part of the biggest problem, the "I don't have time to learn this" attitude, but when people do that in JavaScript, in HTML, in CSS, what do they do? Go to some framework and learn that INSTEAD. EVEN when the framework is more to learn, harder to use, and results in more work overall! See jQuery and Bootcrap for stunning examples of this in action. They PROMISE to be easier or simpler when in fact they typically result in as much if not more code, that's harder to follow, harder to debug, and in many ways pisses on the entire intent of the parent languages -- much less good practices!

Laugh being bootcrap and jQuery are some of the better ones. Ever see W3Fools halfwitted w3.css? If you don't know what's wrong with class="w3-red w3-css w3-border" please just back the f*** away from the keyboard now... that or go back to using HTML 3.2 without CSS and all that <font>, <center>, border="", align="" , color="" garbage the nitwits who created that mess so clearly miss.

For a long time I've wondered just what the f*** is in the kool-aid being peddled by these frameworks, and I spent a good deal of time chalking it up to the 7 classic propaganda techniques. In particular, glittering generalities (easier, simpler, smaller), bandwagon (everyone is using it, you should to), card stacking (picking examples that favor their system or worse, using horrible code to compare to), and testimonial (It works for me, it works for these big companies) abound... as does plain folks _(since so many beginners use it), name calling (via the inversion method, "this is easier" is the same as saying "that is harder"), and of course transfer (it was made by twiiter, you like twitter right?) _-- they all seem to fit.

But it ends up equally mated to something I've said for a long time, people diving for the frameworks and their ilk before they know enough about the underlying languages to even build a valid opinion on the framework's value! That's how my list of "everything I've ever seen done with jQuery" came into being... said list being that EVERYTHING I've EVER seen done with jQuery falls into one of these three categories:

Stuff that would be less work -- and less code without the framework, NOT counting the size of the framework against it.
Stuff that's HTML or CSS' job.
Stuff that has ZERO blasted business on a website if you care at all about accessibility, usability, and basic functionality.

That's not a joke.

But if that analysis holds true,, how and why are people using them? What about the underlying languages is driving people to these garbage "shortcuts" that only end up screwing them over in the long run. Even if they don't know enough to realize how badly it's screwing them, you'd THINK user complaints might mean SOMETHING!

... and the obvious answer is quality documentation and tutorials -- or more specifically a lack therein.

The specifications themselves in their current state are GARBAGE for people actually trying to learn -- or even to use the languages for what they are for. This is easiest to explain with the latest iterations of HTML, as they are written with the INTENT of being NOT for the people writing websites with HTML, but for the people writing BROWSERS.

Let me just repeat that, the HTML specification is NOT written for people who use HTML to write websites!

This is why to us "mere mortals" the entire specification reeks of having been written in Finnish, translated to Japanese by a Russian, then Google translated back to English.

Just look at the definition of an "empty" where <div></div> is NOT an "empty tag" ! That's why even in XHTML<div/> is gibberish nonsense and not valid XHTML or HTML. (even if it would be valid XML). An "empty" tag is one that CANNOT wrap other tags or have DOM children, and NOT one that doesn't have content.

When something as simple as that has such convoluted language, is it any wonder people go to third parties to learn HTML?

... and therein lies more of the problem, outdated, outmoded, and just plain inaccurate third party references and tutorials. Certainly web-rot accounts for a lot of this. Computing is an industry where -- as the saying goes -- "3 years is obsolete, 5 years is the scrapheap", and whilst that concept applies to hardware, look at the changes to HTML over the past two decades, or JavaScript over just the past decade, then look at adoption rates for those changes.

Like again, take HTML. How many people ACTUALLY embraced HTML 4 Strict properly? I'd be shocked if it was more than two dozen given the volume of people who sleazed out HTML 3.2 with a 4 tranny doctype atop it. Today people just vomit up that same bloated gibberish non-semantic swill, but get to wrap 5 lip-service around it and pat themselves on the back over how "modern" they are.

Seriously, how many people out there writing HTML actually understand WHY grammatically headings have numbers? How many people understand that <P> is for a grammatical paragraph?

No, people use <H1> ..<H6> JUST for "different weights and sizes" in gibberish nonsensical orders, and the tag that was SUPPOSED to fix that,<section> has only made it WORSE. People still wrap <p> around single images, labels and inputs, and all sorts of other crap that ARE NOT GRAMMATICAL PARAGRAPHS! Meaning in all likelihood they'd have failed 4th Grade English class in the 1970's, which by today's American education standards is what, first year of college IF you're an English major?

We spent over a decade of people not realizing that transitional LITERALLY meant "In transition from 1997 to 1998 development practices" and completely missing the fact that NO NEW WEBSITE WRITTEN AFTER 1998 SHOULD HAVE BEEN WRITTEN IN ANYTHING BUT 4 STRICT OR XHTML 1.0 STRICT... at least not until HTML 5 derped along.

_Wah, wah, but I can't use __target="_blank" ! ... yeah, about that._

HTML 5 only made things worse in a lot of regards re-introducing redundancies 4 Strict was trying to eliminate, encouraging techniques and methodologies that set development practices back to the worst of the browser wars pissing on accessibility (target much?) and usability... but the most egregious sin of all is that the entire blasted specification is a massively ridiculous 10 megabytes of HTML for some 103 tags and not even two dozen attributes. Even stripped down as plaintext it's 2.5 megabytes (which means some really shitty HTML under the hood) -- basically 20k of text for each significant element to explain! You need that much space to explain HTML you need to learn how to write a SPECIFICATION.

But that's why when I say "specification" in relation to HTML 5, I make air quotes with my fingers like a second rate Doctor Evil. "Laser"...

Worse though is that HTML 5 was created NOT to tell people writing websites what to do, no... instead they wanted to document what people WERE doing. The problem with this attitude is that many people were doing things that shouldn't have been done in the first place -- like presentational markup, like flipping the bird at accessibility, like failing to grasp basic semantics or the professional writing concepts on which they were based.

A stunning example of this is the -- now defunct -- <hgroup> tag. It existed so that you could pair two headings as a single heading; such as a title and tagline. You see people do that all the time right?

<h1>Site Name</h1><h2>TagLine</h2>

Well that's semantic gibberish... and creating a tag to wrap them for that use simply proved that the folks at the WhatWG who created HTML 5, didn't know -- or flat out didn't care -- enough about HTML, semantics, or accessibility to have been creating HTML 4 Strict's successor!

I'm not going to explain that in this post, I'm already so "large" the Twitter-generation TLDR mouth-breathers left long ago. Oh for the days when people used to kvetch about 32k being too small for a post size on forums.

JavaScript is similarly hobbled. Have you read the ECMAScript specification? Yeah that. There's a reason people in the case of web languages are driven to quality third party resources like MDN, or in a far, far, darker case into the arms of predatory scam-artists peddling web-rot and bad practices like W3Schools. Not a fan.

In JavaScript you also have a nasty predator factor, particularly in tutorials (again W3Fools) but also in print. I still remember a friend (Dan Schulz, RIP) flipping out thoroughly pissed off because he got one of Kevin Yank's "JavaScript" (again, air quotes, mocking sarcasm) from the sleazy snake-oil peddlers at SitePoint, and finding out that despite not even mentioning it on the jacket or promotional materials, the book was cover to cover jQuery. He didn't want to learn jQuery, he wanted to learn JavaScript!

Again though, web-rot is a serious factor too. On the web outdated outmoded tutorials filled with bad and even insecure practices don't die, they don't even fade away... instead they get bounced and promoted by some nube on Facepuke, half-tweet, Booble+, some random forums -- or even Hashnode -- and the head-bobbers and b***-jobbers nod in mindless unison over how great it is.

See how people JUST learning PHP are STILL stumbling into mentally enfeebled tutorials teaching the outdated mysql_ functions, or if they do teach mysqli/PDO they STILL teach the outright moronic insecure practice of slopping variables into the damned query strings!

Bad tutorials, outdated web-rot, obtuse specifications, sleazy book publishers who rewrite two pages and slap a new cover on the same garbage books, sleazy authors unqualified to flap their gums on the topic of web development, AND a marketing that fosters a cult-like dedication? Talk about an uphill battle!

Search Hashnode