Back to the Future

6 טכניקות שיזניקו את קוד ה-web שלכם אל העתיד

אחת הבעיות המעיקות ביותר בפיתוח web, בין אם מדובר באתר פשוט או ב-web app מורכב, היא חוסר התמיכה של דפדפנים שונים בסטנדרטים חדשים של HTML, CSS ו-Javascript. בשנים האחרונות שפות אלו מתפתחות בקצב מסחרר, וליצרני הדפדפנים השונים קשה לעמוד בקצב. אנחנו כמפתחי web לרוב נרצה שהאתר שלנו יעבוד כמו שצריך על כל הדפדפנים הפופולאריים, אך לעיתים אפילו הגרסאות החדשות ביותר שלהם (שלא נדבר על גרסאות קודמות…) חסרות תכונות בסיסיות, מה שהופך תכונות אלו בפועל ללא שמישות.

לדוגמה, תחביר חדש ושימושי של javascript הוא arrow functions:

var func = (x, y) => x + y - 1;
func(3, 4); // 6

נכון לכתיבת שורות אלו השימוש ב-arrow functions לא אפשרי ב-Internet Explorer (באף גרסה), ואף יגרום ל-syntax error. הדבר מונע לחלוטין שימוש ביכולת זו באתר שאמור לתמוך ב-IE (אלא אם בוחרים להתעלם מבערך 10% מהגולשים שלנו).

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

#1 – הכרת השטח

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

Can I use

האתר המדהים הזה מחזיק רשימה מעודכנת של כל הפיצ'רים החדשים של HTML, CSS ו-Javascript ועבור כל אחד מהם מציג באיזה פלטפורמות הוא נתמך, ואיזה בעיות ידועות יש איתו.

למשל בתמונה למעלה ניתן לראות ש-CSS3 3D Transforms נתמכים בכל הדפדפנים למעט IE בגרסה 9 ומטה ו-Opera Mini. כעט ניתן להחליט האם להשתמש בפיצ'ר זה ולפגוע בנראות האתר בדפדפנים הישנים או לא.

בהמשך נראה מה ניתן לעשות אם החלטנו להשתמש ביכולת שלא נתמכת בכל הדפדפנים.

ECMAScript Compatibility Table

בשונה משפות תכנות קונבנציונליות שיוצאות לשוק בגרסאות, Javascript, או בשמה החדש ECMAScript, היא אוסף גדול של יכולות בלתי תלויות. כל פלטפורמה (דפדפן, mobile os, מנוע JS) בוחר לממש חלק מהפיצ'רים האלו בסדר שרירותי כלשהו, כלומר תמיכה ביכולת אחת לא בהכרח מעידה על תמיכה באחרת.

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

ECMAScript Compatibility Matrix
ECMAScript Compatibility Matrix

בדומה ל-Can I use, ניתן להשתמש במידע זה כדי להחליט באילו יכולות שווה לנו להשתמש, באילו לא, ולאילו אפשר לחפש חלופות.

#2 – Transpiling

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

Javascript Transpilers

קיימים מספר טרנספיילרים עבור javascript, והמועדף עליי הוא Babel (בעבר 6to5). כלי זה ממיר שימוש בפיצ'רים חדשים של JS לקוד המבצע את אותה פעולה בדיוק (או בערך), אך ע"י שימוש בקוד JS הנתמך בכל הדפדפנים והפלטפורמות.

כמו שניתן לראות כאן, נכון לכתיבת שורות אלו, מבין כל פלטפורמות ה-JS השונות Babel תומך כמעט במספר הרב ביותר של פיצ'רים (שני רק ל… Edge?!), מה שמבטיח לנו שכמעט כל יכולת חדשה של JS שנשתמש בה תעבוד על כל הדפדפנים.

CSS Transpilers

גם עבור CSS ישנה סוג של טרנספילציה המיועדת לתמיכה בדפדפנים ישנים, זאת עקב העובדה שישנם מאפייני CSS הנתמכים בדפדפן מסויים רק אם מוסיפים תחילית ספציפית (vendor prefix) לאותו דפדפן. לדוגמה, נכון לכתיבת שורות אלו, המאפיין appearance יעבוד על רוב הדפדפנים רק אם נשתמש בו כך:

div {
  appearance:button;
  -moz-appearance:button; /* Firefox */
  -webkit-appearance:button; /* Safari and Chrome */
}

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

תהליך בנייה

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

#3 – Polyfills

יכולות מסויימות של Javascript או HTML הן מורכבות מדי כדי לממש בתוך טרנספיילר, למשל SVG, Canvas, HTML Storage ועוד. כדי שבכל זאת נוכל להשתמש בהן, נכתבו עבורן תחליפים עבור דפדפנים ישנים. תחליפים אלו נקראים polyfills (ולעיתים shims). קיימים Polyfills כמעט עבור כל תכונה חדשה של HTML או JS, ורשימה די מקיפה שלהם ניתן למצוא כאן.

ברוב המקרים polyfill לא ירוץ אם הוא יזהה שהיכולת שהוא אמור להחליף כבר קיימת בדפדפן הנוכחי, ולכן זה בטוח להכיל את ה-polyfills בקוד שלנו תמיד. אך שימו לב ש-polyfills הם בסופו של דבר קוד JS, ושימוש מופרז בהם יכול להגדיל את הקוד שלכם משמעותית. אם לא אכפת לכם לבצע בקשת HTTP נוספת, תוכלו להשתמש בשירות polyfills.io, המוריד את ה-polyfills הנדרשים לפי ה-user agent של הדפדפן, וכך יכול לחסוך רוחב פס יקר.

#4 – זיהוי בזמן אמת ומימוש חלופות

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

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

לאחר ריצה של כל בדיקה תתווסף מחלקה (class) לתגית ה-html של האתר שלכם, שתאפשר לכם לבנות התנהגות שונה, אפילו בקוד ה-CSS עצמו, במידה ויכולת מסויימת ממומשת או לא. כמובן שניתן לגשת לתוצאות הבדיקות גם באמצעות JS.

#5 – בדיקות, בדיקות, בדיקות

אז סיימתם לבנות את האתר שלכם, ווידאתם שהוא עובד מעולה ב-Chrome ,Firefox ו-IE בגרסאות המותקנות לכם על המחשב. אבל מה עם גרסאות דפדפן ישנות? ומובייל? ודפדפנים איזוטריים?

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

  • אתרים כמו Browsershots (ויש עוד עשרות כאלו) יצלמו עבורכם את האתר שלכם בכל דפדפן שתבחרו. כך תוכלו לזהות במהירות היכן יש בעיות נראות לעין ולהתמקד בדפדפנים הבעייתיים.
  • השירות BrowserStack מאפשר לכם להתחבר לעשרות גרסאות של דפדפנים על כל סוגי מערכות ההפעלה (כן, גם מובייל) ולבדוק בפועל את האתר שלכם עליהם. ניתן אפילו לבדוק את האתר כאשר הוא רץ על המחשב שלכם!!
  • אם אין לכם כח לבדוק ידנית כל פעם, ואין לכם צוות QA פנימי, חברת Rainforest QA מספקת שירותי QA as a Service, ומאפשרת לכם להגדיר בדיקות ידניות, שיבוצעו ע"י בודקים אנושיים באופן מיידי. אגב, הם משתמשים ב-Mechanical Turk.
  • ואם יש לכם קצת זמן פנוי, אולי שווה לכם לכתוב בדיקות אוטומטיות באמצעות Selenium. ישנם שירותים (BrowserStack ביניהם) המאפשרים לכם להריץ את בדיקות ה-Selenium שלכם בענן על עשרות דפדפנים שונים.

#6 ואחרון – ניטור שגיאות

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

אך זה שמשהו קורה אי שם אצל הלקוח לא אומר שאי אפשר לדעת עליו ולטפל בו!

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

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

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

לסיכום

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

כתיבת תגובה

האימייל לא יוצג באתר. (*) שדות חובה מסומנים