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

זהו פוסט המשך. את החלק הראשון תוכלו למצוא כאן.

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

האם JavaScript היא שפת Object Oriented? - תלוי את מי שואלים.
פורמלית, ג'אווהסקריפט מוגדרת כ Object-Oriented Language מול Class Oriented-Languages שהן ג'אווה ו#C. יש שוני שהדגש הוא על אובייקטים - לא מחלקות. בואו נשים את הפורמליסטיקה בשלב זה בצד.

התשובה שלי היא כזו: ג'אווהסקריפט היא יותר סט של כלים (toolkit) בו ניתן להשתמש בכדי לכתוב קוד OO. ניתן גם לכתוב בה קוד פונקציונלי ואולי אפילו גם קוד לוגי. השפה לא תחייב אתכם ל OO וכמעט לא תסייע או תנחה. זוהי גישה שונה למדי משפות כמו #C או Java שהן שפות OO מוצהרות ומכוונות את המפתח להשתמש בהן ככאלו.

אם תרצו לכתוב OO איכותי בג'אווהסקריפט - תדרשו להפעיל לא מעט משמעת עצמית. הקלות בה ניתן לבצע "תרגיל" (hack) בקוד ג'אווהסקריפט היא מדהימה, אנו נזדקק למנגנונים חברתיים (למשל Code Review) או טריגרים אוטומטיים (JSLint / JSHint) על מנת לשמור על קוד OO נקי ומסודר.

הכמסה
מהו העיקרון החשוב ביותר של Object Oriented? נכון: הכמסה (אם אתם חושבים אחרת - אז זהו פוסט בשבילכם).
הדרך הבסיסית להשיג הכמסה בג'אווהסקריפט היא בעזרת Closure:

(function() {
  var n = 2;
  var addBy = function(num, x) { return num + x; }
  var multiplyBy = function(num, x) { return num * x; }

  n = addBy(n, 2);
  n = multiplyBy(n, 3);

  console.log(n);
}());

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

שימו לב לחשיבות להגדיר את המשתנים ואת הפונקציות הפנימיות בעזרת var. ללא var, הפונקציה / המשתנה יוגדרו ב global scope.
באפליקציות ג'אווהסקריפט, רוב הקוד שנכתוב יהיה private - אף אחד לא אמור לקרוא לו. אנו ניגש ל DOM, נייצר UI, נרשום אירועים ונגיב אליהם - את כל זה אפשר לעשות מבלי "ללכלך" את ה global scope. אין סיבה שלא תעטפו את כל הקוד האפליקטיבי שלכם, שאינו מספק שירותים לקוד אחר - בצורה זו.
עבור ספריות שבהן נרצה לחשוף פונקציות לשימוש חיצוני - הסיפור הוא אחר.

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

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


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

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

בואו נתבונן כיצד המילים השמורות prototype ו new בשפה מאפשרת לנו לנהל "אובייקטים":

var Calculator = function () { // constructor
  this.value = 0;
};

Calculator.prototype = { // prototype = Object Literal
  addBy: function (x) {
    this.value += x;
    console.log('value = ' + this.value);
  }
};

// alternate way to define method, less recommended
Calculator.prototype.multiplyBy = function (x) {
  this.value *= x;
  console.log('value = ' + this.value);
};

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

הורשה בג'אווהסקריפט מבוטאת ע"י שרשרת של קשרי prototype - לכל אובייקט יש אב שמסומן ב property בשם __proto__. ב default זה יהיה האובייקט Object - האב המשותף לכל האובייקטים בשפה. המילה השמורה prototype מייצגת את המשתנה __proto__ (שלא אמורים להשתמש בו ישירות, אך הוא שימושי ל debug).

בשלב הבא אנו מחליפים את ה prototype של הפונקציה Calculator (שהיה עד כה האובייקט Object) לאובייקט שאנו מגדירים (בעזרת תחביר של object literal). ההחלפה תשפיע על כל instance חדש שייווצר מ Calculator בעזרת המילה השמורה new.

לבסוף, אנו מוסיפים מתודה נוספת לאובייקט שנוצר.


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

לאחר הגדרה זו, אנו יכולים לייצר instances ולהפעילם בצורה הבאה:

var calc = new Calculator();
calc.addBy(4);
calc.multiplyBy(6); 
> 24

בואו נסכם מה קיבלנו:

• יצרנו מעין "מחלקה"* שניתן לייצר instances שונים שמתנהגים אותו הדבר. השימוש במילה "מחלקה" היא הרגל מג'אווה, הוא לא מדויק כאשר אנחנו מדברים על ג'אווהסקריפט. בעצם יצרנו אובייקט Prototype (אב-טיפוס) שבקריאה ל new ייווצר instance חדש שלו. סלחו לי אם אני ממשיך להשתמש ב"מחלקה" - הרי זה פוסט למפתחי ג'אווה / #C.
• אנו יכולים להוסיף דינמית ל"מחלקה" זו מתודות או משתנים ע"י שימוש במילת ה prototype. האמת, כל אחד יכול. גם מפתח אחר שכותב קוד בקובץ אחר משלכם ומודע למחלקה בדרך-לא-דרך.
• חשוב!: השימוש ב this בתוך המתודה, כמו addBy, הוא חיוני על מנת לגשת ל instance / אובייקט. 
• הקוד של פונקציות (addBy) נטענות לזיכרון פעם אחת בלבד. זה עשוי להישמע מוזר, אך במבנים אחרים, שנגיע אליהם עוד מעט, הגדרת הפונקציה תוכפל בזיכרון עבור כל אובייקט שנייצר. ההשלכה היא זמן יצירה ארוך יותר של אובייקטים ותפוסת זיכרון גדולה יותר - בעיה משמעותית אם אנו עומדים לייצר מאות או אלפי אובייקטים מאותו הסוג.
• בעזרת השימוש ב Object Literal ה"מחלקה" מוגדרת בשני חלקים. ניתן גם להגדיר על פונקציה כהשמה חדשה ל Prototype וכך ליצור אובייקט שהגדרתו אינה בהכרח רציפה בקוד. רציפות זו כמובן רצוייה - ועל כן צורת ה Object Literal נראית לי עדיפה.

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

למרות שכמה ספריות נפוצות (למשל Prototype.js) עושות תרגילים שכאלו - זו נחשבת התנהגות לא רצויה ולא מומלצת בעליל. כדאי להימנע ממנה לגמרי.
רק להזכיר סיבוך אחד אפשרי: בג'אווהסקריפט אובייקטים הם "שקים" של properties (מעין HashTable או Map) - ולעתים קרובות אנו מתייחסים אליהם ככאלו. כל אובייקט יציג את ה properties שהוגדרו עליו ישירות וגם על כל שרשרת ה prototypes שהוא קשור בה. שינוי (הוספה / מחיקה) של property לאחד ה prototypes - יכול לשבור קוד קיים במספר תסריטים. ההמלצה היא לנקוט באחת משתי גישות:

• בכל גישה ל property של אובייקט - לבדוק שה property באמת שלו (קריאת hasOwnProperty)
• להימנע לחלוטין משינויים ב prototypes מלבד הגדרת ה"מחלקה".

אתם בוודאי מנחשים איזו גישה קלה יותר ליישום.

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

var Calculator = function () {
  // private members
  var value = 0;

  return {
    // public members
    addBy : function (x) {

      value += x;
      console.log('value = ' + value);

    },

    multiplyBy : function (x) {

      value *= x;
      console.log('value = ' + value);

    }
  };
};


var calc = new Calculator();
calc.addBy(4);
calc.multiplyBy(6); // 24

הבסיס כאן הוא דיי פשוט: נשתמש ב Closure על מנת לבצע הכמסה ונשתמש בערך החזרה מסוג Object Literal על מנת לאפיין את המחלקה.
הפונקציה Calculator (=קונסטרקטור) מגדירה משתנים ופונקציות בתוך עצמה, בתוך ה Closure. בנוסף היא מייצרת אובייקט (בעזרת Object Literal) שחוזר למי שקורא לה - במקום this. לא ציינתי קודם, אך קריאה ל new תחזיר את this רק במידה ולא הוגדר return value מפורש. אם הוגדר return - אזי הוא מה שיחזור.

שימו לב שבעזרת החזרה זו נוצר ההבדל מהדוגמה הקודמת: הערך החוזר מהקונסטרקטור הוא לא instance של הפונקציה Calculator עצמה, אלא אובייקט שאנו יצרנו ואנו שולטים בו. אובייקט זה מייצג את החלקים ה public של האובייקט שלנו. כמובן שבג'אווהסקריפט אין type safety ואין שום בעיה שקונסטרקטור יחזיר אובייקט מ"טיפוס" אחר.
כיוון שיש לנו פונקציה בתוך פונקציה, ויש reference מהפונקציה addBy למשתנה value - מובטח לנו שהמשתנה value ימשיך לחיות גם לאחר שהפונקציה Calculator הסתיימה. אם אתם לא זוכרים מדוע - חזרו להסבר על Closure בפוסט הקודם.

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

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

מבנה זה הוא דיי מקובל ונקרא "Module".

הנה וריאציה קצת שונה של Module:

var myNS = myNS || {};

myNS.Calculator = function () {
  // private members
  var value = 0;

  var addBy = function (x) {
    value += x;
    console.log('value = ' + value);
  };

  var multiplyBy = function (x) {
    value *= x;
    console.log('value = ' + value);
  };

  return { // public parts (aka interface)
    addBy : addBy,
    multiplyBy : multiplyBy
  };
};

var calc = new myNS.Calculator();
calc.addBy(4);
calc.multiplyBy(6); // 24

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

בנוסף עשיתי עוד שדרוג קטן והגדרתי את המודול בתוך namespace. באופן זה אני מצמצם משמעותית את היכולת של ה Constructor להידרס ע"י מפתח אחר שגם במקרה בחר בשם Calculator. ייתרון נוסף ב namespace הוא ב Debugging, כאשר אוכל למצוא בקלות את המשתנים שלי בתוך ה namespace - ולא בערמה אחת עם כל משתני המערכת. ייתרון זה בא לידי ביטוי במיוחד כאשר יש כמה מפתחים על אותו הקוד. עדיין במודול יש Closure ומשתנים פרטיים של Closure לא נראים ברוב ה debuggers ללא breakpoint בתוך הקוד של יצירת ה Closure. לא נורא.

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

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


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

כמעט מיותר לציין שחלק גדול מהקוד שכתוב ב JavaScript הוא:
א. מבנים פרימיטיביים ולא אופטימליים (אם ניתן לקרוא לזה מבנים)
ב. Copy-Paste של מבנים שחשבו עליהם - אך מי שהעתיק לא צלל למשמעות המלאה של המבנה. JavaScript Kiddies.

בואו נתבונן על הווריאנט הבא:

var calculator = function () {
  // private members
  var value = 0;

  var addBy = function (x) {
    value += x;
    console.log('value = ' + value);
  };

  var multiplyBy = function (x) {
    value *= x;
    console.log('value = ' + value);
  };

  return { // public parts (aka interface)
    addBy : addBy,
    multiplyBy : multiplyBy
  };
}();

שמתם לב להבדל? הוא קטן למדי ולכן הדגשתי אותו ב Bold.
הסוגריים בסוף הביטוי גורמים לכך שהמשתנה calculator מכיל את תוצאת הרצת הפונקציה ולא מצביע לפונקציה, כפי שהיה קודם. לכן, ע"פ קונבנציה, יש לקרוא לו calculator ב c קטנה.

האם אתם יכולים לעצור לרגע ולחשוב מה ההשלכות של שינוי זה?
כיצד תתבצע קריאה ל"מחלקה" שכזו?

ובכן, Singleton הוא דיי נפוץ בפיתוח אפליקציות Client Side. השינוי שביצענו בעצם הוא דרך לבטא Singleton. בניגוד לצד השרת בו דיי נדיר למצוא Singleton ברמת שפה - אנו לרוב מגדירים singleton ברמת הDependency Injection Framework או Service Layer. בג'אווהסקריפט לא נראה לי שיש דDI או Service Layer ואנו מגדירים Singleton ברמת השפה.

הקריאה לקוד, אם כן, תראה משהו כזה:

calculator.addBy(4);
calculator.multiplyBy(6); // 24

ניתן גם לממש Singleton בצורה יותר "קלאסית" (דומה לג'אווה): לאכסון את המצביע ל instance היחיד על ה prototype ולהחזיר אותו בפונקציית getInstance. אני חושב שהדרך שהצגתי פה היא משמעותית יותר נפוצה בעולם הג'אווהסקריפט. שימו לב לדקויות כמו אם שם הפונקציה מתחילה ב Capital Letter או האם יש סוגריים של הפעלה בסוף הגדרת הפונקציה. פעמים רבות הסוגריים לא יהיה ריקים אלא יגדירו פרמטר שמועבר לקונסטרקטור - אולי ערך שמחושב בזמן יצירתה.

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

var Calculator = function () { // constructor
  // private fields
  this._value = 0;
};

Calculator.prototype = function () {
  // private functions

  var _addBy = function (x) {
    this._value += x;
    console.log('value = ' + this._value);
  };

  var _multiplyBy = function (x) {
    this._value *= x;
    console.log('value = ' + this._value);
  };

  return { // interface
    addBy : _addBy,
    multiplyBy : _multiplyBy
  };
}();


var calc = new Calculator();
calc.addBy(4);
calc.multiplyBy(6); // 24

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


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

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

המשתנים שמוגדרים בתוך הקונסטרקטור צריכים להיות מוגדרים ביחס ל this - כך בפעולת new הם יהיו משויכים ל instance שנוצר. ללא this הם פשוט "ימחקו" בסוף הרצת הקונסטרקטור - לא דבר שאנחנו רוצים.
גם ההתייחסות בחלק הפרוטוטייפ צריכה להיות ל this - מסיבה זהה.

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


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

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

• JavaScript Garden - ריכוז מצוין של נושאים מבלבלים / בעייתיים בג'אווהסקריפט. אתם תזהו כמה דוגמאות שלקחתי משם וקצת פישטתי.
• Learning Advanced JavaScript - מדריך מאת ג'ון רזיג לקידום ספרו "סודות הג'אווהסקריפט נינג'ה". אם אתם זוכרים את קוד ה C-Syntax הלא ברור בעליל בתחילת הפוסט הראשון - מדריך זה הולך צעד אחר צעד להסביר אותו - ואתם אמורים להיות מוכנים "לרוץ" עליו.
• Learning JavaScript Design Patterns - מדריך קצת יותר ארוך שעוסק במבנים בג'אווהסקריפט, גם הוא כאמצעי לקידום ספר שיצא בקרוב. כל עניין ונושא בשפה (למשל namespace) מוגדר במדריך זה כ "pattern" - אבל נו טוב, אני מניח שככה מוכרים הרבה עותקים של ספר תכנות.

אם אתם רוצים לבדוק את הקוד ולבצע debug בסביבה קצת יותר רצינית מהדפדפן, אז שווה לנסות את jsFddle או ישר לקפוץ ל IDE מלא כמו Netbeans, Aptana או WebStorm.

הערות / השגות / מחשבות, כרגיל, יתקבלו בשמחה.

שיהיה לכם המון בהצלחה!

מה הבעיה של 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 - שפה לא-חדשה בעליל.