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 out. I did a more or less direct port of Hiccup to ClojureScript last year, which also returns strings like the original: https://github.com/teropa/hiccups. I haven't really been maintaining it, though, so it might take some work to get it running with recent ClojureScript versions. tiistai, 27. marraskuuta 2012 11.57.20 UTC+2 Dave Sann kirjoitti: > > 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 November 2012 01:51:30 UTC+11, Max Penet wrote: >> >> 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 >> strings (when working with a large number of Elements), for performance >> reason. This would help to solve such issues. >> >> Max >> >> >> On Sunday, November 25, 2012 12:11:09 PM UTC+1, Dave Sann wrote: >>> >>> 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 case of crate - directly producing DOM nodes in the browser >>> >>> My thought is that this would give a generic set of hiccup data >>> generating functions that could be easily used across both libs with >>> rendering specific to the environment. >>> >>> I don't generally use the libs in hiccup or crate because they are not >>> portable and slightly inconsistent in places - all my hiccup data >>> generation code can run on the server or on the browser. It might be good >>> to have a core unified set for both... >>> >>> thoughts? >>> >>> Dave >>> >>> >>> >>> -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
