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

ความปลอดภัย

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

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

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

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

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

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

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

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

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

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

การประชุม

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

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

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

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

การอัปเดต

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

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

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

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

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

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

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

การมีส่วนร่วม

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

ข้อดี

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

ข้อเสีย

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

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

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

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

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

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

บทสรุป

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

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

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