เลือกไลบรารีหรือเฟรมเวิร์ก JavaScript

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

ไลบรารีและเฟรมเวิร์ก JavaScript คืออะไร

ไลบรารี JavaScript คืออะไร ไลบรารี JavaScript คือโค้ดที่เขียนไว้ล่วงหน้าซึ่งคุณสามารถเรียกใช้ในโค้ดของโปรเจ็กต์เพื่อให้งานหนึ่งๆ บรรลุผล

โพสต์นี้พูดถึง "คลัง" เป็นหลัก อย่างไรก็ตาม การหารือส่วนใหญ่ก็เกี่ยวข้องกับกรอบงานด้วยเช่นกัน โดยสรุปแล้ว ความแตกต่างระหว่าง 2 รายการนี้ได้แก่

• สำหรับไลบรารี โค้ดแอปพลิเคชันจะเรียกโค้ดไลบรารี
• สําหรับเฟรมเวิร์ก เฟรมเวิร์กจะเรียกใช้โค้ดแอปพลิเคชัน

ตัวอย่างการใช้งานต่อไปนี้จะช่วยอธิบายความแตกต่าง

ตัวอย่างการเรียกใช้ไลบรารี JavaScript

ไลบรารี JavaScript จะทํางานบางอย่าง แล้วส่งการควบคุมกลับไปยังแอปพลิเคชัน เมื่อใช้ไลบรารี คุณจะควบคุมขั้นตอนการสมัครใช้บริการและเลือกเวลาเรียกใช้ไลบรารีได้

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

import capitalize from 'lodash.capitalize';
capitalize('hello'); // Hello

เมื่อเรียกใช้เมธอด lodash.capitalize ระบบจะเรียกใช้โค้ด JavaScript ที่เขียนไว้ล่วงหน้าซึ่งจะเปลี่ยนอักขระตัวแรกของสตริงเป็นตัวพิมพ์ใหญ่

ตัวอย่างการใช้เฟรมเวิร์ก JavaScript

เฟรมเวิร์ก JavaScript คือเทมเพลตโค้ดที่กําหนดไว้ล่วงหน้าซึ่งคุณใช้สร้างลักษณะการทํางานของแอปพลิเคชัน กล่าวคือ เมื่อคุณใช้เฟรมเวิร์ก เฟรมเวิร์กจะควบคุมขั้นตอนการสมัคร หากต้องการใช้เฟรมเวิร์ก คุณต้องเขียนโค้ดแอปพลิเคชันที่กําหนดเอง จากนั้นเฟรมเวิร์กจะเรียกโค้ดแอปพลิเคชันของคุณ

ตัวอย่างต่อไปนี้แสดงข้อมูลโค้ดที่ใช้เฟรมเวิร์ก JavaScript ของ Preact

import { createElement } from 'preact';

export default function App() {
  return (
    <p class="big">Hello World!</p>
  )
}

จากตัวอย่าง จะเห็นได้ว่าเฟรมเวิร์กนี้ควบคุมโค้ดที่คุณเขียนได้มากขึ้น และในบางกรณี เฟรมเวิร์กนี้จะควบคุมเวลาในการเรียกใช้โค้ดด้วย

เหตุผลที่ควรใช้ไลบรารี

การใช้ไลบรารี JavaScript จะช่วยหลีกเลี่ยงการเขียนโค้ดซ้ำที่ไม่จำเป็น ไลบรารีอาจตัดตรรกะที่ซับซ้อนออกไปได้ เช่น การดัดแปลงวันที่หรือการคำนวณทางการเงิน นอกจากนี้ ไลบรารียังช่วยคุณสร้างผลิตภัณฑ์เริ่มต้นได้โดยไม่ต้องเขียนโค้ดทั้งหมดตั้งแต่ต้น ซึ่งอาจใช้เวลานาน

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

ห้องสมุดบางแห่งได้รับการสนับสนุนจากบริษัทขนาดใหญ่ที่ทุ่มเทเวลาและเงินเพื่อให้ห้องสมุดทันสมัยและปลอดภัย ไลบรารีจำนวนมากมาพร้อมกับเอกสารประกอบที่ครอบคลุม ซึ่งจะช่วยให้คุณและทีมทำความคุ้นเคยกับการใช้งานไลบรารีได้อย่างรวดเร็ว

ท้ายที่สุดแล้ว การใช้ไลบรารี JavaScript จะช่วยประหยัดเวลา

เหตุใดคุณจึงควรสนใจเรื่องการใช้งานไลบรารี

ในทางเทคนิค คุณสามารถพัฒนาเว็บแอปพลิเคชันได้ตั้งแต่ต้น แต่ทำไมจึงต้องเจอกับปัญหาในเมื่อคุณใช้ซอฟต์แวร์ฟรี (โอเพนซอร์ส) หรือซื้อโซลูชันที่ช่วยคุณประหยัดทั้งเงินและเวลาได้ในระยะยาว ไลบรารีและเฟรมเวิร์ก JavaScript มีให้บริการจํานวนมาก โดยแต่ละรายการมีแนวทางในการแก้ปัญหาที่ไม่เหมือนกันและมีลักษณะเฉพาะตัว เช่น

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

ดังที่คุณอาจคาดเดาได้ ลักษณะต่างๆ อาจส่งผลต่อเว็บแอปพลิเคชันของคุณในลักษณะที่แตกต่างกัน บางครั้งการเลือกก็ไม่ใช่เรื่องที่ต้องคิดมาก และคุณเปลี่ยนคลังได้อย่างปลอดภัยหากไม่ชอบ อย่างไรก็ตาม บางครั้งไลบรารีอาจส่งผลอย่างมากต่องานและเว็บแอปพลิเคชันของคุณ ซึ่งอาจต้องใช้แนวทางที่มีความรู้มากขึ้น

มีสภาพแวดล้อม JavaScript บางอย่างที่ไม่ใช่ฝั่งไคลเอ็นต์ เช่น บนเซิร์ฟเวอร์ (ทำงานในสภาพแวดล้อมระบบคลาวด์) หรือใน Raspberry Pi ซึ่งคุณอาจต้องปรับเกณฑ์ที่ใช้ในการตรวจสอบไลบรารีและเฟรมเวิร์ก

ประสิทธิภาพ

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

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

ยิ่งไลบรารี JavaScript ใหญ่เท่าใด ผลกระทบด้านประสิทธิภาพต่อผู้ใช้ก็จะยิ่งมากขึ้นเท่านั้น

เมื่อประเมินหรือใช้ไลบรารีหรือเฟรมเวิร์ก JavaScript ให้พิจารณาคําแนะนําต่อไปนี้เพื่อปรับปรุงประสิทธิภาพ

• หากมีไลบรารี JavaScript ขนาดใหญ่ ให้ลองใช้ไลบรารีอื่นที่ขนาดเล็กกว่า เช่น date-fns มีฟังก์ชันการทำงานมากมายในขนาดที่สมเหตุสมผลกว่าตัวเลือกอื่นๆ
• จากตัวอย่าง date-fns ก่อนหน้านี้ ให้นำเข้าเฉพาะฟังก์ชันที่ต้องการ เช่น import { format } from 'date-fns' อย่าลืมใช้แนวทางนี้ร่วมกับการแยกไฟล์ JavaScript ออกเพื่อให้ระบบสร้างและส่งเพย์โหลด JavaScript เพียงเล็กน้อยไปยังผู้ใช้
• ใช้เครื่องมือทดสอบประสิทธิภาพ เช่น Lighthouse เพื่อสังเกตผลกระทบด้านประสิทธิภาพของการใช้ไลบรารี JavaScript บางรายการ หากไลบรารีเพิ่มเวลาในการโหลดหน้าเว็บ 1 วินาที (อย่าลืมจำกัดเครือข่ายและ CPU ในระหว่างการทดสอบ) คุณอาจต้องประเมินไลบรารีที่เลือกใหม่ นอกจากการตรวจสอบการโหลดหน้าเว็บแล้ว อย่าลืมตรวจสอบลักษณะการทํางานของหน้าเว็บที่เรียกใช้โค้ดจากไลบรารีที่เป็นปัญหาด้วย เนื่องจากประสิทธิภาพการโหลดหน้าเว็บไม่ได้บอกข้อมูลทั้งหมด
• หากผู้เขียนคลังยินดีรับความคิดเห็น ให้ส่งการสังเกตประสิทธิภาพ คำแนะนำ และแม้แต่การมีส่วนร่วมในโปรเจ็กต์ ตรงนี้แหละที่ชุมชนโอเพนซอร์สจะแสดงศักยภาพ หากตัดสินใจที่จะบริจาค คุณอาจต้องตรวจสอบกับนายจ้างก่อน
• ใช้เครื่องมือติดตาม Bundle แบบอัตโนมัติ เช่น bundlesize เพื่อตรวจหาการอัปเดตไลบรารีขนาดใหญ่โดยไม่คาดคิด เป็นเรื่องปกติที่ไลบรารี JavaScript จะมีจำนวนเพิ่มขึ้นเรื่อยๆ การเพิ่มฟีเจอร์ การแก้ไขข้อบกพร่อง กรณีขอบเขต และอื่นๆ ล้วนทำให้ไฟล์ของคลังมีขนาดใหญ่ขึ้น เมื่อคุณ/ทีมของคุณตกลงที่จะใช้ไลบรารีแล้ว การอัปเดตไลบรารีอาจไม่มีปัญหามากนักและอาจทำให้เกิดคำถามน้อยมากหรือไม่มีเลย การทำงานอัตโนมัติจึงมีประโยชน์ในสถานการณ์เช่นนี้
• พิจารณาข้อกำหนดสำหรับไลบรารีและประเมินว่าแพลตฟอร์มเว็บมีฟังก์ชันการทำงานเดียวกันโดยกำเนิดหรือไม่ เช่น แพลตฟอร์มเว็บมีตัวเลือกสีอยู่แล้ว ซึ่งทำให้ไม่จำเป็นต้องใช้ไลบรารี JavaScript ของบุคคลที่สามเพื่อใช้งานฟังก์ชันเดียวกันนี้

ความปลอดภัย

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

ลองพิจารณาไลบรารีที่เผยแพร่ไปยังระบบนิเวศ NPM แพ็กเกจดังกล่าวอาจเป็นของจริง แต่เมื่อเวลาผ่านไป แพ็กเกจอาจถูกบุกรุกได้

เคล็ดลับด้านความปลอดภัยที่ควรพิจารณาเมื่อใช้หรือประเมินโค้ดของบุคคลที่สามมีดังนี้

• หากคุณใช้ GitHub ให้พิจารณาข้อเสนอด้านความปลอดภัยของโค้ด เช่น Dependabot หรือลองใช้บริการอื่นที่สแกนหาช่องโหว่ในโค้ด เช่น snyk.io
• ลองใช้บริการตรวจสอบโค้ด ซึ่งเป็นทีมวิศวกรที่สามารถตรวจสอบโค้ดของบุคคลที่สามที่คุณใช้อยู่ด้วยตนเอง
• ประเมินว่าคุณควรล็อกการพึ่งพาไว้กับเวอร์ชันที่เจาะจง หรือคอมมิตโค้ดของบุคคลที่สามภายในการควบคุมเวอร์ชันหรือไม่ ซึ่งจะช่วยล็อกการพึ่งพาไว้กับเวอร์ชันหนึ่งๆ ที่ถือว่าปลอดภัย แต่การดำเนินการนี้อาจส่งผลเสียต่อความปลอดภัย เนื่องจากคุณอาจพลาดการอัปเดตที่สำคัญในคลัง
• สแกนหน้าแรกของโปรเจ็กต์หรือหน้า GitHub หากมี ตรวจสอบว่ามีปัญหาด้านความปลอดภัยที่ยังรอดำเนินการอยู่หรือไม่ และปัญหาด้านความปลอดภัยก่อนหน้านี้ได้รับการแก้ไขภายในกรอบเวลาที่เหมาะสมหรือไม่
• โค้ดของบุคคลที่สามที่ใช้โค้ดของบุคคลที่สามอื่นๆ อาจเสี่ยงมากกว่าไลบรารีที่ไม่มีทรัพยากรภายนอก โปรดคำนึงถึงความเสี่ยงนี้

การช่วยเหลือพิเศษ

คุณอาจสงสัยว่าไลบรารีซอฟต์แวร์เกี่ยวข้องกับการช่วยเหลือพิเศษบนเว็บอย่างไร แม้ว่าจะใช้ไลบรารีซอฟต์แวร์ในสภาพแวดล้อมที่แตกต่างกันได้ แต่ในบริบทของไลบรารีที่ใช้ JavaScript ฝั่งไคลเอ็นต์ การช่วยเหลือพิเศษบนเว็บมีความสำคัญสูง

ไลบรารีที่ใช้ JavaScript ฝั่งไคลเอ็นต์ (หรือเฟรมเวิร์ก) สามารถเพิ่มหรือลดความสามารถในการเข้าถึงของเว็บไซต์ได้ ลองใช้ไลบรารี JavaScript ของบุคคลที่สามที่เพิ่มแถบเลื่อนรูปภาพลงในหน้าเว็บ หากแถบเลื่อนรูปภาพไม่คำนึงถึงการช่วยเหลือพิเศษบนเว็บ คุณในฐานะนักพัฒนาเว็บอาจมองข้ามฟีเจอร์สำคัญดังกล่าวและเปิดตัวผลิตภัณฑ์ที่ไม่มีฟีเจอร์สำคัญ เช่น แถบเลื่อนที่ไปยังส่วนต่างๆ ได้ด้วยแป้นพิมพ์

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

เราคาดหวังว่าคุณในฐานะนักพัฒนาเว็บจะต้องมีส่วนร่วมในระดับหนึ่งเพื่อให้เป็นไปตามข้อกำหนดการช่วยเหลือพิเศษดังกล่าว เช่น

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

การประชุม

ไลบรารีซอฟต์แวร์ที่ใช้รูปแบบการเขียนโค้ดที่ยอมรับแล้วจะใช้งานได้ง่ายกว่า หากไลบรารีใช้รูปแบบการเขียนโค้ดที่ไม่เคยได้ยินมาก่อน คุณและทีมอาจใช้งานไลบรารีดังกล่าวได้ยาก

หากไลบรารีไม่เป็นไปตามแบบแผนการเขียนโค้ดทั่วไป (เช่น คู่มือสไตล์ทั่วไป) คุณจะไม่สามารถแก้ไขอะไรได้ในทันที แต่ยังมีตัวเลือกอื่นๆ อยู่ 2-3 รายการ ดังนี้

• โปรดแยกความแตกต่างระหว่างซอร์สโค้ดของไลบรารีกับ API ที่แสดงให้คุณซึ่งเป็นผู้ใช้ไลบรารีเห็น แม้ว่าซอร์สโค้ดภายในอาจใช้รูปแบบที่ไม่คุ้นเคย แต่หาก API (ส่วนของไลบรารีที่คุณโต้ตอบด้วย) ใช้แบบแผนที่คุ้นเคย คุณก็ไม่ต้องเป็นกังวล
• หากไลบรารี API ไม่เป็นไปตามกฎการเขียนโค้ดทั่วไป คุณสามารถใช้รูปแบบการออกแบบ JavaScript เช่น รูปแบบพร็อกซี เพื่อรวมและมีการโต้ตอบทั้งหมดกับไลบรารีในไฟล์เดียวในโค้ดเบส จากนั้นพร็อกซีจะเสนอ API ที่ใช้งานง่ายขึ้นให้กับส่วนอื่นๆ ของโค้ดภายในโค้ดเบส

รูปแบบการใช้งานมีบทบาทสำคัญกับความสะดวกในการใช้งาน ไลบรารีที่มี API ที่ใช้งานง่ายจะช่วยประหยัดเวลาได้หลายชั่วโมงหรือหลายวันเมื่อเทียบกับ API ที่ใช้งานยากซึ่งต้องใช้เวลาทดลองมากจึงจะเข้าใจ

อัปเดต

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

เมื่อเลือกไลบรารีหรือเฟรมเวิร์ก ให้สังเกตวิธีจัดการการอัปเดต และตระหนักว่าการตัดสินใจดังกล่าวอาจส่งผลต่อคุณดังนี้

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

การอนุญาตให้ใช้สิทธิ

การอนุญาตให้ใช้ซอฟต์แวร์เป็นสิ่งสำคัญในการใช้คลังซอฟต์แวร์ของบุคคลที่สาม ผู้แต่งคลังอาจมอบหมายใบอนุญาตให้กับคลังของตน หากคุณกำลังพิจารณาใช้ไลบรารี ตัวเลือกใบอนุญาตของบริการดังกล่าวอาจส่งผลต่อคุณ

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

หากมีข้อสงสัย โปรดขอคำปรึกษาทางกฎหมายจากผู้เชี่ยวชาญหรือปรึกษาทีมกฎหมายภายในบริษัท

ชุมชน

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

ข้อดี

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

ข้อเสีย

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

เอกสารประกอบ

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

เอกสารประกอบอาจมีโค้ดตัวอย่างด้วย ซึ่งจะช่วยให้คุณเริ่มต้นใช้งานได้ง่ายขึ้น เมื่อประเมินไลบรารีหรือเฟรมเวิร์ก คุณอาจถามคำถามต่อไปนี้ได้

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

เอกสารประกอบอาจไม่สมบูรณ์เสมอไป ซึ่งก็ไม่ใช่เรื่องที่ต้องกังวล คุณจะต้องประเมินความต้องการขององค์กร ข้อกำหนดของโครงการ และความซับซ้อนของซอฟต์แวร์ แล้วใช้ข้อมูลนี้เพื่อระบุระดับของเอกสารที่ต้องใช้

บทสรุป

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

ยังมีแง่มุมอื่นๆ ของไลบรารีและเฟรมเวิร์กที่คุณอาจต้องพิจารณาด้วย ซึ่งไม่ได้กล่าวถึงในบทความนี้มากนัก

• ความสามารถในการขยาย: การขยายไลบรารีด้วยตรรกะและ/หรือลักษณะการทำงานที่กำหนดเองนั้นง่ายเพียงใด
• เครื่องมือ: ไลบรารีมีเครื่องมือ เช่น ปลั๊กอินเครื่องมือแก้ไขโค้ด เครื่องมือแก้ไขข้อบกพร่อง และปลั๊กอินระบบการสร้าง (หากมี) หรือไม่
• สถาปัตยกรรม: โค้ดที่เขียนอย่างสะอาดเป็นสิ่งสำคัญ แต่สถาปัตยกรรมโดยรวมของไลบรารีมีความเหมาะสมหรือไม่
• การทดสอบ: โปรเจ็กต์มีชุดทดสอบไหม เว็บไซต์ของโปรเจ็กต์ใช้ป้ายหรือตัวบ่งชี้ที่ชุดทดสอบผ่านกับคอมมิตล่าสุดหรือไม่
• ความเข้ากันได้: ไลบรารีทำงานได้ดีกับไลบรารีและ/หรือเฟรมเวิร์กอื่นๆ ที่คุณใช้งานอยู่หรือไม่
• ต้นทุน: เฟรมเวิร์กมีต้นทุนเท่าใด ซอฟต์แวร์ดังกล่าวเป็นโอเพนซอร์สหรือมีให้ซื้อ
• เมตริกที่ไม่เกิดประโยชน์: ควรจัดให้อยู่ในลำดับท้ายๆ ของรายการเกณฑ์ หรืออาจละเว้นไปเลย แต่คุณอาจพิจารณา "การโหวต" ของโปรเจ็กต์ บัญชีโซเชียลมีเดียที่แสดงถึงโปรเจ็กต์ และ/หรือจำนวนข้อบกพร่อง/ปัญหาที่ยังไม่ได้รับการแก้ไขในหน้าโปรเจ็กต์