מה הבעיה של Internet Explorer?

בשבוע האחרון הייתה חגיגה רבתי ברחבי האינטרנט: דפדפן כרום עקף את דפדפן האינטרנט אקספלורר בנתח הגלישה.

האמנם כך? אם כן - מדוע אתרים כגון Stat Owl עדיין טוענים שIE מחזיק את הכתר בבטחה?

ובכן, איסוף נתוני גלישה היא משימה לא פשוטה ולא מדויקת:

• במשך השבוע האנשים גולשים בעיקר ממקומות העבודה, שם IE (אינטרנט אקספלורר) הוא הדומיננטי[א] ובסוף השבוע הם גולשים מהבית בעיקר בכרום או FF. ההבדלים במדידות בין יום ראשון (יום חופש) ויום שני (יום עבודה) הם דרמטיים.
• זהות הדפדפן הנפוץ היא שונה למדי בין צפון אמריקה, אירופה, דרום אמריקה וסין.
• האם מדובר על התקנות או על שימוש? למשל, על מכשירי טלפון יש הכי הרבה התקנות של דפדפן Opera (לרוב מכשירים זולים או ישנים - יש הרבה כאלה במדינות מתפתחות) . לא ברור בכלל איזה אחוז מבעלי הטלפונים האלה השתמש איי פעם בדפדפן שלו. אם מודדים את תעבורת הרשת - אז עיקר התעבורה נעשית מספארי (של אפל).
• איך מודדים גלישה? זמן שהדפדפן פתוח? תעבורת רשת או מספר page views?

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

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

הדפדפן הנפוץ - ע"פ מדינה. כחול = IE, ירוק = כרום, כתום = FF, אדום = Opera. מקור: wikipedia

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

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

קצת היסטוריה: מאיפה הגיע ה Quirks Mode וה Standards Mode?

בשנות ה-90 דפדפן אינטרנט הייתה תוכנה ייעודית עבור אלו שהתעסקו ב"אינטרנט", לא משהו מובן מאליו[ד]. היו מספר דפדפנים חינמיים (מבוססים על מנוע בשם מוזאיק, שפותח ע"י גוף ממשלתי של ארה"ב) אך הדפדפן שהתבלט היה  Netscape Navigator - שפותח ע"י חברה מסחרית קטנה שזה היה כל עיסוקה.
Netscape שיפרה את חווית הגלישה והפכה אותה לנוחה יותר. היא למשל פיתחה את קונספט ה "bookmarks" שזכה להצלחה רבה. השיפורים הללו הקנו לה יתרון ומשתמשים החלו לשלם כסף עבור "דפדפן יותר טוב". Netscape Navigator הפך לדפדפן הנפוץ ביותר בעולם.

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

אמנם ל Netscape היה יתרון שכבר היה לה מוצר קיים, אך תוך שנתיים מרגע השחרור של IE1 מייקרוסופט שחררה את IE4 שכבר נחשב למוצלח יותר מזה של חברת Netscape. הדפדפן של Netscape היה מבוסס על "קוד ספאגטי" והפיתוח על בסיס בקוד הקיים היה קשה. גרסה 5 של הדפדפן בוטלה לאחר שהפיתוח שלו התמשך והתמשך ללא תוצאות. ה Technical Debt הגדול הכריע את חברת Netscape והיא החלה לפתח דפדפן חדש מאפס. במקביל היא ביצעה כמה צעדים, נואשים אולי, על מנת להתמודד עם מייקרוסופט, ביניהם תרומה של הגרעין של הקוד שלה לארגון Open Source שהוקם בשם מוזילה (על מנת לאפשר ייצורם של "תואמי Netscape" חינמיים שיזנבו ב IE) ומיזוג לתוך חברת התקשורת AOL.

הפיתוח של Netscape Navigator 6.0 התמשכה והתמשכה והפכה לבדיחה בתעשייה: דוגמה לסכנה הטמונה בפרויקט Next-Generation. מייקרוסופט שחררה בינתיים את IE5 וסיימה את כיבוש שוק הדפדפנים.
Netscape Navigator 6.0 ששוחרר בשנת 2000 כבר איחר את המועד ולא הצליח להתרומם. מייקרוסופט מחצה את התחרות.

נתח השוק של דפדפנים בין 96 ל 2009. מקור: wikipedia

עם נתח שוק של בערך 90% מייקרוסופט לא ראתה אף אחד ממטר. היא הגדירה הרחבות לא סטנדרטיות ל HTML, DOM ועוד ועודדה את המפתחים בעולם להשתמש בהם. ניתן להניח שזו הייתה דרך לבצע "Lock-In" של המפתחים ל IE.
בנוסף לכך, מייקרוסופט לא הצטיינה בהצמדות לסטנדרטים. אמנם הדפדפן שלה היה עדיף על זה של Netscape - אך עושר ה Features הוא מה שיצר את הייתרון - לא הדיוק בסטנדרט. נוצר בפועל סטנדרט חדש: "כמו-IE".

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

הנה דוגמה מפורסמת: לתיבה ב HTML (נאמר, אלמנט div) יש רוחב וגובה. ניתן להוסיף לתיבה margin ו padding - שהם ריווחים מבפנים ומבחוץ, וגם מסגרת בעלת עובי. אם קבעתי תיבה ברוחב 100 פיקסלים והוספתי לה מסגרת בעובי 2 פיקסלים (מכל צד) - האם היא תתרחב לרוחב כולל של 104 פיקסלים, או האם התוכן בתוך התיבה יצטמק ל 96 פיקסלים? זה עניין של פרשנות. המתכנתים של מייקרוסופט ושל Netscape פירשו זאת בצורה שונה.

פרשנות שונה ל box model, ע"פ Netscape (שהפך לתקן ה W3C) ומייקרוסופט. מקור: wikipedia

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

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

זוכרים את הקוד ש Netscape תרמה לארגון מוזילה? ארגון מוזילה המשיך, בשקט בשקט, לפתח את הקוד ובשנת 2004 מוזילה שחררה דפדפן חדש בשם פיירפוקס (שועל האש). פיירפוקס הכיל חידושיים אמיתיים בחווית הגלישה, כשהבולטים בהם הם השימוש בטאבים והקלות בפיתוח Plug-Ins. מייקרוסופט מצידה נרדמה בשמירה והצהירה ש FF לא מהווה איום עליה. רק בגרסה 3, בערך (שנת 2008), FF היה מספיק בוגר ומהיר על מנת שייחשב כעליון על IE6. אחד המאפיינים הבולטים שלו היו מהירות גבוהה, מהירות שגרמה ל IE6 להראות כמו מוצר שנזנח במשך חצי עשור.

נראה שמייקרוסופט התעוררה בסוף 2007, כשגרסאות בטא של FF3 היו זמינות בשוק - והיתרון של FF היה ברור. היא הסירה את הדרישה לבדיקות רישיון חוקי (Windows Genuine Advantage) כתנאי להתקנת IE7 (כל הישראלים היו תקועים עד אז עם IE6) והעירה את צוות הפיתוח שלה מתרדמת ארוכה והחלה לפתח את IE8 במרץ. IE8 סיפק תמיכה טובה בהרבה מ IE7 בסטנדרטים (כלומר: תמיכה סבירה) ומייקרוסופט ניסתה את מזלה ביצירת חווית גלישה חדשה בעזרת  ה Accelerators - ניסיון שנכשל.

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

מוזילה, בניגוד למייקרוסופט, הייתה קפדנית מאוד בהצמדות לתקנים. היא חרטה את התאימות לתקנים על דגלה והצליחה להביך את מייקרוסופט לא פעם. המשתמשים בחרו בפיירפוקס כיוון שהיה מהיר יותר, נוח יותר ומגניב יותר - אך הדיון בצורך בתקנים והתאמה של אתרים לדפדפנים שאינם IE חזרה לתודעה הכללית.
IE6, וכל גרסאות IE שיצאו אחריו, עדיין מאפשרים להריץ דפי אינטרנט בדיוק כפי שרצו על IE5.5 - דפדפן משנת 2000. למייקרוסופט הייתה חשובה התאימות לאחור והיכולת להריץ כהלכה דפי אינטרנט ישנים. מוד הרצה זה נקרא "Quirks Mode". הוא זמין רק על גבי דפדפני IE, למרות שאופרה ו FF מספקים Quirks Mode Emulation (בקיצור QME) - מצב שבו דפדפנים אלו מציגים "בקירוב" דפים ישנים של IE.

עד היום FF הוא הדפדפן המחמיר ביותר בהצמדות לתקן. אפילו Chrome "מוכן לוותר לפעמים למפתחים". הנה דוגמה פשוטה: URLs לתמונות בתוך קבצי CSS מחושבים יחסית למיקום של קובץ ה CSS. פיירפוקס לא יאפשר לנהוג אחרת. ספארי, כרום וIE ינקטו גישה מקלה ואם הם לא מוצאים את התמונה במקום המצופה, הם ינסו שוב בהנחה שה URL הוא יחסית לדף ה HTML - טעות נפוצה של מפתחים. האם הקלה בתקן היא דבר טוב? היא חוסכת מהמפתחים לתקן את הקוד שלהם - אך מאפשרת יצירה של דפי אינטרנט לא תקניים. A Tradeoff.

בחזרה לעתיד: שנת 2010

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

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

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

תאימות של דפדפנים ל HTML5. מקור: html5test.com

2. בעוד כרום ופיירפוקס מעדכנים את גרסת הדפדפן אוטומטית, IE יתעדכן רק בעקבות הסכמה מפורשת של המשתמש.
בנוסף לזאת, IE מציבה קשיים בעדכון של גרסאות חדשות: אם אתם רוצים את IE9 עליכם להיות בעלי Windows Vista SP2 ומעלה. עבור IE10 תאלצו להיות בעלי Windows 7 ומעלה.

הווה אומר: משתמשי Windows XP, שהם עדיין רוב משתמשי ה Windows בעולם, לא מסוגלים לשדרג ל IE9 - הדפדפן הראשון של מייקרוסופט שניתן לייחס לו תמיכה סבירה ב HTML5. מצד שני, אין להם בעיה להשתמש בגרסאות האחרונות של כרום או פיירפוקס - מה שמצביע שההחלטה של מייקרוסופט נובעת משיקולים עסקיים. נראה שIE נדרש "לדחוף" שדרוגים של מערכת ההפעלה Windows, ואינו חופשי להתחרות בצורה "חופשית לחלוטין" מול הדפדפנים האחרים.

קצב השדרוג של גרסאות IE מול גרסאות כרום - הבדל דרמטי וקריטי. מקור: ArsTechnica

אם משווים את התמיכה ב HTML5 עבור ה"משתמש הממוצע של כרום" מול תמיכה ב HTML5 עבור ה"משתמש הממוצע של IE" הפער הוא אדיר. הרכיבו את שני התרשימים האחרונים בכדי להבין את גודל הפער.

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

יש פה משהו לא הוגן כלפי מייקרוסופט: התמיכה של IE בגרסאות ישנות נובעת מלקוחותיה שדורשים זאת. מייקרוסופט מחויבת לתמוך בכל מוצריה 10 שנים מרגע ששוחררו. ארגונים המפתחים תוכנות ארגוניות (בניהם גם SAP) לא רוצים לבצע בדיקות, כל 6 שבועות, שהתוכנה עובדת שלהם כמו שצריך. בפעמים רבות מדובר ב"מסכים" ישנים שאף אחד לא נגע בקוד שלהם במשך שנים - אך הם עדיין שימושיים. גרסה יציבה וידועה של הדפדפן חוסכת מכותבי התוכנה את הצורך בבדיקות רגרסיה מול גרסאות חדשות, ומהלקוח את מפח הנפש כאשר משהו לא יעבוד.
ולמה שמשהו לא יעבוד? חחחחח..... זו שאלה מצחיקה. IE6 למשל, הוא רחוק למדי מהסטנדרטים. עצם המעבר לתמיכה בסטנדרט עשויה לגרום לקוד הישן, הלא סטנדרטי, להפסיק לעבוד.
התמיכה של IE אחורה היא חרב פיפיות: ארגונים רבים לא נוטשים את IE בגלל התמיכה הזו, ומצד שני התמיכה הזו מקשה על IE להפוך לסטנדרטי ולהתקדם קדימה.

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


Internet Explorer 10
אז אולי למייקרוסופט לא יהיה את הדפדפן הנפוץ או הטוב ביותר בשוק - מה הבעיה?

• פגיעה במנוע החיפוש Bing. גם כאשר הוא מנוע החיפוש המסופק כברירת מחדל ב IE, משתמשים שונים מחליפים אותו ל Google. פחות חיפושים => פחות הכנסות מפרסום.
• מוצרים רבים של מייקרוסופט הם מוצרי ווב. למשל: Office 365 ו Azure. הבעלות על דפדפן, והיכולת לקדם "סטנדרטים" בדפדפנים הם רוח גבית שמסייעת לשלמות של פתרונות הווב של מייקרוסופט. מגמה של אתרים שיפסיקו לתמוך ב IE, אם תהיה כזו, תפגע קשה ביכולת של מייקרוסופט לקדם מוצרים בעזרת הדפדפן.
• Windows 8 הופך להיות מבוסס ווב ו JavaScript. השינוי הארכיטקטוני הגדול של מייקרוסופט ב Windows Vista (שהיה אסטרטגי, אך לא עניין את המשתמשים) היה לעבור ל Kernel מצומצם יותר ולהפוך את ה CLI (ה virtual machine של .NET) לסביבת ההרצה העקרית של Windows. חזון יפה ושאפתני.
  אבל מאז מחשבי הטאבלט הפכו למציאות ארגונית בה למייקרוסופט אין כרגע נוכחות. ההשקעה בפתרונות התלויים ב.NET ולא יכולים לרוץ על מחשבי טאבלט של אפל או אנדרואיד היא החלטה מגבילה למדי עבור ארגונים רבים. מייקרוסופט נאלצה להתכופף ברגע האחרון ולהפוך את JavaScript ו HTML5 ל "First Class Citizens" של Windows 8, אולי אפילו על חשבון טכנולוגיות .NET (נוכל לדעת זאת עם הזמן). הדבר העצוב עבור מייקרוסופט הוא ש IE10 שיתמוך באסטרטגיה הזו עתיד להיות בעת השקתו דפדפן בינוני למדי - יחסית לשאר הדפדפנים הזמינים [ג].

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

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

----

קישורים רלוונטיים:
ההיסטוריה של אינטרנט אקספלורר (מפורט)

----

[א] ההערכה שאני מכיר היא שבתוך ארגונים IE מהווה בערך 70% מסך הדפדפנים. זוהי הערכה פנימית ששמעתי במסגרת העבודה. אין לי מקורות חיצוניים ע"מ לחזק אותה.

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

[ג] מייקרוסופט תטען אחרת, כנראה. אחד הגורמים שבהם מייקרוסופט מנסה "למכור" לנו את העליונות של IE10 היא בדיקות ביצועים של Canvas (כתיבה ישירה ל"מסך") ו WebGL. דפדפן IE אכן נהנה מיתרון בכל הנוגע ל Hardware Acceleration במערכות Windows - אך זה רק מימד אחד ולא כ"כ קריטי לדעתי.

[ד] הדפדפן הראשון, אגב, נקרא WorldWideWeb ונכתב ב Objective-C - שפה לא-חדשה בעליל.

[ה] הנה תגובתה של מייקרוסופט. http://windowsteamblog.com/ie/b/ie/archive/2012/03/18/understanding-browser-usage-share-data.aspx.

מבוא מואץ ל JavaScript עבור מפתחי Java / #C מנוסים - חלק 1

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

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


שייך לסדרה מבוא מואץ ל JavaScript ו jQuery

למה JavaScript?

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

• בעוד ה JVM של ג'אווה רץ על "כל שרת" - עובדה שסייעה לג'אווה להפוך למאוד נפוצה, ג'אווהסקריפט יכולה לרוץ על כל פלטפורמות ה JVM (בעזרת Rhino) ובנוסף - גם על דפדפנים ועל iOS -> שתי פלטפורמות אסטרטגיות שחשיבותן רק הולכת ועולה. תאהבו את זה או לא, אבל ג'אווהסקריפט היא שפת התכנות האוניברסלית ביותר שקיימת כיום.
• ג'אווהסקריפט היא "מונופוליסטית": אין שפה אחרת שנתמכת ע"ג כל הדפדפנים החשובים.
  בניגוד ל JVM וה CLI שמריצים ByteCode ולא מודעים לשפה שבהם ה ByteCode נכתב (וכך נפתח פתח ל JRuby, סקאלה ועוד) JavaScript היא שפה מפוענחת (interpreted) והמנועים של ג'אווהסקריפט שפרוסים על הדפדפנים יודעים להריץ רק אותה.
• ג'אווהסקריפט טובה לבניית UI. בניגוד לג'אווה שבמשך שנים ניסתה וניסתה - אך נכשלה, בג'אווהסקריפט ניתן לכתוב UI יפה ובצורה קלה. (על בסיס HTML ו CSS - כמובן).
• לג'אווהסקריפט יש בסיס מתכנתים גדול. הרבה מפתחי #PHP, Ruby, C וג'אווה - יודעים גם קצת ג'אווהסקריפט. יש איזה ייתרון בלהיות שפה זקנה בת 17.
• לג'אווהסקריפט אין הרבה מתנגדים. אין פה מלחמה בין אורקל למייקרוסופט, בין גוגל לפייסבוק וכו'. ג'אווהסקריפט נמצאת בעין הסערה.

ע"פ ה HTTP Archive, למשל, פרויקט שעוקב אחרת מגמות באתרי האינטרנט הגדולים, כמות הג'אווהסקריפט בשימוש באתרים שבמדגם זינקה ב 50% בשנה האחרונה בלבד.

כמה ג'אווהסקריפט יש בדפי אינטרנט של אתרים מפורסמים? הממ... זה גדל! מקור: pingdom.com

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

טעות מס' 1: "אני מכיר את ה Syntax". זהו C-Syntax. אני אסתדר Along the way.

המציאות: Java ו JavaScript דומים אחד לשני כמו "Car" ו "Carpet": בעיקר בשם.
הקוד הבא אכן נראה מוכר למדי:

for (i = 0; i< set.length; i++) {
  set[i].doSomething();
}

האם אתם יכולים לומר בוודאות באיזו שפה כתוב קוד זה? אני בספק.
אם אתם מדמיינים כך את הג'אווהסקריפט שתתקלו בו - אתם טועים. מהר מאוד תתקלו בביטויים כמו prototype, הסימן $ שמופיע המון, משתנים עם קווים תחתונים __ ובכלל - סגנון זר ולא מוכר. זהו אמנם C-Sytnax - אך יש בו מספיק אלמנטים לא מוכרים על מנת לבלבל אתכם לגמרי.

למשל, האם אתם יכולים להסביר מה עושה הקוד הבא (שכתוב ב C-Syntax)?

Function.prototype.bind = function(){
  var fn = this, args = Array.prototype.slice.call(arguments), object = args.shift();
  return function(){
    return fn.apply(object, args.concat(Array.prototype.slice.call(arguments)));
  };
};

טעות מס' 2: לחפש דוגמאות קוד והסברים באינטרנט.

המציאות: פעם סיפרתי איך שמם הטוב של האקרים נהרס בגלל הפצה של כלים פשוטים לפריצה - שהמשתמשים בהם לא ידעו כמעט כלום על Hacking באמת. ההאקרים קראו לאלה Script Kiddies - מריצי סקריפטים.
בעולם הג'אווהסקריפט יש תופעה דומה. המון ממשתמשי הג'אווהסקריפט הם לא מתכנתים מקצועיים - אלא משתמשים לא מקצועיים ש"בונים אתרי אינטרנט". אני קורא להם: ה-JS Kiddies.
התוצאה היא שיש המון חומר ברמה נמוכה באינטרנט, בפורומים ובכלל. אם תחפשו סתם כך בגוגל יש סיכוי גבוה למדי שתקבלו עצות חלקיות, תקראו tutorials שלא מגרדים את עומק השפה ותראו דוגמאות קוד לא מקצועיות.

קחו לדוגמה את האתר W3Schools - אתר reference לטכנולוגיות ווב המוכר. לאתר, מסתבר, אין שום קשר ל W3C והוא התבקש ע"י ה W3C, כמה פעמים, לשנות את שמו. מדוע?
האתר כולל שגיאות גסות בנוגע ל HTML, CSS וג'אווהסקריפט בכלל. אמנם הוא עושה רושם רציני - אך העובדות מדברות בשם עצמן. W3Fools - אתר שאוסף (חלק מ-) השגיאות וחוסרי הדיוקים של W3Schools, ממליץ למשל לחפש בגוגל עם "w3schools-", כלומר: רק תוצאות שלא כוללות את W3Schools. בהסתמך על הפופולאריות של W3Schools וכמות הפעמים שהוא מופיע בגוגל - זו עצה לא כל-כך רעה...


טעות מס' 3: "הבנתי. משהו פה לא עובד. נקרא את התיעוד הרשמי מקצה-לקצה כך שלא יהיו לנו הפתעות".

המציאות: כשלמדתי Java באמת הלכתי ל Spec - אך זו הייתה שפה ראשונה והייתי סטודנט צעיר. כשניסיתי לקרוא את התיעוד המומלץ של ג'אווהסקריפט - מצאתי את עצמי משתעמם מהר מאוד. רוב מה שכתוב שם הוא ברור מאליו למי שמכיר את ג'אווה או #C לעומק.

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

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

בהמשך הסדרה אני עוסק ב jQuery, מקור מקיף לגבי ה DOM הוא DOM Enlightenment. עוד חומר על פיתוח ווב תוכלו למצוא באתר העברי אינטרנט-ישראל.



כמה הבדלים בסיסיים בין JavaScript וג'אווה:

הערה: אני מקצר וכותב "ג'אווה" בלבד, אך מה כתוב כאן רלוונטי באותה מידה ל #C.

Scope
בג'אווה, Scope נוצר ע"י סוגריים מסולסלים, יהיה זה משפט if, לולאת for או סתם סוגריים שהוכנסו בתוך הקוד.
בג'אווהסקריפט Scope נוצר רק על ידי פונקציה. הנה דוגמה להתנהגות הצפויה (מקור: javaScriptGarden):

function test() { // a scope
  for(var i = 0; i < 10; i++) { // not a scope
    // do something
  }
  console.log(i); // 10
}

Global Scope
מה שלא מוגדר בתוך ה Scope של הפונקציה - שייך ל Scope הגלובלי. דריסות הדדיות הן תקלה שכיחה.

// Defined in Global Scope
foo = '42';

// Defined in "current" scope. Either function or global
var foo = '42';

קצת יותר גרוע היא העובדה שאם הגדרתם משתנה בתוך פונקציה ללא המילה השמורה "var" - אותו משתנה יוגדר אוטומטית ב Scope הגלובלי.
שכחתם? התבלבלתם? בזמן Refactoring מחקתם את ה "var" - בעיה שלכם.

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

weddingParticipantsCounter = 100;

function acceptParticipation(name) {
weddingParticipnatsCounter = weddingParticipantsCounter + 1;
alert('Registration Accepted: ' + name);
}

acceptParticipation("Mr. President");
acceptParticipation("The First Lady");
console.log(weddingParticipantsCounter); // -> 100?!

האם אתם יכולים להסביר מה השתבש? [א]

איך מתמודדים עם pitfall שכזה שבנוי בתוך השפה? כלי וריפיקציה בשם JSLint יספק הזהרה, אם אתם עובדים ב IDE שמריץ אותו תוך כדי כתיבה - יש סיכוי שתצליחו להימנע מכמה תקלות. הבעיה ב JSLint (או חברו JSHint) הוא שההזהרות שהם מספקים נכונות רק ל 90% המקרים ואתם נשארים עם רשימה של Warnings לא מטופלים - גם כאשר יש לכם קוד נפלא.
CoffeScript היא דרך נוספת להתמודדות. הוא לדוגמא מוסיף var מאחורי הקלעים לכל הגדרה.

Hoisting
חשבתם שהדברים מסתדרים? שימו לב לכלל הבא: הקוד בג'אווהסקריפט לא ירוץ ע"פ הסדר שבו הוא נכתב.
אני חוזר: הקוד בג'אווהסקריפט לא ירוץ ע"פ הסדר שבו הוא נכתב.

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

התבוננו על דוגמת הקוד הבאה:

var n = 1;
function foo() {
    if (false) { var n = 10; }
    console.log(n);
}
foo();

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

אני מניח שהעובדה שללוג נכתב הערך "undefined" - עלולה להיות מבלבלת. "undefined" הוא ה null של ג'אווהסקריפט (יש גם null, אבל לא משתמשים בו הרבה. הוא כמו "ערך נוסף" שמשתמשים בו בכמה מקרים מסוימים - אך כ"קונבנציה". נראה שניתן היה להשתמש ב "undefined" במקרים אלו באותה המידה [ב]).

הקוד שבעצם רץ, לאחר פעולת ה hoisting, הוא זה:

var n;
function foo() {
    var n;
    if (false) { n = 10; }
    console.log(n);
}
n = 1;
foo();

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

n מוגדר ב scope של הפונקציה ולכן הוא "מחביא" את n שהוגדר ב global scope.

כיוון שהתנאי "false" לא מתרחש במקרה זה, n נשאר undefined עד לנקודה בה הערך נכתב ללוג.

מה עושים? 

שומרים במשמעת ברזל על הכלל הבא:

• כל הגדרות ה var וה function יהיו תמיד בראש ה scope הנוכחי, אם זה הקובץ (גלובלי) או הפונקציה.

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

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

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

אם כן - זה יכול להיות Case Study טוב ב Pre-Sale. אני מניח שלא מעט תוכנות ארגוניות נהנות מהמנגנון הזה.

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

אני יודע (ע"פ סטטיסטיקות של Google Analytics) שאם אתם קוראים את הבלוג הזה יש סיכוי של 50% שאתם משתמשים בכרום, ועוד כ 20% שאתם משתמשים ב FireFox. לשני הדפדפנים הללו יש סביבת פיתוח לא רעה בכלל לג'אווהסקריפט שניתן להתחיל להשתמש בה מיד. אם אתם עדיין תקועים עם IE - השיגו לכם כרום. הגיע הזמן.

הנה דוגמא פשוטה כיצד להריץ קוד ג'אווהסקריפט אם אתם רצים בכרום. אתם יכולים לעשות זאת מבלי לאתחל את הדפדפן. פשוט פתחו טאב חדש, לחצו על הכפתור הימני של העכבר בתוך הדף, בחרו את "Inspect Element" - כניסה מהירה לכלי הפיתוח של כרום, עברו ל Console והנה יש לכם Interpreter ג'אווהסקריפט איכותי:

הנה אני מקליד בו איזו פיסת קוד:

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

אובייקטים ופונקציות

Object Literal

{};

כך יוצרים בג'אווהסקריפט אובייקט. זהו אובייקט ריק.


בפועל אובייקט הוא רשימה של תכונות:

var myObj = { a: "Hello", b: "World" };

אם התחביר נראה לכם מוכר, נסו להיזכר מהם ראשי התיבות של JSON. הא!

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


פונקציות הן אובייקטים
בג'אווהסקריפט, פונקציות הן אובייקטים לכל עניין ודבר. על כן, אין לי מניעה לכתוב את הקוד הבא:

function foo(text) { console.log(text); }
foo.x = 4;
foo(foo.x);

שידפיס כמובן את הערך 4.

Anonymous Functions

ג'אווהסקריפט בדפדפן היא שפה עשירה מאוד בשימוש בevents ולכן התחביר של Anonymous Functions הוא קצר ונוח. לדוגמה:

obj.doSomething(function(event) { console.log(event.getMessage()); });

הדרך המומלצת להגדרת פונקציות בג'אווהסקריפט היא להגדיר פונקציות אנונימיות ולבצע השמה למשתנה:

var foo = function(text) { console.log(text); };

בלינק זה תוכלו למצוא כמה דוגמאות מה יכול לקרות לכם אם לא תעשו זאת (מוהא-הא-הא!).

על מנת למנוע דריסה של פונקציות, אפשר להשתמש ב namespace:

var myNS = myNS || {}; // if namespace myNS exists - use it, else create a new namespace.
myNS.foo = function(text) { console.log(text); };

Closure

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

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

function simpleFunction() {
  var x = 4;
}
// x no longer exists

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

function Counter(start) { // closure

  var count = start;
  return function() { // function with scope
      return ++count;
  }
}

var c = Counter(4);
// count still exists
c(); // 5
c(); // 6

המשתנה c מחזיק reference לפונקציה הפנימית של Counter, והיא מצידה מחזיקה reference למשתנה count - וכך הוא נשמר בחיים. 

בואו נסתכל בדוגמא לבעיה שיכולה להיפתר ע"י שימוש ב Closure.

בדוגמת קוד תמימה זו, אני משתמש ב anonymous function מהסוג שהזכרנו קודם לכן על מנת לממש Listener. זוהי פעולה נפוצה למדי בג'אווהסקריפט. אני מגדיר פונקציה פשוטה למדי שתכתוב לערכים לlog.
התוצאה הצפויה היא, אם כן, ספירה מ 1 עד 15 ל log.

var listeners = []; // array

// fill up some listeners
for (var i = 0; i < 15; i++) {
  listeners.push(function() { console.log(i); });
}

// trigger an event to all listeners. Each one counts.
for (var j in listeners) {
  listeners[j](); // execute
}

התוצאה בפועל היא 15 פעמים המספר "15".
הסיבה לכך היא כזו: הפונקציה שנוצרת בתוך לולאת ה for מתייחסת למשתנה i, אבל i הוא משתנה בסביבה הגלובלית. נזכיר שסוגריים מסולסלים לא מייצרים scope. בנוסף - הפונקציה אינה מחושבת בזמן ההגדרה, אז בפועל נוצרות לנו במערך ה listeners חמש עשר עותקים של פונקציה שתוכנן הוא (console.log(i.

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

הדרך לפתרון היא להוסיף Closure שישמור (או "יקפיא") את ערך המשתנה i, עבור הרגע בו הוגדרה הפונקציה:

var listeners = []; // array

function eventHandler(i) { // outer function = closure

  return function() { // inner function

    console.log(i);

  }

}

// fill in the listeners (syntetic)
for (var i = 0; i < 15; i++) {
  listeners.push( eventHandler(i) );
}

// trigger an event to all listeners. Each one counts.
for (var j in listeners) {
  listeners[j](); // execute listener
}

בדוגמה זו, הפונקציה eventHandler מבוצעת בתוך הלולאה. הערך i עובר אליה כפי שהוא, ואז נלכד "לנצח" בתוך ב closure. טוב, לא ממש לנצח - אולי עד שנגלוש לדף ווב אחר.

הפונקציה שנשמרת במערך listeners היא כבר הפונקציה הפנימית והרצתה תגרום לכתיבת הערך המצופה, קרי 0 עד 14.

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


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

מקווה שנהניתם!


פוסט ההמשך בו אדבר על מבנים בג'אווהסקריפט ומשמעותם.


---

[א] קצת אכזרי, אך זו מהמציאות: weddingParticipnatsCounter = weddingParticipantsCounter + 1. ג'אווהסקריפט זיהה משתנה לא מוכר ובמקום להטריד את המתכנת - טרח והגדיר אותו בשבילו. איזה יופי!
IDE טוב היה מספק value highlighting שאולי, היה יכול לעצור מוקדם את התקלה.

[ב] האם זו טעות תכנונית שתעלה למשק העולמי 2 מיליארד דולר?