Generating Elements With JS

Say you have that job to create a web app, and what you want to do is generate some HTML elements with JS, based on some JSON response. It's a small app, so you decide against using big-ass frameworks and libraries (and JSX). Now that you actually have to implement the element generation from some kind of template, you find out that there are several ways to actually do that.

You start to wonder: which way is the best one to actually add elements or even element trees to a DOM? What's the most used one and why? How good is the performance of each and what about events, like click, focus, hover, etc., especially on re-render? Do the different ways have specific use-cases? What are advantages and disadvantages?

I consciously do not want to add a poll here, because that would make people click whatever they feel comfortable with instead of giving it a moment to think, re-evaluate the methods and find arguments.

Some methods, which are available using VanillaJS are

document.createElement(); //..., add attributes etc. and append to targetNode
targetNode.innerHTML += '... ${something} ...';, (imagine a template literal here)
targetNode.appendChild(hiddenDiv.cloneNode(true));
targetNode.appendChild(document.importNode(template.content), true);

I will write my view on the above ways into an answer below. What are your thoughts on the topic?

Check out RE:DOM: redom.js.org 😉

In Vanilla JavaScript Components I have a section called "What about a template/view/UI?"

You just use right tool for the right job.

Do you need to create span with textContent and append it? Use createElement.NEVER use innerHTML, use only textContent.

Do you need to insert many elements at once? Use documentFragment;

Do you need to insert same small HTML widget/component like post box or product card many times? Use <template> . Moreover, you can insert your data from JSON into templates with basic string replace or a bit of a custom parser. Here I have a proposal for native variables for <template> and a polyfill.

I use <template> all the time for all components bigger than just one, two tags. For example, I use it with my DataTable. I don't need to write any custom JS at all anymore. Just almost empty <table> and I define row in <template>. I NEVER had any performance issues with Vanilla JS and <template> what I can not say about jQuery DataTables, those fancy frameworks with JSX/TS/whatever overcomplicated garbage.

Finally, just create a UI object or add UI methods/logic into same object if you have a very basic component and if in the future you would like to change your CommentUI.create() implementation, for example to replace createElement with <template> or just use handlebars, whatever, you might do so easily without changing anything else in your architecture. Let the UI layer handle it for you. Main component's object should NOT be coupled to either UI/view layer nor Model/API/JSON layer.

You can read my article on Medium to see also code samples of a basic Like button component using nothing but a few lines of Vanilla JS.

medium.com/bunnyllc/vanilla-js-components-8d20c58…

Last note about performance. You could ask this question 5+ years ago, today all browsers will handle optimization even when you do not use documentFragment on their own. (However, last time I played with huge lists in Firefox, I have found that there is a very big difference between appending element at the end of a huge list and before the last element, I am not sure if there is still same bug/issue). Anyway for a modern browsers and devices even for heavy DOM operations, there is almost no difference in a real world scenario.

I echo the sentiment of a few others about not reinventing the wheel and simply using a library; you'll probably end writing your own in achieving your objective. There are several minimalistic libraries that would moderately address your concern about bloat. If your question is a purely academic question, then that's another thing.

Given the constraint of "small app", Option 1 would be the option that I would go with. It requires the least amount of extra design to achieve. Going one step further, similar to the helper functions that Tommy Hodgins described, you could generalize that approach even more into a simple node builder framework (similar to XmlBuilder in other languages or some of the compiled output of React). You essentially need builder functions for elements and text nodes (for extra credit you could add builders for the other node types like comments, CDATA sections, etc.)

An example in TypeScript. (I just threw this together, so don't critique it too much. But it does work):

type BuilderFunction = (parent?: Node) => void;

function elementBuilder(
  tagName: string,
  children: BuilderFunction[] = [],
  attributes: any = {},
  events: { [key: string]: Function } = {}
): BuilderFunction {
  return (parent: Node) => {
    const element = document.createElement(tagName);

    Object.keys(attributes).forEach((name) => {
      element.setAttribute(name, attributes[name]);
    });

    Object.keys(events).forEach((name) => {
      element.addEventListener(name, (evt) => events[name](evt));
    });

    children.forEach((child) => {
      const childNode = child(element);
    });

    if (parent !== undefined) {
      parent.appendChild(element);
    }
 };
}

function textBuilder(text: string): BuilderFunction {
  return (parent: Node) => {
    parent.appendChild(document.createTextNode(text));
  };
}


const builder = elementBuilder('div', [
  elementBuilder('form', [
    elementBuilder('input', [], { type: 'text' }),
    elementBuilder(
      'button',
      [textBuilder('Submit Button')],
      { type: 'submit' },
      { click: (evt) => { alert('Clicked') } }
    )
  ])
]);

builder(document.body);

Give these functions some aliases, and you've got yourself a very simple and terse domain-specific language.

Options 2, 3, and 4 each have the advantage of being defined with markup but also have the disadvantage of being unable to wire up event handlers or any other type of dynamic linkage. At this point you're verging into territory where frameworks really shine. If you still have the constraint of not using a framework, you could take a few approaches:

Similar to Angular, create a custom parser grammar (something like PegJS would help here). Use the grammar to generate an abstract syntax tree from markup and then walk the AST and utilize something like the builder functions that I described above to generate nodes.
Similar to Vue or Knockout, include special purpose HTML bindings (e.g. v-on:click="handler" or data-bind="click: handler") in markup that your engine will scan for after it has created a DOM subtree. This option too will probably require a custom grammar but a more simplistic one.

React's JSX and Angular's AOT effectively take care of these steps at compile-time and generate builder-type code to be executed at runtime.

Bonus option, one that I have not explored much yet but is supposed to have a lot of potential: HyperHTML. It uses tagged template literals to achieve the change detection features of a virtual DOM without the overhead.

For one, it is actually academic, because I am quite interested in the topic - it comes up from time to time for the smallest things. However, since I have a project which has some constraints at the moment, the question is even more interesting :)

Actually, your idea with the code example is the one I have been thinking about the most, and I probably will implement that. Thank you for offering your implementation and some additional ideas :)

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!

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

I love this comment, Jason. It seems like the current state of our industry (from frameworks to software), is also encouraging a "I don't have the time to learn this properly, so let's reinvent the wheel" temperament.

It also gets scary when they consider innerHTML , appendChild , and insertAdjacentHTML three ways to simply "do the same thing".

Well WebComponent is one word solution which combines/uses all of the options that you have stated.

One simple example is here: time2hack.com/2018/01/todo-app-with-webcomponents… which I wrote as post.

Of course the things are tedious in VanillaJS but you have freedom to take things in any direction and the level of complexity.

Personally I choose frameworks/libs on the basis of size of app and time available. And if I have enough time, I will definitely go for WebComponents.

Few things I would suggest

If you are worried about browser support and weight of JS code, don't use template tag
Definitely not the 3rd option as it will leave the element rendered but not visible which is waste of processing as you are not going to attach it to the DOM
template literals are really powerful as I guess you will be using some bundler and in that case it will be converted to simple string interpolations compatible to most browsers
you can go very functional with createElement and hence save a lot. I am pretty sure it will pain in the ass to manage many edge cases but for a big app it is will be worth

I think I'd do something like #2. I understand the virtues of using createElement() for a few, small elements that don't contain many elements, but by the time you get down to the level of a passage of text with links, <strong> tags and other markup - creating each element that way gets a little overwhelming.

I've been having a ton of fun using JS template literals for composing CSS stylesheets, and it makes it really nice to extend with JS functions that return strings.

Recently I was playing around with some JS helper functions that might help me compose HTML, but I don't really know when or where I'd use these - so for now they're just some explorations. I was trying to see if I could create some simple functions for writing HTML and putting some of my understanding about how sites were built into JS functions. I'm sure people have been doing stuff like this with PHP on the backend forever too :P

First we have our generic HTML tag assembler. This accepts a tagName, some content which can be a string or a function that returns a string ;), as well as optionally some attributes if we want to apply those to the element as well.

All HTML tags have closing tags except for 'void' tags, so rather than trying to whitelist all valid HTML tags we don't even need to know or care what those are. All we really need to know is the much shorter list of 'void' tags that don't have closing tags and if we notice our tagName is one of those we don't close it.

// HTML Tag Generator
function html(tagName, contentString, attributeObject) {

  tagName = tagName || 'div'
  contentString = contentString || ''

  let voidTags = ['area', 'base', 'br', 'col', 'embed', 'hr', 'img', 'input', 'link', 'meta', 'param', 'source', 'track', 'wbr']

  let attr = attributeObject
             ? Object.entries(attributeObject).map(item => `${item[0]}='${item[1]}'`)
             : []
             .join(' ')

  return voidTags.includes(tagName.toLowerCase())
         ? `<${tagName} ${attr}>`
         : `<${tagName} ${attr}>${contentString}</${tagName}>`

}

Now we can create elements with code like this:

html('div', 'Hello World')

Now, if we combine our html() function with other functions it becomes easy to template certain types of things: wrappers, wrapped lists, sets of siblings, complex sets of HTML tags like video embeds, link helpers, etc.

Here's a little function that takes an array of content and creates 1 tag for each content item:

// Siblings helper
function siblings(tagName, contentArray) {

  return contentArray
           .map(tag => Array.isArray(tag)
                       ? html(tagName, tag[0], tag[1])
                       : html(tagName, tag)
           ).join('')

}

Now if we wanted to create a set of <li> elements with the texts "one", "two", and "three" and wrap that in a <ul>, we can write it like this:

html ('ul', siblings('li', ['one', 'two', 'three']))

Here's a link helper that will accept as much content as you have and return an <a> element, it wants url at a minimum, it would be nice if you also gave it link text, and if you also supply a title it will be very happy to use that as well:

// Link helper
function link(url, text, title) {

  url = url || '#'
  text = text || url
  title = title || text

  return `<a href="${url}" title="${title}">${text}</a>`

}

Now I'm not sure why I returned a template literal here rather than something like return html('a', …), but it works and it's simple. If we give it examples like this:

link()
link('staticresource.com/&)
link('staticresource.com/& 'StaticResource')
link('staticresource.com/& 'StaticResource', 'Visit StaticResource')

We will get this as the output HTML:

<a href="#" title="#">#</a>
<a href="staticresource.com/" title="staticresource.com/">https://staticresour…
<a href="staticresource.com/" title="StaticResource">StaticResource</a>
<a href="staticresource.com/" title="Visit StaticResource">StaticResource</a>

Lastly, here's a fun one - a responsive video embed container that outputs a wrapped <iframe> and the styles the wrapper and iframe need in order to resize and maintain its aspect ratio:

// Responsive Embed Helper
function embed(url, width, height) {

  url = url || '#'
  width = width || 560
  height = height || 315

  return html('div',
           html('iframe','',
             {
               src: url,
               width: width,
               height: height,
               frameborder: 0,
               style: `
                 position: absolute;
                 width: 100%;
                 height: 100%;
                 top: 50%;
                 left: 50%;
                 transform: translateX(-50%) translateY(-50%);
               `
             }
           ),
           {
             style: `
               position: relative;
               width: 100%;
               padding-bottom: calc(100% / (${width} / ${height}));
             `
           }
         )

}

Here I did make use of html() to return the HTML as a string and you can see how it let me store my CSS as template strings as well. Let's give it a little test with this JS:

embed('youtube.com/embed/LsoLEjrDogU&)

And this is the HTML we get back:

<div style=" position: relative; width: 100%; padding-bottom: calc(100% / (560/315));">
  <iframe src="youtube.com/embed/LsoLEjrDogU" width="560" height="315" frameborder="0" style="position: absolute; width: 100%; height: 100%; top: 50%; left: 50%; transform: translateX(-50%) translateY(-50%);"></iframe>
</div>

Anyway, I am not sure if that helps, or what this might be good for but I had a lot of fun passing functions as arguments and trying to figure out if I could encapsulate some of my HTML-building understanding into code logic that could be run.

Some projects you might want to have a peek at:

HyperScript: github.com/hyperhype/hyperscript

Seems similar in some ways - creating HTML from JS functions, but the way the arguments get passed in is a lot more verbose than the functions I came up with, it seems like it would be a hassle to write that much JS instead of just HTML.

Elm-lang/HTML: github.com/elm-lang/html

This is the HTML-creating part of the Elm language. It seems to 'do too much work' as well, like they try to whitelist all valid HTML tags: github.com/elm-lang/html/blob/master/src/Html.elm

lit-html: github.com/Polymer/lit-html

This project seems interesting, and they're all about using template literals in JS for extending HTML templating. I think these people will discover and develop some really useful techniques in this area!

1. Creating an element functionally

Advantages	Disadvantages
No string parsing, only JS functions	Tedious, because hella lot of LoC -> bad overview
Just hang a new element into the DOM
Add events on the element before even hanging it into the DOM

2. Appending a template literal containing actual HTML

Advantages	Disadvantages
Very simple	String parsing, DOM has to rebuilt partly
	Might have problems in an editor with highlighting and auto-complete
	Might lead to bad overview, if the snippets are big
	Re-add all event-listeners inside targetNode -> lots of trouble!

3. Use a hidden element and clone it

Advantages	Disadvantages
Just hang a new element into the DOM	template is part of your layout code
	Add event listeners after cloning; needs a query to find elements

4. Use a template element and import its content

Advantages	Disadvantages
Just hang a new element into the DOM	template is part of your layout code, but clearly marked with template tag
	Add event listeners after cloning; needs a query to find elements

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!

Even tho I lol'd very much and I agree with most of what you say. I think, the reality (at least in javascript) is that when you're a beginner, it's really hard to do things in vanilla. Hard to understand and, as you said it, hard to learn, because most "teachers" will tell you to just go for the frameworks. And once you're waist deep in jquery, it's really hard to get out of it, cause most of the work you've done depends on plugins, and all your understanding of how things really work are through the library. I think what the industry really needs is a bible, of good practices and how to get things done the right way, from zero to ninja. From hello world to a full responsive, interactive website.

For the purpose of encapsulating expertise in code for an experiment it can :D This returns everything you would need in HTML to do this particular thing. To put CSS in a stylesheet would require returning a <style> tag as well, but I see little advantage to that since you'd then also have to give each video wrapper a unique attribute so you could target it with the correct aspect ratio for each video. If you used the code to embed 10 videos you'd get 10 uniquely named <div> elements wrapping an <iframe>, followed by 10 nearly identical <style> tags with content that's the exact same…except for the selectors and the ${width} and ${height} value in one of the 2 rules.
I'm not sure what you mean here, it seems like you're talking about my CSS which is contained within a JS template string…
This is called the 'Padding Hack' technique, and is the industry standard for embedding scalable responsive iframes. I have a number of experimental plugins that add support for aspect ratios to CSS and I've even written a dream spec, but this particular method I have included here is what's considered the 'best practice' way to do it in CSS now. Here's an article explaining how it works from CSS-Tricks, and they even give a shoutout at the end to my other techniques: css-tricks.com/aspect-ratio-boxes

I know the padding hack, you set the aspect ratio on the DIV. You didn't set the DIV. (you also didn't set it to position:relative)... oh wait, you set that at the bottom. Weird I use the same general format for building on the DOM and still didn't see it. Thought that was being set on the iframe too; and you used calc which I can't since I still have to support legacy browsers for clients. To auto-calc I'd have to set it on the fly and trap window.resize, which is why usually for this I'd just set a class and have the variable styles static in my monolithic stylesheet, so I'm not wasting time setting values from JavaScript that might not apply to all media targets. People are WAY to easily... how to put this... duped into using Element.style when they don't need to. I mean the "big four" usually has you covered, and realistically if you're encountering anything other than 4:3 or 16:9 these days, something's wrong or you're dealing with highly specialized video.

AGAIN doing that in the external stylesheet since that type of information may be gibberish to other media targets. Same reason failing to set media="" on your <link> is as big an epic fail at web development as media="all". Also why I think whatWG's / W3C's removal of projection and TV and making the presence of unknown media targets a warning level event in validation is bullshit that undoes much of why the media attribute EVEN EXISTS!!!

ALSO why so many scripts these days go bits up face down for users with accessibility needs. If you actually are focused on accessibility and usability there's a LOT of things out there right now you just can't use... like calc... like adding content to the markup using JavaScript with no graceful degradation fallback. Case in point if this were a gallery of videos, I'd have the anchor pointing directly at the video link then intercept the anchors from the scripting... scripting off the link to the video launches normally.

I also missed the opening ' for your passing the style as markup -- something I wouldn't be doing and be passing as an object to set it on the new element, but that's because I'd be creating the element instead of dragging the browser performance down (and risking security holes) with innerHTML.

I think it's mostly just that I'm a "say no to innerHTML" kind of developer, and have a different focus than the current hot and trendy "just slop JavaScript all over the place who cares how many users it pisses off" that's all the rage these days.

Experimenting with fun stuff like this is more about learning how to pass things around in JS functions for me that about producing the HTML. I'm curious how HTML might be templated using JS, but mostly just using what I know of HTML as a playing ground for experimenting with string-building plugins, seeing where I can use objects and arrays to help me, etc.

I don't come from a programming background at all - I went to school for graphic design - so some of the stuff I'm doing in JavaScript I'm only doing in JavaScript because that's what I know and use, not necessarily because it's the best language to learn programming in, or because whatI'm doing is the best way to get that task done :D

Just having fun, learning JS, and playing around with some HTML

What you said about capturing window.resize and using JS to calculate the values needed, and supporting legacy clients - that's closer to the kind of stuff I actually do!

Unpopular opinion: honestly before I have to deal with all the disadvantages and time consuming process to get that stuff bug free working I would rather, for a small project, put in preact, take advantage of JSX and pure JavaScript and call it a day. And due 3Kb of size and virtual DOM implementation I’d guess it would at least quite as fast if not faster than direct DOM handling.

Sebastian true, that would be the practical solution. However, I want to toy with that situation and I really would like to know which method you'd work with and why. While it would further my insight into JS<->DOM interaction, it would also come in handy for some real projects for which I don't have a choice.

ok, if I had to choose I would go with No 1 and may No. 2 because at least it would feel like that I'm able to structure the code without losing overview. Hide and Clone, idk feels like cheating, however and the work, to integrate the cloned piece in and fix the loose ends it has from its cloning source, is potentially too high compared to the benefits.

Thread

Generating Elements With JS

Responses(7)

1. Creating an element functionally

2. Appending a template literal containing actual HTML

3. Use a hidden element and clone it

4. Use a template element and import its content

Recent threads

Search Hashnode

Generating Elements With JS

Responses(7)

1. Creating an element functionally

2. Appending a template literal containing actual HTML

3. Use a hidden element and clone it

4. Use a template element and import its content

Recent threads