พาราด็อกซ์ของเว็บไซต์แบบสแตติก
(kristoff.it)- แม้แต่เว็บไซต์เรียบง่ายอย่างบล็อกส่วนตัวหรือหน้าติดต่อ ผู้ใช้ทั่วไปก็ยังมักอยู่กับ CMS อย่าง WordPress ขณะที่เว็บไซต์ HTML แบบสแตติกกลับเป็นสิ่งที่วิศวกรมืออาชีพดูแลได้ง่ายกว่า เกิดเป็นปรากฏการณ์ที่กลับด้านกัน
- หากต้องการสร้างเว็บไซต์สแตติกเอง ต้องจัดการขั้นตอนกลางหลายอย่างด้วยตัวเอง ตั้งแต่ซื้อโดเมน เลือกโฮสติ้ง ตั้งค่า DNS เลือก SSG ไปจนถึงตั้งค่าพipeline การ deploy
- วิศวกรใช้ประโยชน์จาก โฮสติ้งฟรีและโดเมนแบบกำหนดเอง ผ่าน GitHub Pages หรือ Cloudflare Pages ได้ แต่ผู้ใช้ทั่วไปกลับต้องพึ่งบริการที่แพงกว่าและหนักกว่า แม้ในกรณีที่เว็บไซต์แบบสแตติกก็เพียงพอแล้ว
- SuperHTML ถูกแนะนำว่าเป็น HTML language server ตัวแรกที่รายงาน diagnostic ให้ผู้ใช้ โดยเครื่องมือ diagnostic ที่มีอยู่เดิมส่วนใหญ่มักผูกกับ frontend framework เฉพาะ ทำให้ใช้งานกับ vanilla HTML เพียงอย่างเดียวได้ยาก
- หากไม่สามารถทำให้การพัฒนาเว็บแบบเรียบง่ายทำได้ง่ายขึ้น เว็บก็จะห่างไกลจากผู้ที่ไม่ใช่มืออาชีพ และผู้ใช้ทั่วไปจะถูกผลักไปอยู่ในพื้นที่ปิดอย่าง โซเชียลเน็ตเวิร์ก
ความย้อนแย้งที่เว็บไซต์สแตติกกลับยากขึ้น
- มีการเปรียบเทียบตัวอย่างเว็บไซต์ส่วนตัวสองแบบ
- แบบหนึ่งคือ CMS ซับซ้อนที่เขียนด้วย PHP ซึ่งต้องมีเว็บเซิร์ฟเวอร์, worker หลายตัว, แคช Redis และฐานข้อมูล SQL
- ส่วน frontend ก็โหลดเป็น Single Page Application ขอเนื้อหาในรูปแบบ JSON แล้วประกอบใหม่บน client
- อีกแบบหนึ่งประกอบด้วยไฟล์ HTML แบบสแตติกและไฟล์ CSS หนึ่งหรือสองไฟล์ โดยไม่มี JavaScript
- มองเผิน ๆ อาจคิดว่าผู้ใช้ทั่วไปจะใช้เว็บไซต์สแตติกที่เรียบง่าย ส่วนวิศวกรมืออาชีพจะใช้โครงสร้างซับซ้อน แต่ในความเป็นจริงกลับเกือบตรงกันข้าม
- หากผู้ใช้ทั่วไปต้องการดูแลเว็บไซต์สแตติกเอง ต้องผ่านหลายขั้นตอน
- ซื้อโดเมน
- หาแพลตฟอร์มโฮสติ้ง
- ตั้งค่า DNS
- เลือกหรือสร้าง SSG เอง
- ตั้งค่า pipeline สำหรับ deploy
- ในทางกลับกัน วิศวกรซอฟต์แวร์สามารถใช้ โฮสติ้งฟรี และการรองรับโดเมนแบบกำหนดเองผ่าน GitHub Pages, Cloudflare Pages ฯลฯ ได้
- ผลคือแม้ใน 99% ของกรณีที่เว็บไซต์สแตติกก็เพียงพอ ผู้ใช้ทั่วไปกลับถูกผูกติดกับโซลูชันที่ซับซ้อน ซึ่งต้องจ่ายมากกว่าและใช้ทรัพยากรประมวลผลมากกว่า
ความจำเป็นของเครื่องมือที่ทำให้เว็บเรียบง่ายทำได้ง่าย
- การบรรยายที่ SquiggleConf ใน Boston กล่าวถึงประสบการณ์การสร้าง HTML language server และข้อสรุปเชื่อมโยงไปสู่ปัญหา การเข้าถึงเว็บ
- SuperHTML ถูกแนะนำว่าเป็น HTML language server ตัวแรกที่รายงาน diagnostic ให้ผู้ใช้ และบทความที่เกี่ยวข้องได้ขึ้น หน้าแรกของ Hacker News
- มี linter อยู่แล้วและ editor ก็สามารถแสดง diagnostic ได้ แต่โดยทั่วไปมักผูกกับ frontend framework เฉพาะ
- ด้วยเหตุนี้ ผู้ใช้จึงเลือก framework แม้ในความเป็นจริงจะไม่ได้ต้องการความซับซ้อนนั้นก็ตาม
- เว็บไม่ใช่สิ่งของวิศวกรซอฟต์แวร์เท่านั้น และยิ่งทำให้เว็บซับซ้อนขึ้น ผู้ใช้ทั่วไปก็ยิ่งถูกผลักเข้าไปอยู่ใน รั้วของโซเชียลเน็ตเวิร์ก
- Startup หรือ Big Tech มีแรงจูงใจทางเศรษฐกิจไม่สอดคล้องกัน จึงยากที่จะเข้ามาแก้ปัญหานี้แทน และจำเป็นต้องทำให้เว็บแบบเรียบง่ายสร้างได้ง่ายขึ้น
1 ความคิดเห็น
ความคิดเห็นจาก Hacker News
เคยมีประสบการณ์เจ็บปวดมาหลายครั้งจากการพยายามโน้มน้าวฝ่ายการตลาดให้เลิกใช้ WordPress แล้วหันมาใช้ไซต์แบบ static
สุดท้ายประเด็นสำคัญคือ ความง่ายในการแก้ไข ไซต์ WordPress ถูกปรับให้เหมาะกับบรรณาธิการ ไม่ใช่กับโฮสติ้ง คนดูแลเทคนิค ฝ่ายบัญชี หรือผู้อ่าน และคนที่แก้ไขไซต์นี่แหละที่เป็นคนตัดสินใจว่าจะใช้วิธี implement แบบไหน
ถ้าให้เลือกระหว่างไซต์ที่เรนเดอร์ได้ในต่ำกว่า 100ms ปลอดภัยโดยสมบูรณ์ ค่าโฮสต์เป็น 0 บาท แต่ต้องใช้ไฟล์ Markdown กับการ deploy ผ่าน Git นิดหน่อย กับ WordPress ที่ช้า แพง เปราะบาง และต้องดูแลต่อเนื่อง แต่มีประสบการณ์แก้ไขที่ดี พวกเขาจะเลือก WordPress เสมอ
ผมยังงงอยู่เสมอว่าทำไมคนเหล่านี้ถึงมีสิทธิ์เลือก แต่ทำการทดลองแบบเดิมกี่ครั้ง ผลลัพธ์ก็เหมือนเดิมทุกครั้ง
ผมไม่เห็นว่ามันแปลกตรงไหนที่พวกเขาเลือก WordPress แทนที่จะต้องเรียนรู้ text editor กับ Git การทดลองควรเป็นการเปรียบเทียบ WordPress กับเครื่องมือที่ให้ประสบการณ์แก้ไขที่ดี แต่เบื้องหลังสร้าง static site และ deploy ผ่าน Git ให้ แบบนั้นข้อกำหนดรองอย่างความปลอดภัยและความเร็วถึงจะมีความหมายขึ้นมา
มันใกล้เคียงกับแอปพลิเคชันแบบปรับแต่งเองที่คนไม่เชี่ยวชาญสามารถคลิกและลากเพื่อทุบๆ ปรับๆ ให้เข้ากับฟีเจอร์ที่ต้องการ มากกว่าจะเป็นแค่บล็อก ไม่ต้องเขียนโค้ดด้วยซ้ำ จนกว่าจะโดนแฮ็ก หรือมีฟีเจอร์เฉพาะทางที่ต้องใช้วิศวกรตัวจริง
ถ้าใช้ Hugo, Ghost ฯลฯ ก็จะนำไปสู่คำว่า “อันนี้ต้องใช้แพลตฟอร์มอื่น” และแพลตฟอร์มนั้นก็กลายเป็น Shopify, ระบบบัญชี, ปลั๊กอินโซเชียลเน็ตเวิร์ก/สมาชิก, กระดานประกาศงาน ฯลฯ WordPress กลายเป็นของที่แปลงเป็นอะไรก็ได้
พอมีคนบอกที่ปรึกษาว่าต้องการอะไร คำตอบก็จะเป็น “เดี๋ยวผมตั้งค่าด้วย WordPress ให้” และเพราะทุกคนใช้ WordPress เวลาเกิดปัญหา หาคนมาแก้ปลั๊กอินเล็กน้อย หรือติด hook ส่งอีเมลก็ทำได้ง่าย ยุคของที่ปรึกษา PHP คือสิ่งที่สร้างอำนาจครอบงำของ WordPress
ปัญหาคือส่วนใหญ่ แม้รวมถึงโซลูชันแบบเสียเงิน ก็ไม่ใช่โซลูชันที่สมบูรณ์จริงๆ พอเริ่มใช้ คุณจะรู้ได้อย่างรวดเร็วว่า WordPress บังคับข้อจำกัดที่ไร้เหตุผลขนาดไหน คุณออกแบบร้านค้าออนไลน์ให้อยู่นอกหายนะด้านประสิทธิภาพของระบบ entity/metadata ไม่ได้เลย ระบบที่แม้แต่ query ขนาดพอประมาณก็ใช้เวลา 5 วินาที และสร้าง secondary query ที่ไม่ได้ optimize อีก 50 รายการ ปลั๊กอินบางตัวถึงขั้นอ้อม WordPress แล้วสร้างตารางฐานข้อมูลของตัวเอง
WordPress มีสถาปัตยกรรมที่แย่มากสำหรับสิ่งอื่นนอกจากบล็อก แต่กลับถูกใช้เป็นเครื่องมือสำหรับทุกอย่าง CMS อื่นๆ ไม่ทำแบบนั้น คนเลยไม่ใช้
คอนเทนต์ยังคงถูกกระจายผ่าน CDN ในรูปไฟล์ static ที่ generate แล้วได้ ไซต์แบบ static ไม่ได้จำเป็นต้องใช้ Markdown กับ Git
ผมมองหา toolchain มานานที่แม้แต่อินเทิร์นที่ไม่มีประสบการณ์ด้านเทคนิคเลยก็สามารถ deploy การแก้ไขได้โดยไม่ต้องติดอยู่กับรายละเอียดทางเทคนิค แต่จนถึงตอนนี้ยังไม่เจอ
สิ่งที่ใกล้ที่สุดคือวาง static site generator ไว้บน headless CMS แต่พูดตรงๆ คือทั้งหมดก็ไม่ค่อยดีนัก
ตอนที่ผมทำงานที่เอเจนซีซึ่งทำเว็บไซต์แนะนำตัวให้ธุรกิจท้องถิ่นในปี 2016 ลูกค้ารายหนึ่งขอให้ใส่ iframe เล็ก ๆ สำหรับระบบจองลงในเว็บไซต์ที่พวกเขาทำเอง สิ่งที่ส่งมาคือเอกสาร Word ไฟล์เดียว แล้วปรากฏว่าพวกเขา export มันเป็น HTML แล้วอัปขึ้น shared hosting ราคาถูก
สำหรับพวกเขา มันเข้ากันมาก พวกเขาทำให้เมนูออนไลน์เป็นปัจจุบันอยู่เสมอได้ เพราะแค่ export ตรงจากเอกสาร Word ที่ใช้ทำเมนูฉบับพิมพ์ ตอนนั้นในทีมเราก็แอบหัวเราะเยาะกันบ้าง แต่พอมาคิดตอนนี้ก็รู้สึกผิด สำหรับตอนที่มีเรื่องสำคัญกว่าเป็นล้านอย่างอย่างการบริหารร้านอาหาร จริง ๆ แล้วนี่คือ วิธีที่อัจฉริยะ
การทำเว็บไซต์แบบ static ยังง่ายกว่าอยู่ดี เพียงแต่เครื่องมือเขียนที่สร้าง HTML ในปัจจุบันไม่ค่อยดี หรือถึงจะใช้ได้ ก็มีขั้นตอนที่ต้องรันบนเซิร์ฟเวอร์เพื่อเสิร์ฟไซต์พ่วงมาด้วย
งานของผมไม่ใช่การล้อเลียนว่า “ทำให้ดีกว่านี้ได้นะ” แต่คือการปรับปรุงโซลูชันของพวกเขา ทำให้โซลูชันที่ผมให้ทำงานได้ดีเท่าเดิม หรือถ้าเป็นไปได้ดีกว่าเดิม โดยไม่ไปขัดขวางความสำเร็จที่พวกเขามีอยู่แล้ว
นักพัฒนาหลายคนไม่อยากยอมรับ แต่เว็บโซลูชันชั่วคราวแบบนี้มักทำงานได้ดีกว่ากลยุทธ์หลายอย่างที่นักพัฒนาเว็บที่มีทักษะจะลงมือทำคนเดียว
สิ่งสำคัญคือธุรกิจนำเสนออะไร และสร้างความสัมพันธ์กับลูกค้าหรือโต้ตอบกับลูกค้าอย่างไร บางครั้งแค่ export เอกสาร Word เป็น HTML ก็เพียงพอแล้ว เทคโนโลยีช่วยปรับปรุงได้ก็จริง แต่เวทมนตร์ที่แท้จริงอยู่ที่คนที่บริหารธุรกิจ
บางครั้งการหาวิธีปรับปรุงโซลูชันแบบนี้ก็ยากจริง ๆ เราอาจทำเว็บไซต์ที่ดีกว่าและ deploy ลงอินฟราสตรักเจอร์ที่ซับซ้อนขึ้นได้ แต่สุดท้ายลูกค้าชอบมากขึ้นไหม? ธุรกิจดีขึ้นไหม? ตรงนั้นอาจไม่ใช่เรื่องเล็กน้อยเลย
ผมหาทางเลือกดี ๆ ที่สร้าง HTML ได้ถูกต้องกว่า HTML export ของ Word และให้ตัวเลือกมากกว่ามาหลายปีแล้ว
ผมชอบอะไรแบบนี้ มีเว็บไซต์ไฟล์ HTML เดียวที่ทำด้วย Vue template อยู่มากมาย รวมถึงไซต์ที่เผยแพร่เป็นเอกสาร Notion สาธารณะ หรือไลบรารีรูปภาพแบบ inline ของ iCloud มันทำให้ทึ่งว่าการเชื่อมโยงอะไรเข้าด้วยกันกลายเป็นเรื่องง่ายและแพร่หลายแค่ไหน และทำให้รู้สึกด้วยว่าเรามักทำเรื่องให้ซับซ้อนบ่อยแค่ไหนเวลาพยายามสร้างเองตั้งแต่ต้น
เวลามีเวลาไม่พอ ผมก็ชอบเครื่องมืออย่าง mmm.page สำหรับปะติดปะต่อไมโครไซต์เล็ก ๆ หรือไซต์ใช้ครั้งเดียวแบบรวดเร็ว การสำรวจเครื่องมือพวกนี้สนุกดี
แต่ “เอกสาร” ของบางหน้าเป็นชุดตารางที่มีวันที่กับข้อความ และลูกค้าดูแลเอง สุดท้ายวิธีแก้ที่ไปถึงก็คล้ายกัน ให้เขาใส่ตารางในเอกสาร Word แล้วส่งมาให้เรา จากนั้นเรา export เป็น HTML/CSS แล้ววางไว้ในตำแหน่งที่เหมาะสม
ไม่ได้สง่างาม และไม่ใช่วิธีแก้ที่สเกลได้ แต่สำหรับกรณีใช้งานนั้น มันคือ วิธีที่ง่ายที่สุด อย่างชัดเจน
ตอนนั้นก็น่าอัศจรรย์ และตอนนี้ก็ยังน่าอัศจรรย์ เราได้ทำความฝันที่จะนำคอมพิวติ้งไปสู่ทุกคนให้เป็นจริงอย่างเงียบ ๆ แล้ว
ตอนนี้ที่ Asheville กำลังเจอปัญหานี้อย่างหนัก แม้บริการมือถือเพิ่งกลับมาได้ ทุกคนก็ยังใช้ 3G ห่วย ๆ ที่หลุดตลอด และเว็บไซต์ที่ต้องใช้เพื่อหาข้อมูลเอาตัวรอดพื้นฐานก็ไม่มีเว็บไหนโหลดขึ้นเลย
คนดี ๆ บางคนทำไซต์ข่าวแบบข้อความล้วนขึ้นมา และวันนี้ผมเห็นว่าเว็บไซต์ของ Buncombe County ก็มีไซต์แบนด์วิดท์ต่ำแล้ว แต่พอเปิดดู ก็ยังมี Bootstrap CSS 130KB กับ jQuery 50KB ที่บล็อกการเรนเดอร์อยู่
การที่ผู้คนทำสิ่งเหล่านี้ให้เป็นเรื่องยอดเยี่ยม แต่ประชาชนต้องการมันตั้งแต่หนึ่งสัปดาห์ครึ่งก่อน ตอนนี้เรารู้กันแล้วว่าจะหาน้ำ อาหาร น้ำที่ดื่มไม่ได้ ฯลฯ ได้ที่ไหน การได้เห็นเทคโนโลยีล้มเหลวหนักขนาดนี้จากเหตุการณ์นี้ ทำให้ผมตาสว่างในแบบที่ชวนหดหู่
แผนที่ไฟดับของบริษัทไฟฟ้าซ่อนอยู่หลังการล็อกอิน และเรนเดอร์ด้วย clustering กับฟีเจอร์ UI สวย ๆ จึงช้าอยู่แล้วแม้เชื่อมต่อดี ดังนั้นแค่จะตรวจสอบสถานะหรือแจ้งไฟดับก็ใช้เวลาค่อนข้างนาน
โทรหาบริษัทไฟฟ้าก็ได้ แต่เขาตั้งเมนูเป็น voice navigation ไม่ใช่เสียงปุ่มกด และมันจำเสียงที่เพี้ยนจากการเชื่อมต่อ 4G หรือ 2G แย่ ๆ ได้ไม่ดี
ต้องใช้คลื่นยาวกับพลังงานต่ำ แต่การเข้าถึงมันต่ำเกินไป และผมก็ไม่แน่ใจว่านั่นเป็นเพราะเหตุผลที่สมเหตุสมผลหรือไม่
การเชื่อมต่อขาดตั้งแต่ Black Mountain ไปจนถึงแนวเขต Tennessee กับ Georgia ผมสงสัยว่าจะมีคนจำนวนมากไหมที่กลับมาจับสัญญาณ 3G ห่วย ๆ ได้ด้วยซ้ำ สิ่งที่ผมรู้คือการติดต่อกับคนที่อาศัยอยู่ที่นั่นเป็นเรื่องยาก
งานที่ดีที่สุดบางส่วนของผมทำบน MacBook 12 นิ้วที่ต่อกับ Wi‑Fi โรงแรมที่ไม่เสถียร เพราะอย่างนั้นผมจึงใส่ใจ ความเร็วหน้าเว็บ มาก
ถ้าจะสรุปความเจ็บปวดของภัยพิบัติครั้งนี้ในคำเดียว ก็คือ การสื่อสารล่มสลาย ในทุกรูปแบบ
เห็นด้วยอย่างยิ่งกับคำพูดที่ว่า “เว็บไม่ใช่ของวิศวกรซอฟต์แวร์เท่านั้น ยิ่งเราทำให้เว็บซับซ้อนขึ้นเท่าไร เราก็ยิ่งผลักผู้ใช้ทั่วไปเข้าไปอยู่ในรั้วที่เราเรียกว่าโซเชียลเน็ตเวิร์กมากขึ้นเท่านั้น”
ยังมีพอดแคสต์เกี่ยวกับ Squiggle Conf งานประชุมล่าสุดที่มีคำพูดนี้ด้วย: https://changelog.com/jsparty/339
เมื่อเวลาผ่านไป ฟีเจอร์ที่ผู้คนคาดหวังจาก “เว็บไซต์พื้นฐาน” เพิ่มขึ้นมาก
แม้แต่ผมที่เป็นโปรแกรมเมอร์ก็ยังเคยตกหลุมพราง static site generator หลายครั้ง
พอเริ่ม side project ด้วย static site generator แล้วถึงจังหวะที่อยากเพิ่มฟีเจอร์เล็ก ๆ ขึ้นมา ก็หงุดหงิดเพราะรู้สึกว่าไม่น่าเลย น่าจะเริ่มด้วยแอป Rails หรือ PHP ง่าย ๆ ไปตั้งแต่แรก
ทุกวันนี้ถ้าต้องการไซต์แบบ static ผมก็เริ่มจากโฟลเดอร์ไฟล์ HTML ไปเลย เส้นทางจากไอเดียไปสู่การลงมือทำนั้นซับซ้อนน้อยลงและเร็วขึ้นมาก โดยไม่ต้องถกเถียงเชิงทฤษฎีบนโต๊ะหรือผัดวันประกันพรุ่งเรื่องเครื่องมือ
ผมค่อนข้างพอใจกับการเขียน HTML และ CSS เองโดยตรง แต่ก็ไม่ได้แนะนำให้ทุกคนทำแบบนี้
อีกอย่างที่เจ๋งคือ ถ้าภายหลังตัดสินใจ “หนี” ไป Rails ก็แค่คัดลอกโฟลเดอร์ไฟล์ HTML ไปไว้ในโฟลเดอร์ public/ ของ Rails ได้เลย เส้นทางอัปเกรดค่อนข้างง่าย
ในฝั่ง Ruby นั้น Jekyll ดังที่สุด แต่ถูกออกแบบมาสำหรับกรณีใช้งานเฉพาะอย่างการเขียนบล็อกด้วย Markdown หรือภาษา lightweight markup อื่น ๆ จะฝืนใช้กับงานอื่นก็ได้ แต่ในฐานะ static site generator เอนกประสงค์แล้วไม่ได้สะดวกนัก
ถ้าอยากได้สิ่งที่คัดลอก/วางไป Rails ได้ง่าย middleman ซึ่งเป็น static site generator ที่อิง Rack ก็เหมาะ สามารถเขียนด้วย erb/haml และ ActiveSupport ได้ตั้งแต่แรก
ถ้าอยากคงความเรียบง่ายแบบเขียน HTML และ CSS เอง แต่ต้องการแค่ฟีเจอร์อำนวยความสะดวกอย่าง include, partial template, link helper แล้วละก็ nanoc ก็เป็น static site generator แบบค่อยเป็นค่อยไปที่ใช้ได้ เริ่มจาก HTML/CSS ธรรมดา แล้วเพิ่มฟีเจอร์เฉพาะตอนที่ต้องการก็พอ
บางครั้งก็เขียนโค้ดเพื่อปรับพฤติกรรมให้เข้ากับความต้องการ แต่ก็ราว ๆ หลายปีครั้ง เรียบง่ายและใช้งานได้ดี
มีสิ่งที่คิดถึงจากไซต์แบบไดนามิกอยู่บ้าง แต่ก็ไม่ค่อยแน่ใจว่าโฟลเดอร์ไฟล์ HTML เรียบ ๆ ดีกว่า Pelican ในแง่ไหน
กฎพื้นฐานที่ตั้งไว้เพื่อกันไม่ให้เว็บไซต์ฟีเจอร์บวม คือการกำหนดตัวตนที่ต้องการให้ชัด ผมอยากให้มันเป็น อาร์ไคฟ์ ของงานที่ผมเคยทำ และถ้าเป็นอาร์ไคฟ์ก็ต้องอยู่ทนได้ยาวนานมาก ๆ ดังนั้นไฟล์ static ที่คัดลอก ทำมิเรอร์ และรันบนแพลตฟอร์มโฮสติ้งใดก็ได้ง่ายจึงเหมาะสม
การจัดการไซต์หลายภาษาให้เข้าที่ใช้เวลาพอสมควร แต่ก็อย่างน้อยเป็นต้นทุนที่จ่ายแค่ครั้งเดียว
การเปลี่ยนสไตล์ก็อาจเป็นปัญหาได้ถ้ามันถูกฮาร์ดโค้ดอยู่ในไฟล์ HTML
งานที่ซับซ้อนกว่านั้นเขียนด้วย Django การเพิ่มฟีเจอร์สำหรับผมนั้นง่ายมาก
.md→.htmlสำหรับคอนเทนต์ แต่ตอนนี้ยังไม่จำเป็นการดูไซต์ผ่าน local server ได้ง่ายก็เป็นเรื่องดี ทางที่ดีที่สุดคงคือดูผ่าน file:// ได้ด้วย แต่ยังคลี่โครงสร้างทั้งหมดไม่ได้ เลยจบด้วยขั้นตอน
make localที่สร้างสำเนาแยกสำหรับการดูแบบอิงไฟล์เว็บไซต์ส่วนตัวของเว็บดีเวลลอปเปอร์มีปัจจัยที่ทำให้ซับซ้อนอยู่ นั่นคือ การพัฒนาแบบขับเคลื่อนด้วยเรซูเม่
มีผู้เชี่ยวชาญที่อยากใช้ side project ส่วนตัวเพื่อการพัฒนาแบบขับเคลื่อนด้วยเรซูเม่ และคิดว่าทำแบบนั้นจะลดโอกาสทำโปรเจกต์ของนายจ้างพัง
ตัวอย่างเช่น เช้าวันนี้ก็มีเว็บไซต์อิสระที่กำลังจะเปิดตัวอยู่แล้ว และด้วยเหตุผลด้านเรซูเม่เป็นหลักจึงใช้เว็บเฟรมเวิร์กสมัยใหม่ยอดนิยม แต่สุดท้ายกลับอัปเดตเว็บไซต์ต่อไม่ได้
มีแพ็กเกจ NPM ตัวหนึ่งมีปัญหาความปลอดภัยร้ายแรง และพอพยายามอัปเดต NPM ก็ติดความขัดแย้งของ dependency ระหว่างกันที่แก้อัตโนมัติไม่ได้ น่าขันที่เพราะเรื่องนี้จึงไม่สามารถ push security update ไปยังไซต์ production ได้
ไซต์นั้นอาจใช้แค่ไฟล์ HTML ที่เขียนเอง 5 ไฟล์, inline JS นิดหน่อย และสคริปต์ Perl CGI เล็ก ๆ 2 ตัวก็พอแล้ว และถ้าเป็นแบบนั้นอีก 25 ปีก็คงยังทำงานได้สมบูรณ์
แต่กลับกลายเป็นว่าเฉพาะส่วน NodeJS อย่างเดียวก็มีแพ็กเกจ NPM 129 ตัว, security update ที่ต้องทำบ่อย ๆ, และ tree ของซอร์สไฟล์ที่เข้าใจยากซึ่งเต็มไปด้วยชิ้นส่วน template, การตั้งค่า TS และ handler
แต่ผู้เชี่ยวชาญไม่มีความหรูหราพอที่จะไม่ทำด้วยวิธีที่ซับซ้อนเกินเหตุ ตัวอย่างเช่น ถ้ามี Perl อยู่ในเรซูเม่ก็เป็นผลกระทบร้ายแรงต่อโอกาสได้งาน แม้แต่คนที่ไม่ได้ทิ้งเรซูเม่เพราะการเลือกปฏิบัติด้านอายุ ก็ยังจะมองว่าเป็นคนโง่ที่ไม่ได้ทำการพัฒนาแบบขับเคลื่อนด้วยเรซูเม่
ในกรณีของผมไม่ได้สนใจเรซูเม่หรือข้อเสนอเลย แต่ก็ยังต้องการอะไรสักอย่างที่ ergonomic กว่าการปล่อย HTML ออกมาจาก template JS/Python ดังนั้นไซต์ของผมจึงเป็นการผสมกันของ TypeScript, Mithril, Express และไลบรารียูทิลิตีบางตัว
ไม่รู้ว่ามีแพ็กเกจกี่ตัว และก็ไม่สนใจด้วย ขอแค่สิ่งที่ดึงเข้ามาส่วนใหญ่ mature และไม่คลอดฟีเจอร์-ช่องโหว่ใหม่ทุก ๆ ไม่กี่นาทีก็พอ
ถึงจะไม่ได้บอก stack ไว้ แต่ดูมีความเป็นไปได้สูงว่าจะเป็น React กับ ecosystem ที่ “ปรับปรุงอยู่เสมอแต่ไม่มีวันจบ” ของมัน ถ้าจะให้คำแนะนำที่ไม่ได้ขอ ก็คืออย่าเชื่อ false dichotomy ระหว่าง HTML ล้วนกับบ่อโคลนที่เลวร้ายที่สุดนั้นมีพื้นที่กว้างใหญ่ และสถานการณ์ในโลก React ก็เป็นเรื่องเฉพาะของ React ไม่ได้เป็นตัวแทนของโลกภายนอกทั้งหมด
Killer app ของ WordPress คือ คอมเมนต์ ตัวสร้างไซต์แบบสแตติกแทบจะโดยนิยามแล้วไม่รองรับคอมเมนต์ แต่บล็อก WordPress แทบจะมีมาให้ในตัวเสมอ
ถ้าสิ่งอย่าง Hugo อยากดังจริง ๆ ในพื้นที่บล็อก ก็แค่ต้องทำธีมที่ดูดีพร้อมคอมเมนต์ให้ได้ แก้ปัญหาให้รองรับสเกลก็พอ เช่น ใช้ SQLite ที่ shard ตามแต่ละบล็อก ให้บุคคลที่สามโฮสต์ได้ในราคาถูกมาก แบบนั้นก็จะกลายเป็นห่านทองคำตัวเล็ก ๆ
คอมเมนต์และการถกเถียงเกี่ยวกับบทความไปอยู่ในคอมมูนิตี้บุคคลที่สามอย่าง Reddit, HN, Facebook แล้ว ระหว่างคนที่ไล่อ่านรายการคอมเมนต์ใต้บทความ Substack กับคนที่อ่านคอมเมนต์ HN หนึ่งหรือสองหน้าเกี่ยวกับบทความเดียวกัน ฝั่งไหนจะมากกว่ากัน?
ถ้าเป็นบทความสายเทค ผมว่าแทบจะฟันธงได้ว่าการถกเถียงบน HN จะมีคุณภาพสูงกว่าเธรดคอมเมนต์ของบทความใดบทความหนึ่ง เพราะ HN ดึงฐานผู้อ่านที่กว้างกว่าบล็อกทั้งหมดยกเว้น 0.1% แรกไปแล้ว
ข้อดีหลักของการคอมเมนต์โดยตรงบนบทความบล็อกมีแค่อย่างเดียว คือผู้เขียนมีโอกาสเห็นมากกว่ามาก การได้ขึ้นหน้าแรก HN ชั่วครู่เป็นเรื่องไม่ยั่งยืน
ระบบนิเวศ WordPress ตรงกันข้ามเลย มันประกอบด้วยธุรกิจระดับหลายพันล้านดอลลาร์ที่เข้าใจอย่างลึกซึ้งว่าคนที่ดูแล CMS และเว็บไซต์ต้องการอะไรในตลาดเฉพาะกลุ่มเล็ก ๆ ของตนเอง และขนาดตลาดนี้คือเว็บไซต์ราว 500 ล้านเว็บ
คนเขียนบทความนี้อาจจะฉลาดก็จริง แต่ชัดเจนว่าไม่ได้ฉลาดในเรื่องการใช้งาน CMS เชิงปฏิบัติ โลกทัศน์ที่ว่า “ไซต์ HTML แบบสแตติกดีกว่า แต่ไม่เป็นที่นิยมเพราะบริษัทชั่วร้าย” แทบจะรู้ได้ว่าไม่ถูกต้องถ้าเคยรับเงินทำเว็บไซต์สักครั้งสองครั้ง
ตัวสร้างไซต์ HTML แบบสแตติกแทบไม่มีทางทำทุกอย่างที่ลูกค้าต้องการได้ WordPress ตระหนักมานานแล้วว่าตลาดนี้กว้างและหลากหลายแค่ไหน จึงทำระบบรองรับปลั๊กอินขึ้นมา
ผมเห็นด้วย 100% ว่าคอมเมนต์เป็นหนึ่งในการใช้งานดั้งเดิมที่ทำให้เว็บใช้สิ่งที่ใกล้เคียง CMS มากกว่าตัวสร้างไซต์แบบสแตติก แต่นอกเหนือจากนั้นยังมีการใช้งานอีกเป็นล้านอย่าง
เอกสาร HTML แบบสแตติกอย่างเดียวไปได้ไม่ไกลนัก พอพ้นจากบล็อกนักพัฒนาแนวมินิมอล ก็ต้องมีตรรกะของโปรแกรมจำนวนมากเพื่อทำสิ่งที่ผู้ใช้และลูกค้าจริง ๆ ต้องการ ดังนั้นก็ใช้ CMS ที่เหมาะกับความต้องการ และถ้าต้องการให้รองรับทราฟฟิกเยอะ ๆ ก็แคชอย่างหนัก นั่นก็เป็นส่วนหนึ่งของงาน
ผมไม่เข้าใจจริง ๆ ว่าทำไมนักพัฒนาที่คิดว่าตัวเองเก่งมากถึงพยายามประดิษฐ์ล้อใหม่ แทนที่จะเรียนรู้เล็กน้อยว่าแคชทำงานอย่างไรแล้วนำไปใช้ หรือเพราะนี่ก็เป็น “ปัญหาที่แก้แล้ว” ที่น่าเบื่อเกินไปเหมือนกัน?
ผมเองก็ใช้ Hugo แต่จากมุมมองวิศวกรรม แม้ footprint จะใหญ่เกินจำเป็น ประสบการณ์ผู้ใช้ของ WordPress ก็เป็นมิตรกว่ามาก
ไม่ใช่ทุกเว็บไซต์ธุรกิจจะต้องการคอมเมนต์ แต่ก็น่าจะต้องการฟอร์มติดต่อ การเปิดเผยอีเมลแอดเดรสก็เป็นทางเลือกหนึ่ง แต่การจัดการ pipeline การรับข้อมูลน่าจะดีกว่า
สำหรับไซต์สแตติก ต้องหาบริการที่เชื่อถือได้เพื่อจัดการการส่งฟอร์ม แล้วผูกเข้ากับไซต์ให้ถูกต้อง ทำให้มีชิ้นส่วนที่เคลื่อนไหวเพิ่มขึ้นอีกหนึ่งชิ้น อาจกลายเป็นบิลที่ต้องจ่ายแยก และเป็นอีกสิ่งหนึ่งที่ต้องจัดการเมื่ออุตสาหกรรมเกิดการรวมตัวกัน
https://hn.algolia.com/?q=%22disqus%22
Facebook ก็เคยให้ระบบคอมเมนต์ที่หลายเว็บไซต์ใช้ แต่สูญเสียความเชื่อมั่นและ reach ไปเพราะสแกนดัลหลายครั้ง
ผมเองก็เข้ากับพาราด็อกซ์นั้นเหมือนกัน ผมเขียนเว็บไซต์ส่วนตัวใหม่ด้วย PHP สมัยใหม่ โดยไม่ใช้เฟรมเวิร์กหรือฐานข้อมูล
ส่วนใหญ่เป็นไซต์สแตติก แต่ใช้ PHP ใส่ header และจัดการรายการอย่างลิสต์บทความบล็อก การไม่เป็นสแตติกทั้งหมดสะดวกกว่านิดหน่อย เขียนบทความ commit แล้ว push ก็ขึ้นออนไลน์ทันที ตัวสร้างไซต์สแตติกส่วนใหญ่รู้สึกซับซ้อนเกินไป
โค้ดของหน้าเดี่ยว ๆ ประมาณว่า
title = "Blog Article Title";,$this->shortTitle = "Title";,$this->date = mktime(0,0,0,1,27,2024);,if ($this->mode == PageMode::Meta) return;แล้วตามด้วยคอนเทนต์ HTML ดิบrouter จะใส่ header และ footer ของไซต์ให้อัตโนมัติ และถ้าเพิ่มไฟล์
_layout.phpในโฟลเดอร์ ก็สามารถใส่เลย์เอาต์เพิ่มอีกชั้นให้หน้าลูกได้ หน้ารายการบล็อกจะไล่อ่านไฟล์บทความแต่ละไฟล์ในโฟลเดอร์เพื่อสร้างอินเด็กซ์ตรงนี้ใช้
$this->mode == PageMode::Metaโดยรันโค้ดของแต่ละไฟล์เพื่อดึง metadata แล้วออกมาก่อนจะเรนเดอร์ส่วนที่เหลือ ถ้าคอนเทนต์เยอะขึ้นคงสเกลได้ไม่ดีนัก แต่ถ้ากลายเป็นปัญหาก็จะปรับโค้ด PHP ทั้งหมดของ “เฟรมเวิร์ก” ของผมมีแค่สี่ไฟล์:
init.php,functions.php,Layout.php,Page.phpข้อดีของนักพัฒนาคือสามารถใช้ โค้ด แทนการตั้งค่าหรือข้อมูลได้ และยังใช้โค้ดเพื่อเขียนคอนเทนต์ให้มีประสิทธิภาพขึ้นได้ด้วย
ผลลัพธ์ยังค่อนข้างไม่สมบูรณ์ แต่ดูได้ที่นี่: https://www.codaris.com/
include()สำหรับ header กับชิ้นส่วน global บางอย่างหากมองประสบการณ์ผู้ใช้จากมุมของเจ้าของเว็บไซต์ เรื่องนี้ก็ไม่ค่อยเป็น paradox เท่าไร WordPress ทำให้ทุกอย่างง่ายอย่างไม่น่าเชื่อ แม้จะมี overhead มากกว่ามากก็ตาม
มันดูเหมือน paradox ก็ต่อเมื่อคิดว่าเป็น trade-off กับการใช้เวลาตั้งค่าสารพัดอย่างเท่านั้น สำหรับคนส่วนใหญ่ ทางเลือกอื่นคือจ่ายเงินให้ใครสักคนทำเว็บไซต์ให้
ถ้าสร้างตัวแก้ไข WYSIWYG สำหรับ Hugo แล้วทำให้ตั้งแต่จดทะเบียนโดเมนไปจนถึงเผยแพร่ไซต์เสร็จได้ในไม่กี่คลิก ก็น่าจะทำเงินได้มาก
เข้าใจว่าหมายถึงอะไร ถึงบริษัทเหล่านั้นจะใกล้เคียงกับสิ่งที่พูดแล้ว แต่ถ้าจัดการขั้นตอนเล็ก ๆ ระหว่างทางให้ได้ ก็น่าจะเป็นประโยชน์อย่างมากสำหรับบางคน
[1] https://micro.blog
ส่วนประโยคที่ว่า “ตอนที่เปิดตัว SuperHTML ผมรู้ว่ามันเป็น language server ตัวแรกสำหรับ HTML ที่รายงาน diagnostics ให้ผู้ใช้ ผมเขียนบล็อกโพสต์ และมันขึ้นหน้าแรกของ Hacker News แต่ไม่มีใครแก้ความเข้าใจผิดให้ ดังนั้นจึงเป็นความจริง” นั้น อาจเป็นเพราะ IDE ส่วนใหญ่ทำสิ่งนี้กันมาหลายปีแล้ว ตั้งแต่ก่อนที่ Microsoft จะออก LSP ด้วยซ้ำ
Vim, Neovim, Helix, Zed, VSCode ต่างก็ใช้ implementation พื้นฐานเดียวกันที่ไม่มีการรองรับ diagnostics
Helix จะเปิดใช้งาน SuperHTML เป็นค่าเริ่มต้นตั้งแต่รุ่นถัดไป: https://github.com/helix-editor/helix/pull/11609