הלידה והמוות של JavaScript
JavaScript רצה בדפדפן עם הרשאות נמוכות. ובכל זאת, היא מריצה שרתים, כלי בנייה (build tools) וצינורות עבודה (pipelines). זה לא היה תכנון. זו הייתה סדרה של תיקונים (patches) להחלטה משנת 1995.
ההבנה מדוע זה קרה משנה את הדרך שבה אתם מעצבים את ה-stack שלכם היום.
ההרצאה של Gary Bernhardt מ-2014 אינה עוסקת בנוסטלגיה. היא אבחנה של חיכוך ארכיטקטוני. הוא ציין קשת אירונית: JavaScript הייתה שפת צעצוע ששרדה כי הייתה לה מונופול בדפדפן. המונופול הזה הפך אותה לשפה הנפוצה ביותר בעולם.
המתח הוא פשוט. הדפדפן חייב להריץ קוד בצורה בטוחה ומהירה. שני היעדים הללו עומדים בסתירה זה לזה.
בשנת 2014, ההימור היה ש-WebAssembly יחליף את JavaScript. זה לא קרה במלואו. WebAssembly יציב ושימושי לדברים כמו Figma או Google Earth, אך הוא לא החליף את JavaScript כשפת אפליקציה.
במקום זאת, JavaScript עברה מוטציה. TypeScript, bundlers, וסביבות הרצה (runtimes) חדשות כמו Bun קיימות כדי לתקן את החיכוכים שזיהה Bernhardt.
אל תשתמשו בהרצאה הזו כדי להימנע מלמידת JavaScript. אל תשתמשו בה כדי להצדיק מעבר ל-WebAssembly ללא בעיית ביצועים.
השתמשו בה כרשימת תיוג (checklist) עבור ה-stack שלכם:
- האם אני משתמש בזה כי זה הכלי הטוב ביותר?
- או כי זה הדבר היחיד שעובד כאן?
- האם ה-overhead של הכלים פותר את החיכוך או רק מעביר אותו?
- אם הייתי מתחיל מאפס היום, האם הייתי בוחר בזה?
- האם תקרת הביצועים מקובלת עבור מקרה הבוחן (use case) שלי?
TypeScript עוזרת עם טיפוסים (types) בזמן קומפילציה. היא לא פותרת את הפער בין הטיפוסים שלכם לבין הנתונים שמגיעים דרך הרשת. אתם עדיין זקוקים לוולידציה בזמן ריצה (runtime validation).
השיעור החשוב ביותר הוא זה: דעו אם הטכנולוגיה שלכם קיימת בזכות איכותה או בגלל מונופול.
אל תשנו את ה-runtime שלכם על בסיס תחזית מ-2014. שנו אותו כאשר יש לכם נתונים שנמדדו ומראים צוואר בקבוק (bottleneck).
מקור: https://dev.to/jtorchia/the-birth-and-death-of-javascript-2014-what-still-holds-and-what-doesnt-2hae