Markdown กำลังฉุดรั้งคุณอยู่
(newsletter.bphogan.com)- Markdown ที่ถูกใช้อย่างแพร่หลายในการเขียนเอกสารสำหรับนักพัฒนาได้รับความนิยมจากความเรียบง่ายและเข้าถึงง่าย แต่ก็มีข้อจำกัดกับเอกสารเทคนิคขนาดใหญ่เนื่องจาก ขาดความสามารถในการแสดงโครงสร้าง
- Markdown ทำงานคล้าย ระบบชนิดข้อมูลโดยนัย ทำให้ไม่สามารถตรวจสอบความสม่ำเสมอหรือสคีมาได้ และยังมีปัญหาความเข้ากันได้ระหว่าง Markdown หลากหลายแบบ (flavor)
- ไวยากรณ์ขยายอย่าง MDX แม้จะเพิ่มพลังในการแสดงผล แต่กลับเพิ่มความซับซ้อนมากขึ้นจากปัญหา การพกพาข้ามระบบและการขาดมาตรฐาน
- reStructuredText, AsciiDoc, DocBook, DITA เป็นต้น ให้ทั้งโครงสร้างที่ชัดเจนและ semantic markup ซึ่งช่วยเสริมการนำกลับมาใช้ซ้ำและความสามารถในการตีความโดยเครื่อง
- สำหรับเอกสารขนาดเล็ก Markdown ก็เพียงพอ แต่สำหรับ การจัดการเอกสารขนาดใหญ่และหลายช่องทาง จำเป็นต้องเปลี่ยนไปใช้ฟอร์แมตแบบมีโครงสร้าง
ข้อจำกัดเชิงโครงสร้างของ Markdown
- Markdown มี ไวยากรณ์เรียบง่ายที่มนุษย์อ่านได้ง่าย จึงสามารถสร้างเอกสารที่ดูดีบน GitHub หรือเว็บไซต์แบบสแตติกได้
- แต่เพราะไม่สามารถอธิบายความหมายของเนื้อหาได้ จึงขาด ข้อมูลโครงสร้างที่เครื่องเข้าใจได้
- เสิร์ชเอนจิน, LLM, IDE, AI agent และเครื่องมืออื่น ๆ ใช้ประโยชน์จาก โครงสร้างเชิงความหมาย ของเอกสาร แต่ Markdown สร้างได้เพียงแท็ก HTML ที่มีขอบเขตจำกัด
- Markdown ยังมีปัญหาความไม่สม่ำเสมอเมื่อมีการนำกลับมาใช้ซ้ำหรือรวมเนื้อหา เนื่องจาก ความแตกต่างของไวยากรณ์ในแต่ละแพลตฟอร์ม
- ผลลัพธ์คือ Markdown เป็นเพียง ฟอร์แมตระดับตัวหารร่วมต่ำสุด และไม่เหมาะกับการจัดการเอกสารที่ซับซ้อน
ปัญหา implicit type ของ Markdown
- Markdown เป็น ฟอร์แมตที่ไม่มีการกำหนดสคีมาหรือชนิดข้อมูลอย่างชัดเจน ทำให้หัวข้อหรือรายการแบบเดียวกันอาจมีความหมายต่างกันตามบริบท
- มี Markdown หลายแบบ (flavor) อยู่ร่วมกัน จึงเกิด ความแตกต่างในการเรนเดอร์ระหว่างเครื่องมือ
- ตัวอย่าง: บางเครื่องมือรองรับเชิงอรรถ แต่บางเครื่องมือมองข้ามมันไป
- MDX ขยายความสามารถโดยแทรก React component ได้ แต่มีปัญหาความเข้ากันได้ข้ามระบบทำให้ การพกพาต่ำลง
- ส่วนขยายเหล่านี้เป็นความพยายามแก้ข้อจำกัดของ Markdown แต่ก็เป็นเพียง ทางแก้เฉพาะหน้าที่ไม่ได้มาตรฐาน
ความสำคัญของ semantic markup
- semantic markup ใช้อธิบาย ความหมายของเนื้อหา ไม่ใช่รูปลักษณ์
- ตัวอย่าง: “ขั้นตอน (step)” กับ “รายการในลิสต์” แม้จะดูเหมือนกันทางสายตา แต่มีความหมายต่างกัน
- HTML5 เพิ่ม แท็กที่อิงความหมาย อย่าง
<section>,<article>,<aside>เพื่อเสริมการแสดงโครงสร้าง - ข้อดีหลักของ semantic markup
- การแปลงและการนำกลับมาใช้ซ้ำ: สามารถแปลงเนื้อหาเดียวกันเป็น HTML, PDF, ePub และรูปแบบอื่น ๆ ได้
- ความสามารถในการตีความโดยเครื่อง: LLM หรือ agent มองเห็นโครงสร้างได้ชัดเจน จึงให้คำตอบได้แม่นยำขึ้น
- Markdown ไม่สามารถให้ข้อมูลโครงสร้างลักษณะนี้ได้ ทำให้เกิด การสูญเสียข้อมูลระหว่างการประมวลผลภายหลังหรือการแปลงฟอร์แมต
เปรียบเทียบฟอร์แมตทางเลือก
- reStructuredText
- เป็นฟอร์แมตที่ใช้ใน Sphinx ของ ecosystem ภาษา Python โดยใช้ directive และ role เพื่อแสดงความหมายเชิงโครงสร้าง
- รองรับ องค์ประกอบโครงสร้างแบบชัดเจน เช่น code block, หมายเหตุ (note), การอ้างอิงข้าม (:ref:)
- เหมาะกับเอกสารเทคนิคขนาดใหญ่ และรองรับการสร้าง HTML และ PDF
- AsciiDoc
- เป็น ฟอร์แมตข้อความเชิงความหมาย ที่มี attribute, conditional content และความสามารถ include
- รองรับ รูปแบบที่ออกแบบมาสำหรับเอกสารเทคนิคโดยเฉพาะ เช่น ข้อความเตือนอย่าง
NOTE,WARNING, องค์ประกอบ UI และการแสดงคีย์ลัด - สามารถแปลงเป็น HTML, PDF, ePub, DocBook ฯลฯ ผ่าน AsciiDoctor
- DocBook (XML)
- เป็น โมเดลบน XML สำหรับงานตีพิมพ์ด้านเทคนิค ที่มี ระบบแท็กที่มีความหมาย เช่น
<command>,<note>,<xref> - มีแท็กที่จำเป็นสำหรับเอกสารเฉพาะทาง เช่น glossary, index, องค์ประกอบ UI, ชื่อฟังก์ชัน
- สามารถแปลงเป็นรูปแบบผลลัพธ์ที่หลากหลายผ่าน XSLT stylesheet
- ได้เปรียบในด้าน การตรวจสอบโครงสร้างเอกสารขนาดใหญ่และการสร้างดัชนี
- เป็น โมเดลบน XML สำหรับงานตีพิมพ์ด้านเทคนิค ที่มี ระบบแท็กที่มีความหมาย เช่น
- DITA (Darwin Information Typing Architecture)
- เป็น โครงสร้างแบบ XML เชิงโมดูลาร์ ที่ใช้เป็นมาตรฐานเอกสารเทคนิคระดับองค์กร
- เป็น สถาปัตยกรรม XML แบบอิงหัวข้อ ที่กำหนดโครงสร้างเชิงกระบวนการอย่างชัดเจน เช่น
<task>,<step> - ใช้เป็น มาตรฐานการจัดการเอกสารระดับองค์กร สำหรับการใช้ซ้ำของเนื้อหา (conref), การกรอง, การเผยแพร่หลายช่องทาง
- รองรับการทำเรนเดอร์และแปลงฟอร์แมตอัตโนมัติผ่าน DITA Open Toolkit
ทำไม XML ที่ดูไม่สะดวกก็ยังจำเป็น
- Markdown แม้จะเบา แต่เป็น ทางแก้ชั่วคราวที่ขาดทั้งโครงสร้าง มาตรฐาน และความสม่ำเสมอ
- หากคุณกำลังเพิ่มความซับซ้อนให้ Markdown ด้วย MDX, ปลั๊กอิน หรือสคริปต์แบบกำหนดเอง
การเลือกใช้ฟอร์แมตแบบมีโครงสร้างไปเลยจะมั่นคงกว่าในระยะยาว
แล้วควรทำอย่างไร?
- สำหรับ เอกสารขนาดเล็ก อย่าง README หรือเอกสารใช้ครั้งเดียว Markdown ก็เพียงพอ แต่สำหรับ เอกสารขนาดใหญ่ การนำกลับมาใช้ซ้ำ และเอกสารหลายช่องทาง reStructuredText, AsciiDoc, DocBook, DITA เหมาะกว่า
- หากต้องการ เอกสารวางแผน เอกสารนักพัฒนา การใช้ซ้ำ และการจัดการขนาดใหญ่ ให้พิจารณาตามลำดับจาก reST/AsciiDoc ไปสู่ DocBook/DITA
- แนวทางที่เหมาะสมคือ ใช้ฟอร์แมตที่มีโครงสร้างสมบูรณ์ที่สุดเป็นต้นทาง และค่อยแปลงเป็น Markdown เมื่อจำเป็น
- Markdown มีประโยชน์ในฐานะ ฟอร์แมตสำหรับผลลัพธ์ แต่หากใช้เป็น แหล่งข้อมูลต้นทาง (source of truth) จะขยายโครงสร้างได้ยาก
- ทางเลือกที่ดีที่สุดคือเก็บต้นฉบับไว้ใน ฟอร์แมตที่มีโครงสร้างเชิงความหมายสูง และใช้ Markdown สำหรับ ผลลัพธ์ปลายทาง
7 ความคิดเห็น
rst เป็นฟอร์แมตที่อิง XML เหรอ? เพิ่งเคยได้ยินนะ สรุปแปลก ๆ
ดูเหมือนว่าหัวข้อจึงถูกเขียนแบบนั้น เพราะในสรุปได้พูดถึงเกณฑ์การเลือกโดยจัดรวมกับฟอร์แมต XML อื่น ๆ ฉันได้แก้ไขให้ตรงกับต้นฉบับแล้ว
ถ้าจำเป็นก็ใช้ html ใน Markdown แล้วค่อยแปะ mermaid เข้าไปก็พอไหวอยู่.. แต่ถ้าเกินกว่านั้นก็ดูเหมือนจะกลายเป็นงานเอกสารเพื่องานเอกสารอีกที
คนสำคัญกว่าปัญญาประดิษฐ์ อย่ามาขโมยสิ่งที่ฉันเขียนไป จะมาอ้างเรื่อง semantic อะไรกัน
ถ้าต้องใช้ไวยากรณ์เฉพาะ ก็จะเกิดเส้นโค้งการเรียนรู้อีกแบบหนึ่ง และยังต้องรองรับทั้งเครื่องมือพาร์สเฉพาะ, ตัวดู, เอดิเตอร์ ฯลฯ ให้ลื่นไหลทั้งหมดด้วย.. ถ้าระดับนั้นแล้ว อาจจะใช้ Google Docs หรือ Notion ที่เชื่อมต่อกับบริการ AI ส่วนใหญ่ได้อย่างราบรื่นแทนจะดีกว่าก็ได้
ความเห็นจาก Hacker News
จุดแข็งหลักของ Markdown คือ การรองรับอย่างแพร่หลาย ที่ภาษาอื่นไม่มี ทางเลือกส่วนใหญ่ต้องใช้เครื่องมือแยกต่างหาก และใช้ไม่ได้ในสภาพแวดล้อมที่รองรับ Markdown อยู่แล้ว แม้แต่ Google Docs ก็ยังรองรับการวาง Markdown เป็นฟีเจอร์ที่ซ่อนไว้ ถึงจะไม่สมบูรณ์แบบ แต่ข้อดีคือ “ใช้ได้ทุกที่” เหมือนที่ HTML เรียบง่ายกว่า SGML แต่กลายเป็นมาตรฐานเพราะเบราว์เซอร์รองรับ Markdown ก็สามารถพัฒนาไปตามกาลเวลาได้เช่นกัน ความกำกวมของการทำให้เป็นมาตรฐาน การขาดฟีเจอร์ และปัญหาความเข้ากันได้ ก็คล้ายกับยุค HTML4 คิดว่าแนวทางที่เป็นจริงมากกว่าคือ การค่อย ๆ พัฒนาแบบต่อเนื่อง แทนการแทนที่ทั้งหมด
Markdown สามารถใส่ HTML tag ได้ทุกที่ มีระบุไว้ชัดเจนในเอกสารทางการ ดังนั้นข้อจำกัดที่ผู้เขียนพูดถึงจึงไม่มีอยู่จริง
หรืออยู่เรื่อย ๆ ก็ไม่มีเหตุผลที่จะใช้ Markdown ถ้าคำตอบสุดท้ายคือ “ก็ใช้ HTML สิ” งั้นเหตุผลที่ Markdown มีอยู่ก็หายไปตอนเรียนมหาวิทยาลัยในสาขาฟิสิกส์ ฉันเขียนบทความด้วย LaTeX ภาควิชาเคมีใช้ Word ซึ่งแต่ละสาขาก็มีมาตรฐานต่างกัน หมายเลขเวอร์ชันของ TeX ใช้การเข้าใกล้ค่าของ π เพื่อสื่อถึงความสมบูรณ์เป้าหมาย เวอร์ชันปัจจุบันคือ 3.141592653 และคงเสถียรมาเป็นเวลา 47 ปี ดู TeX wiki, คำอธิบายเวอร์ชันแบบ Pi สำหรับเครื่องมือ CLI ฟอร์แมต manpage ก็มีประโยชน์เช่นกัน
Markdown เป็นเหมือน minimum viable product (MVP) เรียนรู้ง่าย และถึงไม่เรนเดอร์ก็ยังอ่านง่าย งานทำ PDF ฉันย้ายจาก AsciiDoc ไป Typst ซึ่งช่วยแก้ปัญหาเรื่องการเข้าถึงได้ แต่ไม่มีภาษามาร์กอัปไหนที่ช่วยยกระดับคุณภาพของงานเขียนได้แทน เปลี่ยนปากกาไม่ได้ทำให้งานเขียนดีขึ้น
น้ำเสียงของบทความนี้คือการอ้างว่า “Markdown ขัดขวางการพัฒนาของ LLM” แต่สมมติฐานที่ว่าความอุดมสมบูรณ์เชิงความหมายจะได้มาแบบอัตโนมัตินั้นไม่สมจริง ในทีมเองก็ไม่มีเวลามานั่งทำงานแบบนั้น และ Markdown ก็เพียงพอแล้ว เหมือนการถกเถียงเรื่อง semantic web ที่ท้ายที่สุดก็เป็นปัญหาว่าใครจะเป็นคนดูแลข้อมูล
ฉันเขียนบล็อกด้วย Org-mode + Emacs สิ่งที่ชอบมากเป็นพิเศษคือความสามารถในการเชื่อม code block และรันมันจากในเอกสารได้ เคยใช้แพลตฟอร์มอย่าง Blorgit, lazyblorg แต่การตั้งค่ายุ่งยาก เลย export เป็น HTML เองแล้วอัปขึ้นเซิร์ฟเวอร์ด้วย rsync ใช้ Ruby script มาต่อ index แล้ว deploy มัน ทรงพลังและเป็นธรรมชาติมากกว่า Markdown มาก
เห็นด้วยบางส่วนกับคำกล่าวที่ว่า “Markdown ขาดโครงสร้าง” แต่ก็รู้สึกเสียดายที่ใช้ วิธีมองแบบสองขั้ว ก่อนจะเลือกฟอร์แมต น่าจะต้องเข้าใจก่อนว่าต้องการโครงสร้างแบบใด เลยทำให้รู้สึกไม่ค่อยสบายใจและเห็นด้วยได้ไม่เต็มที่
การเสนอ DITA เป็นทางเลือกแทน Markdown ถือเป็น ข้อเสนอที่พลาดเป้าอย่างสิ้นเชิง DITA เป็นระบบ XML สำหรับองค์กรขนาดใหญ่ ซึ่งมีจุดประสงค์ต่างจาก Markdown โดยสิ้นเชิง มันเหมาะเฉพาะในสภาพแวดล้อมอย่างองค์กรที่มีคนเกิน 5,000 คน หรือมีสายผลิตภัณฑ์หลายภาษา ถ้าอยู่ในสถานการณ์ที่ใช้ Markdown อยู่ DITA จะไม่เหมาะเลย ทั้งสองอย่างล้วนเป็นการเสียเวลา
ใช้ Markdown มามากกว่า 10 ปีแล้ว และมันก็ยังใช้งานได้ดี ข้อโต้แย้งในบทความก็ไม่ได้ผิดทั้งหมด แต่ก็ไม่ใช่ปัญหาที่ผู้ใช้ Markdown รู้สึกกัน ถ้าจำเป็นก็ไปใช้อย่างอื่นได้ ถึงอย่างนั้นก็ยังอ่านอยู่ประมาณ 5 นาทีเพราะชื่อบทความมันดี
มันแปลกที่พูดถึง MyST ว่าเป็น Markdown รูปแบบหนึ่ง แล้วกลับยก reStructuredText (rST) ขึ้นมาเป็นตัวอย่างอีก เพราะจุดประสงค์ของ MyST ก็คือการเป็น ตัวแทนของ rST อยู่แล้ว ไวยากรณ์เป็นแบบ Markdown แต่รองรับทั้งความหมายเชิงโครงสร้าง directive และ role ครบถ้วน มีการพูดถึงเรื่องนี้ด้วยใน Sphinx issue
ช่วงนี้เห็นบทความแนวนี้บ่อยนะครับ
ไฟล์ข้อความ, Markdown, ฟอร์แมตที่มีโครงสร้างมากขึ้น
เมื่อเปลี่ยนไปแบบนั้น ก็ไม่ได้มีคำตอบตายตัวว่าอะไรถูกต้อง แค่ใช้ฟอร์แมตที่เหมาะสมในเวลาที่เหมาะสมก็พอ
และถ้าพยายามจะทำทุกอย่างด้วยไฟล์เดียว ปัญหาก็จะเกิดขึ้นเสมอ ดังนั้นการแยกหมวดหมู่และจัดให้เป็นระบบตามหัวข้อจึงเป็นสิ่งที่เลี่ยงไม่ได้