เว็บคอมโพเนนต์ก็ใช้ได้

 (nolanlawson.com)
2 คะแนน โดย GN⁺ 2024-10-01 | 1 ความคิดเห็น | แชร์ทาง WhatsApp

เว็บคอมโพเนนต์ก็โอเค

  • ชุมชนนักพัฒนาเว็บมักถกเถียงกันเกี่ยวกับเว็บคอมโพเนนต์อยู่เสมอ
  • Ryan Carniato เขียนบทความชื่อ "Web Components Are Not the Future" และ Cory LaViska ก็ตอบกลับด้วยบทความ "Web Components Are Not the Future — They’re the Present"
  • ผู้เขียนพยายามยุติข้อถกเถียงนี้อย่างสันติ

ประสิทธิภาพ

  • เว็บคอมโพเนนต์สร้างอยู่บนพื้นฐานของ Custom Elements ทำให้อินเทอร์เฟซทั้งหมดถูกจัดการผ่าน DOM
  • การลดจำนวน DOM node ให้เหลือน้อยที่สุดคือหัวใจสำคัญของการปรับแต่งประสิทธิภาพ
  • อย่างไรก็ตาม ประสิทธิภาพไม่ใช่ทุกสิ่ง ยังต้องคำนึงถึงปัจจัยอื่นอย่างการบำรุงรักษา ความปลอดภัย การใช้งาน และการเข้าถึง
  • ตัวอย่างเช่น หากไม่เรนเดอร์แอตทริบิวต์ aria-* ก็อาจช่วยเพิ่มประสิทธิภาพได้ แต่สำหรับการเข้าถึงแล้ว สิ่งนี้จำเป็นอย่างยิ่ง
  • การปรับประสิทธิภาพเป็นเรื่องสำคัญ แต่ในความเป็นจริง ปัญหาที่เรียบง่ายกว่าอย่าง layout thrashing, network waterfall และการ re-render ที่ไม่จำเป็น มักส่งผลต่อประสิทธิภาพมากกว่า

ต้นทุนของมาตรฐาน

  • การรองรับมาตรฐานต้องอาศัยการเขียนและรันโค้ดเพิ่มเติม
  • แต่การรองรับเว็บคอมโพเนนต์ไม่ได้เป็นภาระที่ใหญ่โต
  • การพิจารณาฟีเจอร์ใหม่ของเว็บแพลตฟอร์มเป็นเรื่องปกติ และสิ่งนี้ก็ใช้กับ Symbols, Proxys, Promises เป็นต้นด้วย
  • บางส่วนของชุมชนนักพัฒนาเว็บอาจไม่ต้องการรองรับเว็บคอมโพเนนต์ ซึ่งก็ไม่เป็นไร
  • เว็บเป็นพื้นที่กว้างที่เปิดรับแนวทางที่หลากหลาย

บทสรุป

  • ตัวเว็บคอมโพเนนต์เองไม่ได้มีปัญหา แต่คำสัญญาที่ว่ามันจะมาแทนที่ทุกอย่างได้นั้นเป็นเรื่องอันตราย
  • เว็บคอมโพเนนต์มีจุดอ่อนในด้าน server-side rendering, การเข้าถึง และการทำงานร่วมกันระหว่างระบบ
  • เฟรมเวิร์กอื่นอย่าง React, Solid และ Svelte ก็ยังมีพื้นที่ที่โดดเด่นของตัวเอง
  • เว็บถูกใช้งานอย่างหลากหลายวัตถุประสงค์ และนั่นเปิดโอกาสให้แสดงความคิดสร้างสรรค์ได้
  • เว็บคอมโพเนนต์อาจไม่เหมาะกับคุณ และนั่นก็ไม่เป็นไร

# GN⁺ สรุป

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

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

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

 
GN⁺ 2024-10-01
ความคิดเห็นจาก Hacker News

  • รู้สึกว่าบทความ "Web Components Are Not the Future" ยังขาดข้อโต้แย้งที่น่าโน้มน้าว

    • สถานะปัจจุบันของเฟรมเวิร์กฝั่งฟรอนต์เอนด์ค่อนข้างสับสน
    • ไม่อยากเรียนรู้เฟรมเวิร์กที่ซับซ้อน
    • ไม่ต้องการฟีเจอร์ลึกลับเหมือนเวทมนตร์ที่เข้าใจไม่ได้หากไม่มีเอกสาร
    • Web Components ใช้งานได้อย่างเป็นธรรมชาติและมีการแยกส่วนผ่าน Shadow DOM
    • คิดว่าในยุคของ React ควรเก็บไว้แค่ JSX ก็พอ

  • ผู้คนมีความเห็นแตกต่างกันเพราะต่างก็แสวงหาการปรับให้เหมาะสมคนละแบบ

    • สำหรับสตาร์ตอัปที่ได้รับเงินทุนจาก VC เฟรมเวิร์กอาจเหมาะสมกว่า
    • สำหรับแล็บวิจัยเชิงวิชาการ Web Components ที่มีต้นทุนการบำรุงรักษาต่ำกว่าจะดีกว่า
    • ประสบการณ์การย้ายจาก Vue ไปเป็น Web Components นั้นดีมาก
    • เมื่อมี dependency น้อยลงก็จัดการได้ง่ายขึ้น

  • Svelte รองรับการสร้าง Web Components ผ่าน Custom Elements API

    • Svelte คอมไพล์เป็น JS/HTML/CSS ทำให้สร้างคอมโพเนนต์ที่นำกลับมาใช้ซ้ำได้ง่าย

  • คิดว่า Web Components ไม่ได้ทำให้ชีวิตของนักพัฒนาแบบฟูลสแต็กดีขึ้น

    • ตัวอย่างส่วนใหญ่เป็นเพียงการทำเทมเพลตข้อมูลลงใน HTML
    • เป็นสิ่งที่ทำได้อยู่แล้วด้วย Handlebars

  • Web Components และ Shadow DOM อาจรบกวนการทำงานของส่วนขยายเบราว์เซอร์

    • ผู้พัฒนาเบราว์เซอร์ไม่ได้รีบแก้ปัญหานี้

  • การทำงานร่วมกันได้ย่อมมีต้นทุนด้านประสิทธิภาพ

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

  • คิดว่า Web Components สามารถแก้ปัญหาฟรอนต์เอนด์ในปัจจุบันได้

    • ประสิทธิภาพดีมาก และทำให้เลื่อนตารางข้อมูลได้ลื่นไหล
    • กำลังเตรียมไลบรารี Web Components อยู่

  • ได้รับช่วงต่อโค้ดเบส JS ขนาด 250,000 บรรทัด และกำลังรีแฟกเตอร์เป็น Web Components

    • ลดจำนวนโค้ดลงได้ 50,000 บรรทัด
    • ช่วยให้เข้าใจฟังก์ชันการทำงานของโค้ดเดิมได้ดีขึ้น

  • Web Components สามารถทำงานได้แม้ไม่มี JS

    • เคยใช้มาบ้างเพื่อการปรับปรุงแบบค่อยเป็นค่อยไป
    • ทำงานร่วมกับการเรนเดอร์ฝั่งเซิร์ฟเวอร์ได้ดี

  • เฟรมเวิร์กและ Web Components เป็นเครื่องมือที่แก้ปัญหาคนละแบบ

    • เฟรมเวิร์กมีหน้าที่เรนเดอร์วิวตามสถานะ
    • Web Components ไม่ได้แก้ปัญหาการจัดการสถานะ
    • คิดว่าทั้งสองอย่างสามารถอยู่ร่วมกันได้