A couple of things learned from the August Doc Sprint

This week-end was a MDN doc sprint. I haven’t had the time to do a lot, but some of the interactions have been really useful and i’d like to share a couple of things i’ve learned.


On the Doc Sprint Etherpad, I have noticed that Jonathan Wilsson (McGurk) added pages for setImmediate and clearImmediate. These not-yet-specified functions aim at being an efficient replacement to setTimeout(0) (which is clamped to 4ms for historical reasons) and its hack-ish postMessage based replacement.

In a way, this is a good news, but it’s a bit overlapping with what TC39 has in mind for concurrency. In an es-discuss e-mail, Mark Miller sounded enthusiastic with the idea of making Q.delay part of the default upcoming concurrency API. This would make 2 features for the same purpose. As stated in the es-discuss quoted thread i started, it would make more sense to bring setTimeout to ECMAScript rather than letting it be part of a web standard since timing issue aren’t really specific to the web. As a matter of fact Node.js uses the same API.

textContent VS innerText

I have improved the style for Node.textContent and have read with great interest the notes which state some difference with Microsoft’s innerText. One being that innerText cannot retrieve the text from <script> and <style> elements. Well… That is the explanation of why Selectivizr explains that “Styles defined in <style> tags won’t be parsed.” (in old IE, of course).

innerHTML counter-intuitive performance

I’ve added a security consideration section to the innerHTML page. It was the occasion to re-read the page and re-find Quircksmode performance test. And even in modern Firefoxes and Chrome, innerHTML keeps being (2-3 times) faster than creating DOM elements in memory and appending them. I have to admit that this is counter-intuitive for me (innerHTML requires parsing and creation of a document fragment while DOM elements manipulation doesn’t require the parsing). The best explanation i can come up with is that innerHTML is one line of JavaScript while the several creations and appending required to do the same operations require roundtrips between native code and JavaScript code. I’m looking forward to see dom.js being finished and hopefully integrated in browsers to re-test its performance against a native innerHTML.


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s