เว็บ Plain Vanilla

 (plainvanillaweb.com)
2 คะแนน โดย GN⁺ 2025-05-12 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • คำอธิบายเกี่ยวกับ เทคนิคการพัฒนาเว็บพื้นฐาน ที่ใช้เพียง HTML, CSS และ JavaScript
  • แนะนำวิธีสร้างเว็บไซต์และแอปพลิเคชันด้วยเทคโนโลยีเว็บมาตรฐานล้วน ๆ โดยไม่ใช้ build tool และเฟรมเวิร์ก
  • กล่าวถึงวิธีจัดโครงสร้างและทำสไตล์โดยใช้ Web Components และความสามารถสมัยใหม่ของ CSS
  • มุ่งเน้น สภาพแวดล้อมการพัฒนาที่เรียบง่าย และข้อดีระยะยาวโดยไม่ต้องแบกรับความซับซ้อนของเฟรมเวิร์กและภาระการดูแลรักษา
  • เป็นทิวทอเรียลที่มีกลุ่มเป้าหมายหลักเป็น นักพัฒนา ที่คุ้นเคยกับเทคโนโลยีเว็บมาตรฐานอยู่แล้ว

ภาพรวมของเว็บ Plain Vanilla

ภาพรวมของเทคนิคหลักในการสร้างเว็บไซต์และแอปพลิเคชันด้วยเทคโนโลยีเว็บมาตรฐานล้วน ๆ โดยไม่ใช้ build tool และเฟรมเวิร์กในการพัฒนาเว็บ

  • อธิบายสภาพแวดล้อมที่ใช้เพียง editor, browser และ web standards
  • แนะนำโครงสร้างที่สามารถ deploy สู่ production ได้โดยไม่ต้องมีการตั้งค่าเริ่มต้นและตรรกะฝั่งเซิร์ฟเวอร์

หัวข้อที่ครอบคลุม

1. คอมโพเนนต์ (Components)

  • อธิบายวิธีใช้ Web Components เพื่อประกอบเป็นองค์ประกอบระดับสูงด้วย HTML, JavaScript และ CSS เท่านั้น
  • เป็นแนวทางทดแทนวิธีแบบคอมโพเนนต์ของเฟรมเวิร์กอย่าง React หรือ Vue

2. การทำสไตล์ (Styling)

  • อธิบายวิธีใช้พลังของ CSS สมัยใหม่ เพื่อทดแทนความสะดวกที่ CSS Modules, PostCSS และ SASS มอบให้
  • นำเสนอแนวคิดการจัดสไตล์แบบมีโครงสร้างและเป็นโมดูล แทนการใช้ CSS แบบดั้งเดิม

3. เว็บไซต์ (Sites)

  • อธิบายวิธี จัดโครงสร้างโปรเจกต์เว็บ บนพื้นฐานของ Web Components และ deploy ได้โดยไม่ต้องใช้ build tool หรือฝั่งเซิร์ฟเวอร์
  • นำเสนอเวิร์กโฟลว์การ deploy ที่เรียบง่ายและใช้งานได้จริง

4. แอปพลิเคชัน (Applications)

  • อธิบายวิธีสร้าง single-page web application ด้วยเทคนิค vanilla ล้วน ๆ
  • อธิบายแนวทาง routing และ state management

เหมาะสำหรับใคร

เนื้อหานี้เหมาะสำหรับ นักพัฒนา ที่สามารถใช้งาน HTML, CSS และ JavaScript ได้ในระดับหนึ่งอยู่แล้ว

  • สำหรับผู้ที่เพิ่งเริ่มต้นพัฒนาเว็บ แนะนำเส้นทางการเรียนพื้นฐานอย่าง Odin Project หรือ MDN

ทำไมต้องใช้แนวทาง vanilla

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

  • แนวทาง Plain Vanilla ยอมแลกกับความสะดวกบางส่วนในระยะสั้น เพื่อให้ได้ข้อดีระยะยาวคือความเรียบง่ายและ แทบไม่ต้องดูแลรักษาเลย
  • เบราว์เซอร์ในปัจจุบันรองรับ web standards ได้อย่างยอดเยี่ยม ทำให้แนวทางนี้สามารถนำมาใช้ได้จริง

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

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

 
GN⁺ 2025-05-12
ความคิดเห็นจาก Hacker News

  • ตอนนี้ฉันเลิกถกแบบ "vanilla หรือ framework" แล้ว และหันมาคิดจากมุมว่า 'สิ่งนี้จำเป็นต้องมีเว็บไซต์จริงหรือ?'
    พอเริ่มรู้สึกกังขาว่าเว็บแบบนั้นจำเป็นจริงไหม โดยเฉพาะในสายเว็บแอปและ B2B SaaS ก็จะพบว่าธุรกิจจำนวนมากไปได้ไกลพอสมควรโดยแทบไม่ต้องแตะเบราว์เซอร์เลย
    เวลาส่วนใหญ่ที่ฉันเคยทุ่มไปกับการทำเว็บไซต์และแอป มักหมดไปกับ UI/UX สำหรับงานดูแลระบบ นั่นคือส่วนที่ให้แอดมินเปลี่ยนฟิลด์ในฐานข้อมูลเพื่อให้แอปทำงานตรงกับความคาดหวังของลูกค้า
    ในหลายกรณี การให้ธุรกิจใช้เพียงเทมเพลตการตั้งค่าอย่างไฟล์ Excel แล้วนำผลลัพธ์ไป insert/merge ลงในตาราง SQL โดยตรง กลับเร็ว ง่าย และมีงานไร้ประโยชน์น้อยกว่ามาก
    เว็บมี UI/UX ให้แค่รูปแบบเดียว แต่อีเมลหรือไฟล์ข้อความล้วนกลับยืดหยุ่นกว่า

    • มักเห็นบริษัทที่ปรึกษาแบบ digital-first ขาดความคล่องตัวในตลาด B2B เพราะเอาเวลาไปสร้างเว็บแอปหรู ๆ ที่ไม่จำเป็น
      โดยเฉพาะหน่วยงานรัฐและผู้ซื้อประเภทที่ไม่ค่อยเข้าใจสิ่งที่ตัวเองซื้อ มักจ่ายแพงเกินจริงอยู่บ่อย ๆ
      คนจัดซื้อจำเป็นต้องได้รับการให้ความรู้มากกว่านี้
    • ฉันขายโกศบรรจุอัฐิออนไลน์ เว็บไซต์ของฉันมีแค่ลิงก์อีเมล ไม่มี shopping cart
      ร้านขายโกศจริง ๆ ก็ไม่ได้มีรถเข็น แล้วทำไมร้านแบบเสมือนต้องมีด้วย
      ตอนซื้อเครื่องมืองานไม้เฉพาะทางออนไลน์ ฉันก็แค่กรอกแบบฟอร์มแล้วรับอะไหล่พร้อมใบแจ้งหนี้มาเท่านั้น จะจ่ายหรือไม่จ่ายในตอนนั้นก็ยังได้
      การค้าทั้งออนไลน์และออฟไลน์มีได้หลายรูปแบบมาก ถ้าสังเกตคนที่ใช้ชีวิตในแบบน่าสนใจ คุณจะเห็นตัวอย่างแบบนี้อยู่ทั่วไป
    • สำหรับเครื่องมือภายในที่แทบไม่เกิน CRUD เว็บมีประโยชน์ที่สุดในกรณีที่ให้ที่ปรึกษาภายนอกทำครั้งเดียว หรือมีทีมในบริษัทดูแลต่อไปตลอดไม่ได้
      ถ้ามีความสามารถดูแลระบบเพียงเล็กน้อย วิธีใช้เทมเพลต Excel + สคริปต์แต่งเองง่าย ๆ จะยืดหยุ่นกว่ามาก
      ยิ่งถ้าผู้ใช้ปลายทางเป็นคนที่จัดการข้อมูลดิบได้อยู่แล้ว วิธีนี้ยิ่งได้ผลมาก
    • ก่อนยุค SaaS ฝั่ง B2B แทบ 100% ก็ทำกันแบบนี้
      และจนถึงตอนนี้ 99% ของ B2B ก็ยังเดินตามแนวทางนี้อยู่

  • ฉันไม่ได้ต่อต้าน framework แค่รู้สึกว่าในหลายกรณีมันไม่จำเป็น
    ฉันสงสัยมาตลอดว่าทำไมต้องเพิ่ม JS 100KB ตั้งแต่ก่อนเขียนโค้ดสักบรรทัด
    ทีมของฉันสร้าง https://restofworld.org ขึ้นมาโดยไม่ใช้ framework ใด ๆ
    ทั้งจากแบบสำรวจ งาน outreach และฟีดแบ็กทางอีเมล ผลตอบรับเรื่องการใช้งานและประสบการณ์การอ่านดีมาก
    ภายหลังจะใช้ framework ก็ได้ แต่จนถึงตอนนี้ vanilla JS ก็ยังเหมาะมาก

    • คอมเมนต์นี้เป็นตัวอย่างที่ดีของความไม่เชื่อมกันซึ่งมักเกิดขึ้นในการถกแบบนี้เสมอ
      ฝั่งหนึ่งคือคนที่ทำเว็บแอปขนาดใหญ่ในทีม 30 คนขึ้นไป พอได้ยินว่าไม่ใช้ framework ก็จะตั้งคำถามทันทีว่ารองรับฟีเจอร์ที่จำเป็นในสเกลใหญ่ได้อย่างไร
      แต่คำตอบคือซอฟต์แวร์นั้นไม่ได้ต้องการฟีเจอร์แบบนั้นเลย เพราะมันเป็นเว็บแนวบล็อก จึงไม่มีเหตุผลตั้งแต่แรกที่จะต้องใช้ framework
      ในทางกลับกัน คนที่ไม่เคยมีประสบการณ์กับเว็บแอปขนาดใหญ่มาก ๆ ก็มักคิดว่า "ทำไมผู้คนถึงใช้ framework กัน"
      เว็บคือกลุ่มก้อนของซอฟต์แวร์ที่หลากหลายมาก
      ดังนั้นเวลาพูดถึง framework เราควรบอกให้ชัดว่าหมายถึงซอฟต์แวร์ประเภทไหน
      ในกรณีนี้ มันคือบล็อก WordPress
    • หน้าเว็บดีมากและโหลดเร็ว แต่สิ่งนี้ไม่ได้เกี่ยวกับแนวทางที่ TFA(บทความต้นทาง) อธิบายไว้
      มันใช้ WordPress ซึ่งเป็น framework ขนาดใหญ่ แค่ render แบบ static เท่านั้น
      TFA หมายถึงการไม่ใช้ build tool เลย และใช้เพียงมาตรฐานเว็บสมัยใหม่เท่านั้น ใช้แค่ editor, browser และ web standards
    • "ทำไมต้องเพิ่ม JS 100KB ก่อนเขียนโค้ดสักบรรทัด"
      ในแอปองค์กรที่ฉันทำมา ไม่มีใครต้องกังวลเรื่อง 100KB เลย
      ส่วนใหญ่เป็นแอปขนาดใหญ่ที่หลายทีมทำร่วมกัน และใช้ React เป็นต้น
      ในตลาด LoB/B2B ไม่มีใครสนใจ initial page load
      ผู้ใช้เปิดแอปทุกวัน และส่วนใหญ่โหลด asset แบบ static ได้จาก browser cache อยู่แล้ว
      ถ้าใช้ framework ฉลาด ๆ อย่าง Next.js เนื้อหาจะถูกแยกเป็น immutable chunk ตาม route
      การ render ครั้งแรกก็เป็น static HTML อยู่แล้ว ดังนั้นในมุมผู้ใช้ hydration แทบสังเกตไม่ออก
    • เว็บไซต์สวยดี และฉันก็เจอบทความดี ๆ ด้วย
      แต่พอเห็นว่าตัวอย่างในการถกเรื่อง vanilla vs framework มักเป็นเว็บข่าวหรือเว็บบทความเสมอ ก็อดคิดไม่ได้ว่าเพราะมันไม่ใช่แอปซับซ้อน ฉันเองก็คงไม่ใช้ framework ตั้งแต่แรกเหมือนกัน
      สุดท้ายตัวอย่างการใช้งานจริงควรเป็นแอปที่มีการโต้ตอบมากกว่านี้
      ทุกวันนี้ฉันชอบใช้แค่ framework กับ pattern ที่สม่ำเสมอ แล้วลด dependency อื่นให้น้อยที่สุด
    • ข้อดีอย่างหนึ่งของโครงสร้างแบบนี้คือการย้อน/เดินหน้าประวัติในเบราว์เซอร์เร็วมาก
      บน iPhone ฉันชินมากกับการกดย้อนกลับแล้วหน้าเว็บทั้งหน้าถูกโหลดใหม่อีกครั้ง
    • ยินดีด้วย! ฉันคิดว่าการใช้งานที่ดีต้องมาก่อนเป็นอันดับหนึ่ง
      แต่พวกนักพัฒนามักหมกมุ่นกับ loading screen, component ที่ต้อง hydration, animation เกินเหตุ และ modal ที่น่ารำคาญ เพื่อความสนุกของตัวเอง
    • ไม่แน่ใจว่าเป็นเพราะไม่ใช้ framework หรือเปล่า แต่ตอนย้อนกลับ/เดินหน้า URL เปลี่ยนทันทีแต่หน้าไม่อัปเดต ทำให้ยังค้างอยู่ที่บทความเดิม
      อีกอย่าง infinite scroll ทำให้ติดตามได้ยากว่าตัวเองอยู่ตรงไหนจากตำแหน่ง scrollbar จึงส่งผลเสียร้ายแรงต่อ usability
    • Rest of World ทำงานเร็วมากแม้อยู่ในออสเตรเลีย และเป็นเว็บไซต์ข่าวที่ยอดเยี่ยมซึ่งฉันเพิ่งได้เห็นครั้งแรก
      ขอชมที่มีส่วนร่วมในการสร้างมัน
    • นี่แหละความงามของการสร้างหน้า static ด้วย WordPress
    • framework ส่วนใหญ่ไม่จำเป็นต้องใช้ JS 100KB
      อย่าง Mithril ให้ทุกฟีเจอร์ได้ในขนาดเพียง 10KB gzipped
    • ปัญหาของตัวอย่างแบบ vanilla คือหน้ามักเรียบง่ายเกินไป และ UX มีแต่พื้นฐาน
      ถ้าต้องลงมือทำเองอย่างตาราง reactive ที่มีการค้นหา หรือฟอร์มที่มี label, validation และ error ครบถ้วน ทำไมต้องสร้างเอง ในเมื่อใช้ Svelte UI library พร้อม overhead แค่ 25KB ก็ได้ของที่ดีและผ่านการพิสูจน์แล้ว
    • รูปหลักเกิน 200KB ด้วยซ้ำ ดังนั้นการเถียงเรื่อง 100KB จึงไม่มีความหมาย
      และ WordPress ก็เป็น framework เหมือนกัน
      ใช้ framework ก็ไม่ได้ช้าเสมอไป ไม่ว่าจะเป็น WordPress หรืออะไรก็ตาม
    • นี่เป็นตัวอย่างที่ดีของความพองตัวเกินจำเป็นของเว็บสมัยใหม่
      มันเร็วเกินไป
    • เร็วจริง ๆ!
    • ฉันชอบ Rest of World มาก
    • "ทำไมต้องเพิ่ม JS 100KB"
      เพื่อประสิทธิภาพในการพัฒนาของนักพัฒนาไง (อย่างน้อยในทางทฤษฎี)
      แต่ในทางปฏิบัติ หลายครั้งก็ไม่ได้ช่วยมากขนาดนั้น
    • เว็บไซต์เร็วมากจริง ๆ ฉันเคยเห็นงานสื่อแบบนี้มาก่อน
      เลยสงสัยว่ามีจุดอ่อนคม ๆ อะไรในแนวทางนี้หรือเปล่า
    • อะไรนะ? นั่นเป็นไปไม่ได้
    • ไม่มีใครสนใจ 100KB หรอก

  • ฉันกำลังพัฒนาระบบสำหรับผู้ใช้ราว 2,000 คน และพวกเขาไม่สนใจ UI แบบ reactive เลย
    วิธีที่ดีที่สุดคือสร้าง monolith ไม่ต้องกังวลเรื่อง page refresh แล้วโฟกัสกับการทำงานให้เสร็จ

    • ถ้าจะแย้ง ก็คือแอปเดสก์ท็อปแบบดั้งเดิมจำนวนมากสุดท้ายก็ย้ายมาอยู่บนเว็บ
      แรงจูงใจหลักไม่ค่อยใช่เรื่องเทคนิค แต่เป็นเพราะการกระจาย native app มีต้นทุนสูงเกินไป
      เว็บให้มาตรฐานการแจกจ่ายแอปราคาถูก แต่เทคโนโลยี UI ยังไม่ค่อยดีนัก
      ในอดีตมีความพยายามกึ่ง ๆ กลาง ๆ หลายอย่าง เช่น X11, Java, Flash และหวังว่าสักวันจะมีวิธีพัฒนาเว็บแอปที่สบายกว่านี้
    • แค่ CSS @view-transition ก็สร้าง transition ลื่น ๆ ได้แล้ว
      https://developer.mozilla.org/en-US/docs/Web/CSS/@view-transition
    • ในยุคนี้มันเป็นความเห็นที่ไม่ไวพออย่างมาก
      ซอฟต์แวร์ส่วนใหญ่ช้ากว่าและตอบสนองน้อยกว่าเครื่องกลเมื่อ 120 ปีก่อนเสียอีก
    • แค่ใช้ CSS กับ JS ก็ทำ dynamic แบบรีเฟรชง่าย ๆ ได้สบาย
      ไม่ต้องดึงแพ็กเกจ npm มาใช้เลย
    • การแยกระหว่าง React กับ server ก็ยุ่งเหยิงเหมือนกัน
      backend เป็น express/node โค้ดทั้งหมดอยู่ด้วยกัน แต่ใน dev environment เซิร์ฟเวอร์กลับรันผ่านเซิร์ฟเวอร์พื้นฐานของ React และตอน deploy จริงก็รันอีกแบบ สุดท้ายเลยต้องมีวิธี build/operate ที่ประหลาด ทำให้ความสะดวกของ dev server อย่าง hot reload ดูไม่มีความหมาย
    • ฉันเจอ SPA พังกว่า MPA บ่อยมาก
      แม้แต่ SPA ของบริษัทยักษ์อย่าง Reddit, X(Twitter) ก็บนมือถือไม่เสถียรมาก
      ถ้าไม่ใช่ระดับ Twitter หรือไม่ใช่แพลตฟอร์มแบบ API-first ก็ไม่เห็นจำเป็นต้องยึดติดกับ SPA
      อย่ามั่นใจเกินไปว่าของที่แม้แต่บริษัทร้อยพันล้านยังทำได้ไม่ดี เราจะทำได้ดีกว่า
    • ข้อดีของแนวทาง vanilla คือเอาไปต่อยอดกับเว็บ SSR เดิมได้
      ไม่ต้องรื้อทุกอย่างไปเป็น React
      ฟีเจอร์ขั้นสูงแบบคล้าย SPA ที่ผู้เขียนต้นฉบับพูดถึงนั้นเป็นแค่ตัวเลือก
    • ผู้ใช้สายปฏิบัตินิยมอาจไม่สนใจ แต่ผู้ใช้ที่ชอบคลิกไปเรื่อย ๆ มักกดปุ่มย้อนกลับแทนที่จะรอให้กลับไปหน้า feed หลัก และจังหวะนั้นก็มักเร็วกว่าการไปดึง framework ล่าสุดจาก CDN เสียอีก
    • ถ้าการรีเฟรชหน้าทำได้เร็วจริง ฉันก็เห็นด้วยกับความเห็นนี้
    • ฉันอยากถามว่าคุณรู้ได้อย่างไร ว่าผู้ใช้ไม่สนใจ page refresh เลยจริง ๆ
      คุณได้สำรวจคนที่เลิกใช้งานไปแล้วด้วยหรือเปล่า

  • ฉันอยากอยู่ในโลกแบบนี้
    ฉันมาจากยุคก่อน framework ซึ่งตอนนั้นยังไม่โตเต็มที่ และคนที่รู้แค่ jQuery ก็มีอยู่ทั่วไป
    ตอนนี้ฉันไม่ค่อยรู้สึกว่า framework ยุคหลัง post-query selector ให้ผลคุ้มกับต้นทุนแล้ว (ยกเว้น test framework ที่ยอดเยี่ยมจริง)
    พวกเราถูกขังอยู่ในคุกของ framework React และความล้มเหลวทั้งหมดก็เป็นผลจากความซับซ้อนแบบสปาเกตตี
    state machine ถูก hardcode จนพันกัน ส่วนผลลัพธ์ที่ผ่านการแปล บีบอัด และ transpile ก็ดูแทบไม่ออก
    source map ก็เป็นอีกชั้นของความซับซ้อนในการบำรุงรักษา
    ฉันยอมรับว่ามีเหตุผลที่ framework ถูกสร้างขึ้นมา แต่ก็ยากจะนึกภาพว่าวิศวกรใหม่จะเรียน framework ต่อไปได้ง่ายกว่าการเรียน vanilla JS

    • ฉันก็ผ่านยุคเก่าแบบนั้นมา และปัญหาใหญ่ที่สุดคือเราตัดสินใจสร้างระบบนิเวศแอปไว้บนฟอร์แมตเอกสาร
      HTML ก็เป็นแค่มาร์กอัปที่ทำขึ้นเพื่อช่วย render ข้อความให้ง่ายขึ้น เช่นเดียวกับ HTTP
      แต่ก่อนสัดส่วน text-to-markup ต้องสูงกว่า ทว่าตอนนี้กลับตาลปัตรไปหมดแล้ว
      ถึงอย่างนั้นเรากลับเชื่อว่าการเอาการพัฒนาแอปทั้งหมดไปวางอยู่บนสิ่งนี้คืออนาคต และถ้ามองเข้าไปใน React เองก็เต็มไปด้วยวิธีอ้อมและลูกเล่นที่สะสมมาหลายสิบปี
      เมื่อก่อนมันก็เหมือนพยายามสร้างแอปด้วย Excel+VB หรือ PDF+PostScript ซึ่งฟังดูฝืนมาก
      พอทำกันมาแบบนี้ การใช้ JS เป็น MB ๆ เลยให้ความรู้สึกสิ้นเปลืองเกินไป
    • สำหรับฉัน killer app ของยุคนี้คือ reactivity
      ส่วนที่ UI ตอบสนองทันทีเมื่อข้อมูลเปลี่ยน ถ้าต้องมานั่งทำ listener เอง อัปเดต diff เอง และคอยถอด event เอง มันแทบเหมือนจัดการหน่วยความจำแบบ manual
      สมัย jQuery ก็เป็นแบบนั้น และพลาดกันเยอะมาก
      ถ้าถึงวันที่เราสามารถทำ modularization แบบ component-based และ declarative view ได้ด้วย vanilla JS ค่อยว่ากัน แต่ตอนนี้สำหรับฉันยังห่างไกลมาก
      มันยังขาดองค์ประกอบชี้ขาด
    • ฉันเองก็บางครั้งไม่แน่ใจว่านี่เป็นแค่ความคิดถึงอดีตที่ชุบด้วยหลัก KISS หรือเปล่า
      React และ Angular เคยมีความหมายชัดเจนก่อน ES2015
      หลังจากนั้นฉันก็เริ่มเบื่อกับการเปลี่ยนแปลงของ frontend framework
      แม้แต่ใน React เอง รูปแบบ component และการจัดการ state ก็ยังเปลี่ยนไปเรื่อย ๆ
    • ถ้าต้องให้บริการระดับหลายร้อยล้านวิว ฉันจินตนาการว่าโครงสร้างจริงก็น่าจะใกล้เคียงเว็บ static มากกว่า

  • ฉันยังไม่เห็นด้วยกับ Web Components
    โดยเฉพาะแม้จะมีฟีเจอร์ใหม่อย่าง @scoped, import {type:css} แล้วก็ตาม ฉันก็ยังคิดว่าการ render element แบบ static แล้วค่อยอัปเดตแบบ dynamic ด้วย JS สมัยใหม่มีความหมายกว่ามาก
    ฉันค่อนข้างกังขาต่อแนวทาง Web Components ส่วนใหญ่ และยังเชื่อว่าควรสร้างนวัตกรรมนอก framework อย่าง React/Svelte ต่อไป
    ฉันไม่เคยรู้สึกว่า Web Components มีประโยชน์กับหลายเว็บไซต์ที่ฉันดูแลอยู่เลย

    • Web Components ไม่ได้แก้ปัญหาของฉัน กลับเพิ่มปัญหาใหม่เข้ามาอีก
      เรื่อง Shadow DOM ถูกพูดถึงหลายสิบครั้งต่อหน้า แต่ส่วนใหญ่กลับเป็นปัญหาที่เกิดขึ้นเพราะไปนำมันมาใช้เอง
      คอมโพเนนต์ของแอปฉันเองก็ไม่ได้มีปัญหา Shadow DOM อยู่แล้ว
    • "render element แบบ static + อัปเดตแบบ dynamic ด้วย JS สมัยใหม่"
      ฉันสงสัยว่า Web Components จัดการสิ่งนี้จากฝั่ง backend อย่างไร
    • Web Components ให้ขอบเขตของ abstraction ที่ชัดเจน
      คุณสามารถเพิ่มเมธอดพิเศษให้ tag ของตัวเองได้ และยัง encapsulate logic การอัปเดตไว้ภายใน component ได้ด้วย
    • ฉันคิดว่าเราควรกลับไปสู่ Unobtrusive JS อีกครั้ง
      ต้องการแนวปฏิบัติที่ใช้ไลบรารีเบา ๆ หรือเขียนเองได้
      HTMX มีบางส่วนที่ดี แต่สุดท้ายมันก็ยังทำตัวเหมือน script tag และฉันอยากให้ URL/method อยู่ใน HTML อย่างชัดเจน ส่วนพวก hx-target ก็ให้ไปอยู่ใน JS เป็นแค่ data- attribute ก็พอ
      ฉันไม่อยากแบกฟีเจอร์ HTMX ทั้งหมดมาด้วยทั้งที่ไม่ได้ใช้

  • ฉันไม่คิดว่า Web Components จะมาแทนสิ่งที่ framework อื่นเรียกว่า component ได้
    คุณใส่ค่าซับซ้อนอย่าง Object หรือ Array ลงไปใน attribute ไม่ได้ มี boilerplate เยอะเกินไป และไม่มี reactivity
    ฉันเขียนโค้ดแนว vanilla JS ด้วยวิธี signals[1]
    ไม่ใช่ว่ามาตรฐาน W3C ทุกอย่างจะเป็นคำตอบ และเราควรเรียนรู้จากความล้มเหลวของ XHTML
    [1] https://wrnrlr.github.io/prelude/

  • http://youmightnotneedjs.com

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

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

  • เป็นข้อมูลที่ยอดเยี่ยมมาก
    ฉันคิดว่าถ้าจะทำเว็บ เราควรรู้หลักการของเทคโนโลยีพื้นฐานให้ดี และใช้ประโยชน์จาก web platform ให้เต็มที่
    จากนั้นจะเลือกใช้ build system/framework หรือไม่ ก็แค่รับรู้ trade-off แล้วตัดสินใจได้อย่างอิสระ
    ส่วนตัวฉันชอบ Remix(/React-router v7+) เพราะมันสอดคล้องกับแนวคิด web standards
    กล่าวคือทำได้น้อยลงแต่ได้มากขึ้น เช่น เปลี่ยนข้อมูลบนเซิร์ฟเวอร์ได้ด้วย HTML form อย่างเดียว
    และขอแนะนำ https://every-layout.dev ด้วย สามารถเรียนรู้เทคนิค layout ที่มีประสิทธิภาพสูง เข้าถึงได้ดี และยืดหยุ่น โดยใช้เพียง CSS แบบ native ของเบราว์เซอร์
    ฉันทำงานพัฒนาเว็บอย่างมืออาชีพมาตั้งแต่ปี 1998

  • สัปดาห์ก่อนฉันเพิ่งทำโปรเจกต์เล็ก ๆ ด้วย vanilla ล้วน และมันทำงานได้ดีมาก
    เป็นเว็บทูลสำหรับเขียนเธรดยาวบน Mastodon
    ตอนทำก็แอบคิดอยู่ตลอดว่า "หรือการไม่ใช้ framework แปลว่าฉันกำลังทำอะไรผิดอยู่"
    บรรยากาศโดยรวมเหมือนทุกคนคาดหวังให้ใช้ framework
    Splinter, splinter.almonit.club, ใครอยากดูก็ลองดูได้