במאמר הזה נספק תובנות שיעזרו לכם לבחור ספרייה או מסגרת עבודה לשימוש באפליקציית האינטרנט שלכם. הדיונים שבמאמר הזה יעזרו לכם לשקול את היתרונות והחסרונות של ספריות או מסגרות JavaScript שונות, כדי למצוא את הספרייה או המסגרת שמתאימים לבעיה העסקית שאתם מנסים לפתור. כדי לבחור מתוך המגוון הרחב של ספריות JavaScript הזמינות, חשוב להבין אילו יתרונות וחסרונות רלוונטיים במצבים שונים.
מהן ספריות ו-frameworks של JavaScript
מהי ספריית JavaScript? בצורתה הפשוטה ביותר, ספריית JavaScript היא קוד שנכתב מראש, שאפשר להפעיל בקוד של הפרויקט כדי לבצע משימה ספציפית.
בפוסט הזה מוזכר בעיקר המונח 'ספריות'. עם זאת, הרבה מהדיונים רלוונטיים גם למסגרות. באופן כללי, אפשר לסכם את ההבדל בין השניים באופן הבא:
- בספרייה, קוד האפליקציה קורא לקוד הספרייה.
- כשמשתמשים ב-framework, קוד האפליקציה נקרא על ידי ה-framework.
הדוגמאות הפרקטיות הבאות עוזרות להמחיש את ההבדלים.
דוגמה לקריאה לספריית JavaScript
ספריית JavaScript מבצעת משימה ספציפית ואז מחזירה את השליטה לאפליקציה. כשמשתמשים בספרייה, אתם שולטים בתהליך האפליקציה ובוחרים מתי להפעיל את הספרייה.
בדוגמה הבאה, קוד האפליקציה מייבא שיטה מספריית lodash. בסיום הפונקציה, השליטה מוחזרת לאפליקציה.
import capitalize from 'lodash.capitalize';
capitalize('hello'); // Hello
כשמפעילים את השיטה lodash.capitalize
, היא קוראת לקוד JavaScript שנכתב מראש שממיר את התו הראשון במחרוזת לאות רישית.
דוגמה לשימוש ב-JavaScript Framework
מסגרת 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. - משתמשים בכלים לבדיקת ביצועים כמו Lighthouse כדי לבדוק את ההשפעה של שימוש בספריית JavaScript מסוימת על הביצועים. אם ספרייה מסוימת מוסיפה עיכוב של שנייה אחת לזמן הטעינה של הדף (אל תשכחו להגביל את הרשת ואת המעבד במהלך הבדיקה), יכול להיות שתצטרכו לבחון מחדש את הספרייה שבחרתם. בנוסף לבדיקת טעינת הדף, חשוב ליצור פרופיל של כל התנהגות של דף אינטרנט שמפעילה קוד מהספרייה הרלוונטית – ביצועי טעינת הדף לא מספרים את כל הסיפור.
- אם הבעלים של הספרייה מקבלים תגובות, אפשר לשלוח תגובות, הצעות ואפילו תרומות לפרויקט. כאן קהילת הקוד הפתוח פורחת! אם תחליטו לתרום, יכול להיות שתצטרכו לבדוק קודם עם המעסיק שלכם.
- השתמשו בכלי אוטומטי למעקב אחר חבילות, כמו bundlesize, כדי לבדוק אם יש עדכונים גדולים באופן בלתי צפוי בספרייה. בדרך כלל, ספריית JavaScript גדלה עם הזמן. הוספת תכונות, תיקון באגים, מקרים קיצוניים ועוד יכולים להגדיל את גודל הקובץ של הספרייה. אחרי שאתם או הצוות שלכם תסכימו להשתמש בספרייה, עדכון הספרייה עשוי להיות פחות בעייתי ויכול לעורר מעט שאלות או אף לא לעורר שאלות בכלל. כאן כדאי להסתמך על אוטומציה.
- כדאי לבדוק את הדרישות שלכם לספרייה ולבחון אם פלטפורמת האינטרנט מציעה את אותה פונקציונליות באופן מקורי. לדוגמה, פלטפורמת האינטרנט כבר מציעה בורר צבעים, כך שאין צורך להשתמש בספריית JavaScript של צד שלישי כדי להטמיע את אותה פונקציונליות.
אבטחה
שימוש במודול של צד שלישי כרוך בסיכוני אבטחה מובנים. חבילה זדונית בקוד של אפליקציית האינטרנט עלולה לסכן את האבטחה של צוות הפיתוח ושל המשתמשים.
נניח שספרייה מסוימת פורסמה בסביבה העסקית של NPM. יכול להיות שחבילה כזו היא לגיטימית. עם זאת, לאורך זמן, החבילה עלולה להיחשף לפריצה.
ריכזנו כאן כמה טיפים לאבטחה שכדאי להביא בחשבון כשמשתמשים בקוד של צד שלישי או כשבודקים אותו:
- אם אתם משתמשים ב-GitHub, כדאי להשתמש בחבילות השירות לאבטחת הקוד, כמו Dependabot. לחלופין, אפשר להשתמש בשירותים חלופיים שמאתרים נקודות חולשה בקוד, כמו snyk.io.
- כדאי להשתמש בשירותי ביקורת קוד, צוות של מהנדסים שיכולים לבדוק באופן ידני את הקוד של הצד השלישי שבו אתם משתמשים.
- כדאי להעריך אם כדאי לנעול את יחסי התלות לגרסה ספציפית, או לבצע התחייבות לקוד של הצד השלישי במערכת בקרת הגרסאות. כך תוכלו לנעול את התלות בגרסה מסוימת – כנראה גרסה שנחשבת בטוחה. באופן אירוני, יכול להיות לכך אפקט הפוך מבחינת אבטחה, כי יכול להיות שתפספסו עדכונים חיוניים לספרייה.
- בודקים את דף הבית של הפרויקט או את דף GitHub שלו, אם יש כזה. כדאי לבדוק אם יש בעיות אבטחה לא מטופלות, ואם בעיות אבטחה קודמות טופלו במסגרת זמן סבירה.
- קוד של צד שלישי שמשתמש בקוד של צד שלישי אחר עלול להיות מסוכן יותר מאשר ספרייה עם אפס יחסי תלות. חשוב לזכור את הסיכון הזה.
נגישות
יכול להיות שאתם תוהים איך ספריות תוכנה קשורות לנגישות באינטרנט. אפשר להשתמש בספריית תוכנה בסביבות שונות, אבל בהקשר של ספרייה מבוססת-JavaScript בצד הלקוח, נגישות האינטרנט היא חשובה מאוד.
ספרייה מבוססת-JavaScript (או מסגרת, באותו עניין) בצד הלקוח יכולה להגדיל או להקטין את הנגישות של האתר. לדוגמה, ספריית JavaScript של צד שלישי שמוסיפה לדף פס גלילה של תמונות. אם פס ההזזה של התמונות לא מאפשר גישה לאינטרנט, אתם, כמפתחי האתר, עלולים להתעלם מתכונה חשובה כל כך ולהוציא מוצר בלי תכונות קריטיות, כמו פס הזזה שניתן לנווט בו באמצעות מקלדת.
- האם הפלאגין של הגופנים התואמים לתצוגה במכשירים שונים תומך במשתמשים שמגדילים או מצמצמים את התצוגה של הדף?
- האם הפלאגין להעלאת קבצים תומך בהעלאת קבצים ממכשירים מסייעים?
- האם ספריית האנימציה מספקת תמיכה למשתמשים שמעדיפים תנועה מופחתת?
- האם הפלאגין של המפות האינטראקטיביות תומך בשימוש במקלדת בלבד?
- האם ספריית נגן האודיו מספקת חוויה מתאימה בקוראי מסך?
סביר להניח שתצטרכו, כמפתחי אתרים, להיות מעורבים ברמה מסוימת כדי לעמוד בדרישות הנגישות האלה. לדוגמה:
- אם חסרות תכונות מסוימות, תוכלו להטמיע אותן בקוד שלכם, גם אם תמשיכו להשתמש בספרייה הרלוונטית.
- עם תמיכה של המעסיק, תוכלו לתרום תכונה חסרה כזו לספרייה, אם מחבר הספרייה מאפשר תרומה כזו.
- אתם יכולים לפתוח שיחה עם מחבר הספרייה. לדוגמה, האם תכונות הנגישות הספציפיות האלה נכללות בתוכנית העבודה שלכם? האם לדעתך הם שייכים לספרייה?
- בתרחישי שימוש פופולריים, אפשר לבדוק אפשרויות ספרייה חלופיות שנגישות יותר. יכול להיות שהן קיימות, אבל קשה יותר למצוא אותן.
- במקרה קיצוני, יכול להיות שתצטרכו להפסיק להשתמש בספרייה לגמרי ולהטמיע את התכונות שלכם מהתחלה. זה יכול לקרות כשחוויית הנגישות בספרייה או במסגרת ירודה בשימוש הראשוני, ואתם צריכים לבטל הרבה מהדברים שהספרייה או המסגרת אמורים לספק לכם בחינם.
כנסים
קל יותר לעבוד עם ספריית תוכנה שמשתמשת במוסכמות קוד מקובלות. אם בספרייה נעשה שימוש במסורת תכנות לא מוכרת, יכול להיות שיהיה לכם ולצוות שלכם קשה לעבוד עם ספרייה כזו.
אם ספרייה לא פועלת בהתאם למוסכמות קוד נפוצות (לדוגמה, מדריך סגנון נפוץ), אין הרבה שאפשר לעשות בתור תיקון מיידי. עם זאת, עדיין יש כמה אפשרויות:
- חשוב להבדיל בין קוד המקור של הספרייה לבין ממשק ה-API שחשוף לכם, משתמשי הספרייה. יכול להיות שקוד המקור הפנימי יכלול מוסכמות לא מוכרות, אבל אם ב-API (החלק בספרייה שאיתו אתם מקיימים אינטראקציה) נעשה שימוש במוסכמות מוכרות, יכול להיות שאין מה לדאוג.
- אם ממשק ה-API של הספרייה לא עומד במסורות תכנות נפוצות, אפשר להשתמש בתבנית עיצוב של JavaScript, כמו תבנית proxy, כדי להכיל את כל האינטראקציות עם הספרייה בקובץ יחיד בקוד. לאחר מכן שרת ה-proxy יוכל להציע ממשק API אינטואיטיבי יותר לחלקים אחרים בקוד בתוך קוד המקור.
מוסכמות משחקות תפקיד חשוב בקלות השימוש. ספרייה שכוללת ממשק API אינטואיטיבי יכולה לחסוך שעות רבות של עבודה, ואפילו ימים של עבודה, בהשוואה לממשק API לא אינטואיטיבי שצריך לבצע בו הרבה ניסויים כדי להבין אותו.
עדכונים
לדוגמה, בספרייה שפועלת באופן מלא ומבצעת כמה חישובים מתמטיים, יכול להיות שיהיה צורך בעדכונים לספרייה הזו רק לעיתים רחוקות. למעשה, ספרייה עם כל התכונות היא מציאה נדירה בעולם המשתנה של פיתוח האינטרנט. עם זאת, יש מקרים שבהם תרצו שהמחבר של הספרייה יהיה זמין וישמח לבצע עדכונים. מחקרים ותובנות חדשות יכולים לחשוף דרכים טובות יותר לעשות דברים, ולכן השיטות שבהן נעשה שימוש בספריות ובמסגרות תמיד עשויות להשתנות.
כשאתם בוחרים ספרייה או מסגרת, חשוב לשים לב לאופן שבו העדכונים מטופלים, ולהבין שההחלטות האלה יכולות להשפיע עליכם:
- האם לספרייה יש לוח זמנים הגיוני להפצה? לדוגמה, יכול להיות שיהיו עדכונים למאגר של קוד המקור בתדירות גבוהה, אבל אם העדכונים האלה לא 'יפורסמו' או 'ישוחררו' בהתאם, יכול להיות שיהיה קשה להוריד אותם.
- האם הספרייה מפרסמת עדכונים עם סכימה הגיונית למתן שמות לגרסאות תוכנה? הספרייה אמורה לחסוך לכם זמן. אם תצטרכו לשנות את הקוד באופן בלתי צפוי בכל פעם שתעדכנו את גרסת הספרייה, יכול להיות שהשימוש בספרייה הזו לא יהיה מוצדק מלכתחילה. לפעמים אי אפשר להימנע משינויים משמעותיים, אבל בעולם אידיאלי, השינויים מתרחשים לעיתים רחוקות ולא מאלצים את צרכני הספרייה לבצע אותם.
- האם הספרייה משקיעה מאמצים בתאימות לאחור? לפעמים עדכוני תוכנה כוללים שינויים משמעותיים, אבל הם גם מספקים שכבת תאימות לאחור. כך צרכן הספרייה יכול להשתמש בגרסה העדכנית ביותר של הספרייה עם שינויים מינימליים בקוד שלו.
רישוי
רישוי תוכנה הוא היבט חשוב בשימוש בספריות תוכנה של צד שלישי. מחבר הספרייה יכול להקצות רישיון לספרייה שלו. אם אתם שוקלים להשתמש בספרייה, בחירת הרישיון של היוצרים עשויה להשפיע עליכם.
לדוגמה, יכול להיות שלספריית JavaScript יש רישיון תוכנה שמאפשר להשתמש בה בסביבה לא מסחרית. זו יכולה להיות בחירה מצוינת לפרויקט אישי לצורכי פנאי. אם לפרויקט שלכם יש רכיב מסחרי, יכול להיות שתצטרכו לשקול רישיון לארגון.
אם אתם לא בטוחים, מומלץ לפנות לייעוץ משפטי מקצועי או להתייעץ עם הצוות המשפטי בחברה.
קהילה
ספרייה או מסגרת עם קהילה גדולה של משתמשים או שותפים יכולות להיות מועילות, אבל זה לא מובטח. באופן כללי, ככל שיש יותר משתמשים בספרייה או במסגרת, כך יש סיכוי גבוה יותר שהם ייהנו מהם. כדאי להביא בחשבון את היתרונות והחסרונות הבאים של ההשתתפות בקהילה של מפתחים:
יתרונות:
- בסיס משתמשים גדול עשוי להגדיל את הסיכוי לזהות באגים בשלב מוקדם ובתדירות גבוהה יותר.
- קהילה גדולה ופעילה יכולה לספק יותר מדריכים, מדריכים מפורטים, סרטונים ואפילו קורסים בנושא הספרייה או המסגרת הרלוונטית.
- קהילה גדולה ופעילה יכולה לספק תמיכה רבה יותר בפורומים ובאתרים של שאלות ותשובות, וכך להגדיל את הסבירות לקבלת תשובות לשאלות תמיכה.
- קהילה פעילה יכולה להביא ליותר שותפים חיצוניים לספרייה או למסגרת. הם יכולים לעזור לכם להוסיף תכונות שלא נכללות בתוכנית העבודה של המחבר.
- כשספרייה או מסגרת פופולריות בקהילה, סביר יותר שקולגות ועמיתים שלכם שמעו עליהם או אפילו מכירים אותם.
חסרונות:
- פרויקט עם בסיס משתמשים גדול ומגוון עלול להתנפח בגלל הוספת תכונות באופן קבוע. ספריות גדולות מדי עלולות לפגוע בביצועים של האתר.
- פרויקט עם קהילה פעילה ומעורבת יכול להיות מלחיץ עבור המחברים והמפתחים, ויכול להיות שיידרש ניהול קהילה משמעותי.
- אם פרויקט גדל במהירות אבל אין לו את התמיכה המתאימה, יכול להיות שיתחילו להופיע בו סימנים לכך שיש לו קהילה רעילה. לדוגמה, מפתחי אינטרנט מתחילים או בתחילת הקריירה עשויים להרגיש לא רצויים בקהילה מסוימת בגלל gatekeeping.
מאמרי עזרה
לא משנה כמה ספרייה או מסגרת של JavaScript פשוטות או מורכבות, מסמכי התיעוד של התוכנה תמיד יכולים לעזור. גם מפתחים מנוסים מאוד משתמשים במסמכי תיעוד, במקום לנסות להבין את הקוד בעצמם. במסמכי התיעוד מוסבר איזה ממשק API כדאי להשתמש בו ואיך משתמשים בו.
במסמכי התיעוד יכולים להופיע גם קוד לדוגמה, שיעזור לכם להתחיל לעבוד מהר יותר. כשבודקים ספרייה או מסגרת, אפשר לשאול כמה מהשאלות הבאות:
- האם הספרייה כוללת מסמכי עזר? אם לא, תצטרכו להבין את הדברים בעצמכם.
- האם המסמכים ברורים, קל להבין אותם והם לא מעורפלים? מפתחים רבים משקיעים זמן רב בתיעוד. זה אולי נראה כמו פרט קטן, אבל הבהירות במסמכים הטקסטואליים יכולה להשפיע מאוד על הפרודוקטיביות שלכם.
- האם התיעוד נוצר באופן אוטומטי לחלוטין? תיעוד כזה יכול להיות קשה יותר לעיכול, ולא תמיד הוא מספק הנחיות ברורות לשימוש ב-API.
- האם התיעוד עדכני? לפעמים התחזוקה של המסמכים נחשבת לעניין משני. אם הספרייה מעודכנת אבל המסמכים לא, זה עלול לגרום לבזבוז זמן הפיתוח.
- האם מסמכי התיעוד מקיפים וזמינים במספר פורמטים? מדריכים למשתמש, קוד לדוגמה, מסמכי עזר, הדגמות בזמן אמת ומדריכים הם פורמטים חשובים של מסמכי עזר שיכולים לעזור לכם להשתמש בספרייה או במסגרת בצורה יעילה.
לא תמיד אפשר להכין מסמכי עזרה מלאים, וזה בסדר. עליכם להעריך את הצרכים של הארגון, את דרישות הפרויקט ואת המורכבות של התוכנה, ולהשתמש בנתונים האלה כדי לקבוע את רמת התיעוד הנדרשת.
סיכום
זה טבעי להרגיש מוצפים כשבוחרים ספרייה או מסגרת בפעם הראשונה. כמו בכל דבר אחר, ככל שתלמדו ותתרגלו משימה מסוימת, כך תשתפרו בה. כדאי להיעזר במאמר הזה בפעם הבאה שתבחרו ספרייה או מסגרת עבודה לשימוש. אפשר להשתמש בכותרות שבפוסט הזה כרשימת משימות. לדוגמה: האם הביצועים של הספרייה הזו טובים? האם הספרייה הזו עומדת בתקני הנגישות לאינטרנט של העסק שלי?
יש היבטים נוספים של ספריות ותבניות שיכול להיות שתרצו להביא בחשבון, ולא התייחסנו אליהם בהרחבה במאמר הזה:
- יכולת ההרחבה: כמה קל להרחיב את הספרייה באמצעות לוגיקה או התנהגות מותאמים אישית?
- כלים: אם רלוונטי, האם בספרייה יש כלים כמו פלאגינים של עורכי קוד, כלים לניפוי באגים ופלאגינים של מערכת build?
- ארכיטקטורה: קוד נקי חשוב, אבל האם הארכיטקטורה הכוללת של הספרייה הגיונית?
- בדיקות: האם לפרויקט יש חבילת בדיקות? האם באתר הפרויקט נעשה שימוש בתגים או בסמנים שמציינים ש-suite הבדיקה עובר את הבדיקה מול ה-commit האחרון?
- תאימות: האם הספרייה פועלת היטב עם ספריות או מסגרות אחרות שבהן אתם משתמשים כרגע?
- עלות: מה העלות של מסגרת? האם הקוד פתוח או זמין לרכישה?
- מדדים פופולריים: כדאי להציב את המדדים האלה בתחתית רשימת הקריטריונים, או אפילו להתעלם מהם לגמרי. עם זאת, כדאי להביא בחשבון את מספר 'הצבעות' בפרויקט, את חשבונות הרשתות החברתיות שמייצגים את הפרויקט ו/או את מספר הבאגים או הבעיות הפתוחות בדף הפרויקט.