add note about synchronicity

docs/render.md

@@ -1,7 +1,8 @@
 # render(element, vnodes)
 
 - [API](#api)
-- [How it works](#how it works)
+- [How it works](#how-it-works)
+- [Why Virtual DOM](#why-virtual-dom)
 - [Differences from other API methods](#differences-from-other-api-methods)
 - [Standalone usage](#standalone-usage)
 
@@ -25,6 +26,12 @@ Argument    | Type                 | Required | Description
 
 The `m.render(element, vnodes)` method takes a virtual DOM tree (typically generated via the [`m()` hyperscript function](hyperscript.md), generates a DOM tree and mounts it on `element`. If `element` already has a DOM tree mounted via a previous `m.render()` call, `vnodes` is diffed against the previous `vnodes` tree and the existing DOM tree is modified only where needed to reflect the changes. Unchanged DOM nodes are not touched at all. 
 
+`m.render` is synchronous.
+
+---
+
+### Why Virtual DOM
+
 It may seem wasteful to generate a vnode tree on every redraw, but as it turns out, creating and comparing Javascript data structures is surprisingly cheap compared to reading and modifying the DOM.
 
 Touching the DOM can be extremely expensive for a couple of reasons. Alternating reads and writes can adversely affect performance by causing several browser repaints to occur in quick succession, whereas comparing virtual dom trees allows writes to be batched into a single repaint. Also, the performance characteristics of various DOM operations vary between implementations and can be difficult to learn and optimize for all browsers. For example, in some implementations, reading `childNodes.length` has a complexity of O(n); in some, reading `parentNode` causes a repaint, etc.