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

עוד מאמר שמתיימר להגיד לכם באיזה טכנולוגיה להשתמש

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

כל מפתח פרונט אנד היום (2018) יגיד לכם שריאקט(React) צריכה להיות הבחירה הראשונה שלכם.

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

מודה, גם אני חשבתי את כל הדברים האלה. באחד מהתפקידים הקודמים שלי, התבקשתי לבחור טכנולוגיה עבור צוות של מפתחים. אנגולר לא הייתה מספיק יציבה לפרודקשין, ואחותה המבוגרת (Angular.js) נראתה כאלטרנטיבה לא מושכת לעומת ריאקט הצעירה והמגניבה. אחרי תקופה (לא פשוטה כלל) של כתיבה בריאקט, החלטתי לבחון את אנגולר. הרעיון של תיכנות ריאקטיבי, TypeScript לא נראה מושך במיוחד - אבל הרגשתי שאני חייב להבין על מה כל הHype. היום, אחרי שאני מכיר את שתי הטכנולוגיות לא רע, אחרי שכל הכאוס עם בחירת השם הלא מוצלחת של אנגולר (למה לא לשנות לגמרי את השם?) ובמיוחד אחרי הגרסאות האחרונה של אנגולר שהציגו לי את schematics, multi apps - אני משוכנע שעבור אפליקציות עם סקייל גדול, לא רק שאנגולר הוא הפתרון הטוב ביותר, אלא שהוא הפתרון היחיד שאפשר להשתמש בו ללא שום קשר לחיזוי גודל האפליקציה שלכם.

ריאקט מעולה לאפליקציות קטנות / בינוניות. בקטגוריה הזאת היא תעפיל לגמרי על אנגולר בגלל ריאקט נייטיב (React Native) ובעיקר בגלל עקומת הלמידה הקטנה שלה. אבל מה קורה שהאפליקציות תגדל ותגדל? נדמה שאתגרי סקלביליות מאד מכבידים על אפליקציות ריאקט והמקרה המפורסם ביותר הוא של Airbnb שזנחו את ריאקט ניייטיב אחרי שנתיים של שימוש.

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

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

CLI

אז רוצים לבנות קומפננטה חדשה? הCLI של אנגולר הופך את זה לפשוט מאד. הוא יוסיף לכם את הקומפוננטה ביחד עם קבצי עיצוב, HTML, וטייפ סקריפ. הוא יחבר את הקומפוננטה למודל ואפילו יכין unit test. כל שנדרש הוא פקודה פשוטה. אפשר לשלוט בהגדרות של CLI בקלות - להחליט אם אני רוצה SCSS/CSS, אם אני מעדיף קבצי טסטים ואפילו אפשר להוסיף תמיכה בשפות טמפלט כמו Pug. עם ה CLI של אנגולר, אפשר להוריד את ה Boilplate בצורה משמעותית עם Schematics, שמאפשר ליצור קומפוננטות ומודלים משלך.

נדמה גם שהצוות של אנגולר, הבין היטב שהחוזק של הספרייה הוא בקהילה ובמיוחד בOpen Source. הפיצ׳ר Libraries של ה Cli מאפשר ביתר קלות לתרום לקהילה על ידי הפצת ספריות קוד פתוח לאנגולר. לכל אחד מאיתנו יש פיסות קוד שאנחנו עובדים איתם, קטנים או גדולים - שאולי יכולות לעזור לאנשים אחרים. וגם אם אתם חושבים שזה לא ישמש אחרים, אפשר לשמור את זה ולהשתמש בהם בRepo פרטי - ככה שתוכלו להשתמש בפרוייקטים אחרים.

TypeScript

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

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

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

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

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

זרימת מידע מגיעה Built In

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

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

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

סיכום

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

בהינתן שגוגל הבטיחו שהם לא הולכים לעשות שינויים שישברו את הקוד(Breaking Changes) לפי דעתי אנגולר היא הטכנולוגיה הנכונה לכל אפליקציה בצעדיה הראשונים. אני לא הולך להתעלם מהעבודה שהדרך להתמחות באנגולר היא ארוכה וקשה אבל זה שווה את זה. כמו שהרבה מכם זוכרים לרעה את Angular JS והבעיות הרבות שהיו לה, אני לא אשכח לעולם לReact ולקהילה את ימיו הראשונים של React Router המשתנה לעיתים דחופות ושובר את האפליקציה. כשיש לכם אפליקציה גדולה, תרצו מאד שרוב התלויות שלכם יהיו תחת מטרייה אחת שתדאג שהכל יעבוד תקין וישרוק.

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