47 ספריות ג’אווהסקריפט שכל מפתח חייב להכיר [חלק א’]

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

מקור: Shutterstock

האמת: לא באמת “חייב” – אבל כדאי, כדי להכיר שהן קיימות ולדעת מה מרחב הכלים הקיים לפיתוח ג’אווהסקריפט.

מתכנת שמגיע לג’אווהסקריפט מעולם ה-.NET או JEE עשוי להרגיש קצת אבוד: בשתי פלטפורמות אלו (בעיקר NET.) המתכנת קיבל Stack שלם של טכנולוגיות קצה-לקצה שמתאימות לפתרון מגוון רחב מאוד של בעיות. כשיש דילמה נוסח: “כיצד כותבים אפליקציות מסוג T?” – פשוט הולכים לתיעוד של מייקרוסופט או אורקל ולומדים מהי “הטכנולוגיה המומלצת” לצורך זה: ASP.NET ?Entity Framework אולי JAAS או javaFaces? הכל, לכאורה, שם.

תמיד היה ניתן לחפש מחוץ לקופסה ולמצוא הרבה ספריות קוד-פתוח מעניינות – אך הספריות שהגיעו בחבילה היו “מספיק טובות”. בעולם הג’אווהסקריפט אין שום חבילה: כל מתכנת לעצמו. ג’אווהסקריפט עצמה היא שפה עם כמה כשלים בתכנון, אין לה IDE מוסכם וקרוב לוודאי שתזדקקו לכמה ספריות עבור פיתוח כל אפליקציה שהיא לא מאוד קטנה.

איפה מוצאים את הספריות הללו? תחפשו. כנראה שתגיעו מהר מאוד להוסיף לארסנל שלכם את jQuery, כמה פקדים ויזואליים וכלי Shim (אם אתם תומכים בדפדפנים ישנים). מעבר לבסיס הזה יש עוד הרבה ספריות חשובות שכדאי להכיר. אני לא מדבר על הספריות ל”כיבוי שרפות” נוסח “אני זקוק לפקד של תאריך” או “אנימציה של שעון מסתובב” – את אלו תמצאו בגוגל ברגע שיעלה הצורך. אני מדבר על ספריות שהן יותר לטווח הארוך, על מנת לכתוב ג’אווהסקריפט בצורה מסודרת ונכונה יותר. ספריות חשובות אך לא דחופות.

הכירו את JSter

הטריגר לפוסט הוא אתר נחמד שנתקלתי בו בשם JSter המרכז רשימה של ספריות ג’אווהסקריפט. האם אין המון אתרים כאלה? – יש, אבל בג’סטר היו 2 דברים שקסמו לי:

הוא מנסה למיין את הספריות (בתוך הקטגוריות) ע”פ הפופולריות שלהן – ולהציג קודם את הספריות החשובות ביותר.
הוא מוסיף לכל ספרייה את הלוגו שלה – תוספת קטנה, אבל חשובה, לטעמי. הכרת הסמלים עוזרת להתמצא ביתר קלות ולזהות מהר יותר ספריות שאתם נתקלים בהן פעם נוספת. שמות הספריות בג’אווהסקריפט דומות ומזכירות אחת את השניה. למשל: EmbedJs, Ember.js ו-emojify.js או sprite.js, spine.js, spry ו-spin.js. לכו תבדילו.

אם JSter קיים – מדוע צריך את הפוסט הזה?

לכלי אוטומטי יש הטיות וטעויות. למשל ג’סטר קבע ש-SenchaTouch היא ספריית ה-Mobile במקום ה 16 (מתוך 19), ממש לאחר ספרייה כלשהי בשם JindoMobile. זו שטות גמורה ודיי ברור ש-Sencha היא השנייה הפופולארית אחרי jQueryMobile, אם לא הראשונה. מקור הטעות נובע כנראה מכך שלג’סטר אין נתונים על ספריות שלא מנוהלות ב-Github, והוא מדרג אותן אחרונות / ע”פ הצבעות באתר בלבד.

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

כמה הערות נוספות:

כפי שציינתי, ניסיתי להתמקד בספריות “טווח ארוך” ולא כאלו שפותרות בעיה מיידית.
ניסיתי לקבץ את הספריות קצת אחרת מג’סטר בצורה שנראתה לי יותר הגיונית.
עדיין השתמשתי בצילומי מסך מג’סטר הכוללים נתונים שימוש מ-github. ג’סטר יתעדכן עם הזמן, והפוסט הזה – לא.
יש כאן עניין של דעה אישית – שאחרים עלולים לא להסכים איתה. אני כבר מצפה לכמה תגובות בנוסח: “אבל איך לא ציינת את <שם ספרייה>?”
גם ל”כלי אנושי” יש הטיות וטעויות. ייתכן ויש ספריות שאני חושב שהן “לא פעילות” או “פאסה” – ואני פשוט לא יודע.
אני מציג בכל קטוגריה מספר ספריות שהן חלופות אחת לשנייה. אינני מנסה להמליץ ללמוד את כולן, חס ושלום. בעיקר נראה לי חשוב להכיר את האופציות השונות ותחומים בהן כל אופציה חזקה.

יאללה לדרך!

ספריות בסיס

jQuery היא ספריית “חובה” שבשימוש ע”י כמעט-כל מפתח ווב שאני מכיר. Zepto היא ספרייה המציגה API תואם ל jQuery – אבל עם כמה הבדלים:

Zepto, בהגדרה, תומכת רק בדפדפנים מודרניים. היא לא תומכת ב-IE (אם כי תמיכה ב-IE גרסה +10 נשקלת).
היא לא כוללת את כל הפונקציונליות, אלא קצת פחות. מה שקיים – תואם ל-jQuery.
גודל הספרייה היה כשישית מ-jQuery כשהספרייה הוצגה, כיום הוא כשליש.

מדוע להשתמש בספרייה שעושה את מה ש-jQuery עושה, תומכת בפחות דפדפנים ובפחות פונקציות? בגלל הגודל. קהל היעד של Zepto היה בעיקר אפליקציות / אתרים למובייל, היכן שגודל ה-javaScript הוא משמעותי לביצועי האפליקציה.

דיי מהר הפכה Zeprto לאופציה פופולרית בעולם המובייל. “שליטה בעולם המובייל?!” – jQuery נלחצה, נבהלה, והגיבה בהתאם: התפצלה לגרסת “Legacy Support” (גרסאות 1.9) וגרסה רגילה (גרסאות +2), והוסיפה אופציה לוותר על פיצ’רים כדי להפחית את נפח ההורדה ולצמצם פערים מול Zepto. עדיין יש פער, אבל מפתחים רבים יוותרו עליו בכדי לזכות ב jQuery שהם מכירים. נחייה ונראה כיצד תחרות זו תמשיך ותתפתח.

Prototype ו-MooTools היו שתי מתחרות של jQuery שלא עמדו בתחרות. אני לא מכיר אף אחד שמשתמש בהן כיום – אבל יש עדיין המון קוד כתוב שעובד איתן, בעיקר עם Prototype.

Frameworks בסיס

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

עוד הבדל מהותי הוא שבפיתוח עם jQuery המפתח עדיין עובד עם ה-abstractions של הדפדפן, קרי Style Sheets, DOM וכו’ – jQuery מספקת API נוחים יותר לעבודה עם מודל זה. עקרון זה נכון גם, פחות או יותר, עבור Polymer.

Enyo, YUI ו-Dojo מספקים abstraction שהוא הרבה יותר Object Oriented ומבוסס javaScript – תמונת עולם שמשקפת פחות טוב את מה שקורה בדפדפן – ולכן כנראה קשה יותר לסגל אותה לחידושים בדפדפן.

הבדל מהותי אחרון הוא נושא ההיקף: אפשר לומר של-jQuery ו-YUI (או Dojo) יש חפיפה, אולם בעוד של 80% מהיכולות של jQuery יש תחליפים ב-YUI/Dojo – אולי ל 30% מהיכולות של YUI/Dojo יש תחליפים ב-jQuery. רשימת היכולות שיש ל-YUI ואין ל-jQuery כוללת: פקדי UI (מה שמכוסה חלקית ע”י jQuery UI), הרחבות לשפת ג’אווהסקריפט שמספקות מחלקות (בניגוד לאובייקטים, מה שנקרא Class System), ניהול state על ה-URL, יכולות input validation, ועוד.

Dojo ו-YUI הן דיי מקבילות אחת לשנייה בסט היכולות (שכולל הרבה מאוד), אם כי פילוסופיות המימוש שונות. נראה שמעמדן הולך ונשחק עם השנים לטובת jQuery עם השלמות. כלומר: במקום לבחור ב-Framework אחד שעושה את רוב העבודה – מעדיפים להרכיב סט מותאם-אישית של ספריות קטנות יותר.

שתיהן ספריות שהשפיעו רבות על הרבה עולם הג’אווהסקריפט ורבות מהספריות החדשות שאנו רואים כיום הושפעו לקחו רעיונות משתי ספריות אלה. על כן, שמור להן מקום של כבוד בפנתאון של עולם הג’אווהסקריפט – לנצח (קרי כ-5 עד 10 שנים).

Polymer היא המאפה החם החדש מהתנור של גוגל, שאמור לאפשר לנו להרחיב את שפת ה-HTML לתגיות משלנו תוך שימוש בתקנים עתידיים כגון HTML Custom Elements, שימוש ב-HTML Imports – בכדי לשתף תגיות אלו ו-Shadow DOM על מנת לקבל הפרדה בין קוד התגיות לשאר התוכנה ולמנוע התנגשויות.

יש לה גם ספריית UI עם אלמנטים מוכנים לשימוש חוזר. Polymer משתמשת בסדרה של polyfills = מימושים בג’אווהסקריפט שמדמים תקן עתידי עוד לפני שהדפדפנים תומכים בו. ברגע שדפדפנים יחלו לתמוך בתקנים אלו (אם וכאשר) – סביר שהביצועים יהיו טובים יותר ושבעיות מסוימות תפתרנה.Polymer כנראה תשתלב יפה עם Angular.js – ספרייה אחרת מבית גוגל (בהמשך הפוסט).

Enyo פותחה במקור עבור מערכת ההפעלה WebOS – אבל נתרמה מאז לקהילה. עקרונות רבים דומים בה ל-YUI או Dojo – כך שלא קל לומר מייד במה היא מחדשת. Enyo החלה במקור כספרייה למובייל (כ”ספריית הבית” של WebOS) אבל היא מתאימה לחלוטין גם ל-Desktop.

נקודת חוזק בה היא היכולת לפתח אפליקציה שתרוץ גם על desktop, גם על mobile וגם על יצירי כלאיים (Phablet, מחשב נייד עם touch וכו’). ל-Enyo יש גם חבילת התאמה ל-PhoneGap/Cordova לפיתוח Hybrid Web Apps. עוד Framework נפוץ למדי הוא ExtJS.

ExtJS היא ספרייה עשירה ומלאה בנוסח YUI ו-Dojo, אם כי ברמת מודל ההפשטה שלה היא התרחקה צעד נוסף מה DOM/HTML/CSS והיא קרובה יותר למודלים של פיתוח אפליקציות Desktop כגון Spring או AWT. המומחיות של ספרייה זו היא אפליקציות עסקיות ויש לה פקדים עשירים מאוד ליצירת טבלאות וגרפים.

ל-ExtJS יש כנראה את סט הפקדים העשיר ביותר מבין ספריות הג’אווהסקריפט. התוצרים של ExtJS “כבדים” יותר מ-YUI ו-Dojo מבחינת כמות ומורכבות ה-javaScript שנוצר – ולכן מתאימים יותר לאפליקציות שרצות ב-LAN (בניגוד ל-YUI ו-Dojo שכוונו לאפליקציות אינטרנט). בגרסה האחרונה שלה (4.0) ExtJS עברה הרחבות משמעותיות הוסיפה גם תשתית MVC.

ספריות למובייל

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

jQuery Mobile (בקיצור JQM) היא לא הספרייה הכי ותיקה – אבל היא מתהדרת במותג “jQuery” שכנראה מאוד עוזר. היא גם דיי טובה. היא ו-Sencha Touch מתמודדות זה זמן רב על הבכורה. JQM מתבססת על jQuery והיא פחות או יותר המקבילה למובייל של jQuery UI. היא מספקת מנגנון לחלוקת אפליקציית המובייל לדפים ואת ניהול המעברים בין הדפים – ועושה זו בצורה דיי יעילה.

בנוסף היא עוזרת לטפל ב-touch (תכונה חשובה מאוד במובייל) ויש לה סט גדול של פקדים המותאמים למובייל. היא כוללת Theme Roller שמסייע לשנות את צבעי האפליקציה בקלות (אם כי הוא קצת מוגבל) ואפשר למצוא לה עורכי WYSIWYG – לתחילת עבודה מהירה.

הבדל גדול בין JQM ל-Sencha הוא ש-JQM היא חינמית בעוד Sencha תגבה כסף מארגונים (יש כמה הקלות עבור סטארטאפים ופרויקטי קוד פתוח). Sencha Touch, כמו YUI או Dojo מספקת תמונת עולם (הפשטה) שאיננה מבוססת על HTML, DOM ו-CSS – יש שאוהבים זאת ויש כאלו שלא (אני מאלו שלא).

בניגוד ל JQM ו-SenchaTouch בחרו בפקדים וחווית UI “ניטרלית” למערכת ההפעלה, KendoUI (יש לבטא: “Can Do UI”) מייצר UI שנראה כמו מערכת ההפעלה שהיא רצה עליו: iOS, Android וכו’. אפשר לטעות במבט ראשון באפליקציה ולחשוב שהיא Native Application של מערכת ההפעלה, אולם “גליצי’ם” קטנים פה ושם – יסגירו אותה לאורך הזמן.

אני רואה אותה מוזכרת הרבה במאמרים ובפוסטים – אם כי אני לא מכיר אף אחד שבאמת עובד איתה.

jQTouch (שהשתנה לאחרונה את שמה ל-jQT – נראה שג’סטר פספס את זה איכשהו) היא ספרייה דיי ותיקה (מאז 2009?) שלא כ”כ המריאה עד אשר התאחדה עם ExtJs לחברת Sencha. היא:

חינמית (כרגע)
תלויה ב-jQuery – וחולקת איתה את פילוסופיית השמירה על ה abstraction של הדפדפן.
מיועדת כרגע רק ל-webKit (צעד טקטי, לפי דעתי), בעוד JQM מיועדת לכמעט כל מכשיר מובייל ששמעתם עליו.
כמו KendoUI – מספקת UI שמחקה את מערכת ההפעלה עליה היא רצה.

אני מבין את Sencha שרוצה Plan B במידה ויתגלה שהאסטרטגיה של Sencha Touch נכשלת. האם הייתי מהמר באפליקציות שלי על ספרייה שכזו?

ספריות Client Side MVC

ספריות אלו הפכו כמעט לחלק בלתי-נפרד מפיתוח של כל מערכת בגודל בינוני ומעלה בג’אווהסקריפט (צד-לקוח). במיוחד ב Single Page Applications (בקיצור: SPA). כתבתי על הקונספט וקצת על הספריות בפוסט הצצה מהירה על Backbone.js

עלי לציין שבעת כתיבת הפוסט ההוא הייתי תחת הרושם ש-Backbone, Ember ו-Knockout הן שלושת הגדולות ויש עוד “כמה בינוניות” בניהן Angular.js. מאז, למדתי מכמה מקורות ש-Angular היא דווקא מאוד פופולרית, כנראה שנייה לאחר Backbone ובעלת אופק חיובי. התחלתי להכיר אותה ולהבין גם מדוע.

Backbone היא עדיין הספריה הפופולרית ביותר – אם כי במגמת ירידה קלה. מתכנתים רוצים יותר ממה שהיא מספקת. אופציה מעניינת אחת הוא plugin פופולרי ל-Backbone בשם MarionetteJS שחוסך הרבה “הקלדות חוזרות” שקיימות ה-Backbone.
עדיין נראה לי שתוך שנה-שנתיים האחרות יתפסו את הבכורה ו-Backbone תהפוך קצת יותר לספריית נישה לאלו שאוהבים הרבה שליטה על הקוד שלהם.

עדיין – זו הספרייה הטובה ביותר להתחיל ללמוד ממנה מהו Client-Side MVC. הייתי עדיין פותח בה בכדי ללמוד את העולם הזה, לפני שהייתי מבצע בחירה אחרת ומשקיע את הזמן הרב הנדרש בלימוד Ember, Angular או Knockout.

ספריות צד-שרת

Node.js היא ממש מהפיכה: זוהי פלטפורמה לכתיבת קוד צד-שרת (או מקומי על מערכת ההפעלה) המבוססת על ג’אווהסקריפט ו-V8 (מנוע הג’אווהסקריפט המצוין של כרום, מבית גוגל). יש לה המון ספריות, קהילה גדולה ועתיד מזהיר. Node מספקת לקוד הג’אווהסקריפט שאפליקציות שרת צריכות ואין להן באופן טבעי בשפה:

גישה לקבצים.
פעולות Networking.
ריבוי threads (לפחות נרצה אחד לכל Core של מעבד).
הפשטה וכלים לביצוע משימות נפוצות של פיתוח צד-שרת, כגון Express שהיא המקבילה (ה-low level) של Servlets על Node.

האם היא תחליף את ג’אווה כפלטפורמה – עדיין מוקדם לומר.

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

כותבי אפליקציות עסקיות: זוהי ספרייה שמכוונת להיות Enterprise class ולא עוד “צעצוע”.

בחלק הבא

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

שיהיה בהצלחה!

לחלק ב’

הפוסט פורסם לראשונה בבלוג ארכיטקטורת תוכנה.

מקור תמונה ראשית: Shutterstock / Hands on Keyboard Binary Code

ליאור בר-און

ליאור בר-און הוא Chief Architect בחברת סטארטאפ ישראלית גדולה.

הגב

16 Comments on "47 ספריות ג’אווהסקריפט שכל מפתח חייב להכיר [חלק א’]"

Sort by: newest | oldest | most voted

Guest

דין