Lit - ไลบรารีสำหรับสร้างเว็บคอมโพเนนต์ที่รวดเร็วและมีน้ำหนักเบา

• เพิ่มเพียง ความสามารถเชิง reactive, เทมเพลตแบบ declarative และ boilerplate ขั้นต่ำ บนมาตรฐานเว็บคอมโพเนนต์
• มีขนาดเล็กเพียง 5KB พร้อม การเรนเดอร์ที่รวดเร็ว และอัปเดตเฉพาะส่วนของ UI ที่เปลี่ยนแปลงเพื่อเพิ่มประสิทธิภาพและความเร็วในการโหลด
• คอมโพเนนต์ Lit ทุกตัวเป็น Native Web Component และนำกลับมาใช้ซ้ำได้ทุกที่ที่ใช้ HTML ได้ โดยไม่ขึ้นกับเฟรมเวิร์ก
• ใช้ Shadow DOM เพื่อจำกัดขอบเขตของสไตล์โดยค่าเริ่มต้น ทำให้ CSS selector เรียบง่ายขึ้นและป้องกันการชนกับสไตล์อื่น
• ใช้ Reactive Property ในการโมเดล API ของคอมโพเนนต์และสถานะภายใน พร้อมรองรับการ re-render อย่างมีประสิทธิภาพเมื่อพร็อพเพอร์ตีเปลี่ยน
• เทมเพลตที่อิงกับ Tagged template Literals ทำให้รวดเร็วและเรียบง่าย
• ใช้งานได้ในหลากหลายโปรเจกต์เว็บ ตั้งแต่คอมโพเนนต์ที่ใช้ร่วมกัน, ระบบดีไซน์ ไปจนถึงการสร้างทั้งแอปโดยลด vendor lock-in และเสริมความสามารถในการบำรุงรักษา
• มี บทช่วยสอน ให้ใช้งาน
• GitHub

[devstudyman7]

รู้สึกแบบนี้มาตั้งแต่ 3 ปีก่อนว่า มันทั้งเร็วสำหรับเอา vanilla web components มาใช้ตรง ๆ และก็ให้ความรู้สึกเหมือนเป็นเฟรมเวิร์กช่วงรอยต่อ แต่ก็ช้า..

[cnaa97]

หมายความว่าอะไร?

[bluemir]

ผมกำลังพัฒนาเครื่องมือสำหรับงานปฏิบัติการโดยใช้แค่ web standard อย่าง web component และ lit-html เท่านั้น ซึ่งข้อดีคือมีข้อมูลที่ต้องรู้ให้น้อยที่สุด ใน lit-html ฟีเจอร์ที่ใช้อยู่ก็มีแค่ event handler binding กับ loop templating ประมาณนั้นเอง (ที่เหลือแค่ระดับ web standard ก็เพียงพอแล้ว..) แม้จะมีความไม่สะดวกตรงที่ถ้ามีการเปลี่ยนแปลงต้องเรียก render เองโดยตรง แต่ในอีกมุมหนึ่ง การเรียกแบบชัดเจนก็มีข้อดีมากกว่าการตรวจจับการเปลี่ยนแปลงตัวแปรอัตโนมัติแล้วเกิดพฤติกรรมที่ไม่ชัดเจนได้เหมือนกัน เพราะเป็นเครื่องมือสำหรับงานปฏิบัติการ การรองรับสภาพแวดล้อมที่หลากหลายจึงมีลำดับความสำคัญค่อนข้างต่ำ เลยอาจจะทำให้ผมรู้สึกแบบนั้นก็ได้

[GN⁺]

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

• เคยใช้ Lit ในโปรเจกต์ของบริษัท แต่ตอนนี้เลิกใช้แล้ว รู้สึกโล่งใจมาก
  ตอนนั้นก็ใช้ เฟรมเวิร์กที่หนักอยู่แล้ว แต่มีคนเพิ่ม Lit เข้ามาเพราะอยากมีอีกหนึ่งบรรทัดไว้ใส่ในเรซูเม่ ซึ่งกลายเป็นภาระก้อนใหญ่
  โดยเฉพาะ Shadow DOM ที่ทำให้ปัญหา การเข้าถึง (A11y) หนักขึ้นกว่าเดิม เพราะขอบเขตของ id ถูกแยกออก ทำให้การเชื่อมอย่าง label-for, describe-by พังหมด จนต้องปวดหัวกันมาก
  แน่นอนว่าส่วนหนึ่งก็เป็นปัญหาเรื่อง ทักษะของทีมยังไม่พอ ด้วย
  • กระบวนการรวมเว็บคอมโพเนนต์เข้ากับโค้ดเบส React นั้นลำบากมาก คิดว่าไม่ใช่ปัญหาของ Lit เท่าไร แต่เป็นปัญหาของเว็บคอมโพเนนต์เองมากกว่า
    แม้สไตล์จะถูก scope เอาไว้ แต่ส่วนสำคัญอย่างขนาดฟอนต์กลับเป็นข้อยกเว้น เลยมี บั๊กถดถอย เล็ก ๆ โผล่มาตลอดทุกครั้งที่เปลี่ยนแทน
    DX ก็แย่ลงเยอะ หวังว่า tooling จะดีขึ้น แต่ตอนนี้คือเหนื่อยมาก
  • ใน Lit นั้น Shadow DOM เป็นตัวเลือก ดังนั้นจึง ปิดใช้งานเป็นรายคอมโพเนนต์ ได้
  • มีข้อสงสัยว่ากรณีที่ใครสักคนเอาเทคโนโลยีมาใช้แค่เพื่อเติมเรซูเม่นั้นเกิดขึ้นบ่อยจริงไหม
    เอาเข้าจริง ดูเหมือนว่าจะเป็นกรณีที่แค่อยาก ลองของใหม่ แล้วนำมาใช้โดยไม่ต้องหาเหตุผลมารองรับมากกว่า
• ผมสร้าง ไลบรารีจัดการสถานะ สำหรับ Lit เอง (258 บรรทัด, https://github.com/gitaarik/lit-state)
  มันทำงานได้ดีเมื่อคอมโพเนนต์ที่ซ้อนกันในแอปที่ซับซ้อนต้องโต้ตอบกัน และถึงจะคล้าย React แต่ก็ เป็น native ของเบราว์เซอร์ มากกว่า มี boilerplate น้อยกว่า และเรนเดอร์ได้เร็วกว่า
  ถึงขั้นไม่เข้าใจเลยว่าทำไม Lit ถึงไม่ดังมากกว่านี้
  • ผมเองก็เคยลองเขียนใหม่ตั้งแต่พื้นฐานเพื่อทำความเข้าใจการทำงานภายในของ Lit
    ความสามารถหลักนั้นเรียบง่ายกว่าที่คิด และส่วนใหญ่พึ่งพา Platform API
    เพราะแบบนี้ใคร ๆ ก็เขียนเองได้ และผมคิดว่าความเรียบง่ายแบบนี้มีคุณค่ามาก
    เผื่ออ้างอิง implementation ทดแทนที่ผมทำไว้คือ https://github.com/ruphin/lite-html
• ผมเป็น ผู้ดูแลหลัก ของ Lit ไม่รู้เหมือนกันว่าทำไมวันนี้จู่ ๆ มันถึงขึ้นหน้าแรกของ HN แต่ถ้ามีคำถามก็ยินดีตอบ
  • lit-html มีประโยชน์มากจนผมใช้กับแทบทุกโปรเจกต์ส่วนตัว
    การที่เรียกผ่าน CDN ได้เลยและทดลองได้โดยไม่ต้องมี build step ก็เป็นข้อดีมาก
    มันไม่ได้หนักแบบเฟรมเวิร์กอื่น ๆ และให้ความรู้สึกเหมือนใช้ Vanilla JS + HTML ตรง ๆ เลย จึงแทบไม่มีภาระทางความคิด
  • มีคนพูดถึง Shadow DOM เยอะ เลยขอเรียบเรียงความเห็นของตัวเอง
    โดยพื้นฐานแล้ว Shadow DOM คือ ต้นไม้แบบ private ที่แยก DOM ภายในคอมโพเนนต์ออกมา
    สิ่งนี้ทำให้แนวคิด slot เกิดขึ้นได้ และทำให้สร้างคอมโพเนนต์ที่ประกอบรวมกันได้จริง
    ปัญหาคือการห่อหุ้มสไตล์กลายเป็นอุปสรรคใหญ่เวลาเอาไปผสานกับระบบเดิม
    เพราะงั้นผมจึงเสนอแนวคิด Open Styleable Shadow Roots ซึ่งเป็นวิธีให้สไตล์จากภายนอกไหลเข้ามาข้างในได้โดยยังคง slot เอาไว้ ตอนนี้ยังอยู่ระหว่างพยายามโน้มน้าว browser vendor ต่าง ๆ
  • Lit เป็น เครื่องมือที่สะอาด และไม่เข้ามาขวางทางเฟรมเวิร์ก ผมเลยสร้างทั้งแอปส่วนตัวและแอปงานด้วย Lit ทั้งหมด
    ผมเคยเขียนเรื่องนี้ไว้ด้วย: https://medium.com/gitconnected/getting-started-with-web-com...
  • Lit ทำให้การพัฒนาสนุกทั้งในกรณีง่าย ๆ และกรณีซับซ้อน
    บางทีก็อดสงสัยไม่ได้ว่าทำไมมันยังไม่ถูกใช้อย่างแพร่หลายกว่านี้
  • มีคำถามว่าเป็นไปได้ไหมที่มาตรฐาน Web Components จะรวมความสามารถแบบ Lit เข้าไป
    • Web Components นั้นดีเพราะเป็น native แต่ก็จริงที่การนำไปใช้ยังช้าเพราะขาด reactivity
    • Lit คือส่วนต่อขยายที่เป็นธรรมชาติซึ่งเข้ามาเติมช่องว่างนั้น
• ผมใช้ Lit ในโปรเจกต์ไคลเอนต์แชต XMPP ชื่อ Converse.js
  เดิมทีใช้ Backbone.js เป็นฐาน แล้วค่อย ๆ เปลี่ยนทีละขั้นจาก lit-html → lit-element → lit
  ตอนนี้มันถูกแจกจ่ายเป็นเว็บคอมโพเนนต์ชื่อ <converse-root /> จึงผสานกับเฟรมเวิร์กอื่นอย่าง React ได้ดี
  GitHub: https://github.com/conversejs/converse.js / เดโม: https://chat.conversejs.org/
• ทุกวันนี้รู้สึกว่าไม่จำเป็นต้องใช้ Lit แล้ว แค่ทำงานด้วย Web Components ล้วน ๆ ก็สบายใจกว่า
  ถ้าใช้ระบบเทมเพลตอย่าง JSX ฝั่งเซิร์ฟเวอร์ก็เพียงพอแล้ว และฝั่งไคลเอนต์ก็เป็นแค่ JS เลยไม่ต้องกังวลเรื่องอัปเกรด
  • ข้อดีของ Web Components คือสามารถสร้างได้ในแบบที่ต้องการ
    เพียงแต่ Native API นั้น low-level เกินไป ทำให้ DX ไม่ดี และ Lit ก็เข้ามาวาง reactivity แบบประกาศได้ไว้ด้านบน
  • ผมคิดว่า Lit ช่วย abstract งานซ้ำ ๆ อย่างการจัดการ `` และการเชื่อม DOM ได้ดี
    มันแก้ส่วนที่ถ้าทำเองจะน่ารำคาญได้อย่างเรียบร้อย
  • สำหรับผมแล้ว แทบไม่รู้สึกถึงความต่างมากนักระหว่าง template literal html ของ Lit กับ JSX
    กลับกัน JSX ยังต้องมี ขั้นตอนคอมไพล์ จึงยุ่งยากกว่าอีก
• ผมใช้ Lit ใน production มา 3 ปีแล้ว คิดว่ามันคือ ชั้น abstraction ที่ดีที่สุดบน Web Components API
  • ผมก็มีประสบการณ์คล้ายกัน
    ตอนแรกสร้าง Web Components เองในสภาพแวดล้อมที่ไม่มี dependency แต่พอย้ายมาใช้ LitElement แล้วสะดวกกว่ามาก
    แต่อย่างไรก็ตาม Shadow DOM แม้จะเป็นค่าเริ่มต้น แต่บางทีก็สร้างปัญหาเพิ่มเสียมากกว่า ตอนนี้เลยใช้ LitElement แบบไม่มี Shadow DOM
• ผมใช้ Lit ใน production มาตั้งแต่ปี 2020 และไม่เคยเสียใจเลย
  ข้อดีใหญ่ที่สุดคือมันอยู่บน รากฐานที่มั่นคง
  เพราะ Native Web Components รองรับได้เสถียรในทุกเบราว์เซอร์ จึงโฟกัสกับการพัฒนาได้โดยไม่ต้องเสี่ยงกับการเปลี่ยนเฟรมเวิร์ก
  อยากให้มีทีมมาลองใช้กันมากกว่านี้
  อนึ่ง ขอแนะนำ วิดีโอ HTTP 203 เกี่ยวกับ Lit ด้วย
• สำหรับงานฝั่งฟรอนต์เอนด์ Lit เป็นเหมือน ผู้กอบกู้ จริง ๆ
  Angular หนักเกินไป ส่วน React ก็ถูกออกแบบมาตามข้อจำกัดของเบราว์เซอร์ยุคเก่า จนตอนนี้เหมือนเหลืออยู่เพราะ แรงเฉื่อย เท่านั้น
  • อยากฟังแบบเจาะจงกว่านี้ว่ากำลังพูดถึงความสามารถอะไรของเบราว์เซอร์ยุคเก่า
  • ผมชอบเฟรมเวิร์ก Aurelia มาก เพราะยึดตามมาตรฐานได้ดีและโค้ดก็กระชับ
    เมื่อเทียบกับ boilerplate ของ Angular หรือความซับซ้อนของ hooks ใน React แล้ว มันตรงไปตรงมากว่ามาก
    แต่น่าเสียดายที่มันไม่ได้รับความนิยม
  • พอมีคนบอกว่า React โด่งดังเพราะการรองรับเบราว์เซอร์เก่า จู่ ๆ ก็รู้สึกเหมือนตัวเองแก่ขึ้นมาเลย
• ผมชอบไลบรารีเรนเดอร์ lit-html แบบเดี่ยว ๆ แต่ไม่รู้สึกว่าจำเป็นต้องใช้ Lit ทั้งชุด
  เอาจริง ๆ แค่จับคู่ + Web Components ก็เพียงพอแล้ว
• ผมกำลังจะเผยแพร่คอมโพเนนต์ที่สร้างในโปรเจกต์ Vue 3 ขนาดใหญ่เป็นเว็บคอมโพเนนต์ เพื่อนำไปใช้ซ้ำในไซต์อื่น
  แต่ก็สงสัยว่าการเขียนใหม่ด้วย Lit แทน Vue จะมีข้อดีอะไร
  • ผมเคยใช้ทั้ง Vue และ Lit และโดยส่วนตัวรู้สึกว่า Vue ดีกว่านิดหน่อย
    การจัดการสถานะด้วย ref/reactive ของ Vue 3 นั้นทรงพลัง และทดสอบได้โดยไม่ต้องพึ่ง DOM
    reactivity ของ Lit อยู่ในระดับวิดเจ็ต จึงต้องจัดการตัวกระตุ้นการอัปเดตเอง
    ส่วน Vue มี lifecycle ที่เรียบง่าย แต่ Lit ต้องคอยใส่ใจ callback หลายตัว จึงเกิดบั๊กได้ง่ายกว่า
    ถ้าไม่มีเหตุผลพิเศษ ก็ควรโฟกัสที่ การพัฒนาฟีเจอร์ มากกว่า และการเปลี่ยน tech stack ก็แทบไม่ส่งผลกับผู้ใช้เลย
  • ในมุมของผู้ใช้ปลายทาง ไม่ว่าจะเป็น Vue หรือ Lit ผลลัพธ์ก็คือ Web Components เหมือนกัน จึงแทบไม่ต่าง
    Vue เป็นเฟรมเวิร์กจึงมีความสามารถมากกว่า ส่วน Lit นั้น implement ใกล้กับ Native API มากกว่า
    Vue ต้อง build แต่ Lit สามารถ โหลดตอน runtime ได้
    Vue คอมไพล์ไปยังเป้าหมายอื่นได้ด้วย แต่ Lit เน้นสำหรับ Web Components โดยเฉพาะ จึงดูสะอาดกว่า
    สุดท้ายแล้วสิ่งสำคัญที่สุดคือใช้เทคโนโลยีที่ทีมคุ้นเคยมากกว่า
  • จริง ๆ แล้วแนวทางที่เป็นจริงที่สุดคือแค่ สร้าง bundle ของเว็บคอมโพเนนต์ แล้วส่งออกไป โดยภายในจะ implement อย่างไรก็ได้
    ผู้ใช้งานไม่ได้สนใจรายละเอียดภายใน สนใจแค่ขนาดกับ API เท่านั้น
    ไม่ว่าอย่างไรคนอื่นก็จะสร้าง adapter ให้เข้ากับสภาพแวดล้อมของตัวเองอยู่ดี