値下げについての考え

公開: 2022-03-10
簡単な要約↬すべてのフレーバー、解釈、およびフォークの値下げは消えません。 ただし、現代のニーズを網羅しようとする新しいコンテンツ形式を検討することが重要です。 この記事では、Knutが、Markdownが最初に導入された理由を振り返り、Web上のコンテンツの主要な開発のいくつかを経験することによって、Markdownに対するアドバイスを共有します。

マークダウンは私たちの多くにとって第二の性質です。 振り返ってみると、ジョン・グルーバーがアーロン・スワーツと言語を共同で開発した後、2004年に最初のPerlベースのパーサーをリリースしてから間もなくMarkdownの入力を開始したことを覚えています。

Markdownの構文は、Web用の書き込み形式として使用するという1つの目的を目的としています。

—ジョン・グルーバー

それはほぼ20年前のことです—そうです！ HTMLのよりライターとリーダーに優しい構文として始まったものは、プログラマーと技術に精通した人々のために技術的な散文を書き、保存する方法の最愛の人になりました。

Markdownは、開発者とテキストをいじくり回す文化の象徴です。 しかし、その導入以来、デジタルコンテンツの世界も変化しました。 Markdownはまだいくつかの点で問題ありませんが、それがもはやコンテンツの頼りになるべきではないと私は信じています。

これには2つの主な理由があります。

  1. Markdownは、今日のコンテンツのニーズを満たすようには設計されていません。
  2. Markdownは編集経験を抑制します。

もちろん、このスタンスは、構造化されたコンテンツのプラットフォームで働くことによって影響を受けます。 Sanity.ioでは、データとしてのコンテンツがどのように多くの価値を解き放つかについて考えることにほとんどの日を費やしています。また、エディターエクスペリエンスについて深く考え、人々の時間を節約し、デジタルコンテンツでの作業を楽しいものにする方法について多くの時間を費やしています。 。 つまり、ゲームにはスキンがありますが、コンテンツの頼りになるフォーマットとしてMarkdownに反対しますが、その重要性、アプリケーション、およびレガシーに深い感謝を持っていることを表現できることを願っています。

現在のギグの前は、代理店でテクノロジーコンサルタントとして働いていました。そこでは、クライアントのコンテンツをプレゼンテーションや複雑なデータモデル（オープンソースのものでも）に埋め込むことで、クライアントのコンテンツをロックダウンするCMSと文字通り戦わなければなりませんでした。 私は人々がMarkdown構文に苦労し、編集者やコンテンツ作成者としての仕事に意欲を失っているのを観察しました。 構文を使用する時間や動機がないために使用されたことのないカスタムタグレンダラーの構築に何時間も（そしてクライアントのお金も）費やしてきました。 私でさえ、非常にやる気があれば、コンポーネントベースのMarkdownの実装があまりにも多くの摩擦をもたらしたため、オープンソースドキュメントへの貢献をあきらめました。

しかし、コインの裏側も見えます。 Markdownには印象的なエコシステムが付属しており、開発者の観点からは、プレーンテキストファイルにエレガントなシンプルさがあり、コードを読むことに慣れている人にとっては構文解析が簡単です。 私はかつて、アカデミックライティングのために、印象的なMultiMarkdown > LaTeX > real-time-PDF-preview-pipeline inSublimeTextを構築するのに何日も費やしました。 また、 README.mdファイルをコードエディターで開いて編集し、GitHubで適切にレンダリングできることは理にかなっています。 Markdownがいくつかのユースケースで開発者に便利さをもたらすことは間違いありません。

だからこそ、Markdownが最初に導入された理由を振り返り、Web上のコンテンツの主要な開発のいくつかを経験することによって、Markdownに対するアドバイスを構築したいと思います。 私たちの多くにとって、Markdownは「存在するもの」として当然のことと思っているものだと思います。 しかし、すべてのテクノロジーには歴史があり、人間の相互作用の産物です。 これは、読者であるあなたが他の人が使用できるテクノロジーを開発するときに覚えておくことが重要です。

フレーバーと仕様

Markdownは、WebパブリッシングでHTMLの記述が必要な時代に、Webライターが記事を簡単に操作できるようにするために設計されました。 そのため、HTMLのテキストフォーマットとのインターフェースを簡単にすることが目的でした。 これは地球上で最初の単純化された構文ではありませんでしたが、何年にもわたって最も注目を集めた構文でした。 今日、Markdownの使用法は、HTMLを読み書きするためのより簡単な方法であるという設計意図をはるかに超えて、多くの異なるコンテキストでプレーンテキストをマークアップするアプローチになりました。 確かに、テクノロジーとアイデアは意図を超えて進化する可能性がありますが、今日のMarkdownの使用における緊張は、この起源とその設計に課せられた制約に起因する可能性があります。

構文に慣れていない場合は、次のHTMLコンテンツを使用してください。

 <p>The <a href=”https://daringfireball.net/projects/markdown/syntax#philosophy”>Markdown syntax</a> is designed to be <em>easy-to-read</em> and <em>easy-to.write</em>.</p>

Markdownを使用すると、次のように同じフォーマットを表現できます。

 The [Markdown syntax](https://daringfireball.net/projects/markdown/syntax#philosophy) is designed to be _easy-to-read_ and _easy-to-write_.

テクノロジーの採用には、進化して機能を追加するというプレッシャーが伴うというのは、自然法則のようなものです。 Markdownの人気が高まっているということは、人々がMarkdownをユースケースに適応させたいということを意味していました。 彼らは脚注や表のサポートのようなより多くの機能を望んでいました。 元の実装には意見のあるスタンスがあり、当時の設計意図は次のとおりでした。

Markdownの構文でカバーされていないマークアップについては、HTML自体を使用するだけです。 MarkdownからHTMLに切り替えていることを示すために、前に付けたり、区切りを付けたりする必要はありません。 タグを使用するだけです。

—ジョン・グルーバー

つまり、テーブルが必要な場合は、 <table></table>を使用します。 これは、元の実装にも当てはまることがわかります。 Markdownの精神的後継者の1人であるMDXも同じ原則を採用していますが、JSベースのテンプレート言語であるJSXに拡張しています。

マークダウンからマークダウンへ？

多くの人にとってMarkdownの魅力は、HTMLとの結びつきではなく、平文の人間工学とフォーマットの単純な構文であるように見えます。 一部のコンテンツ作成者は、Web上の単純な記事以外のユースケースにMarkdownを使用したいと考えていました。 MultiMarkdownのような実装では、プレーンテキストファイルを使用したいが、より多くの機能が必要なアカデミックライターにアフォーダンスが導入されました。 すぐに、必ずしもHTMLに変換したり、ストレージ形式としてマークダウン構文を使用したりすることなく、マークダウン構文を受け入れるさまざまな書き込みアプリができあがります。

多くのアプリには、限られたフォーマットオプションのセットを提供するエディターがあり、それらのいくつかは、元の構文からより「インスピレーションを得た」ものです。 実際、この記事のドラフトで私が得たフィードバックの1つは、「Markdown」は非常に一般的になっているため、元の実装と区別するために、今では小文字にする必要があるというものでした。 私たちがマークダウンとして認識するものも非常に多様になっているからです。

CommonMark：値下げを抑える試み

アイスクリームのように、Markdownには多くのフレーバーがあり、他のフレーバーよりも人気があります。 人々が元の実装をフォークしてそれに機能を追加し始めたとき、2つのことが起こりました：

  1. ライターとしてのあなたがMarkdownでできることとできないことは、より予測不可能になりました。
  2. ソフトウェア開発者は、ソフトウェアに採用する実装を決定する必要がありました。 元の実装には、プログラムで使用したい人に摩擦を加えるいくつかの矛盾も含まれていました。

これにより、Markdownを適切な仕様に形式化することについての会話が始まりました。 Gruberは、人々がさまざまな目的でMarkdownを使用したいと考えており、「誰もがすべてを幸せにすることはできない」と認識していたため、Gruberが抵抗し、今でも興味深いことに取り組んでいます。 Markdownがさまざまなニーズに対応するために進化する仕様であるHTMLに変換されることを考えると、これは興味深いスタンスです。

Markdownの元の実装は「BSDライク」ライセンスでカバーされていますが、「Markdownの名前もその貢献者の名前も、書面による事前の特別な許可なしに、このソフトウェアから派生した製品を推奨または宣伝するために使用することはできません。 」 マーケティング資料の一部として「Markdown」を使用するほとんどの製品は、この書面による許可を取得していないと安全に推測できます。

Markdownを共有仕様にするための最も成功した試みは、今日CommonMarkとして知られているものです。 それは、ジェフ・アトウッド（スタックオーバーフローとディスコースの共同設立者として知られている）とジョン・マクファーレン（バベルマークとパンドックの背後にいるバークレーの哲学教授）によって率いられました。 当初は「StandardMarkdown」として発売しましたが、Gruberからの批判を受けて「CommonMark」に変更しました。 スタンスが一貫していた場合、Markdownの目的は、HTMLに変換される単純なオーサリング構文になることです。

これは、Markdownがパブリックドメインに入ったポイントでもあると思います。 CommonMarkは「Markdown」としてブランド化されていませんが、（ライセンスに従って）この仕様は認識され、「markdown」と呼ばれます。 今日では、Discourse、GitHub、GitLab、Reddit、Qt、Stack Overflow、Swiftなどのソフトウェアの基盤となる実装としてCommonMarkが見つかります。 unified.jsのようなプロジェクトは、構文を抽象構文木に変換することで構文をブリッジします。また、マークダウンのサポートをCommonMarkに依存しています。

CommonMarkは、マークダウンの実装方法に関して多くの統一をもたらし、多くの点で、プログラマーがマークダウンサポートをソフトウェアに統合することをより簡単にしました。 しかし、それはマークダウンがどのように書かれ、使用されるかについて同じ統一をもたらしていません。 GitHub Flavoured Markdown（GFM）を利用してください。 CommonMarkに基づいていますが、より多くの機能（テーブル、タスクリスト、取り消し線など）で拡張されています。 Redditは、「Reddit Flavoured Markdown」を「GFMのバリエーション」と表現し、スポイラーをマークアップするための構文などの機能を導入しています。 CommonMarkとGruberの背後にあるグループの両方が正しかったと安全に結論付けることができると思います。それは確かに共有仕様に役立ちますが、そうです、人々はさまざまな特定のことにMarkdownを使用したいと思っています。

フォーマットショートカットとしてのマークダウン

Gruberは、Markdownを共有仕様に形式化することに抵抗しました。これは、Markdownがライター向けのツールではなく、プログラマー向けのツールになると考えたためです。 仕様が広く採用されていても、さまざまなコンテキストで同じように機能する構文が自動的に取得されないことはすでに見てきました。 そして、そのまま人気のあるCommonMarkのような仕様も、限られた成功しか収めていません。 明らかな例は、 *this*をstrong/ boldに変換し、強調/イタリックではなく、 [link](https://slack.com)構文をサポートしないが、 <link|https://slack.com>を使用するSlackのマークダウン実装（ mrkdownと呼ばれる）です。代わりに<link|https://slack.com> 。

また、Markdownのような構文を使用して、Notion、Dropbox Paper、Craftなどのソフトウェアのリッチテキストエディターでフォーマットを初期化できることもわかります。ある程度、Googleドキュメント（たとえば、新しい行のasterisk + spaceは箇条書き）。 サポートされているものと、変化するものに変換されるもの。 したがって、これらのアプリケーション全体で必ずしも筋肉の記憶を持ち歩くことはできません。 一部の人々にとって、これは問題なく、彼らは適応することができます。 他の人にとっては、これはペーパーカットであり、これらの機能を使用できないようにします。 Markdownは誰のために設計されたのか、そして今日そのユーザーは誰なのか、どちらが質問をしますか？

ジャンプした後もっと！ 以下を読み続けてください↓

Markdownのユーザーは誰であると想定されていますか？

マークダウンは、さまざまなユースケース、オーディエンス、およびそのユーザーが誰であるかという概念の間の緊張関係に存在することがわかりました。 特にHTMLに精通したWebライターのマークアップ言語として始まったものは、開発者タイプの最愛の人になりました。

2014年、Webライターは、PerlおよびFTPのパーサーを介したファイルの移動から離れ始めました。 WordPress、Drupal、Moveable Type（Gruberが今でも使用していると思います）などのコンテンツ管理システム（CMS）は着実に成長し、Webパブリッシングの頼れるツールになりました。 彼らは、ウェブライターがブラウザで使用できるリッチテキストエディタのようなアフォーダンスを提供しました。

これらのリッチテキストエディターは、基になるリッチテキスト構文としてHTMLとMarkdownを想定していましたが、この構文をエディターに挿入するボタンを追加することで、認知的オーバーヘッドの一部を取り除きました。 そしてますます、ライターはHTMLに精通している必要はなく、またその必要もありませんでした。 2010年代にCMSを使用してWeb開発を行った場合、Wordから直接貼り付けたときにこれらのエディターを介して発生した「ジャンクHTML」に対処する必要があったに違いありません。

今日、私はMarkdownの主要なユーザーが開発者とコードに興味を持っている人々であると主張します。 ソフトウェアが技術部門以外のより多くの人々によって使用された後、SlackがWYSIWYGをデフォルトの入力モードにしたのは偶然ではありません。 そして、これが物議を醸す決定であり、オプションとしてそれを取り戻さなければならなかったという事実は、マークダウンへの愛が開発者コミュニティにどれほど深いかを示しています。 Slackを誰にとっても簡単でアクセスしやすいものにしようとしていることを祝うことはあまりありませんでした。 そして、これが問題の核心です。

マークダウン付きのSlackに関するコメントセクション。
（大プレビュー）

マークダウンのイデオロギー

マークダウンが共通語の書き方になっているという事実、そしてほとんどのWebサイトのフレームワークが対応していることも、私がこれを公開することに少し気が進まなかった主な理由です。 それはしばしば本質的で否定できない善として語られます。 マークダウンは、開発者に優しいことの特徴となっています。 賢くて熟練した人々は、あらゆる種類のコンテキストでマークダウンを可能にするために多くの時間を費やしてきました。 ですから、その覇権に挑戦することは確かにいくつかを苛立たせるでしょう。 しかし、うまくいけば、それはしばしば当たり前のことと見なされていることについての実りある議論を生み出すことができます。

私の印象では、Markdownに関係する開発者の親しみやすさは、主に3つの要因に関係しています。

  1. プレーンテキストファイルの快適な抽象化。
  2. ツールのエコシステムがあります。
  3. コンテンツを開発ワークフローに近づけることができます。

これらのスタンスが間違っていると言っているわけではありませんが、トレードオフといくつかの不合理な仮定が伴うことをお勧めします。

プレーンテキストファイルの単純なメンタルモデル

データベースは素晴らしいものです。 しかし、フロントエンド開発者にとっては困難でアクセスできないという評判もあります。 私は、バックエンドのコードやデータベースを敬遠する多くの優れた開発者を知っています。なぜなら、それらは時間をかけたくない複雑さを表しているからです。 セットアップ後にデータベースを処理する必要がないように、箱から出してすぐに多くのことを行うWordPressを使用しても、起動して実行するのはオーバーヘッドでした。

ただし、プレーンテキストファイルはより具体的であり、推論するのはかなり簡単です（ファイル管理に慣れている限り）。 特に、独自の構造を持つリレーショナルデータベースでコンテンツを複数のテーブルに分割するシステムと比較してください。 画像やリンクを含む単純なリッチテキストのブログ投稿など、限られたユースケースでは、マークダウンによって作業が完了します。 ファイルをコピーしてフォルダーに貼り付けるか、gitにチェックインできます。 ファイルの具体性により、コンテンツはあなたのものだと感じます。 マイクロソフトが所有する営利目的のSoftwareasa ServiceであるGitHubでホストされている場合でも、利用規約の対象となります。

ローカル開発を開始し、リモートとの同期を処理するために実際にローカルデータベースを起動する必要があった時代では、プレーンテキストファイルの魅力は理解できます。 しかし、その時代は、サービスとしてのバックエンドの出現でほとんどなくなりました。 Fauna、Firestore、Hasura、Prisma、PlanetScale、Sanity's Content Lakeなどのサービスとツールは、開発者の経験に多額の投資をしています。 ローカル開発で従来のデータベースを操作することでさえ、わずか10年前に比べて面倒ではなくなりました。

あなたがそれについて考えるならば、それがデータベースでホストされているならば、あなたはあなたのコンテンツをより少なく所有しますか？ また、SaaSツールの登場により、データベースを扱う開発者の経験は大幅に簡素化されたのではないでしょうか。 そして、プロプライエタリデータベーステクノロジーがコンテンツの移植性に影響を与えていると言っても過言ではありませんか？ 今日では、sysadminスキルのない本質的にPostgresデータベースを起動し、テーブルと列を作成し、その中にコンテンツを配置し、いつでも.sqlダンプとしてエクスポートできます。

コンテンツの移植性は、そもそもそのコンテンツをどのように構成するかと関係があります。 WordPressを利用してください。完全にオープンソースであり、独自のDBをホストできます。 XMLで標準化されたエクスポート形式もあります。 しかし、成熟したWordPressのインストールから抜け出そうとした人なら誰でも、WordPressから離れようとしている場合にこれがどれほど役に立たないかを知っています。

広大なエコシステム…開発者向け

広大なマークダウンエコシステムについてはすでに触れました。 現代のウェブサイトフレームワークを見ると、それらのほとんどはマークダウンを主要なコンテンツ形式として想定しており、一部は唯一の形式です。 たとえば、Smashing Magazineで使用されている静的サイトジェネレーターであるHugoは、ページ化された公開のためにマークダウンファイルを必要とします。 つまり、Smashing MagazineがCMSを使用して記事を保存する場合は、マークダウンファイルを操作するか、すべてのコンテンツをマークダウンファイルに変換する必要があります。 Next.js、Nuxt.js、VuePress、Gatsby.jsなどのドキュメントを見ると、マークダウンが目立つように表示されます。 これは、GitHubのREADMEファイルのデフォルトの構文でもあり、プルリクエストのメモやコメントの書式設定にも使用されます。

マークダウンの人間工学を大衆にもたらすためのイニシアチブについてのいくつかの名誉ある言及があります。 Netlify CMSとTinaCMS（Forestryの精神的な子孫）は、マークダウン構文が編集者のためにほとんど抽象化されているユーザーインターフェイスを提供します。 CMSのマークダウンベースのエディターは、フォーマットのプレビュー機能を提供することがよくあります。 Notionのような一部のエディターでは、マークダウン構文を貼り付けて、ネイティブフォーマットに変換します。 しかし、マークダウンのために革新するために費やされたエネルギーは、その構文を書くことに熱心でない人々を支持していないと言っても過言ではありません。 それがそうであったように、それはスタックをだましていません。

コンテンツワークフローまたは開発者ワークフロー？

ブログを作成する開発者にとって、マークダウンファイルを使用すると、フレームワークに組み込みの解析が付属するか、通常はスターターコードの一部として提供されるため、ブログを起動して実行するためのオーバーヘッドの一部が削減されます。 そして、サインアップするために余分なものは何もありません。 gitを使用して、コードと一緒にこれらのファイルをコミットできます。 git diffに慣れている場合は、プログラミングに慣れているようなリビジョン管理も可能です。 つまり、マークダウンファイルはプレーンテキストであるため、開発者のワークフローと統合できます。

しかし、これを超えると、開発者のエクスペリエンスはすぐに複雑になります。 そして、コンテンツクリエーターとしてのチームのユーザーエクスペリエンスに妥協し、私たち自身の開発者エクスペリエンスは、設計意図をはるかに超えた問題を解決するためにマークダウンに固執することになります。

はい、コンテンツチームにgitを使用して変更をチェックインさせると便利かもしれませんが、同時に、これが彼らの時間の最善の使用法ですか？ あなたは本当にあなたの編集者がマージの衝突やブランチをリベースする方法にぶつかって欲しいですか？ Gitは、毎日それを使用する開発者にとっては十分に難しいものです。 そして、このセットアップは、主にコンテンツを扱う人々にとって本当に最高のワークフローを表していますか？ これは、開発者の経験が編集者の経験を打ち負かした場合ではなく、ユーザーにとってより良いものを作るために費やすことができるコスト、時間、労力ではありませんか？

コンテンツと編集環境からの期待とニーズが進化しているので、マークダウンが私たちのためにそれをすることはないと思います。 開発者の人間工学の一部が最終的に非開発者を支持するようになるかどうかはわかりません。開発者にとっても、マークダウンは私たち自身のコンテンツ作成を妨げており、必要性を抑えていると思います。 2000年代初頭以来、Web上のコンテンツが大幅に変更されたためです。

段落からブロックへ

より複雑なものが必要な場合、Markdownには常にHTMLをオプトアウトするオプションがありました。 これは、作成者がWebマスターでもある場合、または少なくともHTMLを知っている場合にうまく機能しました。 Webサイトは通常ほとんどHTMLとCSSであったため、これもうまく機能しました。 Webサイトを設計する方法は、主にページ全体のレイアウトを作成することでした。 MarkdownをHTMLマークアップに変換し、 style.cssファイルと一緒に配置することができます。 もちろん、2000年代にもCMSと静的サイトジェネレーターがありましたが、コンポーネント間で「小道具」を渡さずにテンプレート内にHTMLコンテンツを挿入することで、ほとんど同じように機能しました。

しかし、私たちのほとんどは、昔のようにHTMLを実際に作成することはもうありません。 Web上のコンテンツは、ほとんどが単純なリッチテキスト形式の記事から、多くの場合ユーザーとの対話機能を備えたマルチメディアおよび特殊なコンポーネントで構成されたものに進化しました（これは「ニュースレターのサインアップによる行動の呼びかけ」のファンシーな言い方です）。

記事からアプリへ

2010年代初頭、Web 2.0は全盛期を迎え、Software asaService-企業はデータ量の多いアプリケーションにWebを使用し始めました。 HTML、CSS、およびJavaScriptは、インタラクティブなUIを駆動するためにますます使用されています。 TwitterのオープンソースのBootstrap、より一貫性のある復元力のあるユーザーインターフェイスを構築するためのフレームワーク。 これにより、Webデザインの「コンポーネント化」と呼べるものが生まれました。 それは私たちがウェブのために構築する方法を根本的な方法で変えました。

この時代に登場したさまざまなCSSフレームワーク（BootstrapやFoundationなど）は、標準化されたクラス名を使用する傾向があり、特定のHTML構造を想定して、復元力と応答性の高いユーザーインターフェイスを作成するのを難しくしていませんでした。 Atomic DesignのWebデザイン哲学と、Block-Element-Modifier（BEM）のようなクラス名の規則により、デフォルトは、ページレイアウトを最初に考えることから、ページを繰り返し可能で互換性のあるデザイン要素のコレクションとして表示することへとシフトしました。

マークダウン内にあるコンテンツは、これと互換性がありません。 マークダウンパーサーを挿入するといううさぎの穴を掘り下げて、必要な構文を出力するように微調整しない限り（これについては後で詳しく説明します）。 当然のことながら、Markdownは、スタイルシートでターゲットとするネイティブHTML要素の単純なリッチテキスト記事になるように設計されています。

これは、Markdownを使用してサイトのコンテンツを促進する人々にとっては依然として問題です。

埋め込み可能なWeb

しかし、私たちのコンテンツにも何かが起こりました。 セマンティックな<article> HTMLタグの外でそれを見つけ始めることができただけでなく、より多くの…ものが含まれるようになりました。 私たちのコンテンツの多くは、LiveJournalやブログからソーシャルメディア（Facebook、Twitter、tumblr、YouTube）に移動しました。 コンテンツのスニペットを記事に戻すには、それらを埋め込むことができる必要がありました。 HTML規則では、 <iframe>タグを使用して、YouTubeからビデオプレーヤーをチャネリングしたり、テキストの段落の間にツイートボックスを挿入したりし始めました。 一部のシステムは、これを「ショートコード」に抽象化し始めました。ほとんどの場合、それが表すコンテンツのブロックを識別するためのキーワードと、いくつかのKey-Value属性を含むブラケットです。 たとえば、dev.toは、テンプレート言語のリキッドからの構文をMarkdownエディターに挿入できるようにしました。

 {% youtube dQw4w9WgXcQ %}

もちろん、これには、カスタマイズされたMarkdownパーサーを使用する必要があり、構文がHTMLに変換されたときに正しいHTMLが挿入されたことを確認するための特別なロジックが必要です。 また、コンテンツ作成者はこれらのコードを覚えておく必要があります（コードを自動的に挿入するための何らかのツールバーがない限り）。 また、角かっこが削除されたり、混乱したりすると、サイトが破損する可能性があります。

しかし、MDXはどうですか？

ブロックコンテンツの必要性を解決する試みはMDXであり、「コンポーネント時代のマークダウン」というタグラインが付けられています。 MDXを使用すると、JSXテンプレート言語とJavaScriptをマークダウン構文でインターレースして使用できます。 MDXの周りのコミュニティには、さまざまな構文を抽象構文木（AST）に解析することを専門とする、 Unified.jsを含む多くの印象的なエンジニアリングがあり、プログラムで使用するためによりアクセスしやすくなっています。 マークダウンの標準化により、 Unified.jsの背後にいる人々とそのユーザーの作業が簡単になることに注意してください。これは、対応するエッジケースが少ないためです。

MDXは確かに、コンポーネントをMarkdownに統合する際の開発者エクスペリエンスを向上させます。 ただし、コンテンツの作成と編集に多くの認知的オーバーヘッドが追加されるため、編集者のエクスペリエンスは向上しません。

 import {Chart} from './snowfall.js' export const year = 2018 # Last year's snowfall In {year}, the snowfall was above average. It was followed by a warm spring which caused flood conditions in many of the nearby rivers. <Chart year={year} color="#fcb32c" />

この単純な例のためだけに想定される知識の量はかなりのものです。 ES6モジュール、JavaScript変数、JSXテンプレート構文、および小道具、16進コード、データ型の使用方法について知っている必要があります。また、使用できるコンポーネントとその使用方法について理解している必要があります。 そして、あなたはそれを正しくそしてあなたにある種のフィードバックを与える環境でそれをタイプする必要があります。 MDXの上にもっとアクセスしやすいオーサリングツールがあることは間違いありません。そもそも問題である必要のないものを解決するような気がします。

MDXコンポーネントの作成方法と名前付けに非常に熱心でない限り、コンテンツを特定のプレゼンテーションに結び付けることもできます。 MDXのフロントページから持ってきた上記の例を見てください。 チャートのハードコードされたカラーヘックスがあります。 サイトを再設計する場合、その色は新しい設計システムと互換性がない可能性があります。 もちろん、これを抽象化してprop color=”primary”を使用することを妨げるものは何もありませんが、このような賢明な決定を下すように促すツールもありません。

コンテンツに特定のプレゼンテーションの懸念事項を埋め込むことは、ますます責任になり、コンテンツの適応、反復、および迅速な移動の妨げになるものになっています。 データベースにコンテンツを含めるよりもはるかに微妙な方法でロックダウンします。 プラグインを使用した成熟したWordPressインストールから移動するのと同じ場所に移動するリスクがあります。 構造と表現を切り離すのは面倒です。

構造化コンテンツの需要

より複雑なサイトとユーザージャーニーでは、Webサイト全体に同じコンテンツを表示する必要もあります。 eコマースサイトを運営している場合は、単一の商品ページ以外の多くの場所に商品情報を埋め込む必要があります。 最新のマーケティングサイトを運営している場合は、複数のパーソナライズされたビュー間で同じコピーを共有できるようにする必要があります。

これを効率的かつ信頼性の高い方法で行うには、構造化コンテンツを適応させる必要があります。 つまり、コンテンツにメタデータを埋め込み、意図を解析できるようにチャンク化する必要があります。 開発者が「コンテンツ」を含む「ページ」を見るだけの場合、適切なものを適切な場所に含めることは非常に困難です。 APIまたはクエリを使用してすべての「製品の説明」にアクセスできれば、すべてが簡単になります。

マークダウンを使用すると、分類法と構造化コンテンツの表現が、ある種のフォルダー編成（複数の分類法に同じコンテンツを配置するのが困難になる）に制限されるか、構文を別のもので拡張する必要があります。

マークダウンファイル用に構築された初期の静的サイトジェネレーター（SSG）であるJekyllは、上部の3つのダッシュの間にYAML（スペースを使用してスコープを作成する単純なキー値形式）を使用して投稿にメタデータを追加する方法として「FrontMatter」を導入しましたファイルの。 したがって、これで2つの構文を処理する必要があります。 YAMLは、いたずら好きであるという評判もあります（特にノルウェー出身の場合）。 それにもかかわらず、他のSSGはこの規則を採用しており、コンテンツ形式としてマークダウンを使用するgitベースのCMSも採用しています。

構造化コンテンツのアフォーダンスを取得するためにプレーンファイルに構文を追加する必要がある場合、それが本当に価値があるかどうか疑問に思うかもしれません。 そして、そのフォーマットは誰のためのもので、誰を除外するのか。

あなたがそれについて考えるならば、私たちがウェブ上で行うことの多くは、コンテンツを消費するだけでなく、それを作成しています！ 私は現在、この長い記事をブラウザの高度なワードプロセッサで書いています。

最新のコンテンツアプリケーションでブロックコンテンツを作成することもできるはずだという期待が高まっています。 人々は、機能し、見栄えがよく、特殊な構文を学ぶ必要がない、楽しいユーザーエクスペリエンスに慣れ始めています。 Mediumは、Web上で楽しく直感的なコンテンツを作成できるという概念を広めました。 そして「概念」と言えば、人気のあるノートアプリはブロックコンテンツに全面的に組み込まれており、ユーザーはさまざまな種類のアプリを最大限に組み合わせることができます。 これらのブロックのほとんどは、マークダウンとHTMLのネイティブ要素を超えています。

概念上のブロックコンテンツの例。
（大プレビュー）

Notionは、待望のAPIを介してコンテンツにアクセスできるようにするプロセスを説明し、コンテンツ形式の選択を強調していることは注目に値します。

あるMarkdownエディターのドキュメントは、別のアプリケーションでは解析とレンダリングが異なることがよくあります。 不整合は単純なドキュメントでは管理できる傾向がありますが、Notionの豊富なブロックライブラリとインラインフォーマットオプションにとっては大きな問題です。これらの多くは、広く使用されているMarkdown実装ではサポートされていません。

Notionは、構造化データとして表現できるJSONベースの形式を採用しました。 彼らの主張は、NotionのAPIから得られるブロックコンテンツの独自のプレゼンテーションを作成したい開発者にとって、対話がより簡単で予測可能になるというものです。

マークダウンでない場合、それでは何ですか？

Markdownの卓越性が、デジタルコンテンツの革新と進歩を妨げているのではないかと思います。 ですから、コンテンツを保存するための主要な方法としてそれを選択するのをやめるべきだと私が主張するとき、それを何に置き換えるべきかについて直接的な答えを出すのは難しいです。 しかし、私たちが知っていることは、最新のコンテンツ形式とオーサリングツールに期待すべきことです。

アクセス可能なオーサリングエクスペリエンスに投資しましょう

マークダウンを使用するには、構文を学ぶ必要があります。多くの場合、複数の構文と特注のタグを使用して、現代の期待に応えることができます。 今日、それはほとんどの人に完全に不必要な期待を抱かせているように感じます。 現代のポータブルコンテンツフォーマットを生み出す、アクセシブルで楽しい編集体験を作ることにもっと力を注ぐことができればと思います。

優れたブロックコンテンツエディターを構築することは非常に難しいことで有名ですが、ユースケースに合わせて拡張およびカスタマイズできる実行可能なオプションがいくつかあります（Slate.js、Quill.js、Prosemirrorなど）。 繰り返しになりますが、これらのツールを取り巻くコミュニティに投資することも、コミュニティの発展に役立つ可能性があります。

ますます、人々はオーサリングツールがアクセス可能で、リアルタイムで、協調的であることを期待するでしょう。 2021年にWeb上の保存ボタンを押さなければならないのはなぜですか？ 同僚がたまたまタブでドキュメントを開いていたので、競合状態のリスクを冒さずにドキュメントに変更を加えることができないのはなぜですか？ 著者がマージの競合に対処しなければならないことを期待する必要がありますか？ また、コンテンツクリエーターが、意味のある視覚的なアフォーダンスを備えた構造化コンテンツを簡単に操作できるようにするべきではないでしょうか。

少し論争的ですが、リアクティブJavaScriptフレームワークとUIコンポーネントにおける過去10年間の革新は、素晴らしいオーサリングツールを作成するのに最適です。 それらを使用してMarkdownをHTMLにトランスパイルし、抽象構文ツリーに変換して、HTMLを出力するJavaScriptテンプレート言語に統合する代わりに。

ブロックコンテンツは仕様に従う必要があります

HTML用のWYSIWYGエディターについては触れていません。 彼らは間違っているからです。 最新のブロックコンテンツエディタは、指定された形式で相互運用できることが望ましいです。 前述の編集者は、少なくとも、よりポータブルなものに変換できる賢明な内部ドキュメントモデルを持っています。 If you look at the content management system landscape, you start to see various JSON-based block content formats emerge. Some of them are still tied to HTML assumptions or overly concerned with character positions. And none of them aren't really offered as a generic specification.

At Sanity.io, we decided early that the block content format should never assume HTML as neither input nor output, and that we could use algorithms to synchronize text strings. More importantly, was it that block content and rich text should be deeply typed and queryable. The result was the open specification Portable Text. Its structure not only makes it flexible enough to accommodate custom data structures as blocks and inline spans; it's also fully queryable with open-source query languages like GROQ.

Portable Text isn't design to be written or be easily readable in its raw form; it's designed to be produced by an user interface, manipulated by code, and to be serialized and rendered where ever it needs to go. For example, you can use it to express content for voice assistants.

 { "style": "normal", "_type": "block", "children": [ { "_type": "span", "marks": ["a-key", "emphasis"], "text": "some text" } ], "markDefs": [ { "_key": "a-key", "_type": "markType", "extraData": "some data" } ] }

An interesting side-effect of turning block content into structured data is exactly that: It becomes data! And data can be queried and processed. That can be highly useful and practical, and it lets you ask your content repository questions that would be otherwise harder and more errorprone in formats like Markdown.

For example, if I for some reason wanted to know what programming languages we've covered in examples on Sanity's blog, that's within reach with a short query. You can imagine how trivial it is to build specialized tools and views on top of this that can be helpful for content editors:

 distinct( *["code" in body[]._type] .body[_type == "code"] .language ) // output [ "text", "javascript", "json", "html", "markdown", "sh", "groq", "jsx", "bash", "css", "typescript", "tsx", "scss" ]

Example: Get a distinct list of all programming languages that you have code blocks of.

Portable Text is also serializable, meaning that you can recursively loop through it, and make an API that exposes its nodes in callback functions mapped to block types, marked-up spans, and so on. We have spent the last years learning a lot about how it works and how it can be improved, and plan to take it to 1.0 in the near future. The next step is to offer an editor experience outside of Sanity Studio. As we have learned from Markdown, the design intent is important.

Of course, whatever the alternative to markdown is, it doesn't need to be Portable Text, but it needs to be portable text. And it needs to share a lot of its characteristics. There have been a couple of other JSON-based block content format popping up the last few years, but a lot of them seem to bring with them a lot of “HTMLism.” The convenience is understandable, since a lot of content still ends up on the web serialized into HTML, but the convenience limits the portability and the potential for reuse.

You can disregard my short pitch for something we made at Sanity, as long as you embrace the idea of structured content and formats that let you move between systems in a fundamental manner. For example, a goal for Portable Text will be improved compatibility with Unified.js, so it's easier to travel between formats.

Embracing The Legacy Of Markdown

そのすべてのフレーバー、解釈、およびフォークの値下げは消えません。 I suspect that plain text files will always have a place in developers' note apps, blogs, docs, and digital gardens. As a writer who has used markdown for almost two decades, I've become accustomed to “markdown shortcuts” that are available in many rich text editors and am frequently stumped from Google Docs' lack of markdownisms. But I'm not sure if the next generation of content creators and even developers will be as bought in on markdown, and nor should they have to be.

I also think that markdown captured a culture of savvy tinkerers who love text, markup, and automation. I'd love to see that creative energy expand and move into collectively figuring out how we can make better and more accessible block content editors, and building out an ecosystem around specifications that can express block content that's agnostic to HTML. Structured data formats for block content might not have the same plain text ergonomics, but they are highly “tinkerable” and open for a lot of creativity of expression and authoring.

If you are a developer, product owner, or a decision-maker, I really want you to be circumspect of how you want to store and format your content going forward. If you're going for markdown, at least consider the following trade-offs:

Markdown is not great for the developer experience in modern stacks :

  • It can be a hassle to parse and validate, even with great tooling.
  • Even if you adopt CommonMark, you aren't guaranteed compatibility with tooling or people's expectations.
  • It's not great for structured content, YAML frontmatter only takes you so far.

Markdown is not great for editorial experience :

  • Most content creators don't want to learn syntax, their time is better spent on other things.
  • Most markdown systems are brittle, especially when people get syntax wrong (which they will).
  • It's hard to accommodate great collaborative user experiences for block content on top of markdown.

Markdown is not great in block content age , and shouldn't be forced into it. Block content needs to:

  • Be untangled from HTMLisms and presentation agnostic.
  • Accommodate structured content, so it can be easily used wherever it needs to be used.
  • Have stable specification(s), so it's possible to build on.
  • Support real-time collaborative systems.

What's common for people like me who challenge the prevalence of markdown, and those who are really into the simple way of expressing text formating is an appreciation of how we transcribe intent into code. That's where I think we can all meet. But I do think it's time to look at the landscape and the emerging content formats that try to encompass modern needs, and ask how we can make sure that we build something that truly caters to editorial experience, and that can speak to developer experience as well.

I want to express my gratitude to Titus Wormer (@wooorm) for his insightful feedback on my first draft of this post, and for the great work he and the Unified.js team have done for the web community.