ชุมชน JavaScript กำลังคึกคักไปด้วยการอพิปรายเกี่ยวกับการจัดการ dependency และ utility libraries หลังจากการเปิดตัว SuperUtilsPlus ซึ่งเป็นทางเลือกใหม่ของ Lodash library ที่ได้รับความนิยม แม้ว่า library นี้จะสัญญาว่าจะมีฟีเจอร์ที่ทันสมัยอย่างการรองรับ TypeScript และความสามารถในการ tree-shaking แต่การสนทนาได้พัฒนาไปสู่การถกเถียงที่กว้างขึ้นเกี่ยวกับวิธีที่นักพัฒนาควรจัดการกับ utility functions ในโปรเจกต์ของตน
คุณสมบัติหลักของ SuperUtilsPlus :
- รองรับ TypeScript อย่างเต็มรูปแบบพร้อมการกำหนดประเภทข้อมูลระดับแรก
- JavaScript สมัยใหม่ ( ES2020+ ) พร้อมรองรับ ESM และ CommonJS
- การ import แบบ tree-shakable เพื่อขนาด bundle ที่เหมาะสม
- ไม่มี dependencies
- ฟังก์ชันการทำงานที่ขยายเกินกว่า Lodash
- การปรับปรุงประสิทธิภาพ
- ความเข้ากันได้ข้ามแพลตฟอร์ม (Browser และ Node.js )
ขบวนการ Zero-Dependency ได้รับแรงผลักดัน
นักพัฒนาจำนวนมากขึ้นเรื่อยๆ กำลังตั้งคำถามว่าพวกเขาต้องการ utility libraries หรือไม่ สมาชิกบางคนในชุมชนสนับสนุนแนวทางที่รุนแรง คือการสร้างไฟล์เดี่ยวที่มีเพียงฟังก์ชันที่พวกเขาต้องการ แทนที่จะพึ่งพา external library ใดๆ ปรัชญานี้เกิดจากความกังวลเกี่ยวกับการบำรุงรักษาในระยะยาวและธรรมชาติที่คาดเดาไม่ได้ของการอัปเดต dependency
เหตุผลหลักของแนวทางนี้มุ่งเน้นไปที่เสถียรภาพและการควบคุม เมื่อ Node.js , TypeScript หรือเครื่องมือหลักอื่นๆ อัปเดต นักพัฒนามักจะเผชิญกับปัญหาความเข้ากันได้กับ dependencies ของพวกเขา แม้กระทั่งเวอร์ชันที่ถูกตรึงไว้ก็อาจกลายเป็นปัญหาได้เมื่อเวลาผ่านไป ทำให้เกิดปัญหาการย้ายระบบที่อาจใช้เวลาหลายวันในการพัฒนา
ความกังวลด้านความปลอดภัยในฟังก์ชันง่ายๆ
การอพิปรายเปลี่ยนทิศทางที่น่าสนใจเมื่อนักพัฒนาตั้งคำถามว่าฟังก์ชัน utility ง่ายๆ อาจมีช่องโหว่ด้านความปลอดภัยได้หรือไม่ อย่างไรก็ตาม ชุมชนได้ชี้ให้เห็นตัวอย่างในโลกจริงอย่างรวดเร็ว รวมถึงช่องโหว่ที่มีการบันทึกไว้ใน libraries ที่มีชื่อเสียงอย่าง Lodash , Ramda และ Underscore ปัญหาเหล่านี้มักเกิดจาก reserved attributes และการโจมตี prototype pollution
โซลูชันสมัยใหม่ที่ใช้ Symbol type ของ JavaScript อาจหลีกเลี่ยงปัญหาดังกล่าวได้ แต่การมีอยู่ของช่องโหว่เหล่านี้ในฟังก์ชันที่ดูเหมือนง่ายๆ ได้เสริมแนวคิด zero-dependency สำหรับนักพัฒนาบางคน
ความหมายของภาษาจุดประกายการถกเถียงทางเทคนิค
การอพิปรายที่ร้อนแรงเกิดขึ้นเกี่ยวกับวิธีที่ utility libraries ควรจัดการกับพฤติกรรมแปลกๆ ของ JavaScript การถกเถียงมุ่งเน้นไปที่ว่า arrays ควรถือว่าเป็น objects หรือไม่ เนื่องจากในทางเทคนิคแล้วใน JavaScript arrays เป็น objects และ [] instanceof Object จะคืนค่า true อย่างไรก็ตาม นักพัฒนาหลายคนโต้แย้งว่าสิ่งนี้ไม่ค่อยตรงกับตรรกะที่พวกเขาตั้งใจไว้
ยุติธรรมพอถ้าสิ่งนั้นไม่เข้ากับแบบจำลองทางความคิดของคุณ แต่ผมจะไม่ใช้ library ใดๆ ที่ปฏิบัติต่อข้อเท็จจริงเหมือนความคิดเห็น
สิ่งนี้เน้นให้เห็นความตึงเครียดพื้นฐานในการออกแบบ utility library คือ libraries ควรสะท้อนความเป็นจริงทางเทคนิคของภาษา หรือให้ประสบการณ์นักพัฒนาที่เข้าใจง่ายกว่า บางคนโต้แย้งว่าการเปลี่ยนความหมายของภาษาสร้างนิสัยที่ไม่ดี ในขณะที่คนอื่นๆ เชื่อว่า libraries ควรบังคับใช้แบบจำลองทางความคิดที่สมเหตุสมผลมากกว่า
ทางเลือกที่มีอยู่แล้วทำให้ภูมิทัศน์ซับซ้อนขึ้น
การสนทนาเผยให้เห็นว่า SuperUtilsPlus เข้าสู่สนามที่มีคู่แข่งหนาแน่น นักพัฒนาได้กล่าวถึงทางเลือกอื่นๆ ของ Lodash ที่มีอยู่แล้วหลายตัว รวมถึง es-toolkit , Remeda และอื่นๆ แต่ละตัวเสนอการแลกเปลี่ยนที่แตกต่างกันในแง่ของขนาด bundle การรองรับ TypeScript และการออกแบบ API
Remeda ตัวอย่างหนึ่ง มุ่งเน้นไปที่การพิมพ์ที่แม่นยำด้วยฟีเจอร์อย่างการรับประกันว่า groupBy จะคืนค่า non-empty lists Es-toolkit ได้พิสูจน์ความสำเร็จแล้วในการย้ายระบบขนาดใหญ่ โดยนักพัฒนาคนหนึ่งรายงานการเปลี่ยนผ่านที่ราบรื่นในแอปพลิเคชัน React ที่มีโค้ดประมาณ 500,000 บรรทัด
ไลบรารียูทิลิตี้ JavaScript ทางเลือก:
- es-toolkit: ใช้งานสำเร็จในแอป React ขนาดใหญ่ (การย้ายโค้ดมากกว่า 500k+ บรรทัด)
- Remeda: เน้นความแม่นยำของ TypeScript types และการรับประกันรายการที่ไม่ว่างเปล่า
- Just: ฟังก์ชันยูทิลิตี้แบบโมดูลาร์ (github.com/angus-c/just)
- Lodash: ไลบรารียูทิลิตี้ต้นฉบับ ยังคงได้รับความนิยมอย่างกว้างขวางแต่ขาดความสามารถในการ tree-shaking
สรุป
การเกิดขึ้นของ SuperUtilsPlus ได้กระตุ้นการสนทนาที่กว้างขึ้นเกี่ยวกับปรัชญาการจัดการ dependency ในการพัฒนา JavaScript แม้ว่า library นี้จะเสนอฟีเจอร์ที่ทันสมัยและการปรับปรุงประสิทธิภาพ แต่ชุมชนยังคงแบ่งแยกระหว่างการยอมรับเครื่องมือใหม่และการแสวงหาความเป็นอิสระอย่างสมบูรณ์จาก external dependencies การถกเถียงนี้สะท้อนถึงวิวัฒนาการอย่างต่อเนื่องของระบบนิเวศ JavaScript และการมุ่งเน้นที่เพิ่มขึ้นของนักพัฒนาต่อความสามารถในการบำรุงรักษาและความปลอดภัยในระยะยาว
อ้างอิง: SuperUtilsPlus