สร้างเว็บไซต์โดยไม่ใช้เฟรมเวิร์กและไลบรารีหลายตัว

 (kodingkitty.com)
3 คะแนน โดย GN⁺ 2023-07-05 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • Koding Kitty ใช้ สแต็กที่เน้น HTML แบบสแตติก กับเว็บไซต์บริษัทขนาดเล็ก เพื่อให้สามารถดูแลเพจที่จำเป็นและบล็อกได้โดยไม่ต้องพึ่ง CMS ขนาดใหญ่หรือเฟรมเวิร์ก
  • เกณฑ์ในการเลือกคือ ความเร็ว·ความสะดวกในการพัฒนา·โฮสติ้งราคาถูก·ความซับซ้อนต่ำ และ WordPress·เครื่องมือโนโค้ด·เฟรมเวิร์ก·Jamstack ต่างมีภาระด้านการตั้งค่าและการเรียนรู้สูงเกินเมื่อเทียบกับข้อกำหนด
  • คอนเทนต์เขียนด้วย HTML โดยตรง แทน Markdown หรือเครื่องมือแก้ไขแบบภาพ ทำให้จัดการโพสต์ที่ผสมข้อความกับวิดเจ็ต HTML/CSS/JS ได้ง่าย
  • โครงสร้างที่ซ้ำกันและบล็อกร่วมถูกจัดการด้วย เทมเพลต Jinja และสคริปต์ Python 45 บรรทัดทำหน้าที่ต่อเนื่องตั้งแต่ตรวจจับการเปลี่ยนแปลง เรนเดอร์ HTML ไปจนถึงเรียก Tailwind CSS CLI
  • เพราะเป็นไซต์สแตติก โฮสติ้งราคาถูกก็เพียงพอ โดยเว็บโฮสติ้งของ Hetzner เริ่มที่ 2 EUR และยังรับมือกับทราฟฟิกที่พุ่งขึ้นจากการขึ้นหน้าแรกของ Hacker News ได้

เหตุผลที่เลือกสแต็กแบบเรียบง่าย

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

ข้อกำหนดและเกณฑ์เริ่มต้น

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

ตัวเลือกที่พิจารณาแล้วแต่ตัดออก

  • WordPress และ CMS ที่คล้ายกัน

    • ยอมรับว่า WordPress มีบทบาทสำคัญต่ออินเทอร์เน็ต
    • แต่สำหรับข้อกำหนดที่ค่อนข้างเรียบง่ายนั้นถือว่าเกินความจำเป็น
    • ไม่จำเป็นต้องเก็บคอนเทนต์ไว้ในฐานข้อมูล และไม่ต้องการปลั๊กอินหรือเครื่องมือแก้ไขแบบภาพ

  • เครื่องมือโนโค้ด

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

  • เฟรมเวิร์ก

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

  • Jamstack และตัวสร้างไซต์สแตติก

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

องค์ประกอบของ KittyStack

  • การจัดชุดของ Koding Kitty ถูกจัดระเบียบโดยยึดข้อกำหนด 4 ข้อเป็นหลัก

  • เว็บไซต์ที่เร็ว

    • เว็บไซต์สแตติกทำงานได้รวดเร็ว

  • การพัฒนาที่เร็ว

    • คอนเทนต์เขียนด้วย HTML ไม่ใช่ Markdown หรือเครื่องมือแก้ไขขั้นสูง
    • โพสต์ของ Koding Kitty ผสมข้อความกับวิดเจ็ต HTML/CSS/JS ดังนั้น การเขียน HTML โดยตรง จึงเหมาะสม

  • โฮสติ้งราคาถูก

    • ค่าโฮสติ้งไซต์สแตติกขึ้นอยู่กับผู้ให้บริการและฟีเจอร์เสริมที่ต้องการ
    • ไซต์สแตติกไม่ต้องใช้ฮาร์ดแวร์ขนาดใหญ่ จึงเลือกคอนฟิกขั้นต่ำได้
    • Hetzner webhosting เริ่มที่ 2 EUR
    • เว็บไซต์ Koding Kitty รับมือกับทราฟฟิกที่พุ่งขึ้นในระดับที่ขึ้นหน้าแรกของ Hacker News ได้

  • ความซับซ้อนน้อยที่สุด

    • บางหน้าและบางโพสต์มีแพตเทิร์นที่ซ้ำกัน
    • แม้จะทำด้วยการคัดลอกและวางได้ แต่เมื่อเวลาผ่านไปอาจควบคุมได้ยาก
    • จำเป็นต้องมีความสามารถสำหรับลูปและการรวมบล็อกโค้ด เช่น เฮดเดอร์และฟุตเตอร์

Jinja และโฟลว์การบิลด์

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

เชนเครื่องมือแบบเรียบง่าย

  • เพจสแตติกสุดท้ายถูกสร้างด้วย สคริปต์ Python 45 บรรทัด
    • เป็นจำนวนบรรทัดที่รวมคอมเมนต์และบรรทัดว่างแล้ว
  • โฟลว์การบิลด์เป็นดังนี้
    • นักพัฒนาแก้ไข index.src.html
    • Watchdog.py ตรวจจับการเปลี่ยนแปลงของไฟล์
    • เรนเดอร์เทมเพลต Jinja เป็น index.html
    • เรียก Tailwind CSS CLI เพื่อสร้าง styles.min.css
  • ระหว่างพัฒนา Live Server จะเสิร์ฟไฟล์และโหลดใหม่เมื่อมีการเปลี่ยนแปลง
  • ตอนดีพลอย จะอัปโหลดไฟล์ด้วย FTP แบบแมนนวล

ข้อดีของการพัฒนาเว็บที่ซับซ้อนน้อยลง

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

บทความที่เกี่ยวข้อง

1 ความคิดเห็น

 
GN⁺ 2023-07-05
ความคิดเห็นบน Hacker News

  • พอร์ตโฟลิโอภาพถ่ายของฉันก็มาลงตัวด้วยแนวทางแบบเดียวกัน พอย้ายจากงานพัฒนามาทำภาพถ่าย ข้อดีคือไม่จำเป็นต้องพึ่ง Squarespace เหมือนช่างภาพคนอื่น
    หลังจากลองทั้งตัวเลือกแบบเซิร์ฟเวอร์ที่ทำด้วย Ghost, Statamic, Phoenix/Vapor และ static site generator ทั่วไปหลายตัว สุดท้ายก็ลงเอยกับการเขียน HTML ล้วนแบบไม่ใช้เทมเพลต แล้วอัปขึ้นเซิร์ฟเวอร์ Hetzner ด้วย rsync
    การไม่มีเทมเพลตสำหรับ UI ที่ใช้ร่วมกันอย่าง navigation อาจน่ารำคาญนิดหน่อย แต่จนถึงตอนนี้ยังไม่เคยมีการแก้ไขไหนที่ regex ใช้เวลานานเกินไม่กี่นาที และครั้งหนึ่งตอนแรก ๆ ที่ greedy regex ลบเนื้อหาทิ้งไป git ก็ช่วยไว้
    การสร้างไฟล์ภาพหลายขนาดและหลายฟอร์แมตค่อนข้างจุกจิก แต่ก็ทำให้ได้ลองเลย์เอาต์ใหม่ ๆ โดยไม่ต้องพึ่งเลย์เอาต์ตายตัวแบบ Ghost อีกอย่าง ตอน export ภาพสำหรับเว็บจากโปรแกรมแต่ง RAW อย่าง Capture One คุณภาพก็ดูดีกว่านิดหน่อยเมื่อเทียบกับไลบรารีหรือเครื่องมือ CLI ที่ static site generator ส่วนใหญ่ใช้
    มันช้ากว่า แต่ผมมองว่ามันใกล้กับการทำสมุดภาพมากกว่า ตอนแรกต้องลงแรงเพิ่ม แต่พอเสร็จแล้วก็จบ และอีก 20 ปีข้างหน้าก็ไม่ต้องคอยย้ายไปมาระหว่าง CMS หลายตัวจนเว็บพัง

    • navigation ก่อนหน้า/ถัดไปแบบพื้นฐาน รวมถึงเมนู, header, footer ที่สม่ำเสมอ สามารถจัดการได้ด้วย server-side include
    • เว็บไซต์ภาพถ่ายส่วนตัวของฉันใช้ Svelte + TailwindCSS, Flickr API และ Netlify
      โดยพื้นฐานก็คือไฟล์ HTML ไม่กี่ไฟล์ที่ได้พลังของเทมเพลตเพิ่มเข้ามา ใช้ Flickr API ดึงรูปจากอัลบั้มที่ทำไว้สำหรับเว็บนี้โดยเฉพาะ และ Netlify จะ deploy อัตโนมัติแค่ git push
      ค่าใช้จ่ายรวมโฮสติ้งคือ 0 ดอลลาร์ และยังจัดการรูปจากมือถือผ่านแอป Flickr ได้ด้วย ชอบตรงที่ Netlify ทำให้ไม่ต้องไปแตะเซิร์ฟเวอร์จริงเลย
    • อยากรู้ว่าประสบการณ์ใช้ Vapor เป็นยังไงบ้าง
      วิธีที่ผมใช้ล่าสุดอาจช่วยได้เหมือนกัน(https://news.ycombinator.com/item?id=36592641) ใช้ Google Sheet เป็นแหล่งข้อมูลได้ง่ายดี และถ้าจะเปลี่ยนเป็นระบบไฟล์รูปภาพก็น่าจะเหมือนกัน
    • กำลังคิดจะเลิกใช้ Smugmug แล้วลองทำแบบนี้พอดี เลยอยากรู้ว่าพอจะแชร์พอร์ตโฟลิโอหรือซอร์สได้ไหม

  • นี่ไม่ใช่ความ "เรียบง่าย(simple)" แต่ดูจะใกล้กับแค่ ดูเหมือนเรียบง่าย(simplistic) มากกว่า ถ้าไม่ทำอะไรเลยแล้วตัดมุมออก ก็สร้างเว็บไซต์ที่ค่อนข้างเรียบง่ายได้อยู่
    แค่ดู dark mode ซึ่งแทบเป็นฟีเจอร์ที่ไม่ trivial อย่างเดียวในหน้านี้ ก็จะเห็นว่าใช้ JS ที่โหลดแบบหน่วงเวลา เลยเกิด อาการหน้าจอขาววาบ ที่เลี่ยงไม่ได้ทุกครั้งที่โหลดหน้า ถ้าจะทำให้ถูกควรใช้วิธี body class ใน CSS และวิธีแก้ที่ใช้ไม่ได้ก็ไม่มีความหมาย ไม่ว่าจะเรียบง่ายหรือซับซ้อน
    อีกอย่าง การดึงตัว interpreter แบบคัสตอมอย่าง https://hyperscript.org/ มาทั้งก้อนเพื่อใช้กับ JS แค่ 3 บรรทัดสำหรับ localStorage กับการตั้งค่า dark mode ก็ขัดกับแนวคิด "ความเรียบง่ายคือความสมบูรณ์สูงสุด" อยู่แล้ว การโหลดไลบรารี 96KB ที่ไม่ได้แคชมาเพื่อจุดประสงค์แค่นั้นดูแปลก และก็สงสัยด้วยว่านี่เป็นเหตุผลที่ HTML validation ไม่ผ่านหรือเปล่า
    สุดท้าย toggle แบบสองสถานะเป็นการมองข้ามการตั้งค่าของระบบ/เบราว์เซอร์ จึงเป็นการทำ dark mode ที่ไม่ดี ต่อให้เปิด dark mode ใน OS ของสมาร์ตโฟน ไซต์ก็ยังแสดง light mode จนกว่าผู้ใช้จะมาเปิดเอง และยังไม่สามารถเคารพการตั้งค่าระบบที่เปลี่ยนตามเวลาหรือแสงรอบตัวได้ localStorage ก็อาจหมดอายุได้และผู้ใช้ก็เปลี่ยนอุปกรณ์ได้ จึงต้องตั้งค่าซ้ำเรื่อย ๆ ทำให้ผู้ใช้อาจไม่เห็นด้วยว่านี่คือการทำแบบ "เรียบง่าย" ตามที่นักพัฒนาพูด

    • ถ้าเป้าหมายคือเว็บไซต์ที่เรียบง่ายที่สุดเท่าที่จะเป็นไปได้ ก็ควร ไม่มี dark mode ไปเลย 90s ก็มีเว็บไซต์ที่เรียบง่ายและอ่านง่ายอยู่แล้ว และก่อนที่ dark mode จะเป็นกระแส light mode อย่างเดียวก็เพียงพอ
      ถ้าต้องคำนึงถึงการตั้งค่าระบบ/เบราว์เซอร์ การสลับตามเวลา หรือแสงรอบตัว ความซับซ้อนก็จะเพิ่มขึ้นจนขัดกับปรัชญาเว็บไซต์เรียบง่าย ตัด dark mode ออกไปเลยน่าจะดีกว่า และ HN เองก็เป็น light mode ตลอด แต่ก็ไม่ได้มีปัญหาใหญ่อะไรเวลาอ่านตอนกลางคืน
    • เห็นด้วยว่าวิธี JS โหลดช้าเป็นวิธีที่ผิด แต่แนวทาง media query ก็จุกจิกเหมือนกัน
      ปกติเรามักอยากเคารพ prefers-color-scheme ไปพร้อมกับมี toggle ให้ใช้ และถ้าผู้ใช้เคยเลือกเองบนไซต์มาก่อน ก็มักอยากให้การเลือกนั้นมาก่อน แบบนั้นก็ยังต้องใช้ JS กับ localStorage อยู่ดี
      วิธีที่ผมชอบคือใส่ inline style เป็น body {visibility: hidden; opacity: 0;} ไว้ก่อน จากนั้นคงหน้าก่อนหน้าไว้จนถึงตอน DOMContentLoaded แล้วค่อยเช็ก prefers-color-scheme กับ localStorage ตั้งค่า body class ให้ถูกต้องก่อนค่อย render หน้า
    • ตอนอ่านก็คิดว่า "วิเคราะห์ได้ดีมาก" แล้วพอเห็นว่าใครเขียนก็เข้าใจเลย ถ้าจะบอก OP คนนี้คือผู้เขียน https://gwern.net และไซต์นี้มีอิทธิพลอย่างมากต่อดีไซน์ของเทคบล็อกกับเว็บไซต์ส่วนตัวหลายแห่ง ทั้งยังมีไอเดียที่แปลกใหม่และยอดเยี่ยมมากมาย
      ไซต์ของผมใช้ CSS เพื่อเคารพธีม light/dark และไม่มี manual toggle ผมตั้งเป้าส่วนตัวให้เป็นไซต์ HTML/CSS ล้วนที่ไม่มี JS และคิดว่าการตั้งค่า light/dark ควรเคารพการตั้งค่าของผู้ใช้ ถ้าจำเป็นต้องมี toggle ก็ควรอยู่ที่แถบเครื่องมือของเบราว์เซอร์ ไม่ใช่ในตัวไซต์
      ถ้า /u/gwern มาอ่าน ไซต์ของผม https://daveon.design/ ได้อิทธิพลมาจากดีไซน์ของ gwern และ Tufte.css รวมถึงสิ่งพิมพ์เก่า ต้นฉบับลายมือ และรสนิยมส่วนตัวบ้าง แต่ตัวอย่างสำคัญแรก ๆ ที่ทำให้ผมเห็นแรงบันดาลใจว่าเว็บไซต์ส่วนตัวสมัยใหม่ที่สะอาดตาจะหน้าตาเป็นอย่างไรและใส่อะไรได้บ้าง ก็คือ gwern
    • บน Firefox, Chrome, Safari ของ Mac และ Firefox, Chrome ของ Android ผมไม่เห็น อาการหน้าจอขาววาบ เลย ทั้งตอนโหลดครั้งแรก รีเฟรช หรือสลับ dark/light ก็ดูเหมือนทำงานได้ปกติดี
    • เป็นประเด็นที่ถูกต้อง น่าเสียดายที่แนวคิดแบบดูเหมือนเรียบง่ายแต่จริง ๆ ใช้งานพัง ก็แพร่หลายพอ ๆ กับแนวทางที่พังและเทอะทะเหมือนกัน

  • ถ้าจะให้พูดแบบนั้น ตอนนี้ SvelteKit + Skeleton น่าประทับใจมากในแง่ความเร็วในการทำโปรโตไทป์ที่ใช้งานได้
    ต่อให้ยังไม่รู้จัก Svelte ดี แค่เข้าใจ file-based routing ก็แทบไม่ต้องรู้อะไรเพิ่มจนกว่าจะถึงตอนที่จำเป็น ที่เหลือก็เกือบเป็น HTML ล้วน, มี Tailwind มาให้เป็นค่าเริ่มต้น และธีมก็โดยมากใกล้เคียงกับวานิลลา
    ช่วงไม่กี่เดือนที่ผ่านมาได้ลองทั้ง Astro, Lit, Next.js, เทมเพลตในตัวของ Go, pug, Eleventy และอีกหลายอย่าง แต่จนถึงตอนนี้ยังชอบชุดนี้ที่สุดแทบทุกด้าน

    • SvelteKit ยอดเยี่ยม แต่เห็นด้วยกับ Skeleton ได้ยาก ตอนแรกมันให้ความรู้สึกว่าทำงานได้เร็วและปลอดภัย แต่มีหลุมพรางเยอะ และถ้ามีจุดที่ไม่ชอบขึ้นมา การปรับแต่งก็ยาก
      ดูแค่เว็บของ Skeleton เอง https://www.skeleton.dev/docs/get-started ก็เห็นแล้วว่า กด Page Down ก็ไม่เลื่อน, เอาเมาส์ไปวางบนแถบนำทางก็เลื่อนไม่ได้, และถ้าสั่งพิมพ์ก็จะตัดออกมาแค่ส่วนที่เห็นบนหน้าจอ ผมเคยแจ้งปัญหานี้ไปแล้ว แต่ยังไม่ใช่เรื่องสำคัญมากนัก ทั้งที่มีหลายเว็บใช้แพตเทิร์นคอมโพเนนต์แบบนี้อยู่
      ดูเหมือน Skeleton จะคิดว่าถ้ากลับค่าสีของธีมมืดก็จะกลายเป็นธีมสว่างที่ใช้ได้ดี แต่ในความเป็นจริงไม่ใช่แบบนั้น DaisyUI ดูโตเต็มที่กว่า เร็วกว่า ใช้กันแพร่หลายกว่า และให้ความสำคัญกับ accessibility อย่างจริงจัง การทำสิ่งต่าง ๆ ได้ด้วย CSS animation ล้วนโดยไม่ต้องมี JS ก็ถือว่าน่าทึ่ง และมันช่วยจัดการส่วน HTML/CSS ที่ยาก ๆ ให้ ขณะเดียวกันก็ปล่อยให้เราเขียนส่วน Svelte ที่ง่ายกว่าเองได้ด้วย ความผูกกับ Svelte ก็น้อยกว่า เลยย้าย HTML ของ DaisyUI ไปเฟรมเวิร์กอื่นได้ง่าย
    • เห็นด้วย ถึงจะเป็นเฟรมเวิร์ก แต่ก็สร้าง static site ที่ยังทำงานได้ดีแม้ปิด JS ได้ง่าย ใช้ได้แม้ไม่รู้จัก Svelte และถ้าจำเป็นก็ใช้ Svelte เพิ่มได้
      Tailwind ใช้งานได้ทันที และการดีพลอยไปที่อย่าง Netlify ก็ง่ายมาก สำหรับตอนนี้ผมมองว่ามันคือ static site builder ที่ดีที่สุด และเรียบง่ายกว่าวิธีที่บทความอธิบายไว้มาก
    • ในฐานะคนที่ชอบความมินิมอล ผมลองใช้ทั้ง Astro และ SvelteKit แล้ว และรู้สึกว่า SvelteKit เหมือนเป็นชั้นบางมากที่วางอยู่บน Svelte ซึ่งก็เป็นไลบรารีคอมโพเนนต์ที่เล็กมากอยู่แล้ว
      ถ้าใช้ +page.ts กับการตั้งค่าที่เหมาะสม ก็ทำเว็บแบบสแตติกได้ และยังไปต่อเป็น multi-page app หรือ single-page app ก็ได้
    • ดูเหมือนจะหาเดโมสไตล์ “พิมพ์อะไรเข้าไปแล้วจะได้หน้าสุดท้ายแบบนี้” ได้ยาก ถ้ามีตัวอย่างที่เปิดดูได้ทันทีโดยไม่ต้องติดตั้งและทำตามขั้นตอนก่อนก็น่าจะดี
    • เป็นคำแนะนำที่ดี อยากฟังประสบการณ์กับเว็บเฟรมเวิร์กอื่น ๆ เพิ่มเหมือนกัน และก็สงสัยว่าลอง Flutter ด้วยหรือยัง

  • โอ้โห จะสร้างเว็บไซต์ด้วย HTML และ CSS นี่ฟังดูบ้าสุด ๆ
    ล้อเล่นนะ นอกจากเทมเพลตแล้วก็ใช้สแตกเดียวกัน ถ้าไม่ได้เป็นเว็บดีเวลอปเปอร์ ผมไม่ค่อยเข้าใจว่าทำไมต้องใช้ CSS framework และการทำเองกลับง่ายกว่ามากด้วย เคยลองใช้ Hugo เป็น site generator แล้ว แต่ก็ไม่ได้ช่วยประหยัดเวลาเลย
    เมื่อไม่กี่เดือนก่อนผมพยายามฝึก CSS โดยลองทำเว็บบริษัทบางแห่งขึ้นมาใหม่ และพบว่าแค่ HTML กับ CSS ก็ทำรูปลักษณ์ภายนอกได้ครบหมด แต่พอปิด JS เว็บจริงของบริษัทเหล่านั้นกลับไม่แสดงอะไรเลย
    เรากำลังเอาเฟรมเวิร์กซ้อนบนเฟรมเวิร์ก เพิ่มภาษาใหม่ เพิ่มเครื่องมือใหม่กันไปเรื่อย ๆ ซึ่งส่วนใหญ่ก็มีแต่เพิ่มความซับซ้อนและเพิ่มงานยุ่งให้คนรุ่นถัดไป ส่วนเว็บ 5% ที่จำเป็นต้องใช้ของพวกนั้นจริง ๆ ก็เป็นข้อยกเว้น
    ที่น่าสนใจอีกอย่างคือมันเป็นเว็บที่ขายบริการจริงด้วย ก็เลยสงสัยเหมือนกันว่าตั้งราคาไว้ประมาณไหน

    • การออกแบบและคงความสม่ำเสมอของมันไว้ให้ได้ รู้สึกว่ายากมาก เลยอยากมี CSS ที่กำหนดไว้ล่วงหน้า ไม่งั้นผลงานที่ออกมาจะดูเละเทะ
    • โดยรวมเห็นด้วย แต่ก็เคยใช้ Astro ได้ผลดีพอสมควร

  • ผมว่าทางที่มินิมอลและได้งานที่สุดคือใช้ PHP ไปเลย เพราะภาษานี้เดิมทีก็ถูกสร้างมาเพื่อจุดประสงค์แบบนั้น
    ถ้าเป็นเว็บเรียบง่าย ก็ไม่ต้องมีทั้ง composer หรือ router logic แค่แยกไฟล์ header/footer/navigation แล้ว include ในแต่ละหน้าก็พอ

    • ต่อให้ไม่มีไลบรารี ก็ทำ router กับ layout ได้ใน ประมาณ 100 บรรทัด router แค่เช็กว่ามีไฟล์อยู่ไหม ส่วน layout ก็แค่ include header.php, pagename.php, footer.php เท่านั้น สำหรับเว็บง่าย ๆ ผมทำแบบนี้ และมันง่ายกับเร็วมาก
    • ถึงจะไม่ใช่ PHP ก็ได้ ขอแค่เป็นภาษา server-side scripting ก็พอ แก่นสำคัญคือความสามารถในการตั้งชื่อให้ข้อมูลและบล็อกโค้ด จัดเก็บ แล้วเรียกกลับมาใช้ เพื่อให้รีแฟกเตอร์เว็บได้
      ถ้า HTML ใส่ HTML ภายนอกได้เหมือนที่ CSS หรือ JS ทำได้ เรื่องพวกนี้ส่วนใหญ่ก็คงไม่จำเป็นเลย อยากให้มันเปิดให้ใช้ได้อิสระกว่านี้
    • ถ้าเอาความเรียบง่าย PHP + HTML ชนะยากมาก สำหรับอะไรที่ใหญ่กว่าสคริปต์จุดประสงค์เดียว ผมคงไม่อยากให้มันเรียบง่ายขนาดนั้น และโดยปกติก็มักจะใส่ template library แยกไว้อย่างน้อยสักตัว แต่การที่ทำแบบนั้นได้ก็ดี
    • เห็นด้วยกับเจตนา แต่ถ้าลงเวลาแค่ราว 5–20 ชั่วโมง ก็สร้าง site generator แบบคัสตอมที่มีประสิทธิภาพบน Eleventy แล้วดีพลอยขึ้น Netlify ฟรีได้
      แค่แก้อะไรสักอย่างแล้ว git commit/push ภายในไม่ถึง 30 วินาทีการเปลี่ยนแปลงก็สะท้อนไปทั่วโลกแล้ว ค่อนข้างยอดเยี่ยมและไม่ต้องมีเซิร์ฟเวอร์โฮสติ้งแยกด้วย
    • มีเฟรมเวิร์กเรียบง่ายอยู่เยอะ แต่พอค่อย ๆ เติมอีกไม่กี่อย่างเข้าไป ไม่นานก็กลับไปเป็นความอืดบวมแบบคุ้นเคยอยู่ดี

  • ทำให้นึกถึงคำพูดที่ว่า “ทำให้เรียบง่ายที่สุดเท่าที่จะทำได้ แต่ไม่เรียบง่ายไปกว่านั้น” น่าจะไม่ใช่คำพูดของ Albert Einstein
    ใช้แค่ HTML + CSS ล้วน ๆ โดยใส่ CSS ไว้ในแต่ละแท็ก HTML หรือในหน้าเดียวกัน ก็โอเคสำหรับการเริ่มต้น พอมีสองหน้าเมื่อไร ก็มักจะแยก CSS ออกไปเป็นไฟล์ต่างหาก
    แต่พอเริ่มทำเว็บที่มีหลายหน้าซึ่งใช้รูปแบบเดียวกัน ก็จะเริ่มต้องมีระบบเทมเพลตที่มี include และ ตัวสร้างหน้าเว็บแบบสแตติก
    ถ้าหน้าเว็บขับเคลื่อนด้วยข้อมูล ก็ต้องมีตัวสร้างเว็บไซต์แบบเขียนโปรแกรมได้ที่รับข้อมูลเข้ามาแล้วสร้างหน้าออกไป และถ้าข้อมูลเป็นแบบ “เรียลไทม์” ก็ต้องสร้างหน้าตามแต่ละวิว อย่างน้อยก็เข้าสู่เขตของ PHP และถัดไปก็เป็นเขตของเว็บเฟรมเวิร์กสมัยใหม่ที่มีเซิร์ฟเวอร์รันอยู่
    เมื่อไม่นานนี้ผมทำเว็บไซต์โปรโบโนเกี่ยวกับงานอดิเรก เป็นเว็บโปรโมตการเต้นและงานอีเวนต์ โดยเจ้าของเป็นครูสอนเต้นที่ไม่ค่อยรู้เรื่องเทคนิค ผมใช้ Eleventy(https://www.11ty.dev/) สร้างเว็บสแตติกบน Netlify ฟรีเทียร์ แล้วต่อโค้ด build แบบคัสตอมเพื่อดึงข้อมูลจาก Google Sheet ให้ครูสามารถกำหนดอีเวนต์ที่กำลังจะมาถึงได้
    ใช้เวลาทำราวสิบกว่าชั่วโมง แต่ตอนนี้มันทำงานได้ดีโดยแทบไม่มีค่าใช้จ่ายด้านปฏิบัติการ/ดูแลรักษา ทำให้ผมเห็นว่ามี จุดกึ่งกลางที่ลงตัว ที่ทรงพลังอยู่ระหว่างการตั้งค่าขั้นต่ำสุดจริง ๆ กับระดับ Rails/Phoenix/Django

    • สุดท้ายแล้ว OP เองก็ยังใช้ไลบรารีสองตัวคือ Jinja เทมเพลตและการจัดสไตล์ด้วย Tailwind มันเป็นจุดกึ่งกลางที่พอดีระหว่าง HTML/CSS ล้วน ๆ กับ Django/Phoenix/Rails + Angular/React/Vue
    • ปกติผมจะรีแฟกเตอร์เมื่ออะไรบางอย่างโผล่มาสองครั้ง แต่ก็เคยได้ยินเหมือนกันว่าเรื่อง DRY นั้นรอให้ถึงสามครั้งก่อนจะคุ้มค่ากับแรงที่ลงทุน
      แต่จำนวนหน้าของเว็บไซต์นั้นแทบจะแน่นอนว่าเกิน 3 หน้าอยู่แล้ว เลยอาจต่างจากกรณีที่บล็อกโค้ดธรรมดาถูกใช้ซ้ำเกิน 3 ครั้ง
    • สงสัยว่าเคยเปิดซอร์สสิ่งนี้ไว้ หรือเคยเจอโครงการคล้าย ๆ กันบ้างไหม
      อยากรู้ด้วยว่าเป็นโครงสร้างที่เรียก Google Sheets API ฝั่งไคลเอนต์เพื่อเติมข้อมูลหรือเปล่า และถ้าใช่ มีชั้นแคชไหม หรือว่าไคลเอนต์แต่ละรายต้องรับสำเนาใหม่ทุกครั้ง

  • ประเด็นถกเถียงเรื่อง เฟรมเวิร์ก กับความซับซ้อนนี่น่าเบื่อจริง ๆ แล้ว
    ถ้าลูกค้าต้องการ CMS แบบคัสตอมที่มีเวิร์กโฟลว์การเผยแพร่หลายขั้น มี i18n และการเข้าถึงตามข้อกำกับดูแล คุณก็ต้องมีเครื่องมือที่ทรงพลังเพื่อทำให้เสร็จทันเวลาที่ลูกค้าคาดหวัง ฝั่งเอ็นเตอร์ไพรส์มีลูกค้าแบบนี้เยอะ เลยมีความต้องการเครื่องมือแบบนี้สูง ถ้าคุณเคยทำแต่ B2C อาจจะประหลาดใจ แต่นี่คือส่วนใต้น้ำของภูเขาน้ำแข็งในอุตสาหกรรมเทคโนโลยี
    จริงอยู่ที่บล็อกสแตติกไม่จำเป็นต้องมีการตั้งค่า Next.js ซับซ้อนหรือ Vite toolchain แต่คนที่พูดถึงเครื่องมือพวกนี้อย่างจริงจัง ไม่ได้กำลังพูดถึงการทำเว็บบล็อกธรรมดา ตัวอย่างย่อในบทสอนอาจเป็นบล็อก แต่ปัญหาจริงไม่ใช่แบบนั้น
    เพราะงั้นก็อยากให้ลดความเกลียดเฟรมเวิร์กลงหน่อย ถ้ามีไอเดียดี ๆ สำหรับการทำเว็บไซต์แบบเรียบง่าย ก็ปล่อยเป็นบทสอนไปเลย ถ้ามันน่าสนใจ คนก็จะหยิบแนวทางนั้นไปใช้ในที่ที่เหมาะสมเอง แต่อยากให้เลี่ยงการตั้งศัตรูแบบคลุมเครืออย่าง “toolchain เผ็ด ๆ กับเฟรมเวิร์กตามกระแส” ขึ้นมาเพื่อคัดค้าน

    • หลายคนที่เข้ามาคุยกันในบทสนทนานี้ไม่เคยเจอปัญหาที่เครื่องมือพวกนี้มีประโยชน์จริง ๆ ด้วยตัวเอง อาจเป็นวิศวกรก็จริง แต่ไม่ได้แตะฟรอนต์เอนด์เลยจนรู้ไม่เกินพื้นฐาน หรือเป็นนักศึกษา CS ที่เคยทำบล็อกส่วนตัวด้วย Jekyll แล้วคิดว่าตัวเองรู้เรื่องฟรอนต์เอนด์หมดแล้ว
      หรืออาจเคยทำแอปใช้งานภายในมานานที่มีผู้ใช้แค่หลักสิบและไม่มีข้อกำหนดด้าน UX แล้วเลยคิดว่าตัวเองรู้ทุกอย่าง การตัดสินแบบข้อมูลน้อยเช่นนี้ทำให้การถกเถียงเสียทิศทาง
    • ถ้าคุณทำของซับซ้อนโดยไม่ใช้เฟรมเวิร์ก สุดท้ายคุณก็จะลงเอยด้วยการสร้าง อีกเฟรมเวิร์กหนึ่ง ขึ้นมาเอง
      คราวนี้คนที่มารับช่วงต่อจากคุณจะไม่ได้อัปเดตอะไรเลย และก็ขอความช่วยเหลือจาก Stack Overflow ได้ยากกว่าเดิม
    • เห็นด้วย ถึงจะเป็นคนที่ไม่ชอบความซับซ้อนที่เฟรมเวิร์กนำเข้ามาก็ตาม
      ผมไม่เข้าใจว่าทำไมถึงคิดว่าแต่ละงานจะใช้เครื่องมือคนละแบบไม่ได้ บางครั้งก็ไม่จำเป็นต้องใช้เฟรมเวิร์กจริง ๆ แต่จากประสบการณ์ของผม มันเกิดไม่บ่อยนัก ถ้าไม่ได้กำลังทำอะไรที่เรียบง่ายมากและแทบไม่เปลี่ยนแปลง
      ในสถานการณ์ที่มีทั้งทีมและลูกค้า ผมนึกภาพไม่ออกจริง ๆ ว่าเว็บแบบ “เครื่องมือง่าย ๆ” จะดำเนินไปอย่างไร และนี่ไม่ใช่การตำหนิ แค่หมายถึงว่าผมไม่รู้จริง ๆ

  • วิธีนี้สำหรับผมก็ยังฟังดูซับซ้อนเกินไปอยู่ดี
    บทความเขียนด้วย Gemtext หรือก็คือมาร์กดาวน์สำหรับ Gemini แล้วแปลงเป็น HTML พร้อมสร้างหน้า index ด้วย สคริปต์ Python
    CSS มีแค่ 42 บรรทัด ผมเลยใส่มันไว้ในแต่ละหน้า และยังคำนวณไว้ด้วยว่าต้นทุนของการเพิ่ม 42 บรรทัดในแต่ละไฟล์ไม่มีทางสูงไปกว่าคำขอ HTTP ครั้งที่สอง
    มันเรียบง่ายกว่าที่คิดมากโดยไม่ต้องมีไลบรารี Python หรือเทมเพลต ส่วนที่ยากที่สุดคือการสร้างอีเมลสำหรับส่งไปยังเมลลิงลิสต์ ผมใช้เวลาหลายเดือนวิเคราะห์เฟรมเวิร์กต่าง ๆ และตัวสร้างเว็บไซต์สแตติกหลายตัว และใช้เวลาหลายสัปดาห์กว่าจะหา CSS ที่โอเคได้
    จากประวัติใน git ใช้เวลาลุยอยู่ 2 สัปดาห์จนเสร็จ รวมถึงการย้ายประวัติ 18 ปีจาก WordPress ด้วย เพราะเป็น Python ล้วน ๆ เลยไม่มีอะไรใหม่ให้เรียนรู้ และถ้ามีบั๊กก็แก้หรือเปลี่ยนได้ง่าย เพราะมันเป็นโค้ดของผมเอง
    นักวิทยาการคอมพิวเตอร์ดูเหมือนจะลืมไปหมดแล้วว่า แทนที่จะพยายามรีใช้ทุกอย่าง เราสามารถแค่เขียน วิธีแก้ปัญหาเฉพาะกิจแบบสั่งตัด ขึ้นมาได้เลย เวลาที่ใช้เรียนรู้และปรับแต่งมันมากกว่าการลงมือสร้างเองเสียอีก
    โค้ด: https://git.sr.ht/~lioploum/ploum.net
    เว็บไซต์: https://ploum.net

    • อีเมลเหรอ? สคริปต์ Python? Git? ช่างเป็น เครื่องรูบ โกลด์เบิร์ก ที่ยอดเยี่ยม
      เว็บของผมเสิร์ฟจากโปรเซสเซอร์ 6502 ที่เหลาด้วยไม้บัลซาและติดกับสายอีเธอร์เน็ตด้วยอีพ็อกซี่ตั้งแต่ปี 2003 ถ้าอยากเปลี่ยนอะไร ก็เอาไดร์เป่าผมเป่า EPROM ให้บิตที่ต้องการพลิกกลับ ไม่มีทั้งเทมเพลต ไม่มีโค้ด ไม่มีความบวม
    • เป็นบล็อกที่ยอดเยี่ยมมาก ผมเปิดเข้ามาเพราะอยากดูแค่ดีไซน์ แต่สุดท้ายอ่านบทความติดกันไป 4 ชิ้น
      ความรู้สึกตอนเลื่อนลงไปแล้วเหมือนได้ย้อนประวัติศาสตร์เทคโนโลยีนั้นชวนให้นึกถึงวันเก่า ๆ

  • ถ้าไม่ได้เข้าใจผิด มันก็ดูไม่ได้ต่างจาก ตัวสร้างเว็บไซต์แบบสแตติก ทั่วไปเท่าไร เหมือนเป็นความต่างระหว่างการสร้างไฟล์ HTML ด้วยเทมเพลต Jinja ที่อิง Python กับ Jekyll ที่สร้างไฟล์ HTML/Markdown ด้วยเทมเพลต Liquid ที่อิง Ruby

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

  • ไม่เข้าใจเลย เหมือนกับว่าไม่ต้องการใช้ตัวสร้างเว็บไซต์แบบสแตติก เลยลงเอยด้วยการเขียน ตัวสร้างเว็บไซต์แบบสแตติก ขึ้นมาเอง