מה עוד רע ב-JavaScript

מאמר זה הוא המשכו של המאמר הקודם בו דיברנו על כמה חסרונות של שפת Javascript. במאמר הזה נעבור על עוד כמה דברים ש-JavaScript פחות טובה בהם כמו this, error handling ועל הספריה הסטנדרטית שלה.

this

נסתכל על הקוד הבא:

	class A {
	f() { console.log(1); }
	g(){ setTimeout(function() { this.f(); }, 1000)}
	}
	function f() { console.log(2); }
	var a = new A()
	a.g()
	> 2

view raw this_problem.js hosted with ❤ by GitHub

בניגוד ל-Java ושפות אחרות, המשתנה this לא מצביע על האובייקט אלא על ה-scope של הקריאה לפונקציה. במקרים רבים ה-scope הוא אכן האובייקט שאליו שייכת הפונקציה. אך במקרים אחרים, כמו בעת קריאה לפונקציה setTimeout, ה-scope של הקריאה לפונקציה איננו האובייקט אליו שייכת הפונקציה אלא ה-scope הגלובלי. בדוגמא הזאת, הפונקציה f שמוגדרת ב-scope הראשי ושמדפיסה 2 היא זו שנקראת, ולא פונקציית המחלקה שמדפיסה 1. אם לא היינו מגדירים את הפונקציה f ב-scope הגלובלי היינו מקבלים שגיאה שהאובייקט f אינו מוגדר.
יוצא שמקריאת הקוד של מחלקה A אי אפשר להבין מה יבצע הקוד, משום שהביצוע תלוי ב-scope שנקבע בזמן הריצה של הקוד. כתוצאה מכך אנו מקבלים קוד לא אינטואיטיבי שלא מסביר את עצמו. בנוסף, המוסכמה ברוב שפות התכנות היא ש-this מצביע על המופע של המחלקה שעליו רצים. תסכול רב היה מנת חלקם של מי שנאלצו ללמוד לאורך השנים בדרך הקשה של-this ב-JavaScript יש משמעות שונה.

כיום אפשר להימנע מהבעיה. בשנת 2015 נוסף לשפה הפיצ'ר פונקציות חץ (Arrow Function). הפונקציות הללו שומרות על ה-scope בהן הן נוצרות וכך נשמרת המשמעות האינטואיטיבית של this. הקוד הבא ידפיס 1 כמצופה.

	class A {
	f = () => { console.log(1); }
	g = () => setTimeout(() => this.f(), 1000)
	}
	function f() { console.log(2); }
	var a = new A()
	a.g()
	> 1

view raw this_arrow.js hosted with ❤ by GitHub

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

שגיאות חסרות טיפוסים

בכל שפת תכנות מודרנית יש מנגנון לזריקת ותפיסת שגיאות. למשל בג׳אווה:

	try {
	System.out.println(obj.charAt(0));
	} catch(NullPointerException e) {
	System.out.println("NullPointerException..");
	} catch(MyAwesomeCustomException e) {
	System.out.println("Caught an exception: " + e.myCustomInformation);
	}

view raw 07_java_exception_handling hosted with ❤ by GitHub

או בפייתון:

	try:
	ratio = a / b
	except ZeroDivisionError:
	ratio = float(‘inf’)
	except TypeError as e:
	logger.critical(‘Got TypeError: %s’, e)

view raw 07_python_exception_handling hosted with ❤ by GitHub

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

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

	try {
	const y = x
	} catch(err) {
	console.log(err.name + ': ' + err.message);
	}
	> ReferenceError: x is not defined

view raw 07_javascript_exception_handling hosted with ❤ by GitHub

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

	class MyError extends Error {}
	try {
	doStuff();
	} catch(err) {
	if (err.name == 'MyError') {
	console.log("This is my error");
	} else if (err.name == 'ReferenceError') {
	console.log("Not my error. Ask the ReferenceError guys");
	} else {
	console.log("I have no idea");
	throw err;
	}
	}

view raw 07_javascript_exceptions_types hosted with ❤ by GitHub

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

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

https://gist.github.com/2a27471e24abe923e8e8dd7c5e4ac07b.git

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

	try {
	throw “this is an error”;
	} catch(err) {
	console.log(err.name + ': ' + err.message);
	}
	> undefined: undefined

view raw 07_javascript_throw_string hosted with ❤ by GitHub

בשפות אחרות מקובל שכדי לזרוק אובייקט כשגיאה עליו לרשת מ-Exeption או להיות throwable בצורה כלשהי. ב-JavaScript אפשר לזרוק ממש כל אובייקט.

	try {
	throw new Date();
	} catch(err) {
	console.log(err);
	}
	Tue Jun 25 2019 19:12:20 GMT+0300 (Israel Daylight Time)

view raw 07_javascript_throw_date hosted with ❤ by GitHub

אם אנחנו כותבים גם את הקוד שמטפל בשגיאה שנתפסה זה לא נורא, פרט לעובדה שמדובר בקונבנציה רעה. אך הדבר יכול להוביל לשגיאה של ממש במערכות שמניחות מבנה של שגיאה כדי להדפיס stack trace וכדומה, כמו ב-node.
עד ES6 היה אפשר לזרוק רק שישה סוגים של שגיאות חוץ מ-Error הבסיסי.

חוסר בספרייה סטנדרטית

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

	>>> x = {'a': 1, 'b': 2}
	>>> y = {'b': 2, 'a': 1}
	>>> x == y
	True

view raw 07_python_dict_comparison hosted with ❤ by GitHub

או בג׳אווה:

	HashMap<String, Object> map1 = new HashMap<String, Object>();
	map1.put("a", 1);
	map1.put("b", 2);
	TreeMap<String, Object> map2 = new TreeMap<String, Object>();
	map2.put("b", 2)
	map2.put("a", 1);
	map1.equals(map2); // true

view raw 07_java_hashmap_comparison hosted with ❤ by GitHub

לעומת זאת ב-JavaScript השוואה כזו לא נותנת תוצאה דומה.

	x = {'a': 1, 'b': 2}
	y = {'b': 2, 'a': 1}
	x === y // false
	x == y // false

view raw 07_javascript_object_comparison hosted with ❤ by GitHub

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

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

ב-JavaScript ניתן לבצע רק מיון במקום שמשנה את המערך המקורי.

	>>> var a = [3, 2, 1];
	>>> var b = a.sort();
	>>> b
	[1, 2, 3]
	>>> a
	[1, 2, 3]

view raw 07_javascript_array_sort hosted with ❤ by GitHub

במקרה שנרצה להציב במשתנה b את המערך a הממויין תוך כדי שמירה על הסדר המקורי של a נצטרך להשתמש בספרייה כדוגמת immutable-sort:

	>>> const sort = require('immutable-sort')
	>>> var a = [3, 2, 1];
	>>> var b = sort(a);
	>>> b
	[1, 2, 3]
	>>> a
	[3, 2, 1]

view raw 07_javascript_array_sort_immutable hosted with ❤ by GitHub

למה זה לא טוב?

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

	>>> f'{7:03}'
	'007'

view raw 07_python_string_pad hosted with ❤ by GitHub

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

	>>> (7).toString().padStart(3, '0');
	"007"

view raw 07_javascript_string_pad hosted with ❤ by GitHub

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

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

סיכום

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

Business photo created by yanalya – www.freepik.com