title: What are the downsides of delegating Markdown parsing to the client side?
body: <p>I'm planning on including Markdown in a coming project. In the past, I've just used a pre-packaged server-side Markdown parser, re-sanitized the HTML output (an unnecessary step?) and shipped it off to the client.</p>
  
  <p>I'm interested in offloading at least this portion of the view rendering to the client. I've used client-side Javascript Markdown parsers with great success in Rails applications before. I'd delegate the body object to watch for DOM insertions of class <code>markdown-parseme</code> or the like and then to parse it and replace the original text with the result.</p>
  
  <p>But this is the first time I'm considering it for an in-the-wild production site. What are the gotchas and security concerns when letting the client handle Markdown rendering? Are there any specific libraries that take these issues into account?</p>
  
  <p><strong>EDIT:</strong> the obvious concern that springs to mind is "what about those without Javascript". It is perfectly within our capabilities to detect browsers that don't have Javascript enabled and to implement a mechanism that will allow clients to (perhaps manually) flag that they don't have JS and to move parsing to the server side. I would very much like to investigate if there are serious issues with offloading Markdown parsing to the client beyond this ordinary question of compatibility. Rendering a decently-sized page without output caching is adding a non-negligible amount to the response time and through that, the server load, and it would be nice if we could be confident in moving that task off the server for 95% of users.</p>