The editor is essentially a virtual list - sliding buffer of DOM elements - only visible lines are represented in the DOM. That's probably the only reasonable way of doing such editors effectively in modern browsers. Drawback of this approach: hard to integrate platform scrollbar to that, quite a lot of JS code to support virtualization, etc.

Speaking about syntax/text highlighting in HTML ...

In Sciter I've added an option [1] to mark character runs without creating tons of heavy weight DOM elements (The Monaco uses <span>'s for that). Plus an option to style those run marks in CSS:

  plaintext > text::mark(keyword) { color: blue; }
  plaintext > text::mark(symbol) { color: brown; }

Editor's DOM model in Sciter's case is a flat list of <text> elements representing each line.

  <plaintext>
    <text>first line</text>
    <text>first line</text>
    ...
  </plaintext>

In fact such marks are needed not only for syntax colorizing but for other things like misspelling highlighting, text found highlighting and other cases where you need to highlight text but DOM change is highly non-desirable.

[1] Tokenizer + ::mark() = syntax colorizer : http://sciter.com/tokenizer-mark-syntax-colorizer/