- มุ่งสู่การเป็นภาษาสำหรับเอกสารที่ก้าวข้ามข้อจำกัดของ PDF และหน้าเว็บแบบสแตติก โดยทำให้ เบราว์เซอร์เข้าใจโครงสร้างเอกสาร และให้ผู้อ่านนำไปใช้ต่อได้โดยตรง
- เอกสาร Nota ถูกคอมไพล์เป็น โปรแกรม JavaScript และรันในเบราว์เซอร์ ทำให้สามารถใช้ตัวแปร ฟังก์ชัน และโครงสร้างข้อมูลในการเขียนเอกสารได้
- ออกแบบมาโดยคำนึงถึง การผสานรวมกับไลบรารี JavaScript อย่าง KaTeX, Vega-Lite และ Penrose รวมถึงการรองรับข้อกำหนดด้านการเข้าถึง
- สามารถติดตั้งไฟล์รัน
notaด้วยแพ็กเกจ@nota-lang/notaและจัดการเอกสารผ่านเวิร์กโฟลว์การ build หรือ การแก้ไขแบบโต้ตอบ ได้ - ยังเป็น เทคโนโลยีใหม่และกำลังเปลี่ยนแปลง ดังนั้นสถาปัตยกรรมและ API อาจเปลี่ยนได้ และควรคำนึงถึงบั๊ก การขาดหาย หรือความไม่แม่นยำของเครื่องมือและเอกสาร
โครงสร้างเอกสารที่เบราว์เซอร์เข้าใจ
- Nota เป็นภาษาสำหรับเขียนเอกสารอย่างบทความวิชาการและบล็อกโพสต์
- เป้าหมายคือพาเอกสารไปสู่การเป็น สื่อในศตวรรษที่ 21
- ภายในเอกสารมีโครงสร้างมากมายที่ผู้อ่านต้องติดตาม เช่น การนิยามคำศัพท์และการอ้างอิง
- ตัวอย่างเช่น คำว่า
Notaอ้างถึงคำศัพท์ที่ถูกนิยามไว้ในย่อหน้าก่อนหน้า - Nota เปิดให้ผู้เขียนแสดงโครงสร้างเหล่านี้ออกมา และให้เบราว์เซอร์เข้าใจเพื่อที่ผู้อ่านจะนำไปใช้ได้
- ในหน้าตัวอย่างสามารถคลิกหรือดับเบิลคลิกการอ้างอิง
Notaเพื่อดูการทำงานได้
- ตัวอย่างเช่น คำว่า
- เอกสาร Nota จะถูกคอมไพล์เป็น โปรแกรม JavaScript
การติดตั้งและเวิร์กโฟลว์การแก้ไข
- Nota ใช้งานได้ผ่านการติดตั้งไฟล์รัน
notaด้วยแพ็กเกจ@nota-lang/nota- ข้อกำหนดคือ NodeJS ≥ 16 และ npm ≥ 6
- ไดเรกทอรีไบนารีแบบ global ของ NodeJS ต้องอยู่ใน
PATHของเชลล์
- เอกสาร Nota เดี่ยวสามารถ build ได้ตามขั้นตอนต่อไปนี้
npm install --global @nota-lang/notaecho "@Title: Hello world" > index.notanota build index.notaopen dist/index.html
- ไฟล์ Nota สามารถ แก้ไขแบบโต้ตอบ ได้ด้วยคำสั่ง
nota edit index.nota - วิธีการเขียนเอกสารดูได้ที่ Reference
- หากต้องการเพิ่ม Nota ลงในเว็บไซต์หรือดูสถาปัตยกรรม ให้ดู Integration guide
ช่องว่างระหว่าง PDF กับเว็บแบบสแตติก
- สื่อหลักของเอกสารดิจิทัลแบ่งออกเป็น PDF และหน้าเว็บ
- PDF ถูกออกแบบมาให้สะท้อนเอกสารทางกายภาพ จึงมีข้อจำกัดแบบกระดาษ เช่น การแบ่งหน้า ความกว้างคงที่ และรูปแบบที่ไม่เปลี่ยนแปลง
- หน้าเว็บสามารถทำ การจัดรูปแบบแบบไดนามิก ได้ เช่น ปรับขนาดสำหรับมือถือ แปลเป็นภาษาอื่น หรือเปลี่ยนสีสำหรับผู้ใช้ที่มีภาวะตาบอดสี
- หน้าเว็บยังรองรับ ปฏิสัมพันธ์แบบไดนามิก ได้ เช่น ข้อความที่ขอบริบทเพิ่มเติม แผนภาพที่เปลี่ยนมุมมอง หรือหมายเหตุสำหรับภายหลัง
- ความสามารถแบบไดนามิกเหล่านี้ในปัจจุบันยังเข้าถึงได้เป็นหลักเฉพาะนักพัฒนาเว็บมืออาชีพ
- เครื่องมือเอกสารเดิมอย่าง LaTeX, Pandoc, Markdown และ Scribble ส่วนใหญ่สร้างได้เพียงหน้าเว็บแบบสแตติก
- Nota พยายามลดช่องว่างนี้ด้วยภาษาสำหรับเอกสารที่มีจุดเริ่มต้นต่ำ ขยายได้มาก และมีเส้นโค้งการเรียนรู้ที่ค่อยเป็นค่อยไป
สถานะปัจจุบันและข้อมูลอ้างอิง
- Nota ยังเป็น เทคโนโลยีใหม่และกำลังพัฒนา
- สถาปัตยกรรมและ API เปลี่ยนแปลงอยู่เสมอ
- เครื่องมืออาจมีบั๊กและฟีเจอร์ที่ยังขาดอยู่
- เอกสารอาจยังไม่สมบูรณ์หรือไม่แม่นยำ
- ตอนนี้กำลังมองหาผู้ใช้กลุ่มแรกที่จะเข้ามามีส่วนร่วมในการทำให้ Nota เป็นภาษาสำหรับเอกสารแห่งอนาคต
- คอมโพเนนต์
@Definitionและ@Refช่วยให้เมื่อผู้เขียนเพิ่มคำอธิบายประกอบในเอกสารเพียงเล็กน้อย Nota runtime จะสามารถแสดงคำนิยามของการอ้างอิงเป็น tooltip ภายในบริบทได้- Nota เวอร์ชันในอนาคตอาจมีฟีเจอร์อย่างการค้นหาการอ้างอิงทั้งหมดของคำนิยามที่กำหนด
- ดูปรัชญาการออกแบบเพิ่มเติมได้ที่ A New Medium for Communicating Research on Programming Languages
1 ความคิดเห็น
ความคิดเห็นจาก Hacker News
ผมเป็นคนสร้าง Nota ตอนนี้กำลังปรับแต่งงานออกแบบใหม่ หลังจากทำโปรโตไทป์เว็บเพจช่วงแรก
กำลังสร้างรากฐานที่แข็งแรงขึ้นสำหรับประเด็นอย่าง จะผสมเนื้อหากับการคำนวณเข้าด้วยกันอย่างไร(https://arxiv.org/abs/2310.04368) และไวยากรณ์ทำให้งานเอกสารง่าย/ยาก/เป็นไปไม่ได้อย่างไร(https://github.com/cognitive-engineering-lab/doclang-benchma...)
ยังเชื่อในปรัชญาหลักอยู่ แต่คิดว่า Nota น่าจะ เปลี่ยนไปค่อนข้างมากในราว 6 เดือน ระหว่างนี้ ผมมองว่าพัฒนาการที่เจ๋งที่สุดในสายภาษาเอกสารคือ Typst และแนะนำให้ลองดู: https://typst.app/
Nota เวอร์ชันถัดไปจะเขียนด้วย Rust 99% :-)
ถ้าประสิทธิภาพเป็นปัญหาจริง ๆ Rust ก็สมเหตุสมผลกว่า JavaScript แต่ไม่แน่ใจว่าจะเป็นปัจจัยชี้ขาดในกรณีใช้งานส่วนใหญ่หรือไม่
แม้จะเคยเขียนเอกสารขนาดใหญ่ด้วย LaTeX มามาก แต่ไม่เคยชอบเลย มันเหมือนสัตว์ประหลาดสำหรับวงการวิชาการ ไม่ใช่สำหรับธุรกิจ ส่วนใน Word งานที่อยากทำให้สม่ำเสมอก็ไม่ได้ง่ายเสมอไป สไตล์เละได้เร็ว และการลำดับเลขกับ bullet ก็มีข้อผิดพลาดแทรกซึมได้ง่าย
เมื่อมีการแก้ไขหลายรอบ การติดตามการเปลี่ยนแปลง จะกลายเป็นปัญหาใหญ่ และสุดท้ายก็ต้องพึ่งความเชื่อใจว่าอีกฝ่ายจะไม่เขียนทับประวัติการแก้ไข แค่มีผลิตภัณฑ์ที่รับประกันได้ว่าการเปลี่ยนแปลงทั้งหมดตั้งแต่ต้นจนถึงอนุมัติขั้นสุดท้ายจะแสดงให้เห็นอย่างถูกต้อง ก็อาจเป็น killer app ที่องค์กรและทนายความชอบได้แล้ว
ถ้าโรยบล็อกเชนเข้าไปด้วย อาจระดมทุนได้ง่ายขึ้น แต่จริง ๆ ดูเหมือนจะใกล้เคียงกับปัญหาคริปโตกราฟีพื้นฐานมากกว่าบล็อกเชน และไม่น่าจำเป็นต้องมีความซับซ้อนระดับนั้น
สิ่งสำคัญที่สุดในภาษาเอกสารคือการให้สองอย่างนี้มาก่อน ตัวอย่างเช่น เอกสาร TeX เริ่มด้วยโค้ดเตรียมการอย่าง
\documentclass,\usepackageหลายตัว, การนิยาม theorem, การตั้งค่าฟอนต์ แต่เอกสาร R Markdown/Quarto เริ่มจากความหมายของงานเขียนจริง ๆ อย่างชื่อเรื่อง ผู้เขียน และบทคัดย่อทันทีเห็นความแตกต่างของจุดเน้นได้ชัดเจน
รวมถึงเลย์เอาต์ที่แน่นและข้อมูลเยอะอย่างโปสเตอร์ประชุมวิชาการขนาด A0, สไตล์เอกสารตามมาตรฐานระดับชาติอย่าง GOST ในกลุ่มประเทศหลังสหภาพโซเวียต, ข้อกำหนดสไตล์บรรณานุกรมที่เพิ่มพรวดพราดตามธรรมเนียมนานาชาติต่าง ๆ, การทำให้ดูเหมือนสไตล์เริ่มต้นของ MS Word เวอร์ชันใดเวอร์ชันหนึ่ง, การวางภาพหรือข้อความซ้อนบนภาพอย่างแม่นยำเพื่อแก้ไขบทความแบบเร่งด่วน และการปรับสิ่งเหล่านี้อย่างตั้งใจ
ในโลกของ TeX ทั้งหมดนี้ทำได้ในทางเทคนิค แต่ในทางปฏิบัติต้องใช้ มนตร์ดำ ลึกจนผู้ใช้ทั่วไปที่มีปริญญาก็ไม่อยากขุดลงไป
หลายเดือนที่ผ่านมา ผมใช้มันอย่างสนุกในการสำรวจไอเดียแอนิเมชัน SVG(https://simpatico.io/svg) หรือทำให้โครงสร้างข้อมูล/อัลกอริทึมใหม่ ๆ เป็นรูปธรรม(https://simpatico.io/stree3)
เซิร์ฟเวอร์ทั้งหมดและตัวประมวลผล Markdown เป็นโค้ด Node ที่อ่านง่ายราว 500 บรรทัด มี dependency น้อยมาก ไม่มี transitive dependency และไม่ต้องมีขั้นตอนคอมไพล์ โดยค่าเริ่มต้นเซิร์ฟเวอร์ไม่อนุญาตทรัพยากรจากบุคคลที่สามหรือคุกกี้ใด ๆ
อยู่บน GitHub ภายใต้ไลเซนส์ MIT และกำลังจัดระเบียบระหว่างย้ายจาก repo ส่วนตัวไปเป็น repo ขององค์กร ดูได้ที่: https://simpatico.io/lit
ในจุดที่ไม่จำเป็นต้องมี “ความไดนามิกที่จำเป็น” การไม่มีมันต่างหากที่เป็น ฟีเจอร์ ไม่ใช่บั๊ก
บนมือถือ ผมชอบอ่านเว็บเพจมากกว่า PDF อยู่มาก เพราะถ้าเป็นเว็บเพจที่สมเหตุสมผล ก็มักปรับให้พอดีกับหน้าจอมือถือได้
เราต้องการรูปแบบที่เข้ารหัสทั้ง ข้อมูลเชิงภาพและข้อมูลดิจิทัล ร่วมกัน เลเยอร์ดิจิทัลอาจไม่ต้องมองเห็นโดยค่าเริ่มต้น แต่ควรเข้าถึงได้เมื่อจำเป็น
แน่นอนว่า “ฟีเจอร์” เหล่านี้ถูกมองเป็นบั๊กและถูกตัดออกจากสเปก ISO PDF/A ที่ใช้เพื่อการเก็บรักษาระยะยาว: https://en.wikipedia.org/wiki/PDF/A
ประเด็นคือ บางครั้งเอกสารก็ควรเป็นแค่เอกสาร ในบทความวิทยาศาสตร์ LaTeX คือสิ่งที่คนเขียนเพื่อให้คนอ่าน และด้วยคำสั่งกับแพ็กเกจแบบกำหนดเอง ก็สามารถเขียนเอกสารข้อความธรรมดาที่อ่านง่ายพอ ๆ กับบทความที่ถูกสร้างออกมาได้ ด้าน accessibility ก็ถือว่าดีด้วย
เอกสารไดนามิกยังมีพื้นที่น่าสนใจที่ยังไม่ค่อยถูกสำรวจ แต่ต้องมีตัวอย่างดี ๆ ของการใช้อย่างมีรสนิยม
สรุปคือมันใกล้กับ LaTeX มากกว่า และมีองค์ประกอบของ Markdown อยู่บ้าง เขียนด้วย JavaScript ทำให้หลายคนสามารถมีส่วนร่วมด้วยภาษาที่รู้อยู่แล้ว และที่ดีคือใช้ไลเซนส์ MIT
ยังไม่รู้ว่าจะมีงานให้ใช้ทันทีไหม แต่ดูเจ๋งทีเดียว ถ้าต้องเขียนงานที่ต้องการฟีเจอร์แบบ LaTeX แต่ปลายทางไม่ได้บังคับให้ใช้ LaTeX ก็คงลองใช้ Nota
ผมคิดว่า Knuth แทบเป็นเหมือนกึ่งเทพก็จริง แต่เขาไม่ได้ลงมาจากสวรรค์พร้อมมอบ TeX แล้วบอกว่า “อย่าลองของใหม่ไปชั่วนิรันดร์” เสียหน่อย
มันยังขาดกลไกกันพลาดและฟีเจอร์อำนวยความสะดวกที่ภาษาออกแบบสมัยใหม่มีอยู่มากเกินไป เวลาใช้ LaTeX ผมต้องพึ่งชิ้นส่วน
\input{}อย่างหนักเพื่อแยกบล็อกออกจากกัน จะได้หลีกเลี่ยงปัญหาที่พังเพราะพลาด escape แค่ตัวเดียวผมยังคงหวังให้มีการตีความใหม่ในแบบสมัยใหม่ แต่รู้สึกเหมือนเราติดอยู่ใน จุดเหมาะที่สุดเฉพาะที่ ที่หนีออกมายาก เพราะแรงเฉื่อยและแพ็กเกจที่สะสมมาหลายสิบปีบน TeX
สิ่งที่คล้ายกันมี https://pandoc.org/, https://quarto.org/, https://markdoc.dev/, https://mdxjs.com/, https://typst.app/
ปัญหาของความพยายามใหม่ในสาขานี้คือมันเข้ามาในพื้นที่ที่แออัดเกินไปอยู่แล้ว ไม่ค่อยสำคัญนักว่าโซลูชันเดิมจะไม่สมบูรณ์แบบหรือไม่
คล้ายกับการเข้าไปในเมืองประวัติศาสตร์ของยุโรปที่มีประวัติศาสตร์สถาปัตยกรรมสะสมมานับพันปี แล้วอ้างแบบอาคารใหม่ที่ยอดเยี่ยม ที่ดินว่างนั้นหายาก และผู้คนไม่รื้อโครงสร้างเก่า ๆ เพียงเพื่อทดลองของใหม่ ต้องทำให้รู้สึกได้ถึงข้อได้เปรียบอย่างท่วมท้น
ในสถาปัตยกรรม เหล็กและคอนกรีตเสริมเหล็กเปิดมิติแนวตั้ง ทำให้การใช้พื้นที่ดีขึ้นอย่างมาก และหลังจากนั้นประวัติศาสตร์ก็เปลี่ยนไป
ประเด็นสำคัญคือมี มิติที่ยังไม่ถูกสำรวจ พอจะดึงคนให้มาใช้รูปแบบเอกสารอีกแบบหนึ่งเพื่อ “ปรับปรุง” ASCII, reStructuredText, wikitext, Markdown, TeX/LaTeX, AsciiDoc, HTML ฯลฯ หรือไม่
คำตอบที่พบบ่อยคือโครงสร้างพื้นฐานไฮเปอร์เท็กซ์เชิงความหมาย วิสัยทัศน์ดั้งเดิมยังไม่เกิดขึ้นจริง หากสมมติว่าระบบนิเวศแบบปิดในปัจจุบันเป็นฝันร้ายที่จะผ่านไป เว็บแบบกระจายศูนย์อีกครั้งก็ต้องการโครงสร้างพื้นฐานการเขียนเอกสารที่ทันสมัย เป็นมิตรต่อผู้ใช้ และเพิ่มพลังให้ผู้ใช้
อย่างไรก็ดี อาจยังมีมิติอื่นที่จะยกระดับการเขียนและแชร์เอกสารไปอีกขั้น ความงามของนวัตกรรมอยู่ที่การไม่ถูกผูกมัดด้วยกฎและภูมิปัญญาเดิม
ต้องมีรูปแบบเอกสารที่มีประสิทธิภาพ และเพื่อให้เป็นเช่นนั้น รูปแบบนั้นต้องไม่พยายามทำทุกอย่าง กล่าวคือ ตารางควร แยกประเภทเอกสารตามไฟล์ เหมือนรูปแบบสเปรดชีตมาตรฐาน และแตกต่างจาก HTML ที่พยายามทำเองทั้งหมดทั้งตาราง กราฟิก(SVG) ฯลฯ
ถ้าแยกแต่ละอย่างเป็นไฟล์ต่างหาก ผู้ใช้ก็สามารถเลือกโปรแกรมที่ต้องการเพื่อดูหรือจัดการเอกสาร แทนที่จะดูทุกอย่างด้วยเบราว์เซอร์เดียว อีกทั้งยังช่วยด้านการกระจายผ่านเครือข่าย และเป็นประโยชน์ในสภาพแวดล้อมที่มีพื้นที่จัดเก็บหรือแบนด์วิดท์ต่ำ
ดังนั้นจากมุมมองของผม ไม่มีอะไรต้องประดิษฐ์ขึ้นใหม่ แค่ทำให้สิ่งที่ถูกประดิษฐ์ไว้แล้วเฉพาะทางขึ้นและขัดเกลาให้ดีขึ้นก็พอ
หากลองตามลิงก์ไปดู https://willcrichton.net/nota/ จะเห็นว่า Nota มีข้อดีที่น่าเชื่อถือในกลุ่มเฉพาะที่ตั้งใจไว้ นั่นคือการทำให้ บทความวิชาการด้านภาษาโปรแกรมมิง เข้าใจได้ง่ายขึ้น
การเรนเดอร์เป็น PDF คุณภาพสูงได้หรือไม่นั้นเป็นทั้งความจำเป็นและคำถามที่ชัดเจนอยู่แล้ว เพื่อให้เข้ากันได้กับระบบเดิม ๆ บางทีการเรนเดอร์เป็น LaTeX อาจจะดีกว่าด้วยซ้ำ
โดยพื้นฐานแล้ว Nota คือมาร์กอัป + โค้ด (JavaScript) และชุดนี้ก็เป็นพื้นที่ที่ MDX เล็งอยู่ เมื่อก่อนมีคนเคยพูดถึงเรื่องนี้ ผู้สร้างบอกว่า Nota เหมาะกับเอกสาร ส่วน MDX เหมาะกับเว็บไซต์: https://news.ycombinator.com/item?id=31349579
ถ้าอย่างนั้น ถ้า Nota จะเป็นที่นิยมขึ้นมา ก็คงต้องมีใครสักคนเอาไปห่อเป็นผลิตภัณฑ์ ผลลัพธ์ดูดี แต่การต้องไปยุ่งกับ Node.js เพื่อทำเอกสารนั้นยุ่งยากเกินไป และให้ความรู้สึกเหมือนกลับไปใช้ LaTeX อีก คนส่วนใหญ่น่าจะชอบ Notion หรือโปรแกรมประมวลผลคำมากกว่า
ยิ่งไปกว่านั้น Nota ไม่ใช่คู่แข่งโดยตรงของตระกูล TeX Nota สร้างสิ่งที่เว็บเบราว์เซอร์อ่าน ส่วน xxxTeX สร้างสิ่งที่ PDF reader อ่าน ผมรู้ว่า xxxTeX สร้างเอาต์พุตรูปแบบอื่นได้ด้วย แต่คนส่วนใหญ่ใช้มันเพื่อสร้าง PDF
MDX พร้อมใช้กับเฟรมเวิร์กอะไรก็ได้อย่าง React/Vue เป็นต้น แต่นั่นก็หมายความว่าโดยพื้นฐานแล้วมันไม่ได้เสนอแนวทางความเห็นใด ๆ มาให้เลย
Nota ให้ความรู้สึกเหมือนน่าจะเสียบเข้ากับ static site generator ได้ แน่นอนว่าต้องทำให้ทั้งสองทำงานร่วมกันให้ได้ก่อน แต่ผมคิดว่านี่เป็นความคาดหวังที่ทำได้สำหรับใครสักคนที่ทุ่มเทมากกว่าผมนิดหน่อย
ไม่เข้าใจว่าทำไมต้องมีภาษาที่คอมไพล์เป็น JavaScript เพื่อสร้างหน้าข้อความ เป้าหมายเดียวกันนี้ AsciiDoc ก็จัดการได้
สำนักพิมพ์จริง ๆ อย่าง O’Reilly ก็ใช้ AsciiDoc เป็นรูปแบบอินพุตสำหรับทำหนังสือและเว็บไซต์
ผมใช้ AsciiDoc มาหลายปีแล้วและชอบมัน จะกลับไปใช้ Markdown เฉพาะที่ที่ยังไม่รองรับ AsciiDoc เท่านั้น ตัวอย่างเช่น GitHub และ GitLab รองรับการเรนเดอร์ AsciiDoc
น่าเสียดายที่ PyPI ยังไม่รองรับ แต่ก็ดีที่ดูเหมือนจะมีคนหันมาดูเรื่องนี้มากขึ้น: https://github.com/pypa/readme_renderer/issues/205
แต่เครื่องมือช่วงหลัง ๆ ก็มีเรื่องที่น่าหงุดหงิดอยู่ เห็นและขอบคุณว่ามีความพยายามมหาศาลใส่เข้าไปใน Asciidoctor แต่ ไม่มีเอาต์พุต HTML5 เชิงความหมาย, การผสานกับ image generator ทำได้ยาก หรืออย่างน้อยก็ยากเกินจำเป็น และมันหนักถึงขั้นเป็น dependency Ruby เพียงตัวเดียวบนเครื่องทั้งหมดของผม
ถ้าไม่นับปัญหา Ruby แล้ว ประเด็นเหล่านี้เปิดไว้ใน GitHub อยู่ ดังนั้นถ้ามีเวลาและทรัพยากรมากขึ้นก็น่าจะแก้ได้
ยังไม่แน่ใจ Emacs org-mode ดูดีกว่าและพึ่งพา JavaScript น้อยกว่าด้วย
https://docusaurus.io/ ก็ดีและยืดหยุ่นมาก ถ้าอยากขยาย Nota ในลักษณะคล้ายกัน แนะนำให้ดูสองอย่างนี้
กำลังคิดอยู่ว่าวิธีที่ง่ายที่สุดในการทำบล็อกที่คอนเทนต์ส่วนใหญ่เป็นแบบ static แต่สามารถใส่กราฟแบบโต้ตอบหรือการปรับแต่งตามใจได้เมื่ออยากใส่ คืออะไร สงสัยว่า Nota จะเป็นตัวเลือกที่ดีไหม
ผมก็ดูตัวเลือกอื่นอย่าง Quarto(https://quarto.org/) ไว้ด้วย และไม่แน่ใจว่าอาจจะใช้บล็อก static site ง่าย ๆ อย่าง Jekyll แล้วแก้ HTML เอาต์พุตเองเมื่อจำเป็นได้หรือเปล่า
วิธีนี้ทำให้ใช้ HTML ได้ทั้งหมด ปรับแต่งกระบวนการสร้างได้ จัดการ dependency ได้ค่อนข้างง่าย และรูปแบบที่เกี่ยวข้องก็เป็นมาตรฐาน
Astro ให้เขียนคอมโพเนนต์สไตล์ React แล้วคอมไพล์เป็น HTML/CSS ล้วน ยกเว้นกรณีที่จำเป็นต้องใช้ JavaScript จริง ๆ เว็บส่วนตัวและบล็อกของผมก็ทำด้วย Astro: https://sjer.red/, ซอร์สอยู่ที่ https://github.com/shepherdjerred/shepherdjerred.com
มีบทช่วยสอนสำหรับทำบล็อกด้วย Astro ด้วย: https://docs.astro.build/en/tutorial/0-introduction/