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

לא יצא לכם להשתתף בכנס Front Trends 2013? לא נורא, הנה תקציר ההרצאות הכי מעניינות של אחד הכנסים החשובים עבור קהילת מפתחי ה-Front End

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

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

טכנולוגיות Web כפלטפורמה למחשוב העתיד, אלן ווירפס-ברוק

אלן ווירפס-ברוק (Allen Wirfs-Brock) העומד בראש הפרויקט לתקינת ECMAScript 6 היה ה-Keynote Speaker עם הרצאה מרתקת ומעוררת השראה. בהיותו איש מחשבים ותיק (בניגוד לחלק גדול מהנוכחים בכנס שממוצע הגילאים שלהם היה להערכתי 25-35), הוא סיפר על התפתחות המחשוב התאגידי שנשלט ברובו ע”י IBM והשפות COBOL/Fortran.

בשנות ה-80 התרחשה מהפכת המחשוב האישי (ה-PC) שהכתיר את אינטל למובילת התחום עם ++C. כיום, לפי אלן, אנו עומדים בפתחה של תקופת המחשוב האמביינטי, תקופה בה המחשבים יהיו מודעים לקיומם של אנשים ויגיבו בצורה משמעותית לכך. כבר כיום ישנם שלל מכשירים אשר לא מנסים להיות ה-PC באריזה שונה, אלא כולם מחוברים יחדיו ומציגים חוויה אחידה כאשר הפלטפורמה שהמכשירים הללו משתמשים בה היא Web, כלומר HTML, CSS ו-JavaScript. דוגמאות לכך ניתן לראות בהתרבות אפליקציות מבוססות HTML5 בטלפונים הניידים והטאבלטים, מערכות הפעלה למכשירי מובייל, בטלויזיות חכמות ומוצרים נוספים כמו שעוני יד חכמים או המשקפיים המהפכניות של גוגל.

בואו נעשה const ו-let ביחד כבר היום, אולוב לאסוס

בכנס דובר רבות אודות ECMAScript 6, אשר טיוטת התקן שלו צפויה להיות מוכנה עד סוף השנה וה-Working Group שלו צופה לאשרה כתקן עד סוף 2014. אולוב לאסוס (Olov Lassus) הציג את פרויקט ה-DEFS.js שלו, precompiler ל-JavaScript המאפשר להשתמש ב-let ו-const של ECMAScript 6 כבר היום.

פרט לכך, DEFS.js מבצע ניתוח של הקוד ומתריע על בעיות scope פוטנציאליות. היופי בפריקומפיילר זה הוא שבעתיד הקרוב יחסית, כאשר הדפדפנים יתמכו ב-EC6 בצורה טובה יותר, ניתן יהיה פשוט לוותר על השימוש בו. כמו כן, הוא כמעט ולא משנה את הקוד המקורי שלנו פרט להוספת suffix (של דולר ומספר אינדקס) למשתנים שהוגדרו כ-let/const בצורה צפויה מראש ללא שינוי מספרי שורות.

מקור

[javascript]
function fn() {
let y = 0; // z is certainly not defined here

for (let x = 0; x < 10; x++) {
let y = x * 2;
let z = y;
}

console.log(y); // prints 0
// z is not defined here
}
[/javascript]

מקומפל

[javascript]
function fn() {
var y = 0; // z is certainly not defined here

for (var x = 0; x < 10; x++) {
var y$0 = x * 2;
var z = y$0;
}

console.log(y); // prints 0
// z is not defined here
}
[/javascript]

שיקולים לשיפור ביצועים במובייל, אסטל וואי

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

  • העדיפו להשתמש ב-JPEG על פני PNG או GIF. זאת בעיקר מאחר ו-JPEG לא תומך בשקיפות ולכן נדרשים פחות משאבים (=חשמל) לרינדור התמונה.
  • מזערו את כמות האלמנטים ב-DOM למינימום האפשרי.
  • הקטינו את כמות קוד ה-JavaScript שאתם טוענים. כלומר, אם חשבתם שמאחר ואתם טוענים את jQuery והספרייה תהיה ב-cache של הדפדפן אתם “מוגנים” אז אתם כנראה טועים שכן הדפדפן בכל זאת צריך לפרסר את כל הקוד של הספרייה. לכן, אם אתם מוסיפים את jQuery (או כל ספרייה אחרת) לפרוייקט רק כדי לעשות דברים שיכולתם לעשות באמצעות Vanilla JS, וותרו על כך. זכרו גם כי מכשירי המובייל בד”כ מריצים דפדפנים מודרניים המאפשרים לעשות את מה שספריות כמו jQuery מנסות להשלים בצורה מלאכותית. לדוגמה, הדפדפנים תומכים ב- Query Selector ולכן אין צורך ב- Sizzle, המנוע שמאפשר ל-jQuery לבחור אלמנטים ב-DOM.
  • השתדלו לוותר על אנימציות מבוססות JavaScript והשתמשו ב- CSS transitions/animations על מנת להשיג תוצאות דומות. הרווח מסעיף זה הוא איננו רק חסכון בסוללה, אלא גם אנימציות חלקות יותר.

נקודת תורפה נוספת של מכשירי המובייל היא שחיבור האינטרנט מתבצע באמצעות רשת הסלולר. במחשב רגיל התקשורת עוברת מהמחשב ישירות לספקית הרשת (ISP) ומשם לשרת היעד. לעומת זאת, בסלולר על התקשורת לעבור באנטנה הסלולרית ובתשתית של חברת הסלולר ורק לאחר מכן להמשיך לספקית הרשת ולשרת היעד. לכן חשוב מאוד למזער חיפוש (lookup) ב-DNS במידת האפשר, להקטין את כמות הבקשות לקבצים חיצוניים (CSS, JS, פונטים, תמונות וכו’) מהשרת ולאחד אותן במידת האפשר. ניתן להשיג את המטרה הזאת באמצעות שימוש בספרייטים או ב-Data URI, חיבור מספר קבצי JS או CSS יחד וכו’.

טכניקת עבודה נוספת ומומלצת היא להשתמש ב- Web Storage, כלי מתקדם נוסף שזמין לנו כבר היום במכשירי המובייל, על מנת לעשות caching חכם בצד לקוח. עלינו לשאוף לדחוס גם את התמונות שלנו למקסימום האפשרי. ניתן להשיג זאת ע”י מזעור השימוש ב-Animated GIFs (ולהחליפן באנימציות CSS כמובן) וכן לוותר על שקיפות alpha בתמונות PNG. מומלץ להשתמש בכלים כמו TinyPNG למזעור התמונות. בנוסף, במקרים רבים ניתן להמנע מתמונות לאייקונים לגמרי ע”י שימוש בספריות אייקונים דוגמת Font Awesome או CopyPasteCharacter (שאפילו לא דורש טעינה של שום דבר נוסף על מנת להשתמש בה – רק להעתיק ולהדביק).

אופטימיזציה נוספת היא להשתמש ב-CSS Transformations לאנימציות במידת האפשר (לדוגמה לצורך הזזת אלמנט ממיקום אחד לאחר – במקום שימוש ב- absolute/top/left). זאת מאחר שבצורה כזאת לא מתבצע reflow מיותר של העמוד בגלל שפונקציית ה-transform משתמשת באותו ה-bitmap על מנת לעשות את המניפולציות הגרפיות ולא מציירת את האלמנט(ים) מחדש. בנוסף אנחנו גם מרוויחים ביצועים טובים יותר מאחר ונעשה שימוש בהאצת חומרה, כלומר בכרטיס הגרפי של המכשיר.

אסטל הציגה שיטה מאוד מעניינת להשגת התנהגות של Responsive Images (שכרגע לצערנו זו רק הצעה לתקינה) תוך שימוש ב-CSS ו-SVG בלבד, בניגוד לשיטות הנהוגות כיום המאפשרות לבצע זאת באמצעות JavaScript בלבד. הטריק בשיטה שאסטל הציגה מתבסס על כך שבמידה ועובדים עם SVG ובתוכו משתמשים ב-media query, אזי ערכי ה-min/max-width/height מתייחסים לגודל האלמנט בעמוד ולא לגודל חלון הדפדפן. בצורה כזאת נוכל להכין לנו קבצי SVG לכל סט של גדלי תמונות ולהטמיעה את קובץ ה-SVG כאילו היה תמונה. כך תמונת ה-SVG שניצור תהיה רספונסיבית ותציג את התמונה המתאימה לגודל הרצוי.

המטרה: אנימציות חלקות בדפדפן, ג’ק ארצ’יבלד

ג’ק ארצ’יבלד (Jake Archibald) משמש כ-Developer Advocate בגוגל. ג’ק הדגיש את חשיבות השימוש בכלים שהדפדפנים המודרנים כוללים על מנת לבדוק ולשפר את ביצועי הקוד אותו אנחנו כותבים, או במילים שלו – “Tools, not Rules”.

בהרצאה שלו ג’ק הציג בצורה מדעית (באמצעות ה-profiler של Chrome DevTools) באיזה שלב של הרצת הקוד אנחנו “משלמים” הכי הרבה בביצועים וגורמים לדפדפן לעבוד קשה כדי לצייר על המסך את מה שהעמוד מכיל. הירידה הזאת בביצועים באה לידי ביטוי בכך שמאחר וכל ציור של פריים לוקח יותר זמן, הדפדפן מספיק לצייר פחות פריימים בשניה ולכן מדד ה-FPS (Frames Per Second) יורד למספרים נמוכים.

כדוגמה, ג’ק הציג עמוד ובו כמה עשרות אלמנטים עם box-shadow. לאחר שהדפדפן יסיים לצייר פעם אחת את כל האלמנטים הללו, הוא לא יצטרך לעבוד קשה על מנת לצייר את העמוד כתגובה לביצוע גלילה ע”י המשתמש. לעומת זאת, אם נוסיף ל-body של העמוד רקע עם –

[css]background-position: fixed;[/css]

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

ג’ק הסביר בהמשך את הבעייתיות עם אנימציות על מסכים בכלל ובתוך הדפדפן בפרט ולאחר מכן הציג את צורת העבודה הנכונה כדי להשיג אנימציות חלקות בדפדפן. הבעיה, תחילה, נובעת מכך שעלינו לסנכרן בין ציור הפריימים בדפדפן לבין קצב הריענון (refresh rate) של המסך. פתרון הטוב ביותר הוא יצירת אנימציות באמצעות CSS. במידה ואתם צריכים אנימציות מבוססות JavaScript, אז הדרך הטובה ביותר היא עבודה עם requestAnimationFrame ו-fallback בדמות setTimeout של 16.7 שניות. למה 16.7? תצטרכו לעבור על המצגת המדהימה שלו.

כך שלסיכום, עליכם כל הזמן לשאול את עצמכם WTFPS?!

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

המחשבה מאחורי BEM, ורוורה סטפנובה

ורוורה סטפנובה (Varvara Stepanova) היא ראש צוות פיתוח צד קדמי ב-Yandex.ru, הגוגל הרוסי. בהרצאתה היא הציגה את פרויקט BEM (שזה Block Element Modifier). מדובר בכלי פנימי של יאנדקס שפותח על ידם החל מ-2005 וכעת הם שחררו אותו כפרויקט Open Source.

מההרצאה, כמו גם משיחה שניהלתי עם ורוורה לאחר מכן קשה שלא לשים לב שיאנדקס צמאים לדחוף את הפרוייקט הזה קדימה וישמחו לקבל pull requests ב-GitHub. לי אישית הפרויקט הזה מזכיר קצת את Twitter Bootstrap שכן גם הגרעין שלו הוא קופמוננטות (בלוקים בשפת BEM) לשימוש ב-UI של אתרים ואפליקציות ווב.

בולטת מאוד העובדה שקיימת פילוסופיה שלמה העומדת מאחורי הפרויקט והושקעה בה מחשבה רבה שכן יאנדקס מפתחים אותו במשך כ-8 שנים ומשתמשים בו בלמעלה מ-100 שירותים שונים שלהם. פרט לאפשרות לייצר קומפוננטות באמצעות BEM, הפרויקט מגיע עם מספר כלים מעניינים נוספים, אחד הבולטים שבהם הוא CSS Optimizer, או CSSO בקיצור. ה-CSSO מאוד הזכיר לי גירסה קצת מצומצמת של SASS + Compass. כשורווה נשאלה למה CSSO עדיף על SASS, תשובתה הייתה פשוט “כי ככה”. כמובן שתשובה מסוג זה גררה צחוק ומחיאות כפיים רבות מהקהל. ללא ספק מומלץ לבדוק את BEM. יש לו תיעוד רב באנגלית וגם עומדת מאחוריו חברת ענק בשוק הרוסי ומציעה גישות קצת שונות לכל נושא הקומפוננטות שאנחנו (הישראלים שהולכים בעיקר אחרי הטרנדים האמריקאים והאירופאים) כמעט ולא נחשפנו אליהן.

הכירו את השגיאות שלכם, דייגו אנטונס

דייגו אנטונס (Diogo Antunes), מפתח צד קדמי מ-Booking.com סיפר על ההתמודדות שלהם עם מעקב אחר שגיאות JavaScript. עבור חברה כמו Booking.com, אתר שלא מתפקד כראוי מתורגם בצורה ישירה להפסד כספי ולכן הנושא מאוד קרוב לליבם.

אחת השיטות הפשוטות ביותר שהוא הציג להתמודדות עם ניטור ומעקב אחר שגיאות JavaScript היא שימוש ב- window.onerror, כך ניתן בקלות להתמודד עם שגיאות המתרחשות בקוד או לכל הפחות להשתיק אותן מבלי שהמשתמשים ירגישו. במידה ונהיה מעוניינים לשמור את השגיאות, מומלץ לעשות זאת באמצעות Pixel Image; השיטה שנמצאת איתנו כבר שנים רבות מתבססת על טעינת תמונה בגודל 1×1 פיקסלים והוספת query string לכתובת של התמונה עם מידע אותו ברצוננו להעביר לשרת. נעדיף להשתמש בשיטה זו במקום AJAX request מאחר וייתכן והבעיה שיצרה את השגיאה נעוצה דווקא ב-AJAX. כלומר, ננסה לכתוב כמה שפחות קוד JavaScript על מנת לדווח על השגיאה ונשתמש בתכונות הבסיסיות של הדפדפן לטעינת תמונות על מנת להעביר את הדיווח לשרת.

דיאגו הציג גם את השימוש בבלוקים של try/catch כאפשרות, אך בעיניי מדובר בפתרון גרוע שכן נענש בביצועים פחות טובים – try/catch גוזל הרבה משאבים מהדפדפן, וחבל. אפשרות נוספת, במידה ומעניין אותנו לצרכים סטטיסטים לנטר את כמות השגיאות, ניתן להשתמש ב- Google Analytics על מנת לדווח על “ארוע” של שגיאה.

מיקרו-ספרייה מעניינת שדיאגו הציג היא stacktrace.js אשר עוזרת מאוד לקבל מידע רב על השגיאות שהתרחשו ושימושית במיוחד בדפדפנים בעייתים ל-debugging כגון IE לדורותיו. בנוסף, ישנם שירותים קיימים לניטור שגיאות JavaScript כגון: Qbaka, Errorception, jsErrLog, Muscula ונוספים. רובם ככולם מאוד דומים בפונקציונליות שלהם פרט לכך שחלקם מוצעים במודל של SaaS ואחרים ניתנים להתקנה על השרת שלכם.

בקטנות

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

2013 היא השנה שבה אפשר להפסיק לחשוב על back end

לא עוד יצירת טפסי הרשמה וניהול סיסמאות משתמשים אלא ריכוז המשאבים במה שהופך את האפליקציה שלנו לכל כך טובה. כבר היום יש כלים כמו Firebase ואחרים, אך כל כלי הולך בגישה מעט שונה ומנסה לפתור את הנושא בצורה אחרת. לפי גרגור, שנת 2013 היא שנת המפנה ובסופה נוכל לכתוב את ה-dreamcode שלנו שמתעסק רק בדברים שמעניינים אותנו כמפתחי צד קדמי. בקיצור, אל תתנו ל-back end לסרס את היצירתיות שלכם והרשו לעצמכם לחלום.

זביגניו ברנצקי (Zbigniew Braniecki) יחד עם סטאש מאלולפשי (Staś Małolepszy) הציגו את L20N, ספריה ללוקאליזציה של ממשקי UI עם גישה שונה ומעניינת. בין היתר הספריה חוסכת כתיבה של הרבה קוד מותאם אישית המטפל בתרגומים וכן מאפשרת שינוי הטקסט בהתאם לארועים שונים בדפדפן כמו orientationchange לדוגמה. מוזילה משתמשת בספרייה זו ב-Firefox OS לצרכי לוקאליזציה ותומכת בפרוייקט. שווה בדיקה.

לאה ורו (Lea Verou), שאותה אין צורך להציג, דיברה על הרבה פינות מעניינות של border-radius ומה בדיוק המשמעות של כל הערכים שהמאפיין יכול לקבל וכיצד הדפדפן מפרש אותם. לאה אף אמרה בגיחוך שהיא דיברה בכל הכנסים של Front Trends – בראשון היא דיברה על CSS באופן כללי, בשני על CSS3 ובכנס הנוכחי היא מדברת רק על border-radius, כך שכל פעם נושא ההרצאה שלה מצטמצם. למרות זאת היא הצליחה לתת שואו מעולה על הבמה, על אף שהנושא נראה ממבט ראשון חרוש ומוכר.

ריצ’ל אנדרו (Rachel Andrew) היא הבעלים של חברה בריטית המפתחת מערכת ניהול תוכן קטנה. מאחר ומדובר במערכת להצגת תוכן, כל נושאי ה-layout קרובים מאוד לליבה. ריצ’ל סקרה את החידושים שמגיעים לדפדפנים בימים אלו כמו עמודות, flexbox החדש, ה-grid, ה-regions ונוספים.

סבסטיאן גולש (Sebastian Golasch) הציג את Dalekt JS, כלי לאוטומטיזציה של בדיקות UI ופונקציונליות אשר שואב השראה (וגם מממש) מ-Selenium WebDriver. הכלי כרגע בשלבי פיתוח מוקדמים אך נראה מבטיח. המטרה היא ליצור כלי שיאפשר ל-FED-ים להריץ דפדפן וירטואלי ולשלוט עליו מקוד ה-JavaScript אותו כולנו מכירים. בצורה כזאת ניתן יהיה לבצע בדיקות כמו לחיצה על קישורים ווידאו הכתובת אליה הדפדפן הועבר או בחירת אפשרויות ב-select.

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

סיכום

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

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

יגאל סטקלוב

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

הגב

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

avatar
Photo and Image Files
 
 
 
Audio and Video Files
 
 
 
Other File Types
 
 
 

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

סידור לפי:   חדש | ישן | הכי מדורגים
Yuval Shoshan
Member

מעניין מאוד, למדתי כמה דברים. תודה יגאל! :)

חן ראובן
Guest

תודה רבה, למדתי הרבה דברים חדשים

פיתוח אפליקציות
Guest
פיתוח אפליקציות

תודה, מחכים מאד.

wpDiscuz

תגיות לכתבה: