Member-only story

Building A Better JavaScript DOM Builder : Part 1

Jason Knight
CodeX
Published in
18 min readApr 18, 2024

Well, better might not be the right word. Everyone has a different definition of it; after all I think HTML/CSS frameworks all the know-nothing idiots run around singing the praises of are ignorant incompetent inept garbage created by frauds and poseurs.

One of the many aspects of working with HTML and JavaScript that is far too often neglected is the accessibility notion that if an element only works when JavaScript is present, it has ZERO business in your HTML. This is why some of the newer tags like <dialog> and <template> are just plain dumbass. Scripting off/blocked/irrelevant users you’re just confusing them with garbage that shouldn’t be there.

Likewise innerHTML is often a very poor answer. If you’re doing lots of small changes all over the DOM it can be really slow, and only has a speed advantage when you are literally belting out almost an entire page worth of content at once. Likewise if you need to hook it for events or plugging in live data you’re either stuck doing the dumbass “global scope functions” using the onevent attributes in the markup, or using getElementById or querySelector{All} once it is attached to the DOM.

Worse still are the security risks given that if you dump user generated data into innerHTML without sanitizing it first, you open up the door to XSS exploits. Whilst the…

The author made this story available to Medium members only.
If you’re new to Medium, create a new account to read this story on us.

Or, continue in mobile web

Already have an account? Sign in

CodeX
CodeX

Published in CodeX

Everything connected with Tech & Code. Follow to join our 1M+ monthly readers

Jason Knight
Jason Knight

Written by Jason Knight

Accessibility and Efficiency Consultant, Web Developer, Musician, and just general pain in the arse

Responses (12)

What are your thoughts?