בחירת ספרייה או מסגרת של JavaScript

במאמר הזה נספק תובנות לגבי הבחירה של ספרייה או מסגרת עבודה לשימוש באפליקציית האינטרנט. הדיונים שבמאמר הזה יעזרו לכם לשקול את היתרונות והחסרונות של ספריות או מסגרות JavaScript שונות, כדי למצוא את הספרייה או המסגרת שמתאימים לבעיה העסקית שאתם מנסים לפתור. כדי לבחור מתוך המגוון הרחב של ספריות JavaScript הזמינות, חשוב להבין אילו יתרונות וחסרונות רלוונטיים במצבים שונים.

מהן ספריות ו-frameworks של JavaScript

מהי ספריית JavaScript? בצורתה הפשוטה ביותר, ספריית JavaScript היא קוד שנכתב מראש, שאפשר להפעיל בקוד של הפרויקט כדי לבצע משימה ספציפית.

בפוסט הזה מוזכר בעיקר המונח 'ספריות'. עם זאת, רבים מהדיונים רלוונטיים גם למסגרות (frameworks). באופן כללי, אפשר לסכם את ההבדל בין השניים באופן הבא:

• אם מדובר בספרייה, קוד האפליקציה קורא לקוד הספרייה.
• בשביל framework, ה-framework שולח קריאה לקוד האפליקציה.

הדוגמאות הפרקטיות הבאות עוזרות להמחיש את ההבדלים.

דוגמה לקריאה לספריית JavaScript

ספריית JavaScript מבצעת משימה ספציפית ואז מחזירה את השליטה לאפליקציה. כשאתם משתמשים בספרייה, אתם שולטים בזרימת האפליקציה ומחליטים מתי לקרוא לספרייה.

בדוגמה הבאה, קוד האפליקציה מייבאת שיטה מהספרייה lodash. אחרי שהפונקציה מסתיימת, השליטה מוחזרת לאפליקציה.

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

כשמפעילים את השיטה lodash.capitalize, היא קוראת לקוד JavaScript שנכתב מראש שממיר את התו הראשון במחרוזת לאות רישית.

דוגמה לשימוש ב-JavaScript Framework

מסגרת JavaScript היא תבנית קוד מוגדרת מראש שבתוכה יוצרים את התנהגות האפליקציה. כלומר, כשמשתמשים במסגרת, המסגרת קובעת את תהליך העבודה באפליקציה. כדי להשתמש במסגרת, כותבים את קוד האפליקציה המותאם אישית, ואז המסגרת קוראת לקוד האפליקציה.

בדוגמה הבאה מוצג קטע קוד שמשתמש ב-framework של 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.
• משתמשים בכלים לבדיקת ביצועים כמו Lighthouse כדי לבדוק את ההשפעה של שימוש בספריית JavaScript מסוימת על הביצועים. אם ספרייה מוסיפה עיכוב של שנייה אחת לזמן הטעינה של דף (אל תשכחו לווסות את הרשת והמעבד (CPU) במהלך הבדיקה), ייתכן שתצטרכו לבדוק מחדש את הספרייה שבחרתם. בנוסף לבדיקת טעינת הדף, חשוב ליצור פרופיל של כל התנהגות של דף אינטרנט שמפעילה קוד מהספרייה הרלוונטית – ביצועי טעינת הדף לא מספרים את כל הסיפור.
• אם הבעלים של הספרייה מקבלים תגובות, אתם יכולים לשלוח את התצפיות שלכם לגבי הביצועים, הצעות ואפילו תרומות לפרויקט. כאן קהילת הקוד הפתוח פורחת! אם תחליטו לתרום, יכול להיות שתצטרכו לבדוק קודם עם המעסיק שלכם.
• השתמשו בכלי אוטומטי למעקב אחר חבילות, כמו bundlesize, כדי לבדוק אם יש עדכונים גדולים באופן בלתי צפוי בספרייה. ספריית JavaScript גדלה עם הזמן. הוספות של תכונות, תיקוני באגים, נרתיקי קצה ואחרים יכולים להגדיל את גודל הקובץ של ספרייה. אחרי שאתם או הצוות שלכם תסכימו להשתמש בספרייה, עדכון הספרייה עשוי להיות פחות בעייתי ויכול לעורר מעט שאלות או אף לא לעורר שאלות בכלל. כאן כדאי להסתמך על אוטומציה.
• כדאי לבדוק את הדרישות שלכם לספרייה ולבחון אם פלטפורמת האינטרנט מציעה את אותה פונקציונליות באופן מקורי. לדוגמה, פלטפורמת האינטרנט כבר מציעה בורר צבעים, כך שאין צורך להשתמש בספריית JavaScript של צד שלישי כדי להטמיע את אותה פונקציונליות.

אבטחה

שימוש במודול של צד שלישי כרוך בכמה סיכוני אבטחה מובנים. חבילה זדונית בקוד של אפליקציית האינטרנט עלולה לסכן את האבטחה של צוות הפיתוח ושל המשתמשים.

נניח שספרייה מסוימת פורסמה בסביבה העסקית של NPM. יכול להיות שחבילה כזו היא לגיטימית. עם זאת, לאורך זמן החבילה עלולה להיחשף לפריצה.

ריכזנו כאן כמה טיפים לאבטחה שכדאי להביא בחשבון כשמשתמשים בקוד של צד שלישי או כשבודקים אותו:

• אם אתם משתמשים ב-GitHub, כדאי לשקול את הצעות האבטחה של הקוד, כמו Dependabot. לחלופין, אפשר להשתמש בשירותים חלופיים שמאתרים נקודות חולשה בקוד, כמו snyk.io.
• כדאי להשתמש בשירותי ביקורת קוד, צוות של מהנדסים שיכול לבדוק באופן ידני את הקוד של הצד השלישי שבו אתם משתמשים.
• כדאי להעריך אם כדאי לנעול את יחסי התלות לגרסה ספציפית, או לבצע התחייבות (commit) לקוד של הצד השלישי במערכת בקרת הגרסאות. כך תוכלו לנעול את התלות בגרסה מסוימת – כנראה גרסה שנחשבת בטוחה. באופן אירוני, יכול להיות לכך אפקט הפוך מבחינת אבטחה, כי יכול להיות שתפספסו עדכונים חיוניים לספרייה.
• בודקים את דף הבית של הפרויקט או את דף GitHub שלו, אם קיים כזה. כדאי לבדוק אם יש בעיות אבטחה לא מטופלות, ואם בעיות אבטחה קודמות טופלו במסגרת זמן סבירה.
• קוד של צד שלישי שמשתמש בקוד של צד שלישי אחר עלול להיות מסוכן יותר מאשר ספרייה עם אפס יחסי תלות. חשוב לשים לב לסיכון הזה.

נגישות

ייתכן שתהיתם את הקשר בין ספריות תוכנה לנגישות באינטרנט. אפשר להשתמש בספריית תוכנה בסביבות שונות, אבל בהקשר של ספרייה מבוססת-JavaScript בצד הלקוח, נגישות האינטרנט היא חשובה מאוד.

ספרייה מבוססת-JavaScript (או מסגרת, באותו עניין) בצד הלקוח יכולה לשפר או לפגוע בנגישות של האתר. נבחן ספריית JavaScript של צד שלישי שמוסיפה פס הזזה של תמונה לדף. אם פס ההזזה של התמונות לא מאפשר גישה לאינטרנט, אתם, כמפתחי האתר, עלולים להתעלם מתכונה חשובה כל כך ולהוציא מוצר בלי תכונות קריטיות, כמו אפשרות לנווט בפס ההזזה באמצעות מקלדת.

• האם הפלאגין של הגופנים התואמים לתצוגה במכשירים שונים תומך במשתמשים שמגדילים או מצמצמים את התצוגה של הדף?
• האם הפלאגין להעלאת קבצים תומך בהעלאת קבצים ממכשירים מסייעים?
• האם ספריית האנימציות מספקת תמיכה למשתמשים שמעדיפים תנועה מופחתת?
• האם הפלאגין של המפות האינטראקטיביות תומך בשימוש במקלדת בלבד?
• האם בספריית נגן האודיו יש חוויה מתאימה בקוראי מסך?

סביר להניח שתצטרכו, כמפתחי אתרים, להיות מעורבים ברמה מסוימת כדי לעמוד בדרישות הנגישות האלה. לדוגמה:

• אם חסרות תכונות מסוימות, תוכלו להטמיע אותן בקוד שלכם, גם אם תמשיכו להשתמש בספרייה הרלוונטית.
• בעזרת תמיכת המעסיק שלך, יש לך אפשרות להוסיף תכונה חסרה כל כך לספרייה, אם מחבר הספרייה מאפשר תרומה כזו.
• אתם יכולים לפתוח שיחה עם מחבר הספרייה. לדוגמה, האם תכונות הנגישות הספציפיות האלה נכללות בתוכנית העבודה שלכם? האם לדעתך הם שייכים לספרייה?
• בתרחישי שימוש נפוצים, תוכלו לבחון ספריות חלופיות, נגישות יותר. ייתכן שהן קיימות, אבל קשה יותר למצוא אותן.
• במקרה קיצוני, יכול להיות שתצטרכו להפסיק להשתמש בספרייה לגמרי ולהטמיע את התכונות שלכם מחדש. זה יכול לקרות כשספרייה או מסגרת עבודה מציעות חוויית נגישות ירודה בשימוש הראשוני, ואתם צריכים לבטל הרבה מהדברים שהספרייה או המסגרת העבודה אמורים לספק בחינם.

כנסים

קל יותר לעבוד עם ספריית תוכנה שמשתמשת במוסכמות קוד מקובלות. אם בספרייה נעשה שימוש במוסכמות תכנות שלא נשמעות עליה, יכול להיות שיהיה לכם ולצוות שלכם יהיה קשה לעבוד עם ספרייה כזו.

אם הספרייה לא פועלת לפי מוסכמות תכנות נפוצות (לדוגמה, מדריך סגנון נפוץ), אין הרבה מה לעשות כדי לפתור את הבעיה באופן מיידי. עם זאת, עדיין יש כמה אפשרויות:

• חשוב להבחין בין קוד המקור של הספרייה לבין ה-API שגלוי לכם, משתמש הספרייה. קוד המקור הפנימי עשוי אמנם לפעול לפי מוסכמות לא מוכרות, אבל אם ה-API (החלק בספרייה שאיתם אתם יוצרים אינטראקציה) משתמש המוסכמות מוכרות, יכול להיות שאין סיבה לדאגה.
• אם ממשק ה-API של הספרייה לא פועל לפי מוסכמות תכנות נפוצות, אפשר להשתמש בתבנית עיצוב של JavaScript, כמו תבנית proxy, כדי להכיל את כל האינטראקציות עם הספרייה בקובץ יחיד בקוד. לאחר מכן שרת ה-proxy יוכל להציע ממשק API אינטואיטיבי יותר לחלקים אחרים בקוד בתוך קוד המקור.

לכנסים יש תפקיד חשוב וקלות השימוש. ספרייה שכוללת ממשק API אינטואיטיבי יכולה לחסוך שעות רבות של עבודה, ואפילו ימים של עבודה, בהשוואה לממשק API לא אינטואיטיבי שצריך לבצע בו הרבה ניסויים כדי להבין אותו.

עדכונים

לדוגמה, בספרייה שפועלת באופן מלא ומבצעת כמה חישובים מתמטיים, יכול להיות שבספרייה כזו יהיה צורך בעדכונים רק לעיתים רחוקות. למעשה, ספרייה עם כל התכונות הנדרשות היא מציאה נדירה בעולם המשתנה של פיתוח האינטרנט. עם זאת, יש מקרים שבהם תרצו שהמחבר של הספרייה יהיה זמין וישמח לבצע עדכונים. מחקר וממצאים חדשים יכולים לחשוף דרכים טובות יותר לעשות דברים, לכן הטכניקות שבהן משתמשים בספריות ובמסגרות תמיד כפופות לשינויים.

כשאתם בוחרים ספרייה או מסגרת, חשוב לשים לב לאופן שבו העדכונים מטופלים, ולהבין שהחלטות כאלה יכולות להשפיע עליכם:

• האם לספרייה יש לוח זמנים הגיוני לפרסום גרסאות? לדוגמה, יכול להיות שיהיו עדכונים למאגר קוד המקור בתדירות גבוהה, אבל אם העדכונים האלה לא 'יפורסמו' או 'ישוחררו' בהתאם, יכול להיות שיהיה קשה להוריד אותם.
• האם הספרייה מפרסמת עדכונים עם סכימה הגיונית למתן שמות לגרסאות תוכנה? הספרייה אמורה לחסוך לכם זמן. אם תצטרכו לשנות את הקוד באופן בלתי צפוי בכל פעם שתעדכנו את גרסת הספרייה, יכול להיות שהשימוש בספרייה הזו לא יהיה מוצדק מלכתחילה. לפעמים שינויי תוכנה שעלולים לגרום לכשלים הם בלתי נמנעים, אבל בעולם אידיאלי, שינויים מתרחשים לעיתים רחוקות ולא מאולצים את צרכני הספרייה.
• האם הספרייה משקיעה מאמצים כדי להשיג תאימות לאחור? לפעמים עדכוני תוכנה יכולים לכלול שינויי תוכנה שעלולים לגרום לכשלים, אבל הם גם מספקים שכבה של תאימות לאחור. כך צרכן הספרייה יכול להשתמש בגרסת הספרייה העדכנית ביותר עם שינויים קלים בקוד.

רישוי

רישוי תוכנה הוא היבט חשוב בשימוש בספריות תוכנה של צד שלישי. מחבר הספרייה יכול להקצות רישיון לספרייה שלו. אם אתם שוקלים להשתמש בספרייה, בחירת הרישיון של היוצרים עשויה להשפיע עליכם.

לדוגמה, יכול להיות שלספריית JavaScript יש רישיון תוכנה שמאפשר להשתמש בה בסביבה לא מסחרית. אם זה פרויקט תחביב אישי, זו יכולה להיות בחירה מצוינת. אם הפרויקט שלך כולל רכיב מסחרי, ייתכן שיהיה עליך לשקול רישיון לארגון.

אם יש לכם ספק, כדאי לפנות לייעוץ משפטי מקצועי או לפנות לצוות המשפטי בחברה שלכם.

קהילה

ספרייה או מסגרת עם קהילה גדולה של משתמשים או שותפים יכולות להיות מועילות, אבל זה לא מובטח. באופן כללי, ככל שיש יותר משתמשים בספרייה או במסגרת, כך יש סיכוי גבוה יותר שהם ייהנו מהיתרונות. כדאי להביא בחשבון את היתרונות והחסרונות הבאים של ההשתתפות בקהילה של מפתחים:

יתרונות:

• בסיס משתמשים גדול עשוי להגדיל את הסיכוי לזהות באגים בשלב מוקדם ובתדירות גבוהה יותר.
• קהילה גדולה ופעילה יכולה לספק יותר מדריכים, מדריכים מפורטים, סרטונים ואפילו קורסים בנושא הספרייה או המסגרת הרלוונטית.
• קהילה גדולה ופעילה יכולה לספק תמיכה רבה יותר בפורומים ובאתרים של שאלות ותשובות, וכך להגדיל את הסבירות לקבלת תשובות לשאלות התמיכה.
• המשמעות של קהילה מעורבת יכולה להיות תורמים חיצוניים יותר לספרייה או למסגרת. הם יכולים לעזור לספק תכונות שאחרת לא מופיעות בתוכנית של המחבר.
• כשספרייה או מסגרת פופולריות בקהילה, סביר יותר שקולגות ועמיתים שלכם שמעו עליהם או אפילו מכירים אותם.

חסרונות:

• פרויקט עם בסיס משתמשים גדול ומגוון עלול להתנפח בגלל הוספת תכונות באופן קבוע. ספריות מתנפחות עלולות לפגוע בביצועים באינטרנט.
• פרויקט עם קהילה פעילה ומעורבת יכול להיות מלחיץ עבור המחברים והמפתחים, ויכול להיות שיידרש בו ניהול קהילה נרחב.
• פרויקט שגדל במהירות, אך לא מקבל את התמיכה המתאימה, יכול להתחיל להראות סימנים של קהילה רעילה. לדוגמה, מפתחי אינטרנט מתחילים או בתחילת הקריירה עלולים להרגיש לא רצויים בקהילה מסוימת בגלל gatekeeping.

מאמרי עזרה

מסמכי תוכנה תמיד יכולים לעזור, גם אם הספרייה או ה-framework של JavaScript יהיו פשוטים או מורכבים. גם מפתחים מנוסים מאוד משתמשים במסמכי תיעוד, במקום לנסות להבין את הקוד בעצמם. במסמכי התיעוד מוסבר איזה ממשק API כדאי להשתמש בו ואיך משתמשים בו.

במסמכי התיעוד יכולים להופיע גם קוד לדוגמה, שיעזור לכם להתחיל לעבוד מהר יותר. כשאתם בודקים ספרייה או framework, אפשר לשאול כמה מהשאלות הבאות:

• האם הספרייה כוללת מסמכי עזר? אם לא, תצטרכו להבין את הדברים בעצמכם.
• האם המסמכים ברורים, קל להבין אותם והם לא מעורפלים? מפתחים רבים משקיעים הרבה זמן במסמכים. זה אולי נראה כמו פרט קטן, אבל הבהירות במסמכים הטקסטואליים יכולה להשפיע מאוד על הפרודוקטיביות שלכם.
• האם התיעוד נוצר באופן אוטומטי לחלוטין? תיעוד כזה יכול להיות קשה יותר לעיכול, ולא תמיד הוא מספק הנחיות ברורות לשימוש ב-API.
• האם התיעוד עדכני? לפעמים תחזוקת מסמכים נחשבת כמחשבה. אם הספרייה מעודכנת אבל המסמכים לא, זה עלול לגרום לבזבוז זמן הפיתוח.
• האם התיעוד מקיף וזמין בכמה פורמטים? מדריכים למשתמש, קוד לדוגמה, מאמרי עזרה, הדגמות בזמן אמת ומדריכים הם כולם פורמטים חשובים של תיעוד שיכולים לעזור לכם להצליח בשימוש בספרייה או ב-framework.

לא תמיד אפשר להכין מסמכי עזרה מלאים, וזה בסדר. עליכם להעריך את הצרכים של הארגון, את דרישות הפרויקט ואת המורכבות של התוכנה, ולהשתמש בנתונים האלה כדי לקבוע את רמת התיעוד הנדרשת.

סיכום

מבוכה כשאתם בוחרים ספרייה או מסגרת בפעם הראשונה? כמו בכל דבר אחר, ככל שתלמדו ותתרגלו משימה מסוימת, כך תשתפרו בה. כדאי להיעזר במאמר הזה בפעם הבאה שתבחרו ספרייה או מסגרת עבודה לשימוש. אפשר להשתמש בכותרות שבפוסט הזה כרשימת משימות. לדוגמה: האם הביצועים של הספרייה הזו טובים? האם הספרייה הזו עומדת בסטנדרטים העסקיים שלי לנגישות באינטרנט?

יש היבטים נוספים של ספריות ותבניות שיכול להיות שתרצו להביא בחשבון, ולא הרחבנו עליהם במאמר הזה:

• יכולת ההרחבה: כמה קל להרחיב את הספרייה באמצעות לוגיקה או התנהגות מותאמים אישית?
• כלים: אם רלוונטי, האם בספרייה יש כלים כמו פלאגינים של עורכי קוד, כלים לניפוי באגים ופלאגינים של מערכת build?
• ארכיטקטורה: קוד נקי חשוב, אבל האם הארכיטקטורה הכוללת של הספרייה הגיונית?
• בדיקות: האם לפרויקט יש חבילת בדיקות? האם באתר הפרויקט יש תגים או אינדיקטורים שחבילת הבדיקות מעבירה את ההתחייבות האחרונה?
• תאימות: האם הספרייה פועלת היטב עם ספריות אחרות או frameworks אחרות שאתם משתמשים בהן כרגע?
• עלות: מה העלות של מסגרת? האם הקוד פתוח או זמין לרכישה?
• מדדים של התאמה אישית: הם צריכים להיות נמוכים יותר ברשימת הקריטריונים, או אפילו להתעלם לגמרי, אבל כדאי לשקול את האפשרות 'הצבעות' בפרויקט, חשבונות ברשתות חברתיות שמייצגים את הפרויקט ו/או כמה באגים/בעיות פתוחים יש בדף הפרויקט.