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

 (blog.jim-nielsen.com)
2 คะแนน โดย GN⁺ 2023-11-14 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • เว็บคอมโพเนนต์อาจดูเหมือน React component เวอร์ชันเบราว์เซอร์ แต่จริง ๆ แล้วใกล้เคียงกับ โมเดลที่ยึด HTML เดิมเป็นศูนย์กลางแล้วเสริมฟังก์ชันเข้าไป มากกว่า
  • ความแตกต่างหลักอยู่ที่ การเรนเดอร์ก่อน JavaScript ทำงาน: แทนที่จะส่งข้อมูลให้ custom element ว่าง ๆ วิธีที่เป็นธรรมชาติกว่าคือการห่อ HTML ที่มีความหมายด้วย custom element
  • HTML web component คือการขยายมาร์กอัปเดิม ส่วนองค์ประกอบว่างที่ฝากเนื้อหาและฟังก์ชันทั้งหมดไว้กับ JavaScript จะใกล้เคียงกับ JavaScript web component
  • หากคุ้นกับการแยกเป็นคอมโพเนนต์แบบ React ที่เน้นการแทนที่ (replacement) เว็บคอมโพเนนต์ต้องใช้วิธีคิดแบบ การเสริมเพิ่ม (augmentation) ที่คงเนื้อหาไว้แล้วเพิ่มความสามารถเข้าไป
  • บนแพลตฟอร์มเว็บ แนวคิดที่ดีมักอยู่ได้นานในลักษณะ เสริมความสามารถ มากกว่าผลักเทคโนโลยีเดิมออกไป เช่นแนวทางของ HTML5, fetch และ TypeScript

เว็บคอมโพเนนต์กับ React component มีธรรมชาติคนละแบบ

  • ชื่อ “Web components” อาจฟังดูเหมือนสิ่งที่คู่กับ React component บนแพลตฟอร์มเว็บ
    • JSX ของ React ใช้รูปแบบ <MyComponent> ส่วนเว็บคอมโพเนนต์ใช้รูปแบบ <my-component> ได้
    • แต่ถ้าสร้างเว็บคอมโพเนนต์แบบเดียวกับที่สร้าง React component ก็อาจท้อได้ง่าย
  • เทคโนโลยีทั้งสองมี ฟังก์ชันและวิธีใช้งานที่การออกแบบให้ความสำคัญเป็นอันดับแรก แตกต่างกัน
    • หากพยายามใช้ฝ่ายหนึ่งให้เหมือนอีกฝ่าย จะชนกับทิศทางธรรมชาติของแต่ละเทคโนโลยี

เว็บคอมโพเนนต์ HTML เหมาะกับการเสริมมากกว่าการแทนที่

  • React component ทั่วไปอาจอยู่ในรูปแบบที่ส่งข้อมูลผ่านพร็อพเพอร์ตีให้คอมโพเนนต์ว่าง แล้วให้ JavaScript เรนเดอร์เนื้อหาทั้งหมด
<UserAvatar
  src="https://example.com/path/to/img.jpg";
  alt="..."
/>
  • หากดูแค่ภายนอก เว็บคอมโพเนนต์ก็เขียนแบบเดียวกันได้
<user-avatar
  src="https://example.com/path/to/img.jpg";
  alt="..."
></user-avatar>
  • แต่พลังเฉพาะของเว็บคอมโพเนนต์คือความสามารถในการ เรนเดอร์ก่อน JavaScript
    • React component ไม่สามารถทำงานด้วยวิธีนี้ได้
  • ดังนั้น แทนที่จะเป็น “คอมโพเนนต์เปลือก” ว่าง ๆ การจัดโครงสร้างโดยสร้างเนื้อหาหลักเป็น HTML แล้วใช้ custom element ห่อเพื่อเพิ่มฟังก์ชันจะเหมาะกว่า
<user-avatar>
  <img src="https://example.com/path/to/img.jpg"; alt="..." />
</user-avatar>
  • การแบ่งประเภท “HTML web components” ของ Jeremy โฟกัสว่าคัสตอมเอลิเมนต์นั้นขยายมาร์กอัปเดิมหรือไม่
    • หากคัสตอมเอลิเมนต์ว่างเปล่า ก็ไม่ใช่เว็บคอมโพเนนต์ HTML
    • หากห่อมาร์กอัปเดิมเพื่อขยายความสามารถ ก็ใกล้เคียงกับเว็บคอมโพเนนต์ HTML
  • “JavaScript web component” คือรูปแบบที่เนื้อหาและฟังก์ชันขององค์ประกอบว่างพึ่งพา JavaScript ทั้งหมด
<user-avatar
  src="https://example.com/path/to/img.jpg";
  alt="..."
></user-avatar>
  • รูปแบบนี้ไม่มีความหมายต่อผู้ใช้ปลายทางหากไม่มี JavaScript
  • ในทางกลับกัน เว็บคอมโพเนนต์ HTML ยังคงมี ความหมายและเนื้อหา แม้ไม่มี JavaScript และเมื่อมี JavaScript ก็จะเสริมฟังก์ชันเพิ่มเข้าไปบนฐานนั้น
<user-avatar>
  <img src="https://example.com/path/to/img.jpg"; alt="..." />
</user-avatar>

บนเว็บ แนวทางการเสริมอยู่ได้นาน

  • เหตุผลที่แนวทางแบบเสริมเข้ากับเว็บได้ดี คือธรรมชาติของเว็บส่งเสริม การเสริมแบบค่อยเป็นค่อยไปที่ยืดหยุ่นและฟื้นตัวได้ และเหมาะกับการเปลี่ยนแปลงสิ่งที่มีขนาดใหญ่เท่าเว็บซ้ำ ๆ
  • ไอเดียดี ๆ จากเฟรมเวิร์กและไลบรารีรอบเว็บ แม้จะถูกดูดซึมเข้าสู่แพลตฟอร์ม ก็มักเข้ามาในรูปแบบที่เสริมเทคโนโลยีเดิม มากกว่าการแทนที่ทั้งหมด
    • XHTML พยายามแทนที่ HTML4 แต่ HTML5 พยายามเสริม HTML4 และ HTML5 เป็นฝ่ายชนะ
    • ไลบรารีด้านเน็ตเวิร์กกิงพยายามแทนที่ XMLHttpRequest และไอเดียที่ดีในที่สุดก็ย้ายไปเป็นมาตรฐาน fetch
    • ปัจจุบัน fetch มีอยู่ในหลายสภาพแวดล้อมนอกเบราว์เซอร์ด้วย
    • ไอเดียดี ๆ ของ Sass และ jQuery ก็ถูกย้ายเข้าไปในเบราว์เซอร์เช่นกัน
    • ไอเดียดี ๆ ของ TypeScript ก็กำลังเข้าสู่เบราว์เซอร์ในรูปแบบที่เสริมเทคโนโลยีเดิม ไม่ใช่แทนที่
  • เว็บคอมโพเนนต์ก็อาจมองได้ว่าเป็นกระแสที่โมเดลคอมโพเนนต์ของ React ถูกย้ายเข้าสู่เบราว์เซอร์ แต่ใกล้เคียงกับการ เสริม วิธีที่เว็บทำงานอยู่แล้ว มากกว่าการแทนที่
  • หากต้องการแนวทางทางเทคโนโลยีที่ยืนยาว การเลือก การเสริมและการยกระดับ มากกว่าการแทนที่จะสอดคล้องกับทิศทางของเว็บ

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

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

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

  • ผมคาดหวังว่าบทความนี้จะอธิบายว่า user-avatar ทำอะไรหรือให้อะไรจริง ๆ แต่สุดท้ายก็ไม่มี
    ถ้ามันมีแค่สไตล์ ผมก็ไม่เข้าใจว่าทำไมไม่ใช้ CSS class ไปเลย และดูเป็นธรรมชาติกว่ามากถ้า user-avatar รับแอตทริบิวต์ src แทนที่จะบังคับให้ใส่แท็ก img ไว้ข้างในทุกครั้ง
    Vue/React/Angular ไม่ได้พยายาม “แทนที่” HTML เท่าไรนัก แต่ใกล้เคียงกับการสร้างต่อยอดบน HTML/CSS/JS มากกว่า และถ้าเป็นการเรนเดอร์ทุกอย่างด้วยแคนวาส ผมคงรู้สึกว่าข้ออ้างนั้นน่าเชื่อกว่านี้
    ตอน Web Components ถูกประกาศครั้งแรกผมก็เคยคาดหวังไว้ แต่ ฟีเจอร์ที่มีมาให้โดยพื้นฐาน นั้นน้อยเกินไป และให้ความรู้สึกไม่มากนักว่าช่วยสร้างเว็บแอปได้จริงเหมือนเฟรมเวิร์ก
    ทางเลือกแทนเฟรมเวิร์กขนาดใหญ่ โดยเฉพาะอย่างพวก htmlx ดูเหมือนเป็นสาย jQuery ที่เติม syntax sugar เข้าไปนิดหน่อย จึงรู้สึกเหมือนเป็นการถอยหลังครั้งใหญ่สำหรับการสร้างเว็บแอป

    • ผมเห็นด้วยว่า “ทางเลือกแทนเฟรมเวิร์กใหญ่ ๆ ดูเหมือน syntax sugar ของ jQuery” แต่ก็ยังไม่ชัดว่าทำไมมันถึงเป็นตัวเลือกที่ผิดอย่างสิ้นเชิงสำหรับการสร้างเว็บแอป
      ถ้า ‘เว็บแอป’ หมายถึงสิ่งอย่าง Google Sheets ผมก็เห็นด้วย แต่ กระแสต้าน React นี้ดูเหมือนกำลังวิจารณ์แนวปฏิบัติที่ลงเฟรมเวิร์กเป็นค่าเริ่มต้นแล้วเริ่มทำตั้งแต่ศูนย์ มากกว่าจะวิจารณ์กรณีแบบนั้น
      จริง ๆ แล้วยังมีเว็บไซต์จำนวนมากที่ต้องการแค่ “การโต้ตอบที่วางทับเพิ่มเล็กน้อย” เท่านั้น
    • ผมคิดว่าบทความของ Eric Meyer แสดงเจตนาได้ดีกว่ามาก: https://meyerweb.com/eric/thoughts/2023/11/01/blinded-by-the...
      ประโยชน์หลักคือ progressive enhancement โดยแท็ก img มีพฤติกรรมพื้นฐานอยู่แล้ว จึงอาศัยการเรนเดอร์พื้นฐาน แล้วใช้เว็บคอมโพเนนต์ “เสริม” เฉพาะส่วนที่จำเป็นก็พอ
    • เพราะขาดตัวอย่างที่เป็นรูปธรรม บทความนี้เลยให้ความรู้สึกเหมือน ไอเดียที่ผุดขึ้นมาตอนอาบน้ำ อยู่บ้าง
    • ตัวอย่างที่แสดงใจความของบทความได้เป็นรูปธรรมกว่าคืออันนี้: https://www.zachleat.com/web/details-utils
      คอมโพเนนต์ details-utils ช่วยเสริมพฤติกรรมของคอมโพเนนต์ HTML ในตัวอย่าง detail
      หาก JavaScript ถูกปิดด้วยเหตุผลใดก็ตาม คอมโพเนนต์ detail ก็ยังทำงานตามเดิม และเมื่อ JavaScript เปิดอยู่หรือดาวน์โหลดเสร็จ ก็จะได้พฤติกรรมที่ดีขึ้น เช่น คลิกด้านนอกแล้วพับเก็บได้
      ส่วนที่นำกลับมาใช้ซ้ำได้ในแนวทางนี้ก็คือ การเสริมพฤติกรรม แบบนั้น
      พอเห็นเว็บคอมโพเนนต์นี้จากผู้สร้าง 11ty ผมก็เข้าใจใจความของบทความ และจุดที่ผมเคยรู้สึกตอนเห็น Web Components ครั้งแรกว่า “สุดท้ายก็ยังต้องใช้ JavaScript และถ้าไม่มีมันก็ไม่ทำงานอยู่ดี” ก็เป็นประเด็นเดียวกับที่ปรากฏในบทความของ Rich Harris ด้วย: https://dev.to/richharris/why-i-don-t-use-web-components-2ci...
    • ไม่รู้ว่าเคยลองใช้ htmx หรือยัง แต่คำวิจารณ์นั้นดูจะพลาดเป้า เพราะ htmx จัดการปัญหาคนละแบบกับประสบการณ์ผู้ใช้จาก JavaScript ฝั่งไคลเอนต์ที่ jQuery เคยแก้
      htmx หลัก ๆ คือการขยายพาราไดม์ HTML ที่เรนเดอร์จากเซิร์ฟเวอร์ จากการรีเฟรชทั้งหน้าไปเป็นการอัปเดตบางส่วนของหน้า โดยหลีกเลี่ยงการเขียน JavaScript

  • ถ้าอยากดูไอเดีย “HTML Web Components” เพิ่ม บทความเหล่านี้ก็น่าอ่าน
    https://meyerweb.com/eric/thoughts/2023/11/01/blinded-by-the... - “ก็เป็นอันตามนั้น: ข้อความหลายพันคำเกี่ยวกับเส้นทางของผมในการเริ่มเข้าใจและใช้งานเว็บคอมโพเนนต์แบบ Light DOM ล้วนเหล่านี้ หรือที่เรียกอีกอย่างว่า custom elements ตอนนี้สิ่งที่พวกมันต้องการก็แค่ชื่อที่ติดหู เพื่อที่เราจะได้ดึงคนให้มาสู่ฝั่งสว่างของเว็บมากขึ้น”
    https://adactio.com/journal/20618 เสนอชื่อที่ฟังดูเข้าท่าไว้

    • ผมยังไม่ค่อยเข้าใจประเด็น
      มันเขียนยุ่งยากจนสุดท้ายก็ต้องมีเฟรมเวิร์กเบา ๆ วางบนเฟรมเวิร์กในตัวอย่าง Lit อีกที และ Lit ก็ยังใหญ่กว่า Preact ด้วยซ้ำ
      แถมยังไม่แก้ปัญหาจริงอย่าง state management, routing จึงมีโอกาสสูงที่จะต้องดึงอย่างอื่นเข้ามาเพิ่ม
      อาจจะได้คอมโพเนนต์ที่นำกลับมาใช้ซ้ำได้ก็จริง แต่ถ้าคิดว่าจะเอาเว็บคอมโพเนนต์ที่ข้างในใช้ Vue ไปใช้ในที่ที่ใช้ React อยู่ ก็ฟังไม่ค่อยสมเหตุสมผล
    • ผมดีใจมากที่มีกระแสผลักดัน เว็บคอมโพเนนต์ที่ไม่มี Shadow DOM
      ความงามและความสง่างามของเว็บมาจากโครงสร้างแบบ declarative และนั่นทำให้มันสังเกตตรวจสอบและแก้ไขได้
      Shadow DOM ให้ความรู้สึกเหมือนความต้องการแบบองค์กรที่อยากสร้างกำแพง encapsulation และความแน่นอนให้สูงขึ้น ซึ่งโดยส่วนตัวแล้วไม่ใช่เป้าหมายที่ผมมีร่วมด้วย
      บทความนี้แสดงให้เห็นว่างานบน Light DOM สามารถนำมาประกอบกันได้อย่างไร
      ผมคิดมาตลอดว่าเว็บคอมโพเนนต์หรือ custom elements ควรสามารถแก้ DOM ภายในของตัวเอง ย้ายลูก ๆ และสร้างคอนเทนต์ใหม่ได้
      เช่น หน้าเว็บหรือเฟรมเวิร์กอาจใส่ไอคอน และ element อวาตาร์ผู้ใช้อาจแทรกชื่อหรือองค์ประกอบตกแต่งเข้าไปได้
      อย่างไรก็ตาม สิ่งหนึ่งที่กังวลเกี่ยวกับ Light DOM/HTML Web Components คือ Shadow DOM ให้ข้อได้เปรียบด้านประสิทธิภาพบางอย่าง
      ในฐานะนักพัฒนา ผมนึกภาพได้ว่ามันช่วยลดจำนวน element ที่ CSS selector ต้องไล่ค้นหา และก็อยากให้ใช้ประโยชน์ข้อนั้นได้ในทางใดทางหนึ่ง
      ผมยินดีมากที่มีแนวทางซึ่งมอง custom elements และ Web Components ให้เบาลง และขอบคุณสำหรับลิงก์ด้วย
    • ถ้าจะย่อชื่อที่ฟังดูเข้าท่าลงอีก เรียกว่า HTML components ก็น่าจะดี

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

    • เป็นข้อสังเกตที่ดี และในทางกลับกัน เว็บคอมโพเนนต์เองก็ต้องถูกลงทะเบียนด้วย JavaScript ก่อนที่หน้าจะโหลด จึงอาจมองว่าไม่สามารถทำได้เช่นกัน
      มีวิธีแก้ด้วย Hydration อยู่ แต่โดยทั่วไปมักแย่กว่า มีจุดประนีประนอมที่น่าประหลาดใจ และหลายครั้งทำลาย ความสามารถในการประกอบรวมกัน
    • ปัญหาใหญ่ที่สุดของ Web Components คือ ไม่เป็นมิตรกับการเรนเดอร์ฝั่งเซิร์ฟเวอร์
    • ไม่แน่ใจว่า “HTML Web Component” จะจัดการการเปลี่ยนแปลงของสถานะอย่างไร
      ถ้าดูแค่ตัวอย่างที่ครอบแท็ก img ก็ยังไม่ค่อยเห็นประโยชน์ชัดเจน และถึงจะรวมองค์ประกอบร่วมกันเพื่อนำกลับมาใช้ใหม่ได้ แต่ถ้าจะให้โต้ตอบได้ก็ยังต้องใช้ JavaScript อยู่ดี
      ข้อความทางเลือกของรูปภาพในตัวอย่างทุกวันนี้ก็มักเป็นแบบไดนามิกเพราะการทำ localization ดังนั้นถ้าไม่มี JavaScript เนื้อหาอาจหายไปได้

  • รู้สึกว่าในที่สุดก็เริ่มจับทาง Web Components ได้แล้ว: https://github.com/kennyfrc/cami.js
    “No Build Steps, No Client-Side Router, No JSX, No Shadow DOM. We want you to build an MPA, with mainly HTML/CSS, and return HTML responses instead of JSON. Then add interactivity as needed.”
    “Declarative templates with lit-html. Supports event handling, attribute binding, composability, caching, and expressions.”

    • ความงดงามของ Web Components อยู่ที่การที่คุณสามารถหา หรือสร้าง คลาสฐาน ที่ทำงานในแบบที่ต้องการได้
      โดยส่วนตัวชอบคลาสสไตล์ React class component ที่มี state machine ซึ่งได้แรงบันดาลใจจาก XState อยู่ในตัว
      https://github.com/codewithkyle/supercomponent/blob/master/s...
    • อยากรู้ว่าเคยลองใช้ HTMX ไหม
      ทิศทางดูคล้ายกันพอสมควร และฝั่ง HTMX อาจมีชุมชนใหญ่กว่าด้วย
      ถ้าเคยใช้แล้ว อยากรู้ว่าขาดอะไรไปบ้าง
    • เท่ากับว่าเปลี่ยน JSX ให้เป็น DSL แบบกำหนดเองที่ไม่ใช่มาตรฐาน แล้วเรียกว่านี่คือชัยชนะ

  • “web components” ไม่ใช่สิ่งเดียว และก็ไม่ได้หมายถึงการสร้าง “a web component”
    “Web Components” คือชื่อของ Web Components API ที่รวมสามอย่างเข้าด้วยกัน
    สิ่งที่สร้างขึ้นจริงคือองค์ประกอบแบบกำหนดเอง และจะใช้ Shadow DOM กับมันก็ได้ หรือจะใช้ HTML template ก็ได้
    ในสามอย่างนี้ สิ่งที่สำคัญที่สุดคือองค์ประกอบแบบกำหนดเอง
    แนวคิดหลักคือ “สร้างองค์ประกอบ HTML เพิ่มขึ้น” ดังนั้นจะรองรับ attribute ใดและ JavaScript API แบบไหน ก็ขึ้นอยู่กับคุณทั้งหมด
    วิธีนำไปวางบนหน้า โต้ตอบกับมัน และฟัง event ก็เหมือนกับองค์ประกอบ HTML อื่น ๆ ทุกประการ
    ถ้าคุณเขียนเว็บเพจแบบ “วิธีเก่า” เป็นอยู่แล้ว คุณก็รู้วิธีใช้องค์ประกอบแบบกำหนดเองอยู่แล้ว เหลือเพียงเรียนรู้วิธีประกาศมันเท่านั้น

  • ช่วงหลังเริ่มลองเล่น Web Components โดยไม่มีสภาพแวดล้อม build
    ไม่มี npm, bun, webpack อะไรแบบนั้น ไม่มี dependency และเขียนด้วย TypeScript
    IntelliJ คอมไพล์เป็น JavaScript ให้อัตโนมัติ และ browser view จะฉีด handler ตรวจจับการเปลี่ยนแปลงเล็ก ๆ เพื่ออัปเดตแบบเรียลไทม์ระหว่างพัฒนา
    จนถึงตอนนี้ยังไม่มีปัญหา
    สิ่งที่ดูเหมือนจะถ่วง Web Components ไว้คือ HTML Modules
    คงจะดีถ้าสามารถลิงก์ไปยังไฟล์ .html แทนไฟล์ .js เพื่อ import เว็บคอมโพเนนต์ได้ แต่ตอนนี้ถ้าจะใช้ template หรืออะไรที่ซับซ้อนขึ้นอีกหน่อย ก็ต้องทำการ inject แบบน่าเกลียดอย่าง .innerHtml = \...``
    นึกว่าจะเป็นปัญหา แต่ IDE parse template string ได้ค่อนข้างดี

    • HTML Modules ถูกยกเลิกและนำออกไปแล้ว และถูกแทนที่ด้วยการ import เฉพาะ JavaScript
      และนั่นก็ไม่ใช่เหตุผลเดียวที่ขวาง Web Components อยู่

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

    • ไม่ว่าสถาปัตยกรรมเว็บแบบไหน สุดท้ายก็ต้องเรนเดอร์องค์ประกอบ HTML อยู่แล้ว ซึ่งเป็นเรื่องแน่นอน และนั่นไม่ใช่ประเด็น
      ประเด็นคือแนวทางที่เรียกว่า “HTML Web Component” นั้นต่างจาก React ตรงที่ ไม่พึ่งพา JavaScript เพื่อเริ่มการเรนเดอร์
    • ผมมองว่าความแตกต่างหลักที่บทความพูดถึงน่าจะประมาณนี้
      ถ้าวัดจากการเรนเดอร์ของเบราว์เซอร์ React คือ “โหลดหน้า → โหลดคอมโพเนนต์” ส่วน Web Component ใกล้เคียงกับ “โหลดหน้า → เรนเดอร์พื้นฐาน → โหลดคอมโพเนนต์”
      คนที่ปิด JavaScript ก็ยังเห็นอะไรบางอย่างในเว็บคอมโพเนนต์ได้ แต่ใน React อาจไม่เห็นอะไรเลย และถ้ามี JavaScript ก็สามารถไปสู่สถานะการเรนเดอร์ที่พัฒนาขึ้นได้
    • ในบางกรณี React ยังทำให้เข้าถึงฟีเจอร์ในตัวได้ยากขึ้นด้วย
      ตัวอย่างเช่น ถ้ากำหนด onchange ให้กับองค์ประกอบ React จะให้สิ่งที่ใกล้เคียงกับอีเวนต์ input ไม่ใช่อีเวนต์ change
      จริง ๆ แล้วไม่ใช่ทั้งสองอย่าง แต่เป็น synthetic event ที่ใกล้กับ input มากกว่า change
      ถ้าต้องการ change จริง ๆ ต้องใช้การอ้างอิงองค์ประกอบ แล้วผูก handler โดยตรงใน effect
    • ขึ้นอยู่กับสถาปัตยกรรมของแอป
      ถ้าใช้ React ส่งคืน HTML จากเซิร์ฟเวอร์ การห่อ img ด้วยคอมโพเนนต์ React ก็ถือว่าเป็นการเสริมองค์ประกอบเดิมจริง
      แต่ถ้าเรนเดอร์ทั้งหมดฝั่งไคลเอนต์ สุดท้าย img นั้นก็แยกออกจากคอมโพเนนต์ React ไม่ได้
    • ตอนอ่านส่วนนั้น ผมนึกถึงทิศทางตรงกันข้าม คือกรณีที่ใส่ React เข้าไปใน HTML อื่น
      จากประสบการณ์ React ยอดเยี่ยมเมื่อให้มันดูแลโครงสร้างทั้งหน้าจากบนลงล่าง แต่ถ้าพยายามสอดแทรกเข้าไปในโครงสร้างเดิมพร้อมทำงานอย่าง server-side rendering ก็อาจยากขึ้นได้

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

  • เว็บคอมโพเนนต์ควรทำ งานอย่างเดียว ส่วน JavaScript framework นั้นใกล้เคียงกับระบบนิเวศทั้งชุด
    ผมเคยสร้างเว็บคอมโพเนนต์วิดีโอเพลเยอร์ที่รับอินพุตได้หลายแบบ และอินพุตที่ซับซ้อนที่สุดคือไฟล์ทอร์เรนต์
    จะพอร์ตไป Vue/React ด้วย StencilJS [0] ก็ได้ แต่แม้ไม่มีมันก็ใช้งานได้เพียงพอแล้ว
    แค่ใส่แท็กนั้นพร้อมกับคลาสที่ export จาก awesomePlayer.js ก็จะได้ HTML5 video player แบบคัดลอก-วางสำหรับเล่นทอร์เรนต์
    ถ้าเป็นไปได้ ผมขอแนะนำอย่างยิ่งให้เลียนแบบองค์ประกอบ HTML เดิมด้วย
    เช่น ที่ใช้ src ก็เพราะ video ทำแบบนั้น และจะทำให้ฝั่งที่ใช้งานโต้ตอบได้โดยไม่ต้องไปค้นเอกสาร
    [0] https://stenciljs.com/

  • ผมเห็นด้วยได้ยากกับการบอกว่าคอมโพเนนต์ของ frontend framework เป็นของที่ใช้แทนที่อย่างสมบูรณ์ และประกอบรวมกันไม่ได้
    ภายนอกอาจดูเป็นแบบนั้น แต่ในคอมโพเนนต์ของผม ผมใช้ slot เยอะมาก การ implement ก็ง่ายและทำงานอย่างเป็นธรรมชาติ
    ตรงกันข้าม Web Components มักถูกสาธิตด้วยการยัดโค้ดมหาศาลเข้าไปเพื่อสร้างอะไรบางอย่างอย่าง editor
    การใช้ slot ใน Web Components นั้นทรมาน ต้องต่อ node เองจำนวนมาก จัดการ template เป็น string และถ้าจะทำอะไรที่ซับซ้อนขึ้นเล็กน้อยก็ยังต้องฟังอีเวนต์ slotchange ด้วย
    โดยเนื้อแท้แล้วมันคือการใช้ DOM API ซึ่งถ้า API นั้นไม่เลวร้าย เราคงไม่ย้ายไปใช้ frontend framework อย่าง React กันหรอก
    ผมก็ไม่เห็นด้วยกับข้ออ้างข้างเคียงที่ว่า XHTML ล้มเหลวเพราะไม่ได้เสริม HTML
    ผมคิดว่ามันล้มเหลวเพราะแอปพลิเคชันต้องถูกต้องสมบูรณ์ทั้งหมด และการตรวจสอบความถูกต้องนั้นถูกฝากไว้กับไคลเอนต์/เบราว์เซอร์
    ถ้าใช้ XHTML จริง ๆ ความผิดพลาดเล็ก ๆ ใน markup ก็ทำให้หน้าพังได้ ดังนั้นทุกคนจึงตรวจสอบ XHTML เพื่อเตรียมพร้อมอนาคต แต่คงไม่มีบริษัทไหนยอมเสี่ยงให้ธุรกิจพังเพียงเพราะแท็ก p ปิดไม่ถูกต้องเพียงแท็กเดียว