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

1. האם אתם מעוניינים לבנות Single Page Application?

לפני שנוכל להתחיל לדבר על Angular חייבים לשים אותו בהקשר הנכון. זהו פריימוורק לבניית Single Page Applications שנותן מענה להרבה מהקושי שיש למפתחים כשמגיעים לכתוב יישומים כאלו. לכן, השאלה הראשונה היא האם בכלל אנו מעוניינים לבנות יישום עמוד-יחיד, וכמובן מדוע. ואל תגידו לי (או לעצמכם) שאתם צריכים אפליקציית עמוד-יחיד כי לכולם יש אחד, או כי זה מה שהולך היום, או כל סיבה אופנתית אחרת. נסו לחשוב טוב עם עצמכם האם מה שאתם בונים דומה יותר לאפליקציה או לאתר מידע. ברור ש Google Drive או Office365 חייבים להכתב בתור אפליקציות עמוד-יחיד וכוללים הרבה מאוד קוד JavaScript, אבל האם זהו סוג היישום שאתם כותבים?

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

2. מי אתכם בצוות?

אנגולר היא Framework שלקחה הרבה השראה מ WinForms וסביבות דומות לה. זה אומר שמתכנתי צד-שרת הרגילים לסביבות אלו ירגישו בבית. היא גם מוסיפה הרבה אבסטרקציות מעולם פיתוח Object Oriented כך שמתכנתי Java גם כן עשויים להרגיש בבית, בייחוד מתכנתים המנוסים ב JSF.

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

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

3. כמה חשיבות אתם מייחסים לביצועים?

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

במחקר שנערך בסוף 2014 בדקו חוקרים כמה זמן לוקח להציג עמוד ראשון באפליקציית דוגמא המשתמשת ב MVC Frameworks שונים. ברשת סלולרית אנגולר הציג זמני טעינה של 3-4 שניות, לעומת שניה אחת באפליקציית Backbone מקבילה. אני לא טוען שאי אפשר להגיע עם Angular לביצועים של Backbone, אלא שתצטרכו לבצע כמות נכבדת של עבודה ״לא לפי הכללים״ באנגולר בשביל להגיע לביצועים אלו.

4. עד כמה אתם סומכים על גוגל עם המערכת שלכם?

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

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

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

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

5. עריכה: המלצה חמה לבדוק את ריאקט

אנגולר הפכה זה לא מכבר לשם גנרי עבור ספריית פיתוח צד-לקוח. למעשה בזמן שכתבתי את הפוסט הזה האפשרות הטובה ביותר לפתח Single Page App היתה אנגולר. גודל הקהילה, כמות הספריות בקוד פתוח שאפשר למצוא ולשלב והתיעוד האינסופי אפשרו לאנגולר להשאיר את שאר ה MVC Frameworks מאחור.

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

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

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