Markdown解析をクライアント側に委譲する際の弱点は何ですか？

Question

今後のプロジェクトにMarkdownを含める予定です。以前は、パッケージ化されたサーバーサイドのMarkdownパーサーを使用していましたが、HTML出力を不要にしてしまいました（不要な手順ですか？）。

私はビューレンダリングのこの部分をクライアントにオフロードすることに興味があります。私はクライアントサイドのJavascript Markdownパーサを使用していましたが、以前はRailsアプリケーションで大きな成功を収めていました。 bodyオブジェクトを委譲して、クラスmarkdown-parsemeなどのDOM挿入を監視し、解析して元のテキストを置き換えます。

しかし、これは野生の生産現場で初めて検討しています。クライアントがMarkdownレンダリングを処理する際の問題とセキュリティ上の懸念は何ですか？これらの問題を考慮する特定のライブラリがありますか？

EDIT：「Javascriptを使用していない人はどうですか？」という心配は明らかです。 Javascriptを有効にしていないブラウザを検出し、クライアントがJSを持たないことを（おそらく手動で）フラグを立て、解析をサーバー側に移動させるメカニズムを実装することは、私たちの能力の範囲内に完全にあります。 Markdown解析をクライアントにオフロードする際に重大な問題があるかどうかは、この通常の互換性の問題を超えて調査したいと思っています。出力キャッシュを持たない控えめなサイズのページをレンダリングすると、応答時間にそれほど無視できない量が追加され、それによってサーバー負荷が発生します。95％のユーザーに対してサーバーからそのタスクを移動することができたらいいでしょう。

Answer 1

クライアントがMarkdown構文を解析できるという前提は、少なくとも一部の人や検索エンジンにとっては間違っている可能性があります。これらのグループにサーバー解析バージョンを提供すると、コードが複製されます。サーバーは通常、XSSなどを防ぐより強力なツールを備えています（これは、サーバーが行うことです：ユーザーコンテンツからHTMLを安全に生成するためです）。

Answer 2

markdown-jsはまだ完成していませんが、異なるHTML変換段階ではなくASTを使用するマークダウンのサブセットのJavaScriptライブラリです。それは当初からまともなHTMLを生成するはずです。私は、このアプローチが適切に実行されると、クライアント側でのレンダリング・マークダウンを実用的にすると考えています。

埋め込みHTMLは意図的にサポートされていません。

Answer 3

今日、ほとんどの人はJavaScriptを使用しているので、問題ではありません。 showdownライブラリは、クライアント側のレンダリングに最適です。