PPK has numbers for this from a few years
ago: http://www.quirksmode.org/dom/innerhtml.html
A more recent benchmark: http://andrew.hedges.name/experiments/innerhtml/
There used to be a huge difference in favor of strings + innerHTML, but
with recent browsers the situation seems to have evened ou
I hadn't considered a need to generate html strings on the browser (at
least, not for performance). Do you have any references that demonstrate
that it is faster to parse strings than generate dom elements directly with
the js dom api. That seems counter-intuitive to me.
D
On Monday, 26 Novem
Another +1 (for those keeping score).
On 2012-11-25, at 9:01 AM, Murphy McMahon wrote:
> +1 for sure! I dug into Crate a while ago specifically to see if I could
> generate strings instead of DOM objects, and was unable to untangle the
> parsing from the output. This would be very useful.
>
>
+1 for sure! I dug into Crate a while ago specifically to see if I could
generate strings instead of DOM objects, and was unable to untangle the
parsing from the output. This would be very useful.
On Sun, Nov 25, 2012 at 12:51 PM, Max Penet wrote:
> Strong +1
>
> This is a great idea.
> This wo
Strong +1
This is a great idea.
This would allow more flexibility in some corner cases and
prevent unnecessary duplication, not to mention sharing.
Another example: I believe crate compiles templates using the DOM API,
which is often fine, but sometimes you'd want it to do this using raw
stri
I wonder if it would be worth making the effort to separate the hiccup
rendering from the hiccup generation in these libraries.
By hiccup generation, I mean constructing data of the form [:tag {:attr
val} contents] ...
By rendering, I mean
in the case of hiccup - producing HTML strings
in the
