
Show HN: mvdom 0.9 – scalable HTML Native MVC library – 5kb – Real DOM is back - jeremychone
https://github.com/mvdom/mvdom
======
gigatexal
Not a front end dev at all just saw the call to innerHTML isn’t that a
security hole?

~~~
jeremychone
First, the use of 'innerHTML' is just for the sake of examples and mvdom does
not promote one way or another.

Now on the broader discussion between innerHTML vs appendChild (with or
without DocumentFragment). There is no real security issue between using one
way or the other, as both get processed by the browser anyway.

The issue was more around performance. innerHTML used to be considered a bad
pattern because developers did it in for loops on elements attached to the DOM
which unnecessarily added a lot of work on the rendering. However, doing
repeating appendChild on a document DOM element will create extra browser work
as well.

The key is to that to minimize DOM change of elements that are attached to the
document, regardless if it is with appendChild or innerHTML. We found that
proper use of innerHTML also can dramatically simplify code with no drawbacks.
If you need to do some work on the DOM element before adding it to the
document, then you can create a DocumentFragment (still with innerHTML) and
then work on the DOM element outside of the document before adding the
DocumentFragment to the appropriate document element. As we can see, the issue
was not to use or not to use innerHTML but rather when to add a blob of
content to the document.

Now mvdom is template agnostic, so, one can even use some templating engine
like lit-html and get the same benefits than react rendering but without the
overhead (i.e., render/re-render black magic)

Note: While innerHTML should be demystified, .innerText should be avoided at
all cost, and .textContent should be used.

