js-framework-benchmark
js-framework-benchmark copied to clipboard
Note: Implementation uses innerHTML for node generation
As more and more frameworks start using innerHTML
and cloneNode
for accelerating node generation, I think this is worth mentioning.
- Security concerns(e.g. XSS).
- Is it still fair to call them "JS" frameworks since they're doing HTML manipulation instead of DOM, while HTML is obviously not a JS directly related thing.
- Native HTML implementation speed may vary vastly between browsers, this could not represent actual daily usage.
- Universality. Derived from 2, there're non-browser DOM implementations that don't support setting
innerHTML
(e.g. DOMiNATIVE for NativeScript and CheeseDOM for Resonance). While using standard DOM APIs, frameworks can work both in browser and on these DOM impls, widening their real world usage, but usinginnerHTML
optimize only for browsers breaks their universatility.
I'd like to hear more opinions, my points of view may not represent yours.
Why do you consider cloneNode to be equivalent to innerHTML? I use a shallow cloneNode on cached (empty) nodes, so it really is just a slightly faster createElement.
@SahAssar
Why do you consider cloneNode to be equivalent to innerHTML? I use a shallow cloneNode on cached (empty) nodes, so it really is just a slightly faster createElement.
For native implementations, creating nodes usually result in an actual native component is created alongside. Since cloneNode requires an existing node as template, it's not desired to have a native component always taken place in the memory doing nothing.
@ClassicOldSong Gotcha, but I think there are two very different things between innerHTML and cloneNode. As you said innerHTML can lead to security concerns and requires a HTML parser. cloneNode on the other hand does not lead to any specific security concerns or require a HTML parser as far as I am aware.
If the note is added I think it'd be good to keep them separate.
Yeah if separated that's more clear, can be another note for cloneNode