Web Components จะอยู่ยืนยาวเกินกว่า JavaScript Framework ของคุณ

• บทความว่าด้วยความยืนยาวและความยืดหยุ่นของเว็บคอมโพเนนต์ เมื่อเทียบกับ JavaScript framework
• ผู้เขียนยืนยันว่าการเลือกเทคโนโลยีของโปรเจ็กต์ควรถูกกำหนดโดยข้อจำกัดของโปรเจ็กต์ ไม่ใช่โดยตัวเลือกตั้งต้น
• เหตุผลที่ผู้เขียนเลือกใช้เว็บคอมโพเนนต์แบบ vanilla JS ในโปรเจ็กต์: ความสามารถในการพกพาและความสามารถในการเรนเดอร์ HTML
• บล็อกของผู้เขียนถูกสร้างด้วยเครื่องมือหลากหลาย เช่น Astro, Hugo, CMS แบบกำหนดเองที่เขียนด้วย PHP, Tumblr, Movable Type และ WordPress
• เน้นย้ำข้อดีของการเก็บคอนเทนต์ไว้ในไฟล์ข้อความธรรมดาที่เขียนด้วย Markdown ซึ่งช่วยให้กระบวนการย้ายคอนเทนต์ระหว่างระบบง่ายขึ้น
• ผู้เขียนระบุว่าแม้ฟีเจอร์เฉพาะของ Astro จะสะดวก แต่ไม่มีความสามารถในการพกพา จึงไม่ได้ถูกใช้ในโปรเจ็กต์
• เว็บคอมโพเนนต์สามารถเขียนเป็น HTML ภายใน Markdown ได้ ทำให้มันพกพาได้มากพอ ๆ กับส่วนอื่นของคอนเทนต์ Markdown
• เว็บคอมโพเนนต์คือชุดมาตรฐานของ W3C สำหรับสร้างองค์ประกอบ HTML ที่นำกลับมาใช้ซ้ำได้ โดยห่อหุ้ม HTML, CSS และ JS ทั้งหมดไว้ในไฟล์เดียว และไม่ต้องใช้ระบบ build
• ผู้เขียนชี้ว่าเว็บคอมโพเนนต์สามารถเปิดเผยแอตทริบิวต์เพื่อให้กำหนดค่าจากภายนอกได้ คล้ายกับ props แบบเนทีฟ
• ผู้เขียนตัดสินใจใช้ vanilla JS แทน framework ที่คอมไพล์ไปเป็นเว็บคอมโพเนนต์อย่าง Lit, Stencil และ Svelte เนื่องจากกังวลเรื่องภาระในการดูแลรักษาและการประนีประนอมด้าน dependency
• ผู้เขียนมองว่า dependency อย่าง TypeScript แม้จะให้ความสามารถที่มีประโยชน์ แต่ก็ต้องใช้เวลาและแรงในการรักษาความเข้ากันได้กับเวอร์ชันและ API ใหม่ ๆ
• เน้นความสำคัญของการหลีกเลี่ยง dependency ที่ผู้ใช้ควบคุมไม่ได้ และการยึดตามมาตรฐานที่พิสูจน์แล้วว่ามั่นคง เพื่อการเข้าถึงระยะยาวและความยืดหยุ่นของคอนเทนต์บนเว็บ
• ผู้เขียนสรุปยกย่องเว็บว่าเป็นแพลตฟอร์มการประมวลผลที่ยืดหยุ่น พกพาได้ และพร้อมสำหรับอนาคตมากที่สุด เมื่อใช้งานโดยคำนึงถึงความยืนยาว

[GN⁺]

ความคิดเห็นจาก Hacker News

• บทความว่าด้วยความยืนยาวของเว็บคอมโพเนนต์เมื่อเทียบกับ JavaScript framework
• ผู้แสดงความคิดเห็นชี้ว่าไลบรารี htmx ไม่ได้ถูกกล่าวถึงในบทความ และมีความแตกต่างจากเว็บคอมโพเนนต์ตรงที่มุ่งเน้นการซิงก์สถานะกับเซิร์ฟเวอร์
• htmx ได้รับคำชมว่าไม่มี dependency และเน้น backward compatibility ซึ่งต่างจากไลบรารี JavaScript จำนวนมาก
• การจัดการสถานะของเว็บคอมโพเนนต์ถูกชี้ว่าเป็นปัญหาที่ยังไม่ถูกแก้ไข และนักพัฒนาต้องจัดการเองโดยตรงหากไม่มี wrapper framework
• ประสิทธิภาพของเว็บคอมโพเนนต์ไม่ได้สำคัญอย่างที่คาดไว้ และองค์ประกอบขนาดเล็กบางส่วนถูกนำกลับออกจากเว็บคอมโพเนนต์เพราะต้นทุนในการสร้างอินสแตนซ์
• เว็บคอมโพเนนต์ได้รับคำชมว่าสามารถเพิ่มลงในหน้าใหม่ได้ง่ายโดยไม่ขึ้นกับ framework ที่ใช้อยู่ และดีต่อการ encapsulate สไตล์
• ผู้แสดงความคิดเห็นบางส่วนแสดงออกว่าชอบความก้าวหน้าและการพัฒนาของ JS framework มากกว่าโซลูชันแบบคงที่อย่างเว็บคอมโพเนนต์
• มีการเน้นย้ำถึงความสำคัญของการพิจารณาความรู้และทักษะของทีมเมื่อเริ่มโปรเจ็กต์ใหม่
• โซลูชันฝั่งเซิร์ฟเวอร์อย่าง Rails Hotwire, Phoenix Liveviews และ Laravel Livewire ถูกกล่าวถึงว่าเป็นพัฒนาการที่น่าสนใจ
• เว็บคอมโพเนนต์ถูกวิจารณ์ว่าไม่สามารถรันบนเซิร์ฟเวอร์ได้ และต้องใช้ JS ฝั่งไคลเอนต์ในการเรนเดอร์
• มีการชี้ว่าการใช้ slot ในเว็บคอมโพเนนต์นั้นชวนสับสนและซับซ้อน ทำให้ดึงดูดน้อยลงสำหรับการสร้างแอปพลิเคชัน
• DOM API ถูกวิจารณ์ว่าไม่เหมาะสำหรับการประกอบคอมโพเนนต์เข้าด้วยกันเพื่อให้แอปพลิเคชันทำงาน
• เว็บคอมโพเนนต์ถูกวิจารณ์เรื่องการขาดการรองรับจาก editor สำหรับความสามารถอย่างการเติมชื่อพร็อพเพอร์ตีและชื่ออีเวนต์อัตโนมัติ
• ฟังก์ชันพื้นฐานบางอย่างในเว็บคอมโพเนนต์ เช่น ปุ่มภายในฟอร์ม ยังคงเป็นปัญหาที่ยังไม่ได้รับการแก้ไข