00:00:00(موسيقى حماسية) - مرحباً بالجميع.
00:00:06أنا ليديا.
00:00:07منصبي هو رئيس الدعاية في BUN.
00:00:11وإذا كنت تعرف قليلاً عني، فأنت تعلم أنني أحب الحديث عن أوقات تشغيل JavaScript والأداء.
00:00:17في الواقع، قبل أن أنضم إلى BUN، كنت في Vercel لبضع سنوات لتعليم مطوري Next كيفية بناء التطبيقات بشكل أسرع.
00:00:24لذا أنا متحمسة جداً لأن أكون هنا اليوم وأريكم كم يمكن أن يتحسن عندما نجمع بين أداء إطار عمل Next مع أداء وقت تشغيل BUN.
00:00:35لكن قبل أن أتحدث عن BUN نفسه، أريد أن أتراجع قليلاً وأريكم ما يجعل أطر عمل مثل Next.js خاصة في المقام الأول.
00:00:45لأنها أعادت تعريف فهمنا للأداء على الويب.
00:00:49لم تجعل المواقع أسرع فحسب.
00:00:52بل أنهت كل جزء من العملية.
00:00:55حصلنا على تجميع أذكى مع Webpack والآن مع Turbo Pack.
00:00:59حصلنا على تحسين الصور والخطوط المدمج.
00:01:02حصلنا على عرض فعال من جانب الخادم، وعرض من جانب ثابت والآن لدينا ISR والآن أعتقد أن لدينا RSC لإحضار استرجاع البيانات إلى المكون نفسه.
00:01:12وكل هذه التحسينات دفعت بشكل ما بما يمكن للإطار تحسينه، لكن حقاً فقط إلى حد معين.
00:01:21كان هناك دائماً هذا الطبقة الأساسية التي لم تتمكن Next.js من تحسينها بعد.
00:01:26وهذا ليس بسبب نقص الجهد الهندسي أو القدرة، لكنها خارج نطاق Next.
00:01:34وهذا هو وقت التشغيل نفسه.
00:01:37عادة عندما تقوم بتشغيل Next dev أو الانتشار إلى Vercel، يعمل تطبيق Next الخاص بك على Node.
00:01:42لذا هذا يعني أن وقت تشغيل Node ينفذ JavaScript الخاص بك.
00:01:45يدير حلقة الأحداث، وملفات IO، كل شيء.
00:01:49وهو يربط رمز JavaScript الخاص بك بنظام التشغيل.
00:01:53وهذا منطقي لأن Node كان وقت التشغيل الافتراضي لمدة 15 سنة تقريباً.
00:01:59تم اختباره بالقتال، وموثوق، لكن في عام 2025، أصبح أيضاً بمثابة اختناق ما.
00:02:06لا تسيء الفهم، Node رائع.
00:02:09جعل من الممكن تشغيل JavaScript على الخادم.
00:02:13قبل ذلك، قبل إدخال Node في عام 2009، كان JavaScript حقاً فقط للمتصفح.
00:02:20غيّر Node ذلك بإعطاؤنا وقت تشغيل مع محرك JavaScript، وحلقة أحداث، وIO غير متزامن وواجهات برمجية للقيام بكل الأشياء التي لا يمكن للمتصفحات القيام بها.
00:02:29مثل قراءة الملفات من القرص، الذاكرة، كل هذا الشيء.
00:02:33الآن تحت السقطة، يستخدم Node محرك JavaScript V8.
00:02:37هذا هو محرك Chrome السريع من Google، وهو رائع للمهام التي تعمل لفترة طويلة، مثل علامة تبويب في متصفح Chrome الخاص بك.
00:02:44لكن بالطبع، V8 هو مجرد محرك.
00:02:46إنه يعرف فقط كيفية تنفيذ JavaScript.
00:02:49لا يمكنه فتح الملفات، إجراء اتصالات TCP، وكل هذا النوع من الأشياء.
00:02:54لذا هذا هو المكان الذي تأتي فيه واجهات برمجية Node المدمجة.
00:02:57مثل FS، HTTP، NET، وما إلى ذلك.
00:03:01لذا فإن هذه الواجهات البرمجية هي نوع من الجسر بين رمز JavaScript الخاص بنا ونظام التشغيل.
00:03:07وتعتمد هذه الواجهات البرمجية نفسها على مكتبة C تسمى libuv.
00:03:13هذا لم يتم بناؤه لـ JavaScript نفسه.
00:03:16إنه أكثر مثل تجريد عام يستخدمه Node ليتمكن من القيام بأشياء مثل ملفات IO والشبكات والأشياء عبر كل هذه أنظمة التشغيل المختلفة.
00:03:27لذا عندما ننادي على شيء مثل fs.read file في رمز JavaScript الخاص بنا، نحن نطلب حقاً من الكمبيوتر، مثل، أريد قراءة هذا الملف من القرص.
00:03:36لكن قبل أن نتمكن من الوصول إلى هناك، يجب أولاً أن يمر عبر V8، أو مثل من رمز JavaScript إلى V8.
00:03:42ثم يمرره إلى ربط C++ Node.
00:03:46هذا يستدعي libuv، وهذا حتى لا يذكر العمل في مجال الخيوط وكل هذا النوع من النفقات العامة.
00:03:52وفقط بعد ذلك يقوم libuv فعلياً بإجراء استدعاء النظام إلى نواة لدينا للحصول فعلياً على هذا الملف من القرص.
00:03:58وبينما يحدث كل هذا، لدينا حلقة الأحداث التي يستخدمها libuv حتى يتمكن باقي رمز JavaScript الخاص بنا من التنفيذ وما إلى ذلك.
00:04:06وهذا النموذج يعمل بشكل جيد.
00:04:08نحن لا نزال نستخدم Node، لكنها ليست مثالية.
00:04:13حتى عودة في عام 2009، لذلك مرة أخرى عندما تم تقديم Node، كان الأجهزة لدينا تبدو مختلفة جداً.
00:04:19قد تكون الخوادم لديها حوالي أربعة نوى، وذاكرة محدودة، والتخزين كان بطيئاً جداً.
00:04:25كانت المواضيع أيضاً مكلفة، لذلك إنشاء خيط جديد لكل اتصال لم ينجح حقاً بشكل جيد.
00:04:32لذا كان نموذج Node رائعاً لتلك الحقبة لأنه يمكننا استخدام خيط واحد للتعامل مع آلاف الاتصالات بكفاءة حقاً.
00:04:40لكن سريعة إلى الأمام إلى 2025، تبدو الأجهزة لدينا مختلفة جداً.
00:04:44لدينا الآن مئات من نوى وحدات المعالجة المركزية، تيرابايتات من الذاكرة، والتخزين يشبه 50 مرات أسرع.
00:04:51لكننا لا نزال نستخدم مثل نموذج Node بناءً على عام 2009.
00:04:55إنه لا يزال يدفع كل شيء من خلال حلقة الأحداث نفسها.
00:04:59ومرة أخرى، هذا بخير.
00:05:00مثل معمارية Node بخير عندما تعمل الخوادم لعدة أيام.
00:05:04لكن في الأوقات الحديثة، غالباً ما يكون لدينا وظائف بدون خادم أو لدينا خوادم تطوير.
00:05:09كل هذه النصوص البرمجية أكثر مثل انفجارات قصيرة التي تحتاج إلى بدء سريع والعمل لفترة زمنية أقصر بكثير.
00:05:16لذا في هذه البيئات، كل ميلي ثانية من البدء وكل طبقة بيانات مهمة هنا لأنها كل شيء يضيف إلى الكمون.
00:05:24الآن مرة أخرى، عندما تقوم بتشغيل تطبيق Next الخاص بك، فأنت تقوم بتشغيله على Node.
00:05:34لذا هذا يعني أن كل شيء يقوم به التطبيق الخاص بك، مثل عرض الصفحات، وتقديم الأصول، والاستجابات المتدفقة، كل ذلك يمر عبر كل هذه الطبقات التي رأيناها للتو.
00:05:43لذا من JavaScript إلى VA إلى Node، كل هذا النوع من الأشياء.
00:05:46و Next قام بعمل رائع جداً في سحق كل بت من الأداء على الرغم من أن وقت تشغيل Node لا يزال يحجب أشياء معينة.
00:05:57لأنه في نهاية اليوم، تعمل كل هذه التحسينات على قمة Node.
00:06:01لذا عندما تقوم بتشغيل خادم تطوير أو إعادة بناء الملفات، أو إعادة تحميل ساخن، فأنت لا تزال تضرب قيود وقت التشغيل.
00:06:09لذا إذا كنا نريد حقاً أن نذهب أسرع، يجب أن ننظر إلى ما وراء الإطار.
00:06:13يجب أن نذهب أعمق قليلاً.
00:06:15يجب أن نعيد التفكير في وقت التشغيل نفسه.
00:06:18لذا هذا هو المكان الذي يأتي فيه BUN.
00:06:20BUN ليس فقط مثل طبقة أخرى مبنية على Node.
00:06:24إنها وقت تشغيل جديد تماماً مبني من الصفر لأجهزة لدينا فعلاً في عام 2025.
00:06:33لذا بدلاً من أن يتم كتابتها بـ C ++ على LibUV كما شاهدت مع Node، يتم بناء BUN في Zig.
00:06:40وهذه لغة أنظمة حديثة تعمل بكثير أقرب إلى المعادن.
00:06:45لذا بالنسبة لمحرك JavaScript، يستخدم BUN محرك JavaScript Core السريع حقاً من Apple.
00:06:51وهذا ينطلق بسرعة حقاً، في الغالب لأنه يمكنه تأجيل بعض تحسينات التهيئة التي تقوم بها محركات مثل V8.
00:06:59وكما أنه يعمل بسرعة كبيرة جداً، وهو مرة أخرى مثالي للمهام الحديثة التي نستخدمها في هذه الأيام مع خوادم التطوير وبيئات بدون خادم وهذه النصوص البرمجية للبناء الأقصر.
00:07:10وقت التشغيل الأساسي نفسه مكتوب في Zig.
00:07:13لذا واجهات برمجية BUN وجميع الأجزاء التي تتعامل مع IO غير المتزامن.
00:07:17لذا حيث يستخدم Node LibUV لكل هذه العمليات غير المتزامنة، مثل قراءة الملفات وطلبات الشبكة وما إلى ذلك، يمكن لـ BUN تنفيذ هذه كاستدعاءات نظام مباشرة لنظام التشغيل لأنها مكتوبة في Zig.
00:07:33الآن بالنسبة لطلبات الشبكة، نستخدم useSockets، لذا فهو مختلف قليلاً.
00:07:37لكننا نزيل الكثير من طبقات التجريد باستخدام Zig بدلاً من LibUV.
00:07:44لذا الآن إذا كنت تريد قراءة ملف مع وقت تشغيل BUN، فإنه يذهب بالطبع من رمز JavaScript الخاص بك.
00:07:49ينتقل الآن إلى محرك JSC إلى Zig، والذي يمكنه بعد ذلك إجراء استدعاء النظام المباشر.
00:07:55إذن مرة أخرى، عدد أقل من الطبقات بين رمز JavaScript الخاص بنا والنظام التشغيلي الفعلي.
00:08:01والنتيجة هنا هي أن كل شيء يشعر أسرع كثيراً من البدء إلى الوصول إلى الملف إلى خوادم HTTP وما إلى ذلك.
00:08:09لكن BUN ليس فقط عن الأداء.
00:08:12نحن أيضاً نهدف إلى أن نكون متوافقة 100٪ مع Node.
00:08:15لذا نريد التأكد من أن جميع واجهات برمجية Node الخاصة بها تعمل.
00:08:19لكن بعد ذلك يتم شحنها أيضاً مع الكثير من واجهات برمجية مدمجة إضافية، مثل S3، SQL، أو Squeel، مهما كنت تريد أن تقول.
00:08:27Redis، التجزئة، قذيفة، أشياء كثيرة جداً.
00:08:30وإذا استخدمت أي لغة برمجة أخرى من قبل، مثل Go أو Python، فإن هذا النهج الشامل للبطاريات مألوف جداً لك.
00:08:39لكن كمطورين JavaScript، لقد اعتدنا فقط على تثبيت التبعيات لكل شيء تقريباً.
00:08:45أستخدم تجزئة كلمة المرور في جميع تطبيقاتي تقريباً.
00:08:48لكنني لا أزال يجب أن أثبت التبعية في كل مرة أستخدمها.
00:08:52لذا يغير BUN ذلك.
00:08:54الأشياء التي تستخدمها بكل ما هو أساسي مدمجة مباشرة في وقت التشغيل نفسه.
00:08:59يتم بناؤها فقط على العام.
00:09:01ومرة أخرى، هذه ليست مثل مجرد أغلفة على مستوى السطح على قمة التبعية NPM.
00:09:06يتم بناؤها حقاً في Zig.
00:09:08لذا يتم تحسينها من أجل الأداء للأجهزة الحديثة.
00:09:12لذا على سبيل المثال، لدى BUN عميل SQL مدمج.
00:09:16لذا يمكنك الاتصال مباشرة بـ Postgres و MySQL و SQLite باستخدام واجهة برمجية واحدة.
00:09:23لا يجب أن تثبت أي التبعيات الإضافية.
00:09:26ومرة أخرى، هذا ليس فقط استدعاء بعض حزم NPM.
00:09:30إنه بحق كل BUN يتحدث مباشرة إلى النظام.
00:09:35وليس فقط الراحة التي يجب أن تتمتع بها هذه المبنية.
00:09:38عادة ما تكون خيارات BUN أسرع أيضاً من بدائل Node و NPM.
00:09:44لذا على سبيل المثال هنا، BUN.SQL أسرع بـ 11 مرة من MySQL 2 على Node، وهو أمر جيد حقاً.
00:09:51أو يمكنك استخدام عميل S3 من BUN.
00:09:54وهذا يعمل خارج الصندوق مع أي تخزين متوافق مع S3.
00:09:58لذا Amazon S3، Super Base Storage، Cloudflare R2، كما تقول.
00:10:03ومرة أخرى، هذه الواجهة البرمجية أيضاً سريعة جداً.
00:10:06لذا هنا، يمكننا أن نرى أنه يصل إلى حوالي ست مرات أسرع من AWS S3 SDK على Node.
00:10:12بالطبع، يمكنك استخدام التبعيات العادية الخاصة بك مع وقت تشغيل BUN أيضاً.
00:10:17لا يجب أن تستخدم هذه الواجهات البرمجية المدمجة.
00:10:20لكنهم يقللون حجم الحزم الخاص بك كثيراً، لأننا لم نعد نضيف هذه التبعيات.
00:10:25وهو يساعد مع ثغرات NPM التي رأيناها مثل الشهر الماضي، لأنك لا يجب أن تثبتها.
00:10:32هناك الكثير من واجهات برمجية أخرى.
00:10:33أوصي بشدة بأن تتحقق من المستندات أيضاً.
00:10:37لكن BUN يأتي مع أكثر بكثير من مجرد وقت تشغيل.
00:10:40كما أنه يتم شحنها مع مدير الحزم السريع حقاً الذي يصل إلى 17 مرة أسرع من YARN وسبع مرات أسرع من NPM وأربع مرات أسرع من PNPM.
00:10:51والشيء الجيد، لا يجب أن تستخدم وقت تشغيل BUN لاستخدام BUN install.
00:10:55وهذا فقط - يمكنك استخدام BUN install مع Node.
00:10:58سوف يعمل فقط.
00:10:59لذا لا يجب أن تغير أي شيء عن مشروعك.
00:11:03كما أنه يحتوي على موزع مدمج سريع جداً وجهاز نقل.
00:11:06لذا يمكنك خدمة وبناء الملفات الخاصة بك على الفور.
00:11:09لذا لا تحتاج إلى Webpack أو ESBuild أو أي إعداد إضافي.
00:11:12والشيء اللطيف هو أنه يدعم أيضاً TypeScript و JSX في الصندوق.
00:11:18كما أنه يحتوي على عداء اختبار مدمج سريع جداً يصل إلى 14 مرة أسرع من vTest و 23 مرة أسرع من jest عندما قمنا بـ SSR من 1،000 اختبار React.
00:11:26لذا مرة أخرى، تحصل على اختبارات سريعة حقاً.
00:11:29لا يجب أن تثبت أي شيء.
00:11:31لذا كل هذا يبدو رائعاً، لكن كيف يمكننا استخدام وقت تشغيل BUN؟
00:11:35والتالي، بصراحة، فإنها سهلة جداً.
00:11:38بعد تثبيت BUN، عليك فقط تحديث أمر البدء أو أمر التطوير الخاص بك وإضافة bun run --bun.
00:11:45هذا كل شيء.
00:11:46أنت الآن تشغل وقت تشغيل BUN.
00:11:48الآن قد تتساءل، لماذا أحتاج إلى هذا --bun؟
00:11:51مثل، أنا أقول بالفعل bun run.
00:11:54هذا، مرة أخرى، لأن BUN يهتم حقاً بتوافق العقدة.
00:11:57لذا عادة، إذا استخدمنا فقط bun run next dev، سيكتشف BUN أن next CLI يستخدم أن عقدة shebang.
00:12:07وفي هذه الحالة، سيكون BUN مثل حسناً، أنا أفهم أنني يجب أن أستخدم العقدة.
00:12:11لذا فإنها ستعود فقط إلى العقدة، حتى على الرغم من أننا قلنا bun run.
00:12:15لكن مع العلم --bun، نحن نفرض هذا إلى حد ما لتخطي shebang والقول، حسناً، نحن فقط باستخدام وقت تشغيل bun.
00:12:21لذا فقط نوع من التوضيح الإضافي.
00:12:25لذا الآن مع هذا الأمر، يبدأ bun خادم next dev الخاص بك.
00:12:29موزع نفسه لا يزال next.
00:12:31لذا هذا لا يزال، كما تعلم، Turbo Pack.
00:12:33أنا أخمن Web Pack، Turbo Pack، الآن هو الافتراضي.
00:12:35لكن الآن وقت التشغيل تحت كل ذلك، لذا الشيء الذي ينفذ JavaScript الخاص بك، قراءة الملفات، خدمة الاستجابات وما إلى ذلك، وهذا كل bun.
00:12:44وبسبب أن bun مصمم ليكون متوافقاً مع العقدة، يجب ألا تضطر إلى تغيير أي شيء عن الكود الخاص بك.
00:12:50أو الحزم الخاصة بك أو البرامج الوسيطة الخاصة بك.
00:12:51كل شيء يجب أن يكون لا يزال يعمل.
00:12:53إذا لم يكن، فهذا يعتبر أيضاً خطأ في bun.
00:12:57يجب أن تكون متوافقة 100٪ مع العقدة.
00:12:59لذا إذا كنت تحاول هذا، فقد قابلت مشاكل، دعنا نعرف.
00:13:02لكنك يجب ألا تضطر إلى إعادة كتابة أي شيء.
00:13:05والآن بما أن التطبيق الخاص بك يعمل على قمة bun، تحصل على الوصول إلى جميع واجهات برمجية bun المدمجة.
00:13:10لذا على سبيل المثال، يمكننا استخدام عميل S3 مباشرة في مثل دالة الخادم، في مكون خادم React وما إلى ذلك.
00:13:16لذا لا يجب أن نثبت أي التبعيات.
00:13:18لذا فقط للمقارنة ما الذي بدا عادة مع هذا مع العقدة، يمكنك أن ترى أنه مع bun، لدينا رمز أقل بكثير.
00:13:25لدينا تبعيات أقل.
00:13:27وهو متوافق فوراً مع جميع موفري S3 الآخرين أيضاً.
00:13:32لذا إذا كنت تريد التغيير من Amazon S3 إلى مثل Cloudflare R2، تخزين super base، كل هؤلاء الموفرين الآخرين، هذا فائق بسيط.
00:13:40أو واحد أكثر مثل كاملة، يمكننا استخدام S3، قذيفة bun، و SQL مباشرة في مكون خادم React.
00:13:47لذا أولاً، نحب الاستعلام قاعدة البيانات مع SQL للحصول على منشور مدونة، تولد عنوان URL مسبق التوقيع S3 للصورة، استخدم قذيفة bun لحساب الكلمات.
00:13:57مرة أخرى، لا توجد طبقة API إضافية أو أدوات من جهات خارجية بأن bun يستدعي.
00:14:02Bun يتعامل مع وقت التشغيل واتصالات قاعدة البيانات والقذيفة الكل بشكل أصلي في SIG، قريب جداً من المعادن.
00:14:10ومرة أخرى، بالطبع، إنه ليس فقط S3 SQL.
00:14:12نحصل على الوصول إلى جميع واجهات برمجية bun فقط بإضافة bun run --bun في الجبهة من next dev.
00:14:20لكن بالطبع، قد تفكر الآن، حسناً، أنا لا أستخدم Postgres.
00:14:24أنا لا أستخدم S3.
00:14:25أنا لا أستخدم أي التبعيات المجنونة، لذا لماذا يجب أن أهتم؟
00:14:28الشيء الذي دخلني إلى bun قبل أن أنضم كان بصراحة مجرد DX لا تصدق.
00:14:34يمكنك فقط تشغيل أي JS أو TS أو TSX أو JSX، لا يهم الملف بدون أي إعداد.
00:14:41إنه يعمل فقط.
00:14:41لا يجب أن تفكر في TSNode أو Babel أو SWC وما إلى ذلك.
00:14:46لذا حتى إذا لم تكن تستخدم next، حتى إذا كنت تتطور فقط، تريد سيناريو بناء سريع، فقط استخدام bun run، جرب للتو، يجعل حياتك أفضل بكثير لأنك لا تحتاج إلى أي تكوين.
00:14:59Bun أيضاً يأتي مع bun x.
00:15:01وهذا هو النوع المكافئ من bun إلى NPX.
00:15:04مرة أخرى، لا يجب أن تغير أي شيء.
00:15:06لا يجب أن تستخدم وقت تشغيل bun لهذا.
00:15:08يمكنك فقط تغيير NPX مع bun x.
00:15:11وترى تحسينات البدء الفورية.
00:15:13لذا على سبيل المثال، باستخدام bun x create next step أسرع بخمس مرات من NPX create next step.
00:15:20ومرة أخرى، لا يجب أن تستخدم وقت تشغيل bun لهذا.
00:15:23إنه فقط أسرع بكثير.
00:15:25لكن بالطبع، هناك أيضاً bun install، والذي، مرة أخرى، لا يتطلب تغيير وقت التشغيل.
00:15:31فقط يجعل التثبيت الخاص بك أسرع بكثير، أيضاً في مشاريع Next الأساسية.
00:15:36الآن بوضوح، تشغيل bun محلياً شيء واحد.
00:15:39لكن كيف ننشر التطبيقات التي تعمل على bun؟
00:15:42لأن هذا هو، بالطبع، وقت تشغيل جديد كلياً.
00:15:46يمكنك بالفعل استخدام Next.js على bun على عدة منصات مثل عرض وسكة حديد أو containerize التطبيق الخاص بك مع Docker.
00:15:54لكننا جميع مطوري Next.js.
00:15:56من المثالي، نريد أيضاً أن نكون قادرين على الانتشار إلى Vercel.
00:16:00لذا طبيعياً، قمنا بتغريد Guillermo، يطلب منه لطيفاً للحصول على دعم bun النسبية على Vercel.
00:16:07وحصلنا بسرعة على رد واعد جداً.
00:16:10وثم بعد بضعة أسابيع، تم تحقيق دعم bun على الأقل داخلياً.
00:16:15لذا أنا متحمس جداً أن دعم bun الأصلي سيأتي إلى Vercel قريباً جداً.
00:16:20وهذا يعني أنك ستكون قادراً - [تصفيق].
00:16:25التصفيق ينتقل إلى المهندسين العظماء في Vercel الذين جعلوا هذا ممكناً.
00:16:29لكن هذا مثير جداً لأن هذا يعني أنه يمكننا الآن تشغيل تطبيقات bun بسهولة مثل أي مشروع Next الآخر على Vercel.
00:16:37لذا أيضاً مثال من العالم الحقيقي فقط.
00:16:39أنا لست متأكداً إذا كان بإمكانك رؤيته على الشاشة.
00:16:41لكن تشغيل HONO API مع bun أسقطت بالفعل 30٪ أو انخفاض CPU من خلال بجرد تشغيل bun على Vercel.
00:16:49هذا، بالطبع، إطار عمل مختلف.
00:16:50هذا هو HONO API.
00:16:52لكنها نفس فوائد وقت التشغيل التي ستحصل عليها إذا كانت هذه مثل وظيفة الخادم، RSC، وما إلى ذلك.
00:16:57لأن bun يوفر الكثير من الاستخدام CPU والذاكرة.
00:17:02الآن نحن، بالطبع، لا يجب أن ننتظر دعم bun الأصلي لبدء استخدامه في تطبيقاتنا.
00:17:06أبسط طريقة هي نوع من البدء في استخدامه أو تبنيه بشكل متدرج.
00:17:11لذا أولاً، أوصي فقط بالتبديل إلى bun install.
00:17:14التغييرات لا شيء في قاعدة رمز الخاص بك.
00:17:16هذا فقط يستخدم مدير حزم bun بسرعة حقاً.
00:17:19أيضاً، إذا كنت مهتماً بمعرفة لماذا بسرعة bun install أسرع بكثير، كتبت مقالة عن هذا ليس منذ فترة طويلة.
00:17:24أوصي بشدة بأن تتحقق من ذلك.
00:17:26فقط يشرح - كما تعرف، لسنا فقط تخطي الخطوات.
00:17:29نحن نفعل مهما.
00:17:29إنه نوع من يشرح الهندسة النظام وراء ذلك التي تجعلها أسرع بكثير.
00:17:35الآن بعد استخدام bun install، جرب استخدام وقت تشغيل bun.
00:17:39يمكنك فقط استخدامه محلياً مع bun run --bun.
00:17:42اختبر التطبيق الخاص بك.
00:17:42انظر إذا كان كل شيء يعمل.
00:17:44يجب.
00:17:45إذا لم يكن، دعنا نعرف.
00:17:47وبعد ذلك أخيراً، يمكنك نوع من الانتقال بشكل متدرج إلى واجهات برمجية bun الأصلية حيث يكون منطقياً.
00:17:53يمكنك، بالطبع، لا تزال مزج ومطابقة هذه التبعيات NPM.
00:17:57لكن أفضل جزء هو أيضاً أن كل خطوة هنا قابلة للعكس.
00:18:00لذا إذا استخدمت أحدهم من واجهات برمجية bun الأصلية ولم تعمل، فيمكنك دائماً التبديل إلى Node.
00:18:06لكنها بالتأكيد تستحق المراجعة.
00:18:08الآن قبل أن أنهي هذه المحادثة، أريد فقط أن أقول شكراً كبير جداً لفريق المهندسين المذهل في bun.
00:18:17معظم الناس قد يعرفون جريد، لكن هناك فريق كامل خلف bun يعمل بجد جداً كل يوم لجعل bun أسرع وأكثر استقراراً وأكثر متعة بكثير في الاستخدام.
00:18:27إنهم يدفعون حقاً حدود ما هو ممكن مع JavaScript.
00:18:32إذن التالي، أعاد تخيل كيفية بناء الويب، لكن bun أعاد تخيل ما يقويها.
00:18:38شكراً لك كثيراً على المجيء إلى محادثتي، وأنا متحمس جداً لرؤية ما ستبنيه مع bun و Next.