ความคิดเกี่ยวกับ Markdown

Markdown เป็นธรรมชาติที่สองสำหรับพวกเราหลายคน เมื่อมองย้อนกลับไป ฉันจำได้ว่าเริ่มพิมพ์ใน Markdown ไม่นานหลังจากที่ John Gruber เปิดตัว Parser ที่ใช้ Perl เป็นครั้งแรกในปี 2004 หลังจากทำงานร่วมกันด้านภาษากับ Aaron Swartz

วากยสัมพันธ์ของ Markdown มีวัตถุประสงค์เพื่อวัตถุประสงค์เดียว: เพื่อใช้เป็นรูปแบบสำหรับการเขียนสำหรับเว็บ

— จอห์น กรูเบอร์

เกือบ 20 ปีที่แล้ว — เย้! สิ่งที่เริ่มต้นในฐานะรูปแบบที่เป็นมิตรกับนักเขียนและผู้อ่านสำหรับ HTML ได้กลายเป็นสิ่งที่ชอบในการเขียนและจัดเก็บร้อยแก้วทางเทคนิคสำหรับโปรแกรมเมอร์และผู้ที่เข้าใจเทคโนโลยี

Markdown เป็นตัวบ่งชี้สำหรับวัฒนธรรมนักพัฒนาและคนจรจัดข้อความ แต่นับตั้งแต่เปิดตัว โลกของเนื้อหาดิจิทัลก็เปลี่ยนไปเช่นกัน แม้ว่า Markdown จะยังคงใช้ได้สำหรับบางสิ่ง ฉันไม่เชื่อว่ามันควรจะเป็นเนื้อหาที่เข้าถึงได้อีกต่อไป

มีสองสาเหตุหลักสำหรับสิ่งนี้:

1. Markdown ไม่ได้ออกแบบมาเพื่อตอบสนองความต้องการของเนื้อหาในปัจจุบัน
2. Markdown ระงับประสบการณ์ด้านบรรณาธิการ

แน่นอนว่าจุดยืนนี้ได้รับอิทธิพลจากการทำงานให้กับแพลตฟอร์มสำหรับเนื้อหาที่มีโครงสร้าง ที่ Sanity.io เราใช้เวลาส่วนใหญ่ไปกับการคิดเกี่ยวกับเนื้อหาที่ปลดล็อกคุณค่ามากมาย และเราใช้เวลาส่วนใหญ่ในการคิดอย่างลึกซึ้งเกี่ยวกับประสบการณ์ของบรรณาธิการ และวิธีประหยัดเวลาของผู้คน และทำให้การทำงานกับเนื้อหาดิจิทัลเป็นเรื่องที่น่าพึงพอใจ . จึงมีสกินในเกม แต่ฉันหวังว่าฉันจะสามารถแสดงให้เห็นว่าแม้ว่าฉันจะโต้แย้งกับ Markdown ว่าเป็นรูปแบบเนื้อหาที่ใช้งานได้จริง ฉันยังคงซาบซึ้งในความสำคัญ การใช้งาน และมรดกของมัน

ก่อนงานปัจจุบันของฉัน ฉันทำงานเป็นที่ปรึกษาด้านเทคโนโลยีในหน่วยงานที่เราต้องต่อสู้กับ CMS ที่ล็อกเนื้อหาของลูกค้าโดยฝังไว้ในการนำเสนอและโมเดลข้อมูลที่ซับซ้อน (ใช่ แม้แต่โอเพนซอร์ส) ฉันสังเกตเห็นผู้คนต่อสู้กับไวยากรณ์ Markdown และถูกปลดออกจากงานในฐานะบรรณาธิการและผู้สร้างเนื้อหา เราได้ใช้เวลาหลายชั่วโมง (และเงินของลูกค้า) ไปกับการสร้างตัวแสดงแท็กแบบกำหนดเองที่ไม่เคยใช้เนื่องจากผู้คนไม่มีเวลาหรือแรงจูงใจในการใช้ไวยากรณ์ แม้แต่ฉัน เมื่อมีแรงจูงใจสูง ก็เลิกสนับสนุนเอกสารโอเพนซอร์ซเพราะการนำ Markdown แบบอิงองค์ประกอบไปใช้ทำให้เกิดความขัดแย้งมากเกินไป

แต่ฉันยังเห็นอีกด้านหนึ่งของเหรียญ Markdown มาพร้อมกับระบบนิเวศที่น่าประทับใจและจากมุมมองของนักพัฒนา มีความเรียบง่ายที่หรูหราสำหรับไฟล์ข้อความธรรมดาและไวยากรณ์ที่แยกวิเคราะห์ง่ายสำหรับผู้ที่คุ้นเคยกับการอ่านโค้ด ครั้งหนึ่งฉันเคยใช้เวลาหลายวันในการสร้าง MultiMarkdown -> LaTeX -> real-time-PDF-preview-pipeline ใน Sublime Text สำหรับการเขียนเชิงวิชาการของฉัน และทำให้รู้สึกว่าไฟล์ README.md สามารถเปิดและแก้ไขในตัวแก้ไขโค้ดและแสดงผลอย่างสวยงามบน GitHub มีข้อสงสัยเล็กน้อยว่า Markdown มอบความสะดวกสบายให้กับนักพัฒนาในบางกรณี

นั่นคือเหตุผลที่ฉันต้องการสร้างคำแนะนำของฉันเกี่ยวกับ Markdown โดยมองย้อนกลับไปว่าทำไมจึงมีการแนะนำสิ่งนี้ตั้งแต่แรก และโดยผ่านการพัฒนาที่สำคัญบางอย่างของเนื้อหาบนเว็บ สำหรับพวกเราหลายคน ฉันสงสัยว่า Markdown เป็นสิ่งที่เรามองว่าเป็น "สิ่งที่มีอยู่" แต่เทคโนโลยีทั้งหมดมีประวัติความเป็นมาและเป็นผลจากปฏิสัมพันธ์ของมนุษย์ นี่เป็นสิ่งสำคัญที่ต้องจดจำเมื่อคุณผู้อ่านพัฒนาเทคโนโลยีให้ผู้อื่นใช้

รสชาติและข้อมูลจำเพาะ

Markdown ได้รับการออกแบบมาเพื่อให้นักเขียนเว็บทำงานกับบทความได้ง่ายขึ้นในยุคที่การเผยแพร่ทางเว็บจำเป็นต้องมีการเขียน HTML ดังนั้น จุดประสงค์คือการทำให้อินเทอร์เฟซกับการจัดรูปแบบข้อความใน 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 คุณเพียงแค่ใช้ HTML เอง ไม่จำเป็นต้องใส่คำนำหน้าหรือคั่นเพื่อระบุว่าคุณกำลังเปลี่ยนจาก Markdown เป็น HTML; คุณเพียงแค่ใช้แท็ก

— จอห์น กรูเบอร์

กล่าวอีกนัยหนึ่งถ้าคุณต้องการตารางให้ใช้ <table></table> คุณจะพบว่าสิ่งนี้ยังคงเป็นกรณีของการใช้งานดั้งเดิม MDX หนึ่งในผู้สืบทอดทางจิตวิญญาณของ Markdown ใช้หลักการเดียวกัน แต่ขยายไปยัง JSX ซึ่งเป็นภาษาเทมเพลตที่ใช้ JS

จาก Markdown ถึง Markdown?

ดูเหมือนว่าการอุทธรณ์ของ Markdown สำหรับหลาย ๆ คนไม่ได้เชื่อมโยงกับ HTML มากนัก แต่การยศาสตร์ของข้อความธรรมดาและไวยากรณ์ที่เรียบง่ายสำหรับการจัดรูปแบบ ผู้สร้างเนื้อหาบางรายต้องการใช้ Markdown สำหรับกรณีการใช้งานอื่นๆ นอกเหนือจากบทความทั่วไปบนเว็บ การนำไปใช้งานอย่าง MultiMarkdown นั้นสามารถจ่ายได้สำหรับนักเขียนเชิงวิชาการที่ต้องการใช้ไฟล์ข้อความธรรมดาแต่ต้องการคุณสมบัติเพิ่มเติม ในไม่ช้า คุณจะมีแอพสำหรับเขียนหลายตัวที่ยอมรับไวยากรณ์ Markdown โดยไม่จำเป็นต้องเปลี่ยนเป็น HTML หรือแม้แต่ใช้ไวยากรณ์ markdown เป็นรูปแบบที่เก็บข้อมูล

ในแอปจำนวนมาก คุณจะพบเครื่องมือแก้ไขที่ให้ชุดตัวเลือกการจัดรูปแบบที่จำกัด และบางส่วนก็ "ได้รับแรงบันดาลใจ" จากไวยากรณ์ดั้งเดิมมากกว่า อันที่จริง ผลตอบกลับข้อหนึ่งที่ฉันได้รับจากร่างบทความนี้คือตอนนี้ “Markdown” ควรจะเป็นตัวพิมพ์เล็ก เพราะมันกลายเป็นเรื่องธรรมดาไปแล้ว และทำให้แตกต่างไปจากการใช้งานดั้งเดิม เพราะสิ่งที่เรารู้จักในฐานะมาร์กดาวน์ก็มีความหลากหลายเช่นกัน

CommonMark: ความพยายามที่จะเชื่อง Markdown

เช่นเดียวกับไอศกรีม Markdown มีหลายรสชาติ บางรสชาติก็เป็นที่นิยมมากกว่ารสชาติอื่นๆ เมื่อผู้คนเริ่มแยกการใช้งานดั้งเดิมและเพิ่มคุณสมบัติเข้าไป มีสองสิ่งเกิดขึ้น:

1. สิ่งที่คุณเป็นนักเขียนสามารถทำได้และไม่สามารถทำได้กับ Markdown เป็นเรื่องที่คาดเดาไม่ได้มากขึ้น
2. นักพัฒนาซอฟต์แวร์ต้องตัดสินใจเกี่ยวกับการใช้งานซอฟต์แวร์ของตน การใช้งานดั้งเดิมยังมีความไม่สอดคล้องกันบางอย่างที่เพิ่มความขัดแย้งให้กับผู้ที่ต้องการใช้งานโดยทางโปรแกรม

สิ่งนี้เริ่มต้นการสนทนาเกี่ยวกับการทำให้ Markdown กลายเป็นข้อกำหนดที่เหมาะสม สิ่งที่ Gruber ขัดขืนและยังคงทำอยู่ น่าสนใจ เพราะเขาตระหนักดีว่าผู้คนต้องการใช้ Markdown เพื่อจุดประสงค์ที่แตกต่างกัน และ "ไม่มีรูปแบบใดที่จะทำให้ทุกคนมีความสุข" เป็นจุดยืนที่น่าสนใจเมื่อพิจารณาว่า Markdown แปลเป็น HTML ซึ่งเป็นข้อกำหนดที่พัฒนาขึ้นเพื่อรองรับความต้องการที่แตกต่างกัน

แม้ว่าการใช้งาน Markdown ดั้งเดิมจะอยู่ภายใต้ใบอนุญาต "BSD-like" แต่ก็อ่านว่า "ห้ามใช้ชื่อ Markdown หรือชื่อผู้ร่วมให้ข้อมูลเพื่อรับรองหรือโปรโมตผลิตภัณฑ์ที่ได้รับจากซอฟต์แวร์นี้โดยไม่ได้รับอนุญาตเป็นลายลักษณ์อักษรล่วงหน้า ” เราสามารถสรุปได้อย่างปลอดภัยว่าผลิตภัณฑ์ส่วนใหญ่ที่ใช้ “Markdown” เป็นส่วนหนึ่งของเอกสารทางการตลาดยังไม่ได้รับอนุญาตเป็นลายลักษณ์อักษรนี้

ความพยายามที่ประสบความสำเร็จมากที่สุดในการนำ Markdown มาสู่ข้อกำหนดที่ใช้ร่วมกันคือสิ่งที่เรียกว่า CommonMark ในปัจจุบัน นำโดย Jeff Atwood (เป็นที่รู้จักจากการร่วมก่อตั้ง Stack Overflow and Discourse) และ John McFarlane (ศาสตราจารย์ด้านปรัชญาที่ Berkely ซึ่งอยู่เบื้องหลัง Babelmark และ Pandoc) ในตอนแรกพวกเขาเปิดตัวเป็น "Standard Markdown" แต่เปลี่ยนเป็น "CommonMark" หลังจากได้รับการวิพากษ์วิจารณ์จาก Gruber ซึ่งมีจุดยืนที่สอดคล้องกัน เจตนา ของ Markdown คือการเป็นไวยากรณ์การเขียนอย่างง่ายที่แปลเป็น HTML:

@davewiner และนั่นคือสิ่งที่มีข้อบกพร่องกับ CommonMark พวกเขาต้องการทำให้โปรแกรมเมอร์ง่ายขึ้นเป็นเป้าหมายหลัก พวกเขาพลาดประเด็น

– John Gruber (@gruber) 8 กันยายน 2014

ฉันคิดว่านี่เป็นจุดที่ Markdown เข้าสู่โดเมนสาธารณะด้วย แม้ว่า CommonMark จะไม่ถูกตราหน้าว่าเป็น "Markdown" (ตามใบอนุญาต) ข้อกำหนดนี้ได้รับการยอมรับและเรียกว่า "markdown" วันนี้ คุณจะพบว่า CommonMark เป็นการใช้งานพื้นฐานสำหรับซอฟต์แวร์ เช่น Discourse, GitHub, GitLab, Reddit, Qt, Stack Overflow และ Swift โปรเจ็กต์ต่างๆ เช่น unified.js bridges syntaxes โดยการแปลเป็น Abstract Syntax Trees ยังต้องพึ่งพา CommonMark สำหรับการสนับสนุน markdown

CommonMark ได้นำการรวมกันจำนวนมากเกี่ยวกับวิธีการใช้งาน markdown และในหลาย ๆ ทางทำให้โปรแกรมเมอร์สามารถรวมการสนับสนุน markdown ในซอฟต์แวร์ได้ง่ายขึ้น แต่มันไม่ได้นำการผสมผสานที่เหมือนกันกับวิธีการเขียนและใช้งานมาร์กดาวน์ ใช้ GitHub Flavoured Markdown (GFM) อิงตาม CommonMark แต่ขยายด้วยฟีเจอร์เพิ่มเติม (เช่น ตาราง รายการงาน และขีดทับ) Reddit อธิบายว่า "Reddit Flavoured Markdown" เป็น "รูปแบบหนึ่งของ GFM" และแนะนำคุณลักษณะต่างๆ เช่น ไวยากรณ์สำหรับการทำเครื่องหมายสปอยเลอร์ ฉันคิดว่าเราสามารถสรุปได้อย่างปลอดภัยว่าทั้งกลุ่มที่อยู่เบื้องหลัง CommonMark และ Gruber นั้นถูกต้อง: มันช่วยในเรื่องข้อกำหนดที่ใช้ร่วมกันได้อย่างแน่นอน แต่ใช่ ผู้คนต้องการใช้ Markdown สำหรับสิ่งที่เฉพาะเจาะจงที่แตกต่างกัน

Markdown เป็นทางลัดการจัดรูปแบบ

Gruber ต่อต้านการทำให้ Markdown กลายเป็นข้อกำหนดที่ใช้ร่วมกันเพราะเขาคิดว่ามันจะทำให้เครื่องมือสำหรับนักเขียนน้อยลงและเป็นเครื่องมือสำหรับโปรแกรมเมอร์มากขึ้น เราได้เห็นแล้วว่าถึงแม้จะใช้ข้อกำหนดในวงกว้าง เราก็ไม่ได้รับไวยากรณ์ที่คาดการณ์ได้โดยอัตโนมัติซึ่งทำงานเหมือนกันในบริบทต่างๆ และข้อมูลจำเพาะอย่าง CommonMark ที่ได้รับความนิยมอย่างที่เป็นอยู่ ก็มีความสำเร็จจำกัดเช่นกัน ตัวอย่างที่ชัดเจนคือการใช้ markdown ของ Slack (เรียกว่า mrkdown ) ที่แปล *this* เป็น strong/bold และไม่เน้น/ตัวเอียง และไม่รองรับไวยากรณ์ [link](https://slack.com) แต่ใช้ <link|https://slack.com> แทน

คุณจะพบว่าคุณสามารถใช้ไวยากรณ์ที่เหมือน Markdown เพื่อเริ่มต้นการจัดรูปแบบในเครื่องมือแก้ไข Rich Text ในซอฟต์แวร์เช่น Notion, Dropbox Paper, Craft และในระดับหนึ่ง Google Docs (เช่น asterisk + space ในบรรทัดใหม่จะเปลี่ยนเป็น รายการหัวข้อย่อย) สิ่งที่ได้รับการสนับสนุนและสิ่งที่แปลเป็นสิ่งที่แตกต่างกันไป ดังนั้น คุณไม่จำเป็นต้องนำหน่วยความจำของกล้ามเนื้อติดตัวไปในแอปพลิเคชันเหล่านี้ สำหรับบางคน วิธีนี้ใช้ได้และพวกเขาสามารถปรับตัวได้ สำหรับคนอื่น นี่คือการตัดกระดาษและป้องกันไม่ให้ใช้คุณสมบัติเหล่านี้ ซึ่งถามคำถามว่า Markdown ออกแบบมาสำหรับใครและใครคือผู้ใช้ในปัจจุบัน

ใครคือผู้ใช้ Markdown ที่ควรจะเป็น?

เราได้เห็นการมาร์กดาวน์อยู่ในความตึงเครียดระหว่างกรณีการใช้งานต่างๆ ผู้ชม และแนวคิดที่ว่าผู้ใช้เป็นใคร สิ่งที่เริ่มต้นเป็นภาษามาร์กอัปสำหรับนักเขียนเว็บที่เชี่ยวชาญด้าน HTML โดยเฉพาะ กลายเป็นสิ่งที่ชอบสำหรับนักพัฒนาซอฟต์แวร์

ในปี 2014 ผู้เขียนเว็บเริ่มย้ายออกจากการย้ายไฟล์ผ่าน parsers ใน Perl และ FTP ระบบจัดการเนื้อหา (CMS) เช่น WordPress, Drupal และ Moveable Type (ซึ่งฉันเชื่อว่า Gruber ยังคงใช้อยู่) ได้เติบโตอย่างต่อเนื่องเพื่อเป็นเครื่องมือสำหรับการเผยแพร่ทางเว็บ พวกเขาเสนอราคาที่ไม่แพงเช่นเครื่องมือแก้ไขข้อความแบบสมบูรณ์ที่ผู้เขียนเว็บสามารถใช้ในเบราว์เซอร์ของตนได้

โปรแกรมแก้ไข Rich Text เหล่านี้ยังคงถือว่า HTML และ Markdown เป็นไวยากรณ์ Rich Text พื้นฐาน แต่พวกเขานำค่าใช้จ่ายด้านความรู้ความเข้าใจบางส่วนออกไปโดยการเพิ่มปุ่มเพื่อแทรกไวยากรณ์นี้ในตัวแก้ไข และยิ่งนักเขียนไม่ได้และไม่จำเป็นต้องเชี่ยวชาญใน HTML ฉันพนันได้เลยว่าถ้าคุณพัฒนาเว็บด้วย CMS ในปี 2010 คุณอาจต้องจัดการกับ "HTML ขยะ" ที่มาจากโปรแกรมแก้ไขเหล่านี้เมื่อมีคนวางโดยตรงจาก Word

วันนี้ฉันจะเถียงว่าผู้ใช้หลักของ Markdown คือนักพัฒนาและผู้ที่สนใจในโค้ด ไม่ใช่เรื่องบังเอิญที่ Slack ทำให้ WYSIWYG เป็นโหมดอินพุตเริ่มต้นเมื่อซอฟต์แวร์ของพวกเขาถูกใช้โดยผู้คนจำนวนมากขึ้นนอกแผนกเทคนิค และความจริงที่ว่านี่เป็นการตัดสินใจที่ขัดแย้งกันมาก จนพวกเขาต้องนำมันกลับมาเป็นตัวเลือก แสดงให้เห็นว่าความรักในการลดราคานั้นลึกซึ้งเพียงใดในชุมชนนักพัฒนา ไม่มีการเฉลิมฉลองของ Slack มากนักที่พยายามทำให้ทุกคนเข้าถึงได้ง่ายขึ้นและเข้าถึงได้มากขึ้น และนี่คือปมของเรื่อง

อุดมการณ์ของ Markdown

ความจริงที่ว่า markdown กลายเป็นรูปแบบการเขียนของ lingua franca และสิ่งที่กรอบงานเว็บไซต์ส่วนใหญ่ให้ความสำคัญ ก็เป็นเหตุผลหลักที่ฉันไม่ค่อยถนัดในการเผยแพร่สิ่งนี้ มักถูกพูดถึงว่าเป็นสินค้าที่มีมาแต่กำเนิดและปฏิเสธไม่ได้ Markdown ได้กลายเป็นจุดเด่นของการเป็นมิตรกับนักพัฒนา คนที่ฉลาดและมีทักษะได้จมลงไปหลายชั่วโมงในการเปิดใช้งานการลดราคาในทุกบริบท ดังนั้นการท้าทายอำนาจของมันจะสร้างความรำคาญให้กับบางคนอย่างแน่นอน แต่หวังว่ามันจะทำให้เกิดการอภิปรายที่เป็นประโยชน์เกี่ยวกับสิ่งที่มักจะมองข้ามไป

ความประทับใจของฉันคือความเป็นมิตรของนักพัฒนาที่ผู้คนเกี่ยวข้องกับ Markdown ส่วนใหญ่เกี่ยวข้องกับ 3 ปัจจัย:

1. นามธรรมที่สะดวกสบายของไฟล์ข้อความธรรมดา
2. มีระบบนิเวศของเครื่องมือ
3. คุณสามารถเก็บเนื้อหาของคุณไว้ใกล้กับเวิร์กโฟลว์การพัฒนาของคุณ

ฉันไม่ได้บอกว่าจุดยืนเหล่านี้ผิด แต่ฉันจะแนะนำว่าท่าทีเหล่านี้มาพร้อมกับการประนีประนอมและการสันนิษฐานที่ไม่สมเหตุสมผล

โมเดลจิตที่เรียบง่ายของไฟล์ข้อความธรรมดา

ฐานข้อมูลเป็นสิ่งที่น่าอัศจรรย์ แต่พวกเขายังได้รับชื่อเสียงว่ายากและไม่สามารถเข้าถึงได้สำหรับนักพัฒนาส่วนหน้า ฉันรู้จักนักพัฒนาเก่งๆ หลายคนที่ไม่กล้าใช้แบ็กเอนด์โค้ดและฐานข้อมูล เพราะพวกเขาแสดงถึงความซับซ้อนที่พวกเขาไม่ต้องการใช้เวลากับมัน แม้กระทั่งกับ WordPress ซึ่งทำสิ่งต่างๆ ได้มากมายจากกล่องเพื่อป้องกันไม่ให้คุณต้องจัดการกับฐานข้อมูลหลังจากตั้งค่าแล้ว ก็ยังเป็นค่าใช้จ่ายในการเริ่มต้นใช้งาน

อย่างไรก็ตาม ไฟล์ข้อความธรรมดาจะจับต้องได้ง่ายกว่าและให้เหตุผลได้ง่าย (ตราบใดที่คุณเคยชินกับการจัดการไฟล์นั่นเอง) โดยเฉพาะอย่างยิ่งเมื่อเทียบกับระบบที่จะแบ่งเนื้อหาของคุณออกเป็นหลายตารางในฐานข้อมูลเชิงสัมพันธ์ที่มีโครงสร้างที่เป็นกรรมสิทธิ์บางอย่าง สำหรับกรณีการใช้งานที่จำกัด เช่น บล็อกโพสต์ของ Rich Text อย่างง่ายพร้อมรูปภาพและลิงก์ มาร์กดาวน์จะทำให้งานเสร็จสิ้น คุณสามารถคัดลอกไฟล์และติดไว้ในโฟลเดอร์หรือตรวจสอบใน git เนื้อหารู้สึกเป็นของ คุณ เพราะความชัดเจนของไฟล์ แม้ว่าพวกเขาจะโฮสต์บน GitHub ซึ่งเป็นซอฟต์แวร์ที่แสวงหาผลกำไรในฐานะบริการที่เป็นของ Microsoft และครอบคลุมอยู่ในข้อกำหนดในการให้บริการ

ในยุคที่คุณต้องสร้างฐานข้อมูลในเครื่องจริง ๆ เพื่อให้การพัฒนาในพื้นที่ของคุณดำเนินต่อไป และจัดการกับการซิงค์กับระยะไกล การอุทธรณ์ของไฟล์ข้อความธรรมดานั้นเป็นสิ่งที่เข้าใจได้ แต่ยุคนั้นแทบจะหายไปพร้อมกับการเกิดขึ้นของแบ็กเอนด์ในฐานะบริการ บริการและเครื่องมือต่างๆ เช่น Fauna, Firestore, Hasura, Prisma, PlanetScale และ Sanity's Content Lake ลงทุนอย่างมากในประสบการณ์ของนักพัฒนา แม้แต่การดำเนินการฐานข้อมูลแบบดั้งเดิมเกี่ยวกับการพัฒนาในท้องถิ่นก็ยังมีความยุ่งยากน้อยลงเมื่อเทียบกับเมื่อ 10 ปีที่แล้ว

หากคุณลองคิดดู คุณเป็นเจ้าของเนื้อหาน้อยลงหรือไม่หากเนื้อหานั้นโฮสต์อยู่ในฐานข้อมูล และประสบการณ์ของนักพัฒนาในการจัดการกับฐานข้อมูลนั้นง่ายกว่ามากเมื่อใช้เครื่องมือ SaaS หรือไม่? และยุติธรรมหรือไม่ที่จะบอกว่าเทคโนโลยีฐานข้อมูลที่เป็นกรรมสิทธิ์ส่งผลกระทบต่อการพกพาเนื้อหาของคุณ วันนี้ คุณสามารถเปิดใช้ฐานข้อมูล Postgres ที่ไม่มีทักษะด้านการดูแลระบบ สร้างตารางและคอลัมน์ ใส่เนื้อหาของคุณ และส่งออกเป็นไฟล์ .sql ได้ทุกเมื่อ

การพกพาเนื้อหานั้นเกี่ยวข้องกับวิธีที่คุณ จัดโครงสร้าง เนื้อหานั้นตั้งแต่แรก ใช้ WordPress เป็นโอเพ่นซอร์สเต็มรูปแบบ คุณสามารถโฮสต์ฐานข้อมูลของคุณเองได้ มันยังมีรูปแบบการส่งออกที่เป็นมาตรฐานใน XML แต่ใครก็ตามที่พยายามจะย้ายออกจากการติดตั้ง WordPress ที่เป็นผู้ใหญ่รู้ดีว่าสิ่งนี้ช่วยได้น้อยเพียงใดหากคุณพยายามหลีกหนีจาก WordPress

ระบบนิเวศที่กว้างใหญ่… สำหรับนักพัฒนา

เราได้สัมผัสกับระบบนิเวศที่ลดต่ำลงที่กว้างใหญ่แล้ว หากคุณดูเฟรมเวิร์กเว็บไซต์ร่วมสมัย ส่วนใหญ่จะถือว่ามาร์กดาวน์เป็นรูปแบบเนื้อหาหลัก บางรูปแบบเป็นรูปแบบ เดียว ตัวอย่างเช่น Hugo ซึ่งเป็นโปรแกรมสร้างไซต์แบบสแตติกที่ใช้โดย Smashing Magazine ยังคงต้องการไฟล์มาร์กดาวน์สำหรับการเผยแพร่แบบแบ่งหน้า หมายความว่าหาก Smashing Magazine ต้องการใช้ CMS ในการจัดเก็บบทความ จะต้องโต้ตอบกับไฟล์ Markdown หรือแปลงเนื้อหาทั้งหมดเป็นไฟล์ Markdown หากคุณดูเอกสารประกอบสำหรับ Next.js, Nuxt.js, VuePress, Gatsby.js และอื่นๆ มาร์กดาวน์จะแสดงให้เห็นอย่างชัดเจน นอกจากนี้ยังเป็นไวยากรณ์เริ่มต้นสำหรับ README บน GitHub ซึ่งใช้สำหรับการจัดรูปแบบในบันทึกคำขอดึงและความคิดเห็น

มีการกล่าวถึงความคิดริเริ่มที่น่ายกย่องบางประการเพื่อนำการยศาสตร์ของการลดราคาไปสู่มวลชน Netlify CMS และ TinaCMS (ผู้สืบทอดทางจิตวิญญาณของ Forestry) จะให้ส่วนต่อประสานกับผู้ใช้ซึ่งไวยากรณ์ markdown ส่วนใหญ่จะแยกออกไปสำหรับบรรณาธิการ โดยทั่วไปคุณจะพบว่าตัวแก้ไขแบบมาร์กดาวน์ใน CMS ให้ฟังก์ชันการแสดงตัวอย่างสำหรับการจัดรูปแบบ บรรณาธิการบางคน เช่น Notion จะให้คุณวางไวยากรณ์ markdown และพวกเขาจะแปลเป็นรูปแบบดั้งเดิม แต่ฉันคิดว่ามันปลอดภัยที่จะพูด ว่าพลังงานที่คิดค้นเพื่อมาร์กดาวน์ไม่ได้ชอบคนที่ไม่ชอบเขียนไวยากรณ์ มันไม่ได้หยดขึ้นกองเหมือนเดิม

เวิร์กโฟลว์เนื้อหาหรือเวิร์กโฟลว์ของนักพัฒนา?

สำหรับนักพัฒนาที่สร้างบล็อก การใช้ไฟล์มาร์กดาวน์ช่วยลดค่าใช้จ่ายบางส่วนในการเริ่มต้นใช้งาน เนื่องจากเฟรมเวิร์กมักมาพร้อมกับการแยกวิเคราะห์ในตัวหรือมักเสนอให้เป็นส่วนหนึ่งของโค้ดเริ่มต้น และไม่มีอะไรเพิ่มเติมในการสมัคร คุณสามารถใช้ git เพื่อคอมมิตไฟล์เหล่านี้ควบคู่ไปกับโค้ดของคุณได้ หากคุณคุ้นเคยกับ git diffs คุณจะสามารถควบคุมการแก้ไขได้เหมือนกับที่คุณเคยชินกับการเขียนโปรแกรม กล่าวอีกนัยหนึ่ง เนื่องจากไฟล์ markdown เป็นข้อความธรรมดา จึงสามารถรวมเข้ากับเวิร์กโฟลว์ของนักพัฒนาซอฟต์แวร์ของคุณได้

แต่นอกเหนือจากนี้ ประสบการณ์ของนักพัฒนาซอฟต์แวร์จะซับซ้อนขึ้นในไม่ช้า และจบลงด้วยการประนีประนอมกับประสบการณ์ผู้ใช้ของทีมของคุณในฐานะผู้สร้างเนื้อหา และประสบการณ์นักพัฒนาของเราเองก็ติดอยู่กับการลดราคาเพื่อแก้ปัญหาที่อยู่นอกเหนือความตั้งใจในการออกแบบ

ใช่ มันอาจจะดีถ้าคุณให้ทีมเนื้อหาของคุณใช้ git และตรวจสอบการเปลี่ยนแปลงของพวกเขา แต่ในขณะเดียวกัน นี่เป็นการใช้เวลาให้เกิดประโยชน์สูงสุดหรือไม่ คุณต้องการให้ผู้แก้ไขของคุณต่อสู้กับข้อขัดแย้งในการผสานหรือวิธีการสร้างสาขาใหม่หรือไม่? Git นั้นยากพอสำหรับนักพัฒนาที่ใช้งานมันทุกวัน และการตั้งค่านี้แสดงถึงเวิร์กโฟลว์ที่ดีที่สุดสำหรับผู้ที่ใช้งานเนื้อหาเป็นหลักหรือไม่ นี่ไม่ใช่กรณีที่ประสบการณ์ของนักพัฒนาซอฟต์แวร์ได้รับประสบการณ์ด้านบรรณาธิการมากกว่า และไม่ใช่ค่าใช้จ่าย เวลาและความพยายามที่จะช่วยพัฒนาสิ่งที่ดีกว่าให้กับผู้ใช้ใช่หรือไม่

เนื่องจากความคาดหวังและความต้องการจากเนื้อหาและสภาพแวดล้อมในการแก้ไขมีวิวัฒนาการไป ฉันไม่คิดว่าการลดราคาจะทำเพื่อเรา ฉันไม่เห็นว่าการยศาสตร์ของนักพัฒนาบางคนจบลงด้วยดีกับผู้ที่ไม่ใช่นักพัฒนา และฉันคิดว่าแม้สำหรับนักพัฒนา มาร์กดาวน์ก็ยังคงสร้างเนื้อหาของเราเองและต้องการกลับมา เนื่องจากเนื้อหาบนเว็บมีการเปลี่ยนแปลงอย่างมากตั้งแต่ช่วงต้นทศวรรษ 2000

จากย่อหน้าสู่บล็อก

Markdown มีตัวเลือกในการเลือกไม่ใช้ HTML เสมอ หากคุณต้องการสิ่งที่ซับซ้อนกว่านี้ วิธีนี้ใช้ได้ผลดีเมื่อผู้เขียนเป็นผู้ดูแลเว็บด้วย หรืออย่างน้อยก็รู้จัก HTML นอกจากนี้ยังทำงานได้ดีเพราะเว็บไซต์ส่วนใหญ่เป็น HTML และ CSS วิธีที่คุณออกแบบเว็บไซต์เป็นส่วนใหญ่โดยการสร้างเค้าโครงหน้าทั้งหมด คุณสามารถแปลง Markdown เป็นมาร์กอัป HTML และวางไว้ข้าง style.css ของคุณ แน่นอน เรามี CMS และเครื่องมือสร้างไซต์แบบคงที่ในทศวรรษ 2000 ด้วยเช่นกัน แต่ส่วนใหญ่ทำงานเหมือนกัน โดยการแทรกเนื้อหา HTML ลงในเทมเพลตโดยไม่ผ่าน "อุปกรณ์ประกอบฉาก" ระหว่างส่วนประกอบ

แต่พวกเราส่วนใหญ่ไม่ได้เขียน HTML เหมือนในสมัยก่อนอีกต่อไป เนื้อหาบนเว็บได้พัฒนาจากส่วนใหญ่เป็นบทความที่มีการจัดรูปแบบข้อความที่หลากหลาย ไปจนถึงมัลติมีเดียที่ประกอบขึ้นและส่วนประกอบพิเศษที่มักจะมีการโต้ตอบของผู้ใช้ (ซึ่งเป็นวิธีแฟนซีในการพูดว่า "การเรียกร้องให้ดำเนินการสมัครรับจดหมายข่าว")

จากบทความสู่แอพ

ในช่วงต้นปี 2010 Web 2.0 อยู่ในช่วงรุ่งเรือง และบริษัท Software as a Service เริ่มใช้เว็บสำหรับแอปพลิเคชันที่มีข้อมูลจำนวนมาก มีการใช้ HTML, CSS และ JavaScript มากขึ้นในการขับเคลื่อน UI แบบโต้ตอบ Bootstrap แบบโอเพนซอร์สของ Twitter ซึ่งเป็นเฟรมเวิร์กสำหรับการสร้างอินเทอร์เฟซผู้ใช้ที่สม่ำเสมอและยืดหยุ่นยิ่งขึ้น สิ่งนี้ผลักดันสิ่งที่เราเรียกว่า "การจัดองค์ประกอบ" ของการออกแบบเว็บ มันเปลี่ยนวิธีที่เราสร้างสำหรับเว็บในลักษณะพื้นฐาน

เฟรมเวิร์ก CSS ต่างๆ ที่เกิดขึ้นในยุคนี้ (เช่น Bootstrap และ Foundation) มักจะใช้ชื่อคลาสที่เป็นมาตรฐานและสันนิษฐานว่าโครงสร้าง HTML เฉพาะเพื่อทำให้ส่วนต่อประสานผู้ใช้ที่ยืดหยุ่นและตอบสนองยากน้อยลง ด้วยปรัชญาการออกแบบเว็บของ Atomic Design และแบบแผนของชื่อคลาส เช่น Block-Element-Modifier (BEM) ค่าเริ่มต้นจึงเปลี่ยนจากการคิดเค้าโครงหน้าก่อน เป็นการมองว่าหน้าเป็นคอลเลกชันขององค์ประกอบการออกแบบที่ทำซ้ำได้และเข้ากันได้

เนื้อหาใดก็ตามที่คุณมีใน markdown ไม่เข้ากันกับสิ่งนี้ เว้นแต่คุณจะลงหลุมกระต่ายในการแทรกตัวแยกวิเคราะห์ markdown และปรับแต่งเพื่อส่งออกไวยากรณ์ที่คุณต้องการ (เพิ่มเติมเกี่ยวกับเรื่องนี้ในภายหลัง) ไม่น่าแปลกใจเลยที่ Markdown ได้รับการออกแบบให้เป็นบทความ Rich Text ที่เรียบง่ายขององค์ประกอบ HTML ดั้งเดิมที่คุณจะกำหนดเป้าหมายด้วยสไตล์ชีต

นี่ยังคงเป็นปัญหาสำหรับผู้ที่ใช้ Markdown เพื่อขับเคลื่อนเนื้อหาสำหรับเว็บไซต์ของตน

เว็บที่ฝังได้

แต่มีบางอย่างเกิดขึ้นกับเนื้อหาของเราเช่นกัน ไม่เพียงแต่เราสามารถเริ่มค้นหามันนอกแท็ก HTML <article> เชิงความหมายได้ แต่มันเริ่มมี… สิ่งต่างๆ มากขึ้นด้วย เนื้อหาของเราจำนวนมากได้ย้ายออกจาก LiveJournals และบล็อกของเรา และเข้าสู่โซเชียลมีเดีย: Facebook, Twitter, tumblr, YouTube ในการนำตัวอย่างเนื้อหากลับเข้าสู่บทความของเรา เราจำเป็นต้องฝังเนื้อหาเหล่านั้นได้ แบบแผน HTML เริ่มใช้แท็ก <iframe> เพื่อจัดช่องโปรแกรมเล่นวิดีโอจาก YouTube หรือแม้แต่แทรกกล่องทวีตระหว่างย่อหน้าข้อความของคุณ บางระบบเริ่มแยกสิ่งนี้ออกเป็น "รหัสย่อ" ซึ่งส่วนใหญ่มักจะอยู่ในวงเล็บที่มีคำหลักบางคำเพื่อระบุว่าควรแสดงบล็อกของเนื้อหาใด และแอตทริบิวต์ของคีย์-ค่าบางอย่าง ตัวอย่างเช่น dev.to ได้เปิดใช้งานไวยากรณ์จากของเหลวภาษาเทมเพลตเพื่อแทรกลงในโปรแกรมแก้ไข Markdown:

 {% youtube dQw4w9WgXcQ %}

แน่นอนว่า คุณต้องใช้ตัวแยกวิเคราะห์ Markdown ที่กำหนดเอง และมีตรรกะพิเศษเพื่อให้แน่ใจว่าได้แทรก HTML ที่ถูกต้องเมื่อไวยากรณ์ถูกเปลี่ยนเป็น HTML และผู้สร้างเนื้อหาของคุณจะต้องจำรหัสเหล่านี้ (เว้นแต่จะมีแถบเครื่องมือบางประเภทที่จะแทรกโค้ดเหล่านี้โดยอัตโนมัติ) และถ้าวงเล็บถูกลบหรือทำให้เสียหาย อาจทำให้ไซต์เสียหายได้

แต่แล้ว MDX ล่ะ?

ความพยายามที่จะแก้ไขความจำเป็นในการบล็อกเนื้อหาคือ MDX นำเสนอด้วยสโลแกน "Markdown สำหรับยุคส่วนประกอบ" MDX ให้คุณใช้ภาษาเทมเพลต JSX เช่นเดียวกับ JavaScript ที่อินเทอร์เลซในไวยากรณ์มาร์กดาวน์ มีวิศวกรรมที่น่าประทับใจมากมายในชุมชนรอบๆ MDX รวมถึง Unified.js ซึ่งเชี่ยวชาญในการแยกวิเคราะห์ไวยากรณ์ต่างๆ ลงใน Abstract Syntax Trees (AST) เพื่อให้เข้าถึงได้ง่ายขึ้นเพื่อใช้ในการเขียนโปรแกรม โปรดทราบว่าการกำหนดมาตรฐานของ markdown จะทำให้ผู้ที่อยู่เบื้องหลัง Unified.js และผู้ใช้ของ Unified.js ง่ายขึ้น เนื่องจากมี Edge case น้อยกว่าที่จะรองรับ

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 และวิธีใช้อุปกรณ์ประกอบฉาก, รหัสฐานสิบหก และประเภทข้อมูล และคุณต้องคุ้นเคยกับส่วนประกอบที่คุณสามารถใช้ได้ และวิธีใช้งาน และคุณต้องพิมพ์ให้ถูกต้องและในสภาพแวดล้อมที่ให้คำติชม ฉันไม่สงสัยเลยว่าจะมีเครื่องมือสร้างที่เข้าถึงได้มากกว่านี้บน MDX รู้สึกเหมือนกำลังแก้ปัญหาบางอย่างที่ไม่จำเป็นต้องเป็นปัญหาตั้งแต่แรก

นอกเสียจากว่าคุณจะขยันอย่างมากในการเขียนและตั้งชื่อส่วนประกอบ MDX ของคุณ มันก็เชื่อมโยงเนื้อหาของคุณกับงานนำเสนอเฉพาะ เพียงใช้ตัวอย่างด้านบนที่นำมาจากหน้าแรกของ MDX คุณจะพบฐานสิบหกสีแบบฮาร์ดโค้ดสำหรับแผนภูมิ เมื่อคุณออกแบบไซต์ของคุณใหม่ สีนั้นอาจเข้ากันไม่ได้กับระบบการออกแบบใหม่ของคุณ แน่นอนว่า ไม่มีอะไรที่ขัดขวางไม่ให้คุณสรุปสิ่งนี้และใช้ prop color=”primary” แต่ก็ไม่มีอะไรในเครื่องมือที่จะกระตุ้นให้คุณตัดสินใจอย่างชาญฉลาดเช่นนี้

การฝังข้อกังวลเฉพาะในการนำเสนอลงในเนื้อหาของคุณได้กลายเป็นภาระหน้าที่มากขึ้นเรื่อยๆ และบางสิ่งที่จะขัดขวางการปรับเปลี่ยน ทำซ้ำ และดำเนินการอย่างรวดเร็วกับเนื้อหาของคุณ มันล็อกไว้ในลักษณะที่ละเอียดอ่อนกว่าการมีเนื้อหาในฐานข้อมูล คุณเสี่ยงที่จะจบลงที่เดียวกับการย้ายออกจากการติดตั้ง WordPress ที่เป็นผู้ใหญ่พร้อมปลั๊กอิน เป็นการยากที่จะ unmix โครงสร้างและการนำเสนอ

ความต้องการเนื้อหาที่มีโครงสร้าง

ด้วยไซต์ที่ซับซ้อนและเส้นทางของผู้ใช้ เราจึงเห็นความจำเป็นในการนำเสนอเนื้อหาเดียวกันทั่วทั้งเว็บไซต์ หากคุณกำลังใช้งานไซต์อีคอมเมิร์ซ คุณต้องการฝังข้อมูลผลิตภัณฑ์ในหลายที่นอกหน้าผลิตภัณฑ์เดียว หากคุณใช้ไซต์การตลาดสมัยใหม่ คุณต้องการแชร์สำเนาเดียวกันในมุมมองส่วนบุคคลหลายมุมมอง

ในการทำเช่นนี้อย่างมีประสิทธิภาพและเชื่อถือได้ คุณจะต้องปรับเนื้อหาที่มีโครงสร้าง ซึ่งหมายความว่าเนื้อหาของคุณต้องถูกฝังด้วยข้อมูลเมตาและแบ่งเป็นส่วนๆ ในลักษณะที่ทำให้สามารถแยกวิเคราะห์ตามเจตนาได้ หากนักพัฒนาเห็นเพียง "หน้า" ที่มี "เนื้อหา" ซึ่งทำให้ยากต่อการรวมสิ่งที่ถูกต้องไว้ในที่ที่เหมาะสม หากพวกเขาสามารถเข้าถึง "คำอธิบายผลิตภัณฑ์" ทั้งหมดด้วย API หรือข้อความค้นหา จะทำให้ทุกอย่างง่ายขึ้น

เมื่อใช้ markdown คุณจะถูกจำกัดการแสดงการจัดหมวดหมู่และเนื้อหาที่มีโครงสร้างสำหรับการจัดระเบียบโฟลเดอร์บางประเภท (ทำให้ยากต่อการวางเนื้อหาเดียวกันในการจัดหมวดหมู่หลายรายการ) หรือคุณจำเป็นต้องเพิ่มไวยากรณ์ด้วยอย่างอื่น

Jekyll ซึ่งเป็น Static Site Generator (SSG) รุ่นแรกๆ ที่สร้างขึ้นสำหรับไฟล์ markdown ได้แนะนำ "Front Matter" เป็นวิธีเพิ่มข้อมูลเมตาในโพสต์โดยใช้ YAML (รูปแบบคีย์-ค่าอย่างง่ายที่ใช้การเว้นวรรคเพื่อสร้างขอบเขต) ระหว่างขีดกลางสามขีดที่ด้านบน ของไฟล์. ตอนนี้คุณจะมี 2 syntax ที่ต้องจัดการ YAML ยังขึ้นชื่อว่าเป็นคนซุกซน (โดยเฉพาะถ้าคุณมาจากนอร์เวย์) อย่างไรก็ตาม SSG อื่นๆ ได้นำอนุสัญญานี้มาใช้ เช่นเดียวกับ CMS แบบ git-based ที่ใช้ markdown เป็นรูปแบบเนื้อหา

เมื่อคุณต้องเพิ่มไวยากรณ์เพิ่มเติมให้กับไฟล์ธรรมดาของคุณเพื่อให้ได้ เนื้อหา ที่มีโครงสร้างที่คุ้มค่า คุณอาจเริ่มสงสัยว่ามันคุ้มค่าจริง ๆ หรือไม่ และรูปแบบนี้มีไว้สำหรับใครและใครยกเว้น

หากคุณลองคิดดู สิ่งที่เราทำบนเว็บมากมายไม่ใช่แค่การบริโภคเนื้อหาเท่านั้น แต่เรากำลังสร้างมันขึ้นมา! ฉันกำลังเขียนบทความยาวนี้ในโปรแกรมประมวลผลคำขั้นสูงในเบราว์เซอร์ของฉัน

มีความคาดหวังเพิ่มขึ้นว่าคุณควรจะสามารถบล็อกเนื้อหาในแอปพลิเคชันเนื้อหาที่ทันสมัยได้ ผู้คนเริ่มคุ้นเคยกับประสบการณ์ผู้ใช้ที่น่าพึงพอใจซึ่งใช้ได้ผลและดูดี และที่ที่คุณไม่จำเป็นต้องเรียนรู้ไวยากรณ์เฉพาะทาง สื่อประชาสัมพันธ์แนวคิดที่ว่าคุณสามารถสร้างเนื้อหาที่น่าพึงพอใจและใช้งานง่ายบนเว็บ และเมื่อพูดถึง "ความคิด" แอพโน้ตยอดนิยมได้รวมเนื้อหาบล็อกทั้งหมดและให้ผู้ใช้ผสมผสานสูงสุดจากประเภทที่แตกต่างกันมากมาย บล็อคเหล่านี้ส่วนใหญ่มีมากกว่า markdown และองค์ประกอบดั้งเดิมของ HTML

เป็นที่น่าสังเกตว่า Notion อธิบายถึงกระบวนการในการทำให้เนื้อหาสามารถเข้าถึงได้ผ่าน API ที่คาดการณ์ไว้สูง ได้ชี้ให้เห็นถึงการเลือกรูปแบบเนื้อหาว่า:

เอกสารจากโปรแกรมแก้ไข Markdown คนใดคนหนึ่งมักจะแยกวิเคราะห์และแสดงผลต่างกันในแอปพลิเคชันอื่น ความไม่สอดคล้องกันมีแนวโน้มที่จะจัดการได้สำหรับเอกสารธรรมดา แต่เป็นปัญหาใหญ่สำหรับไลบรารีบล็อกและตัวเลือกการจัดรูปแบบอินไลน์ของ Notion ที่หลากหลาย ซึ่งส่วนใหญ่ไม่ได้รับการสนับสนุนในการใช้งาน Markdown ที่ใช้กันอย่างแพร่หลาย

แนวคิดใช้รูปแบบ JSON ที่ทำให้พวกเขาแสดงเป็นข้อมูลที่มีโครงสร้างได้ ข้อโต้แย้งของพวกเขาคือทำให้โต้ตอบได้ง่ายขึ้นและคาดเดาได้มากขึ้นสำหรับนักพัฒนาที่ต้องการสร้างการนำเสนอเนื้อหาบล็อกที่มาจาก API ของ Notion

ถ้าไม่ใช่ Markdown แล้วอะไรล่ะ?

ฉันสงสัยว่าความโดดเด่นของ Markdown ได้ยับยั้งนวัตกรรมและความก้าวหน้าสำหรับเนื้อหาดิจิทัล ดังนั้น เมื่อฉันโต้แย้งว่าเราควรหยุดเลือกเป็นวิธีหลักในการจัดเก็บเนื้อหา เป็นการยากที่จะให้คำตอบตรงๆ ว่าควรแทนที่สิ่งใด อย่างไรก็ตาม สิ่งที่เรารู้คือสิ่งที่เราควรคาดหวังจากรูปแบบเนื้อหาที่ทันสมัยและเครื่องมือการเขียน

มาลงทุนกับประสบการณ์การเขียนที่เข้าถึงได้กันเถอะ

การใช้ markdown คุณต้องเรียนรู้ไวยากรณ์ และบ่อยครั้งที่ไวยากรณ์และแท็กที่จัดทำขึ้นเองหลายแบบเพื่อให้ใช้งานได้จริงกับความคาดหวังสมัยใหม่ วันนี้รู้สึกว่าเป็นความคาดหวังที่ไม่จำเป็นอย่างสมบูรณ์สำหรับคนส่วนใหญ่ ฉันหวังว่าเราจะมีพลังมากขึ้นในการสร้างประสบการณ์ด้านบรรณาธิการที่เข้าถึงได้และน่ารื่นรมย์ซึ่งสร้างรูปแบบเนื้อหาแบบพกพาที่ทันสมัย

แม้ว่าจะเป็นเรื่องยากที่จะสร้างตัวแก้ไขเนื้อหาบล็อกที่ยอดเยี่ยม แต่ก็มีตัวเลือกสองสามตัวที่สามารถขยายและปรับแต่งสำหรับกรณีการใช้งานของคุณได้ (เช่น Slate.js, Quill.js หรือ Prosemirror) จากนั้นอีกครั้ง การลงทุนในชุมชนโดยใช้เครื่องมือเหล่านี้อาจช่วยพัฒนาต่อไปได้

ผู้คนคาดหวังว่าเครื่องมือการเขียนจะเข้าถึงได้ แบบเรียลไทม์ และทำงานร่วมกันมากขึ้นเรื่อยๆ เหตุใดจึงต้องกดปุ่มบันทึกบนเว็บในปี 2564 เหตุใดจึงไม่ควรทำการเปลี่ยนแปลงในเอกสารโดยไม่เสี่ยงต่อสภาพการแข่งขัน เนื่องจากเพื่อนร่วมงานของคุณบังเอิญเปิดเอกสารในแท็บ เราควรคาดหวังให้ผู้เขียนจัดการกับข้อขัดแย้งในการผสานหรือไม่? และเราไม่ควรทำให้มันง่ายสำหรับผู้สร้างเนื้อหาที่จะทำงานกับเนื้อหาที่มีโครงสร้างด้วยราคาที่สมเหตุสมผลหรือไม่?

ค่อนข้างขัดแย้ง: นวัตกรรมของทศวรรษที่ผ่านมาในเฟรมเวิร์ก JavaScript เชิงโต้ตอบและส่วนประกอบ UI นั้นสมบูรณ์แบบสำหรับการสร้างเครื่องมือการเขียนที่ยอดเยี่ยม แทนที่จะใช้พวกมันเพื่อแปลง Markdown เป็น HTML และเข้าไปในโครงสร้างไวยากรณ์นามธรรมเพื่อรวมเข้ากับภาษาเทมเพลต JavaScript ที่แสดงเอาต์พุต HTML

เนื้อหาที่ถูกบล็อกควรเป็นไปตามข้อกำหนด

ฉันไม่ได้พูดถึงตัวแก้ไข WYSIWYG สำหรับ HTML เพราะพวกเขาเป็นสิ่งที่ผิด ตัวแก้ไขเนื้อหาบล็อกสมัยใหม่ควรทำงานร่วมกับรูปแบบที่ระบุ บรรณาธิการดังกล่าวอย่างน้อยก็มีรูปแบบเอกสารภายในที่เหมาะสมที่สามารถแปลงเป็นสิ่งที่พกพาได้มากขึ้น 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

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.