במאמר הזה נסביר איך לבחור ספרייה או מסגרת לשימוש באפליקציית האינטרנט שלכם. הדיונים כאן יעזרו לכם לשקול את היתרונות והחסרונות של כל ספרייה או מסגרת של JavaScript, כדי למצוא את הספרייה או המסגרת שמתאימה לבעיה העסקית שאתם מנסים לפתור. כדי לבחור מבין המספר הגדול של ספריות JavaScript שזמינות, חשוב להבין אילו יתרונות וחסרונות רלוונטיים למצבים שונים.
מהן ספריות וסביבות עבודה של JavaScript
מהי ספריית JavaScript? בצורה הכי פשוטה, ספריית JavaScript היא קוד שנכתב מראש שאפשר להפעיל בקוד של הפרויקט כדי לבצע משימה ספציפית.
הפוסט הזה מתייחס בעיקר ל "ספריות". עם זאת, הרבה מהדיונים רלוונטיים גם למסגרות. אפשר לסכם את ההבדל בין שני סוגי הנתונים באופן הבא:
- בספרייה, קוד האפליקציה קורא לקוד הספרייה.
- ב-framework, קוד האפליקציה נקרא על ידי ה-framework.
הדוגמאות המעשיות הבאות ממחישות את ההבדלים.
דוגמה לקריאה לספריית JavaScript
ספריית JavaScript מבצעת משימה ספציפית ואז מחזירה את השליטה לאפליקציה. כשמשתמשים בספרייה, אתם שולטים בתהליך של האפליקציה ובוחרים מתי לקרוא לספרייה.
בדוגמה הבאה, קוד האפליקציה מייבא שיטה מהספרייה lodash. אחרי שהפונקציה מסתיימת, השליטה חוזרת לאפליקציה.
import capitalize from 'lodash.capitalize';
capitalize('hello'); // Hello
כשה-method lodash.capitalize מופעלת, היא קוראת לקוד JavaScript שנכתב מראש, שהופך את התו הראשון של מחרוזת לאות רישית.
דוגמה לשימוש ב-JavaScript framework
JavaScript framework היא תבנית קוד מוגדרת מראש שבה אתם בונים את ההתנהגות של האפליקציה. כלומר, כשמשתמשים במסגרת, היא שולטת בתהליך של האפליקציה. כדי להשתמש ב-framework, כותבים את קוד האפליקציה בהתאמה אישית, ואז ה-framework קורא לקוד האפליקציה.
בדוגמה הבאה מוצג קטע קוד שמשתמש ב-JavaScript framework מסוג Preact:
import { createElement } from 'preact';
export default function App() {
return (
<p class="big">Hello World!</p>
)
}
בדוגמה הזו, שימו לב של-framework יש הרבה יותר שליטה על הקוד שאתם כותבים, ובמקרים מסוימים, ה-framework אפילו קובע מתי להריץ את הקוד.
למה כדאי להשתמש בספרייה?
שימוש בספריית JavaScript יכול לעזור לכם להימנע מחזרה מיותרת על קוד. ספריות יכולות להפשיט לוגיקה מורכבת, כמו מניפולציה של תאריכים או חישובים פיננסיים. ספרייה יכולה גם לעזור לכם להוציא את המוצר הראשוני שלכם, במקום שתצטרכו לכתוב את כל הקוד מאפס, מה שיכול לקחת זמן.
חלק מספריות ה-JavaScript בצד הלקוח עוזרות להפחית את המוזרויות של פלטפורמת האינטרנט. ספרייה יכולה לשמש גם ככלי למידה. לדוגמה, אם אתם לא מכירים את פונקציות ההאטה של אנימציה, קוד המקור של ספרייה יכול ללמד אתכם איך ההאטות האלה פועלות.
חלק מהספריות נתמכות על ידי חברות גדולות שמשקיעות זמן וכסף כדי לעדכן ולאבטח את הספריות. לספריות רבות מצורף תיעוד נרחב, שמאפשר לכם ולצוות שלכם להכיר במהירות את אופן השימוש בספרייה.
בסופו של דבר, השימוש בספריית JavaScript חוסך זמן.
למה חשוב לדעת מה השימוש בספרייה?
מבחינה טכנית, אתם יכולים לפתח את אפליקציית האינטרנט שלכם מאפס, אבל למה לטרוח כשאפשר להשתמש בתוכנה חינמית (קוד פתוח), או לרכוש פתרון שבטווח הארוך יכול לחסוך זמן וכסף? יש הרבה ספריות וסביבות עבודה של JavaScript, ולכל אחת מהן יש מאפיינים שונים וגישה ייחודית לפתרון בעיות. לדוגמה:
- אפשר לכתוב ולתחזק ספרייה באופן פנימי במקום על ידי צד שלישי.
- לספרייה יכולים להיות רישיונות משפטיים ספציפיים שמתאימים או לא מתאימים לאפליקציית האינטרנט שלכם.
- יכול להיות שהספרייה לא מעודכנת או לא מתוחזקת.
- ספרייה יכולה לפשט קבוצה של משימות מורכבות ולחסוך לכם הרבה זמן וכסף.
- ספרייה יכולה להיות בשימוש נרחב בקהילה, ויכולה להיות מוכרת בקרב מפתחים.
כמו שאפשר לנחש, מאפיינים שונים יכולים להשפיע על אפליקציית האינטרנט בדרכים שונות. לפעמים ההחלטה היא לא כזאת קריטית, ואפשר להחליף ספרייה אם לא אוהבים אותה. עם זאת, לפעמים ספרייה יכולה להשפיע באופן משמעותי על העבודה ועל אפליקציית האינטרנט שלכם, ולכן יכול להיות שתצטרכו גישה מושכלת יותר.
יש סביבות JavaScript שלא פועלות בצד הלקוח, כמו בשרת (שפועל בסביבת ענן) או ב-Raspberry Pi, שבהן יכול להיות שתצטרכו לשנות את הקריטריונים שאתם משתמשים בהם כדי לבדוק ספריות וסביבות עבודה.
ביצועים
חשוב לשים לב להשפעה של ספריית JavaScript על הביצועים של אפליקציית אינטרנט בצד הלקוח. ספריית JavaScript גדולה יכולה לפגוע בביצועי הטעינה של הדף. זכרו: כל אלפית שנייה חשובה.
נניח שאתם משתמשים בספריית JavaScript לאנימציה. ספריות מסוימות יכולות להוסיף בקלות עשרות קילובייטים, ובמקרים מסוימים אפילו מאות קילובייטים. משאבי JavaScript כאלה יכולים להוסיף עיכוב משמעותי לטעינת הדף, כי הדפדפן צריך להוריד, לנתח, לקמפל ולהריץ את הקוד.
ככל שספריית ה-JavaScript גדולה יותר, כך ההשפעה על הביצועים של המשתמשים גדולה יותר.
כשאתם בודקים או משתמשים בספרייה או במסגרת של JavaScript, כדאי להביא בחשבון את ההצעות הבאות לשיפור הביצועים:
- אם יש לכם ספריית JavaScript גדולה, כדאי להשתמש בחלופה קטנה יותר. לדוגמה, date-fns מציעה הרבה פונקציונליות בגודל סביר יותר מאפשרויות אחרות.
- בהמשך לדוגמה הקודמת של date-fns, מייבאים רק את הפונקציות שצריך, למשל:
import { format } from 'date-fns'. חשוב לשלב את הגישה הזו עם tree shaking, כדי ליצור מטען ייעודי (payload) מינימלי של JavaScript ולשלוח אותו למשתמשים. - כדי לבדוק את ההשפעה של שימוש בספריית JavaScript מסוימת על הביצועים, אפשר להשתמש בכלים לבדיקת ביצועים כמו Lighthouse. אם ספרייה מוסיפה עיכוב של שנייה אחת לזמן הטעינה של הדף (אל תשכחו להגביל את הרשת ואת המעבד במהלך הבדיקה), יכול להיות שתצטרכו להעריך מחדש את הספרייה שבחרתם. בנוסף לבדיקת טעינת הדף, חשוב ליצור פרופיל של כל התנהגות של דף אינטרנט שמפעילה קוד מהספרייה הרלוונטית – ביצועי טעינת הדף לא מספרים את כל הסיפור.
- אם יוצר הספרייה מאפשר להוסיף תגובות, אתם יכולים לשלוח תצפיות על הביצועים, הצעות ואפילו תרומות לפרויקט. כאן קהילת הקוד הפתוח יכולה לעזור. אם אתם מחליטים לתרום, יכול להיות שתצטרכו לבדוק קודם עם המעסיק שלכם.
- כדי לעקוב אחרי עדכונים גדולים באופן בלתי צפוי בספרייה, השתמשו בכלי אוטומטי למעקב אחרי חבילות, כמו bundlesize. בדרך כלל, ספריית JavaScript גדלה עם הזמן. הוספת תכונות, תיקוני באגים, מקרי קצה ועוד – כל אלה יכולים להגדיל את הקובץ של הספרייה. אחרי שאתם או הצוות שלכם הסכמתם להשתמש בספרייה, עדכון הספרייה יכול להיות פחות בעייתי ולעורר מעט שאלות, אם בכלל. במקרים כאלה כדאי להסתמך על אוטומציה.
- בדקו את הדרישות שלכם מספרייה, והעריכו אם פלטפורמת האינטרנט מציעה את אותה פונקציונליות באופן מקורי. לדוגמה, בפלטפורמת האינטרנט כבר יש כלי לבחירת צבעים, כך שלא צריך להשתמש בספריית JavaScript של צד שלישי כדי להטמיע את אותה פונקציונליות.
אבטחה
שימוש במודול של צד שלישי כרוך בסיכוני אבטחה מסוימים. חבילה זדונית בבסיס הקוד של אפליקציית האינטרנט שלכם יכולה לפגוע באבטחה של צוות הפיתוח ושל המשתמשים.
נניח שיש ספרייה שפורסמה בסביבה העסקית של NPM. חבילה כזו עשויה להיות לגיטימית. עם זאת, עם הזמן, החבילה עלולה להיפגע.
ריכזנו כאן כמה טיפים בנושא אבטחה שכדאי להביא בחשבון כשמשתמשים בקוד של צד שלישי או בודקים אותו:
- אם אתם משתמשים ב-GitHub, כדאי לשקול את הצעות האבטחה של הקוד, כמו Dependabot. אפשר גם להשתמש בשירותים חלופיים שסורקים את הקוד כדי לאתר נקודות חולשה, כמו snyk.io.
- כדאי להשתמש בשירותים של ביקורת קוד, צוות של מהנדסים שיכולים לבדוק באופן ידני את הקוד של הצד השלישי שבו אתם משתמשים.
- כדאי לבדוק אם צריך לנעול את יחסי התלות לגרסה ספציפית, או לבצע commit לקוד של צד שלישי בתוך ניהול הגרסאות. כך אפשר לנעול את התלות בגרסה ספציפית אחת, שככל הנראה נחשבת לבטוחה. באופן אירוני, זה יכול להשפיע לרעה על האבטחה, כי אתם עלולים לפספס עדכונים חיוניים לספרייה.
- סורקים את דף הבית של הפרויקט או את דף GitHub, אם יש כזה. בודקים אם יש בעיות אבטחה שעדיין לא נפתרו, ואם בעיות אבטחה קודמות נפתרו תוך פרק זמן סביר.
- קוד של צד שלישי שמשתמש בקוד אחר של צד שלישי עלול להיות מסוכן יותר מספרייה עם אפס יחסי תלות. חשוב להיות מודעים לסיכון הזה.
נגישות
יכול להיות שאתם תוהים איך ספריות תוכנה קשורות לנגישות באינטרנט. אפשר להשתמש בספריית תוכנה בסביבות שונות, אבל בהקשר של ספרייה שמבוססת על JavaScript בצד הלקוח, יש חשיבות רבה לנגישות באינטרנט.
ספרייה (או מסגרת) מבוססת-JavaScript בצד הלקוח יכולה להגביר או להפחית את הנגישות של האתר. לדוגמה, ספריית JavaScript של צד שלישי שמוסיפה לדף סליידר של תמונות. אם סליידר התמונות לא מביא בחשבון את הנגישות באינטרנט, אתם כמפתחי אתרים עלולים לפספס תכונה חשובה כזו, ולהשיק מוצר שחסרות בו תכונות קריטיות, כמו האפשרות לנווט בסליידר באמצעות המקלדת.
- האם הפלאגין של הטיפוגרפיה הרספונסיבית תומך במשתמשים שמגדילים או מקטינים את התצוגה של הדף?
- האם הפלאגין להעלאת קבצים תומך בהעלאת קבצים ממכשירים מסייעים?
- האם ספריית האנימציה מציעה תמיכה למשתמשים שמעדיפים תנועה מופחתת?
- האם הפלאגין של המפות האינטראקטיביות תומך בשימוש במקלדת בלבד?
- האם ספריית נגן האודיו מציעה חוויה מתאימה בקוראי מסך?
סביר להניח שתידרש מידה מסוימת של מעורבות מצדכם, כמפתחי האתר, כדי לעמוד בדרישות הנגישות האלה. לדוגמה:
- אם חסרות תכונות, אתם יכולים להטמיע אותן בבסיס הקוד שלכם, גם אם אתם ממשיכים להשתמש בספרייה הרלוונטית.
- בתמיכת המעסיק, אתם יכולים לתרום תכונה חסרה כזו לספרייה, אם מחבר הספרייה מאפשר תרומה כזו.
- אתם יכולים לפתוח שיחה עם יוצר הספרייה. לדוגמה, האם תכונות הנגישות הספציפיות האלה נמצאות במפת הדרכים שלכם? האם לדעתך הם שייכים לספרייה?
- בתרחישי שימוש פופולריים, אתם יכולים לבדוק אפשרויות חלופיות לספריות נגישות יותר. יכול להיות שהן קיימות אבל קשה יותר למצוא אותן.
- במקרים קיצוניים, יכול להיות שתצטרכו לוותר על ספרייה מסוימת וליישם את התכונות שלכם מאפס. זה יכול לקרות כשספרייה או מסגרת מספקות חוויית נגישות פחות טובה בשימוש ראשוני, וצריך לבטל הרבה ממה שהספרייה או המסגרת אמורות לספק בחינם.
מוסכמות
קל יותר לעבוד עם ספריית תוכנה שמשתמשת במוסכמות קידוד מקובלות. אם בספרייה נעשה שימוש במוסכמת קידוד לא מוכרת, יכול להיות שיהיה לכם ולצוות שלכם קשה לעבוד עם ספרייה כזו.
אם ספרייה לא פועלת לפי מוסכמות נפוצות של כתיבת קוד (לדוגמה, מדריך סגנון נפוץ), אין הרבה מה לעשות כדי לתקן את זה באופן מיידי. עם זאת, עדיין יש כמה אפשרויות:
- חשוב להבחין בין קוד המקור של הספרייה לבין ה-API שחשוף לכם, המשתמשים בספרייה. יכול להיות שבקוד המקור הפנימי נעשה שימוש במוסכמות לא מוכרות, אבל אם ב-API (החלק בספרייה שאיתו אתם יוצרים אינטראקציה) נעשה שימוש במוסכמות מוכרות, יכול להיות שאין סיבה לדאגה.
- אם ה-API של הספרייה לא פועל לפי מוסכמות נפוצות של כתיבת קוד, אתם יכולים להשתמש בתבנית עיצוב של JavaScript, כמו תבנית שרת proxy, כדי לעטוף את כל האינטראקציות עם הספרייה ולהכיל אותן בקובץ אחד בבסיס הקוד. לאחר מכן, ה-proxy יכול להציע API אינטואיטיבי יותר לחלקים אחרים של הקוד בבסיס הקוד.
מוסכמות משפיעות מאוד על קלות השימוש. ספרייה שכוללת API אינטואיטיבי יכולה לחסוך שעות רבות, או אפילו ימים של שעות עבודה, בהשוואה ל-API לא אינטואיטיבי שדורש הרבה ניסוי וטעייה כדי להבין אותו.
עדכונים
לדוגמה, ספרייה שפועלת באופן מלא ומבצעת כמה חישובים מתמטיים, עשויה להזדקק לעדכונים לעיתים רחוקות. למעשה, ספרייה עם כל התכונות היא מצרך נדיר בעולם המשתנה של פיתוח אתרים. עם זאת, לפעמים תרצו שיוצר הספרייה יהיה זמין ומוכן לבצע עדכונים. מחקרים וממצאים חדשים יכולים לחשוף דרכים טובות יותר לעשות דברים, ולכן השיטות שבהן משתמשים בספריות ובמסגרות תמיד כפופות לשינויים.
כשבוחרים ספרייה או מסגרת, חשוב לשים לב לאופן שבו מתבצעים העדכונים, ולהיות מודעים לכך שהחלטות כאלה יכולות להשפיע עליכם:
- האם לספרייה יש לוח זמנים הגיוני לפרסום? לדוגמה, יכול להיות שעדכונים למאגר המקורות של הקוד יקרו לעיתים קרובות, אבל אם העדכונים האלה לא "מתפרסמים" או "מופצים" בהתאם, יכול להיות שיהיה קשה להוריד אותם.
- האם הספרייה מפיצה עדכונים עם סכמה הגיונית של ניהול גרסאות תוכנה? ספרייה אמורה לחסוך לכם זמן. אם אתם צריכים לשנות את הקוד באופן בלתי צפוי בכל פעם שאתם מעדכנים את גרסת הספרייה, זה עלול לפגוע במטרה של השימוש בספרייה הזו מלכתחילה. לפעמים אי אפשר להימנע משינויי תוכנה שעלולים לגרום לכשל, אבל בעולם אידיאלי, השינויים לא מתרחשים לעיתים קרובות ולא נכפים על משתמשי הספרייה.
- האם מושקע מאמץ בספרייה כדי לשמור על תאימות לדורות קודמים? לפעמים, עדכוני תוכנה יכולים לכלול שינויי תוכנה שעלולים לגרום לכשל, אבל גם לספק שכבה של תאימות לדורות קודמים. כך משתמשי הספרייה יכולים להשתמש בגרסה העדכנית של הספרייה עם שינויים מינימליים בקוד שלהם.
רישוי
רישוי תוכנה הוא היבט חשוב בשימוש בספריות תוכנת צד שלישי. יוצר הספרייה יכול להקצות רישיון לספרייה שלו. אם אתם שוקלים להשתמש בספרייה, בחירת הרישיון שלהם עשויה להשפיע עליכם.
לדוגמה, לספריית JavaScript יכול להיות רישיון תוכנה שמאפשר להשתמש בה לשימוש לא מסחרי. אם מדובר בפרויקט אישי או בתחביב, זו יכולה להיות בחירה מצוינת. אם לפרויקט שלכם יש אלמנט מסחרי, יכול להיות שתצטרכו לשקול רישיון Enterprise.
אם יש לכם ספק, כדאי לפנות לייעוץ משפטי מקצועי או להתייעץ עם הצוות המשפטי של החברה שלכם.
קהילה
ספרייה או מסגרת שיש לה קהילה גדולה של משתמשים או תורמים יכולה להועיל, אבל זה לא מובטח. באופן כללי, ככל שיש לספרייה או למסגרת יותר משתמשים, כך גדל הסיכוי שהיא תפיק תועלת. כדאי לשקול את היתרונות והחסרונות הבאים של השתתפות בקהילת פיתוח:
יתרונות:
- בסיס משתמשים גדול יכול להגדיל את הסיכוי שבאגים יתגלו בשלב מוקדם ובתדירות גבוהה.
- קהילה פעילה גדולה יכולה להציע יותר הדרכות, מדריכים, סרטונים ואפילו קורסים על הספרייה או המסגרת הרלוונטית.
- קהילה גדולה ופעילה יכולה להציע יותר תמיכה בפורומים ובאתרי שאלות ותשובות, ולהגדיל את הסיכוי ששאלות התמיכה ייענו.
- קהילה מעורבת יכולה להביא יותר תורמים חיצוניים לספרייה או למסגרת. הם יכולים לעזור לספק תכונות שלא נמצאות במפת הדרכים של המחבר.
- כשספרייה או מסגרת פופולריות בקהילה, יש סיכוי גבוה יותר שהעמיתים והקולגות שלכם שמעו עליהן או אפילו מכירים אותן.
חסרונות:
- פרויקט עם בסיס משתמשים גדול ומגוון יכול להתנפח בגלל הוספה מתמדת של תכונות. ספריות מנופחות יכולות לפגוע בביצועים של האתרים.
- פרויקט עם קהילה פעילה ומעורבת יכול להיות מלחיץ עבור היוצרים והמתחזקים, ועלול לדרוש ניהול קהילה אינטנסיבי.
- פרויקט שגדל במהירות, אבל אין לו את התמיכה המתאימה, יכול להתחיל להראות סימנים של קהילה רעילה. לדוגמה, מפתחי אתרים מתחילים או זוטרים עלולים להרגיש לא רצויים בקהילה מסוימת בגלל התנהגות של שומרי סף.
מאמרי עזרה
לא משנה כמה פשוטה או מורכבת ספרייה או מסגרת של JavaScript, תיעוד התוכנה תמיד יכול לעזור. אפילו מפתחים מנוסים מאוד משתמשים במסמכי תיעוד, במקום להבין את הקוד בעצמם. במסמכי התיעוד מוסבר באיזה API צריך להשתמש ואיך להשתמש בו.
במסמכי התיעוד אפשר למצוא גם קוד לדוגמה, שיעזור לכם להתחיל לעבוד במהירות. כשאתם בודקים ספרייה או מסגרת, אתם יכולים לשאול את עצמכם את השאלות הבאות:
- האם הספרייה כוללת תיעוד? אם לא, תצטרכו להבין דברים בעצמכם.
- האם התיעוד ברור, קל להבנה וחד-משמעי? מפתחים רבים משקיעים זמן רב בתיעוד. זה אולי נראה כמו משהו קטן, אבל בהירות בתיעוד טקסטואלי יכולה להשפיע מאוד על הפרודוקטיביות.
- האם התיעוד נוצר באופן אוטומטי לחלוטין? יכול להיות שיהיה קשה יותר להבין את התיעוד הזה, והוא לא תמיד מספק הנחיות ברורות לגבי אופן השימוש ב-API.
- האם המסמכים מעודכנים? לפעמים תחזוקת התיעוד נחשבת למשהו שולי. אם הספרייה מעודכנת אבל התיעוד לא, זה יכול לגרום לבזבוז זמן פיתוח.
- האם התיעוד מקיף וזמין בכמה פורמטים? מדריכים למשתמשים, קוד לדוגמה, מאמרי עזרה, הדגמות בשידור חי ומדריכים הם כולם פורמטים חשובים של מסמכי תיעוד שיכולים לעזור לכם להשתמש בספרייה או במסגרת.
התיעוד לא תמיד יכול להיות מלא, וזה בסדר. כדי לקבוע את רמת התיעוד שאתם צריכים, אתם צריכים להעריך את צורכי הארגון, את דרישות הפרויקט ואת מורכבות התוכנה.
סיכום
זה נורמלי להרגיש מוצפים כשבוחרים ספרייה או מסגרת בפעם הראשונה. כמו בכל דבר אחר, ככל שלומדים ומתרגלים משימה, כך משתפרים בה. כדאי לעיין בפוסט הזה בפעם הבאה שתבחרו ספרייה או מסגרת לשימוש. אתם יכולים להשתמש בכותרות של הפוסט הזה כרשימת משימות. לדוגמה: האם הספרייה הזו יעילה? האם הספרייה הזו עומדת בתקני הנגישות באינטרנט של העסק שלי?
יש היבטים נוספים של ספריות וסביבות עבודה שכדאי להביא בחשבון, ולא דנו בהם בהרחבה בפוסט הזה:
- יכולת הרחבה: עד כמה קל להרחיב את הספרייה באמצעות לוגיקה או התנהגות בהתאמה אישית?
- כלים: אם רלוונטי, האם הספרייה כוללת כלים כמו פלאגינים של עורך קוד, כלי ניפוי באגים ופלאגינים של מערכת build?
- ארכיטקטורה: קוד נקי הוא חשוב, אבל האם הארכיטקטורה הכוללת של הספרייה הגיונית?
- בדיקות: האם לפרויקט יש חבילת מקרים לבדיקה? האם באתר הפרויקט יש תגים או אינדיקטורים שמראים שחבילת המקרים לבדיקה עוברת את הבדיקה מול ה-commit האחרון?
- תאימות: האם הספרייה פועלת היטב עם ספריות או מסגרות אחרות שבהן אתם משתמשים כרגע?
- עלות: מהי העלות של מסגרת? האם הוא בקוד פתוח או זמין לרכישה?
- מדדי פופולריות: המדדים האלה צריכים להיות נמוכים ברשימת הקריטריונים שלכם, או אפילו להתעלם מהם לחלוטין, אבל אולי כדאי לשקול את "ההצבעות" של הפרויקט, חשבונות ברשתות החברתיות שמייצגים את הפרויקט ו/או כמה באגים/בעיות פתוחים יש בדף הפרויקט.