ในโลกของการพัฒนา JavaScript การแสวงหาความเรียบง่ายบางครั้งก็ทำให้เกิดไลบรารีที่ให้ความสำคัญกับขนาดมากกว่าฟังก์ชันการทำงาน ไลบรารี PubSub ขนาด 149 ไบต์ที่เพิ่งเปิดตัวได้จุดประเด็นถกเถียงอย่างเข้มข้นในหมู่นักพัฒนาเกี่ยวกับการแลกเปลี่ยนระหว่างขนาดของโค้ดกับการนำไปใช้งานจริง
EventTarget เป็นพื้นฐานของ PubSub
ไลบรารีดังกล่าวใช้ประโยชน์จาก API ดั้งเดิมของ JavaScript อย่าง EventTarget เพื่อสร้างสิ่งที่ผู้พัฒนาอ้างว่าเป็นการใช้งานแบบ publish-subscribe ที่มีขนาดเล็กที่สุดเท่าที่เป็นไปได้ ด้วยขนาดเพียง 149 ไบต์เมื่อทำการ minified ทำให้มีขนาดเล็กกว่าคู่แข่งอย่าง nano-pubsub (194 ไบต์) และ tiny-pubsub (401 ไบต์) การใช้งานทั้งหมดประกอบด้วยโค้ดเพียงสามบรรทัดที่สร้างฟังก์ชันระดับโกลบอล pub และ sub ซึ่งสร้างขึ้นบน API ของ EventTarget และ CustomEvent
แม้จะน่าประทับใจในความกระชับ สมาชิกในชุมชนได้แสดงความกังวลที่มีเหตุผลเกี่ยวกับแนวทางนี้ ข้อดีที่สำคัญประการหนึ่งที่ถูกเน้นย้ำคือ EventTarget ใช้การอ้างอิงแบบอ่อน (weak references) กับผู้ฟังของมัน ซึ่งช่วยป้องกันการรั่วไหลของหน่วยความจำ ซึ่งเป็นปัญหาทั่วไปในการใช้งาน PubSub แบบกำหนดเองที่ผู้ฟังไม่ได้ถูกยกเลิกการสมัครอย่างเหมาะสม
หากผู้ฟังของการใช้งานนี้ไม่ได้ถูกยกเลิกการสมัคร พวกเขาจะไม่สามารถถูกเก็บขยะได้ และในโค้ดเบสของโลกจริงนั่นหมายความว่าการรั่วไหลของหน่วยความจำเป็นสิ่งที่หลีกเลี่ยงไม่ได้ EventDispatcher มีการอ้างอิงแบบอ่อนไปยังผู้ฟังของมัน ดังนั้นจึงไม่มีปัญหานี้
การเปรียบเทียบขนาดของไลบรารี PubSub:
- pico-pubsub: 149 ไบต์
- nano-pubsub: 194 ไบต์ (ใหญ่กว่าประมาณ 30%)
- tiny-pubsub: 401 ไบต์ (ใหญ่กว่า nano-pubsub มากกว่าสองเท่า)
ข้อพิจารณาทางเทคนิคที่สำคัญ:
- EventTarget ใช้การอ้างอิงแบบอ่อน (weak references) กับผู้ฟัง (ช่วยป้องกันการรั่วไหลของหน่วยความจำ)
- การห่อหุ้มด้วย CustomEvent ต้องใช้โค้ดเพิ่มเติมที่จุดเรียกใช้งาน
- การสนับสนุน TypeScript ต้องการโค้ดประกาศเพิ่มเติม
ข้อกังวลเกี่ยวกับการออกแบบ API
นักพัฒนาหลายคนตั้งคำถามว่าการเลือกออกแบบ API ของไลบรารีนี้มีความเหมาะสมในการใช้งานจริงหรือไม่ การวิจารณ์ที่สำคัญมุ่งเน้นไปที่วิธีที่ไลบรารีส่งข้อมูลผ่านคุณสมบัติ detail ของออบเจ็กต์ CustomEvent ซึ่งทำให้นักพัฒนาต้องแกะข้อมูลนี้ที่ทุกจุดที่เรียกใช้ด้วย event.detail ตามที่ผู้แสดงความคิดเห็นรายหนึ่งระบุว่า สิ่งนี้ทำให้โค้ดย้ายจากไลบรารีไปยังทุกที่ที่มีการใช้งาน ซึ่งขัดกับหลักการออกแบบไลบรารีที่ดี
การขาดการสนับสนุน TypeScript ก็ถูกระบุว่าเป็นข้อจำกัดเช่นกัน แม้ว่าผู้พัฒนาจะรวมส่วนของ TypeScript declaration ไว้เป็นทางแก้ปัญหาชั่วคราว นักพัฒนาบางคนแนะนำการใช้งานทางเลือกที่ยังคงรักษาขนาดเล็กไว้ในขณะที่ให้การพิมพ์ที่ดีขึ้นและ API ที่ใช้งานง่ายกว่า
คำถามเรื่องคุณค่าที่นำเสนอ
การสนทนาในชุมชนสุดท้ายแล้ววนเวียนอยู่รอบคำถามพื้นฐาน: ไลบรารีนี้ให้คุณค่าเพียงพอที่จะรับรองการมีอยู่ของมันในฐานะแพ็คเกจหรือไม่? นักพัฒนาบางคนเปรียบเทียบมันกับข้อถกเถียงอันโด่งดังเรื่อง left-pad โดยแนะนำว่าการห่อหุ้ม API ดั้งเดิมที่เรียบง่ายเช่นนี้อาจไม่จำเป็น
คนอื่น ๆ ชื่นชมแง่มุมด้านการศึกษาของโปรเจกต์ โดยระบุว่ามันแนะนำพวกเขาให้รู้จักกับ API CustomEvent ที่พวกเขาไม่คุ้นเคยมาก่อน ผู้แสดงความคิดเห็นบางคนถึงกับกล่าวถึงแผนที่จะนำแนวทางที่คล้ายกันไปใช้ในโปรเจกต์ของตนเอง แสดงให้เห็นว่าแม้แต่ไลบรารีขนาดเล็กก็สามารถสร้างแรงบันดาลใจให้กับเทคนิคใหม่ ๆ ได้
ในท้ายที่สุด ไลบรารีขนาดเล็กนี้ทำหน้าที่เป็นจุดเริ่มต้นของการสนทนาเกี่ยวกับความสมดุลระหว่างความเรียบง่ายและความใช้งานได้จริงในการพัฒนา JavaScript แม้ว่าขนาด 149 ไบต์ของมันอาจน่าประทับใจ การสนทนาในชุมชนเน้นย้ำว่าขนาดไม่ใช่ทุกสิ่ง - การออกแบบ API การจัดการหน่วยความจำ และประสบการณ์ของนักพัฒนายังคงเป็นสิ่งสำคัญที่ต้องพิจารณาเมื่อประเมินไลบรารีใด ๆ ไม่ว่าจะมีขนาดเล็กแค่ไหนก็ตาม
อ้างอิง: pico-pubsub