Hello! I make Soundslice (soundslice.com), which is interactive/reflowable sheet music in the browser, synced with audio recordings and more loveliness. I very deliberately use canvas instead of SVG.

Soundslice isn't a score editor -- "just" a renderer (as if rendering sheet music is easy...!) -- so that influenced my decision. But if I were making an editor, I might make the same decision.

The reason is performance. A single piece of sheet music (a "score") might include thousands of individual glyphs, and if each one of those is a DOM element (as with SVG), the performance just wouldn't be as good as canvas.

One big tradeoff is that, with canvas, you need to implement your own hit detection (e.g., figure out what the user clicked on). But that's not super hard, and it's the kind of thing you write once and use forever.

Here's a tech talk I gave about an earlier version of Soundslice, where I talk about the canvas advantages: http://37signals.com/talks/soundslice

Either. http://www.vexflow.com/ and http://www.musicxml-viewer.com/ use canvas. http://www.alphatab.net/ and http://abcjs.net/ use svg.

I don't think you'd want to try and do this with web technologies. I followed StaffPad's development pretty closely (due to it being a project of my brother). They pushed what even Windows native apps could do to the limit to make this. It's performance sensitive and benefits a lot from serious pen APIs. The web is not a reasonable platform for solving every problem and this sort of boundary-pushing productivity app would be an especially bad fit for HTML5.