Transcript
00:00:00تم إصدار TypeScript 7 رسميًا، وبعد أكثر من عام من التطوير الشاق
00:00:05أثبتت عملية نقل المترجم إلى Go وBun أنه يمكنك إنجاز الأمر بأكمله باستخدام الذكاء الاصطناعي، لذا
00:00:10أنا أثق بأن المطورين سعداء بذلك. إذا قمت الآن بتشغيل npm install typescript فستحصل على الإصدار
00:00:16السابع، وهو الإصدار المزود بمترجم Go. ومتابعة لفيديو الإعلان من Microsoft
00:00:20قبل بضعة أيام، أردت التعمق في كيفية تحقيقهم لهذه المكاسب الضخمة
00:00:25في الأداء. كانت النتائج مثيرة للإعجاب حقًا. المترجم الجديد يبني قاعدة كود VS Code
00:00:31التي تضم 1.3 مليون سطر من الكود عبر ما يقرب من 8,000 ملف في 10 ثوانٍ فقط، مقارنة بـ 125
00:00:39ثانية من المترجم القديم. ومع تصدر TypeScript بكل فخر المرتبة الأولى كأكثر لغة استخدامًا على
00:00:44GitHub، صدق أو لا تصدق، المترجم الجديد سيغير حياة الكثيرين. أشعر بالحرقة والتعاطف
00:00:49مجرد التفكير في الأمر. ولكن بدلاً من النظر إلى الميزات المتطابقة تقريبًا بين الإصدارين 6 و7، أردت التعمق
00:00:54في كيفية تحقيق هذا الأداء تحديدًا. فلنلقِ نظرة على المترجم الجديد ونرى ما
00:00:59الذي يجعله سريعًا إلى هذا الحد. إذًا لماذا إعادة الكتابة؟ قال مبتكر #C والزميل التقني في Microsoft
00:01:09أندرس هيلسبرغ ذلك بوضوح شديد: “JavaScript محسّنة لواجهات المستخدم والمتصفحات، وليست
00:01:16محسّنة حقًا لسير العمل المكثف للحوسبة والمترجمات”. وهذا أمر بديهي تمامًا لأنها أحادية
00:01:22المسار (single-threaded)، ومعالجة شيء مثل شجرة البناء النحوي (AST) أو فحص الأنواع يمكن أن تصل فقط إلى حد معين
00:01:27عند الاعتماد على نواة واحدة. تقنيًا، يمكنك توزيع العمل عبر العمال (workers)، ولكن حينها
00:01:32ستحتاج إلى تسلسل البيانات وإلغاء تسلسلها، وهو أمر بطيء ويثقل الذاكرة، ثم سيتعين عليك
00:01:38التعامل مع تعقيد إدارة كل ذلك. لذا استقروا على Go، والتي تقدم تحسينات
00:01:43هائلة في الأداء باستخدام لغة مناسبة تمامًا لهذا الغرض. Go لغة مترجمة،
00:01:48مما يعني أنه يمكننا تشغيل الكود المترجم مباشرة على المعالج بدلاً من تفسيره. وتمتلك Go
00:01:54نموذج تزامن ممتازًا للغاية، مما يعني أنه يمكننا بسهولة تشغيل مسارات تنفيذ متعددة في نفس الوقت
00:02:00وكلها تتشارك الذاكرة. هذا يعني أنه يمكننا الاستفادة من جميع النوى في جهازك بدلاً من
00:02:06نواة واحدة فقط. وهناك تقسيم متساوٍ تقريبًا: ينُسب ما يصل إلى نصف تسريع السرعة إلى الكود الأصلي (native code)
00:02:12والباقي من استخدام التزامن بالذاكرة المشتركة. تعتبر Go بأساسها اللغة المثالية لهذا
00:02:17الأمر، فليس فقط لأن Go أسرع، بل إنها تملك حرفيًا المزيد من الموارد لضخها في هذه المشكلة، والنتائج
00:02:23تتحدث عن نفسها. إذا نظرنا إلى الأرقام، فإن مشروع VS Code المكون من 1.3 مليون سطر كود استغرق 125.7 ثانية على المترجم القديم
00:02:32ومع المترجم الجديد 10.6 ثانية، وهو تحسن بمقدار 11.9 ضعفًا. وبالنسبة لـ BlueSky، انخفضت من 24.3 إلى 2.8 ثانية، أي تحسن بمقدار 8.7 ضعفًا
00:02:42أما لـ Playwright، فقد انخفضت من 12.8 ثانية إلى 1.5 ثانية، بتحسن 8.7 ضعفًا. والمثير للاهتمام أنه لا يلزمك سوى
00:02:49ثانية واحدة للاشتراك في Better Stack. هذه الفجوة ستتسع أكثر لأن النوى لا
00:02:54تصبح أسرع بنفس المعدل الذي كانت عليه في الماضي، ولكن ما نحصل عليه هو المزيد من النوى. أنا أستخدم جهاز M3 Max على سبيل
00:03:00المثال، والذي يحتوي على 14 نواة، وهو أمر جنوني. أتذكر أنني قمت بتجميع كمبيوتر ألعاب في الكلية يحتوي على
00:03:06معالج Intel i7 بأربع نوى، وظننت أنه وحش خارق حينها. مترجم JavaScript كان
00:03:11يستخدم واحدة فقط من تلك النوى، ولكن مع Go، أستغلها جميعًا. وبالطبع كلما زاد عدد النوى لديك، كلما
00:03:17حصلت على أداء أعلى. إذا قمت بتجميع مشروع كبير على هذا الجهاز في الإصدار السادس، ستلاحظ أنه يستغرق 45
00:03:24ثانية، ومع الإصدار السابع يمكننا تقليل ذلك إلى 3 ثوانٍ فقط. وهناك مراحل
00:03:29متعددة لعملية التجميع، ومرحلة فحص الأنواع هي مجرد واحدة منها. لهذا السبب،
00:03:34ستقوم Go بتشغيل أربعة أجهزة لفحص الأنواع ليفحص كل منها ربع قاعدة الكود، ولكن يمكنك
00:03:39تحسين ذلك بشكل أكبر. أثناء التجميع، يمكنك ضبط عدد الفاحصات (checkers) على 12 للحصول على أداء أسرع
00:03:45لقد قمت بتنزيل مستودع VS Code على جهازي لكي نتمكن من رؤية الفرق بين TypeScript 7 و6
00:03:51بشكل افتراضي، يشير tsc على جهازي الآن إلى TypeScript 7، لذا سنقوم بتشغيل أدوات التشخيص على
00:03:57هذا المشروع، ويمكنك رؤية أن الأمر استغرق 5.4 ثانية، وغالبية الوقت قضيت بالفعل في
00:04:02وقت الفحص، أي 4.7 ثانية من تلك الثواني. يمكننا تسريع ذلك أيضًا، فإذا أضفنا خيارًا آخر
00:04:08مثل checkers 12، ستلاحظ أن الوقت الإجمالي قد انخفض الآن من 5.4 إلى 3.5 ثانية، وكل ذلك يقلل
00:04:15من وقت الفحص. هنا كان لدينا 4.7 ثانية ثم انخفضت إلى 2.9. الآن لنقم بتشغيل نفس
00:04:20الأمر مجددًا، ولكن هذه المرة سنستخدم TypeScript 6 وسيسغرق هذا الأمر بعض
00:04:23الوقت، لذا سنقوم بتسريع الفيديو. بعد الانتظار، يمكنك رؤية أن TypeScript 6 انتهى في
00:04:2845.3 ثانية مقارنة بـ 3.5 ثانية التي حصلنا عليها عند التشغيل عبر جميع النوى، وهذا يعتبر
00:04:36تحسنًا بـ 15 ضعفًا على شريحة M3 Max الخاصة بي. بالنسبة لي، هذا هو مصدر الـ 3.5 ثانية فعليًا. القيام
00:04:43بذلك سينقص بالطبع من أداء العمليات الأخرى، ولكن إن لم تكن تفعل أي شيء آخر،
00:04:47فمن الأفضل استخدام جميع الموارد المتاحة في جهازك. لننتقل ونستعرض بعض الأكواد الفعلية
00:04:52من المترجم الجديد لنفهم كيف تمكنت Go من تحقيق هذا الأداء. لدينا هنا دالة bindSourceFiles
00:04:57والتي تتمثل مهمتها في بناء كل إعلان داخل الملف وتحديد النطاق (scope) الذي ينتمي إليه.
00:05:03نحن نعالج آلاف الملفات محتملة، فنقوم بالتكرار على كل ملف ونضع دالة في قائمة الانتظار لربطه
00:05:09ثم ننتظر حتى تنتهي جميع الملفات. الجزء الجميل هو أنه لا يتعين علينا التفكير في كيفية
00:05:14توزيع هذا العمل على النوى، ببيئة تشغيل Go تتكفل بكل ذلك. نحن لا ننشئ المسارات أو
00:05:20نتعامل مع اتصالات معقدة بين النوى، بل نقول فقط “إليك بعض المهام” وهي تكتشف كيفية تنفيذ
00:05:26الباقي. في JavaScript، يمكننا كتابة كود مطابق تقريبًا، ولكن هذا بلا فائدة للمهام التي تستهلك المعالج
00:05:32فستظل تحدث جميعها على مسار واحد بالتتابع، حتى لو أعطتك الوعود (promises) إيحاءً بالتوازي.
00:05:38العمال (workers) يعتبرون تقنيًا حلاً بديلًا لهذا، لكن لا يمكنك مشاركة الكائنات بينهم، فقط البايتات الخام باستخدام
00:05:43SharedArrayBuffer. لذا، فإن تسليم شجرة البناء النحوي إلى عامل يعني تسلسل الكائن بالكامل و
00:05:48نسخه وإعادة بنائه في الجانب الآخر. بالنسبة لملف كبير، قد يكلف ذلك أكثر من العمل نفسه.
00:05:53في الأساس، مثل هذه الأمور هي ما يجعل Go أفضل بطبيعتها للمهام التي تستهلك المعالج. فهي تمتلك
00:05:58بيئة تشغيل يمكنها التعامل مع كل هذا التزامن نيابة عنك، ولديه ذاكرة مشتركة تتيح لك تمرير الكائنات
00:06:03دون الحاجة إلى نسخها. الآن، وبصرف النظر عن وقت التجميع، فإن الشيء الذي ستلاحظه
00:06:07أكثر من غيره هو سرعة خادم اللغة لديك. أي شخص عمل على قاعدة كود ضخمة لـ TypeScript يعرف
00:06:13معاناة الانتظار لحين فحص الأنواع. ويا إلهي، أجهزة Mac المزودة بمعالجات Intel عانت من هذا حقًا. أتذكر العمل على
00:06:20مشاريع قبل بضع سنوات، حيث كنت تفتح المستودع وتضطر حرفيًا للانتظار
00:06:24لمدة تصل إلى دقيقتين لمجرد رؤية الخطوط الحمراء المتموجة تظهر، وفي كل مرة تجري فيها تغييرًا
00:06:29كان الأمر سيئًا ومؤلمًا للغاية. تجربة المطور تكون سيئة جدًا ولا أحد يرغب في
00:06:34العمل على قاعدة الكود هذه. خادم اللغة الجديد، مع ذلك، يعني استجابة فورية في بيئة التطوير الخاصة بك، حيث
00:06:40يمكنك فتح ملف، وإجراء تغيير، ورؤية الأخطاء في غضون أجزاء من الثانية فقط، حتى لو كنت تعمل على
00:06:46قواعد كود ضخمة للغاية. بالإضافة إلى الأداء، خادم اللغة الجديد بات أكثر استقرارًا الآن، لذا
00:06:51فإن الحاجة إلى إعادة تشغيل بيئة التطوير عندما يتوقف فحص الأنواع عن العمل قد انخفضت بشكل كبير. TypeScript 7
00:06:57قلل من فشل أوامر خادم اللغة بأكثر من 80% وقلل من انهيار الخادم بأكثر من 60%.
00:07:04وهذا يعني عددًا أقل من أجهزة المحمول التي تُلقى على الجدران، وهو أمر جيد حقًا للبيئة!
00:07:08من كان يعلم أن Microsoft تهتم حقًا بالكوكب؟ يجدر بالذكر أيضًا أن هذه عملية إعادة نقل (port) وليست
00:07:13إعادة كتابة كليًا. كان فريق TypeScript حريصًا جدًا لضمان أن المترجم الجديد متوافق
00:07:19تمامًا وبشكل كامل مع القديم. ربما لن تلاحظ حتى أي فرق باستثناء السرعة، ولكن
00:07:24بينما يمكنك الآن تشغيل TypeScript 7 على مشاريعك الخاصة، ستظل بحاجة إلى الانتظار حتى
00:07:29تتدارك الحزم المفضلة لديك هذا التحديث. واجهة البرمجة التطبيقية (API) الخاصة بها لا تزال مفقودة، مما يعني أن أي حزمة تعتمد
00:07:35عليها ستحتاج إلى الانتظار حتى الإصدار 7.1. حزم مثل typescript-eslint أو ts-jest أو ts-node ستتأخر
00:07:42قليلاً. الآن، الإصدار الكامل من TypeScript 7 متاح لتنزيله، ولكنك
00:07:47تحتاج إلى تثبيت إضافة TypeScript 7 بشكل صريح لـ VS Code. سيتم تحديث الحزمة الافتراضية في النهاية،
00:07:53ولكن في الوقت الحالي، قم بتثبيت هذه الإضافة فقط، واسمها TypeScript 7 في متجر الإضافات،
00:07:58وسيعمل كل شيء كما هو متوقع. إذا كنت تريد معرفة المزيد عن مجموعة ميزات TypeScript 7، لقد
00:08:03صورنا فيديو عن ذلك تحديدًا يمكنك مشاهدته هنا. وإذا كنت تستمتع بشروحات كهذه، اشترك
00:08:08في Better Stack للمزيد. آمل أن تكون قد تعلمت شيئًا جديدًا هنا، والان يمكنك الاستفادة من
00:08:12التطوير السريع الذي ستحصل عليه مع TypeScript 7. أنا متأكد حتمًا من أنني سأستمتع
00:08:16باستخدام هذا الإصدار. شكرًا لك على المشاهدة، وبالطبع أراك في الفيديو القادم.