Sorry, but getting the DOM parser involved is going full Gungan... the OPPOSITE of good practices in most cases. Likewise if we're talking websites, the overhead of HTML can actually become inefficient with large amounts of data, which is why you send JUST the data as JSON then glue it into DOM elements created BY the scripting.

JSON can transmit data in a smaller format, particularly if you limit yourself to Arrays. This is the Internet, that matters.

If you're working in client side JavaScript and are doing ANYTHING in strings that even remotely resembles HTML, you've not just screwed the pooch, you're sitting there hugging it whilst saying "it rubs the lotion on its skin"

Though your third bullet point at the start? Yeah, that's where most people make their first HUGE mistake. The train wreck laundry lists of how NOT to use HTML/CSS/JavaScript that are "Frameworks" are a blight upon the internet, propagated through propaganda and BALD FACED LIES, and on the whole developers are dumber for most of them even existing.

You also have the telltales of rookie code, what with the use of to set a border, the much slower querySelectorAll instead of getElementsByClassName when all you're doing is grabbing classes, not pre-selecting and storing for dynamic nodeLists, etc, etc. Even the markup of some of your examples is junk what with having multiple H1.

It's also a laugh your "goToXXX" scripts are things I don't even use JavaScript for anymore. :target and :checked along with adjacent selectors let me get rid of most of that junk.

No joke:

NOT JavaScript's job anymore. Even better it gracefully degrades scripting off to take you to each section since it's all triggered by hash links. Remember, quality client-side scripting should ENHANCE an already working page, not be the only means of supplying functionality. Otherwise you could land yourself in court for WCAG violations under the US ADA, UK EQA, or similar such regulations. Don't believe me? Ask Dominos and Beyonce.

It's also funny how much you TALK about the DOM, but clearly don't actually use it.

Saddest of all though is how you don't even know the most basic parts of HTML. What makes the name of a place and a UL a grammatical / semantic paragraph? Why would the name of a place get "more emphasis" instead of being the appropriate depth heading? Since you used section H1 is ok if you give a flying purple fish about legacy UA's and screen/braille readers (should probably be a H2) but the STRONG should be a H3. Or definition lists where all you have is definitions without any terms for them to define!!!

No offense, but I don't think you know enough HTML or CSS to even be playing with JavaScript, at least not on the client-side. The methodologies you are presenting and the code you have shown has a lack of proper semantics or structure, and is a walking talking accessibility violation BEGGING to get whoever you're building sites for sued in civil court or criminally prosecuted.

Written by

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store