00:00:00- لذا، ستكون النسخة العامة النهائية من +V على الأرجح،
00:00:03ستبدو وكأنها شيء ممتع.
00:00:06- هذا إيفان يو.
00:00:07- إيفان يو.
00:00:09- إيفان يو.
00:00:10- إيفان يو!
00:00:10- أنا من ابتكر Vue، وأنا من ابتكر Vite.
00:00:14الآن أدير شركة تسمى Voice Zero.
00:00:16- ما الفرق بين Vite و +Vite؟
00:00:19- ستكون تجربة التطوير الخاصة بك مطابقة تماماً
00:00:21لما هي عليه في Vite اليوم.
00:00:22ولكن إذا أردت التعمق أكثر،
00:00:24فهي موجودة لدعمك طوال الطريق.
00:00:26- كيف تستخدم أنت وفريقك الذكاء الاصطناعي؟
00:00:28- بدأنا في إجراء تجارب جنونية
00:00:30مثل نقل مترجم Angular إلى لغة Rust.
00:00:32- ما رأيك في مكونات خادم React (RSC)؟
00:00:34- لقد كنت متشككاً فيها منذ اليوم الأول.
00:00:36- عادةً عندما أقدم بودكاست،
00:00:39أطلب من الضيوف تقديم أنفسهم.
00:00:40ولكن أعتقد أنه إذا كان هناك من يشاهدنا
00:00:42ولا يعرف من أنت، سأكون متفاجئاً للغاية.
00:00:44أعتقد أنك مشهور جداً.
00:00:46ولكن يجب أن يعرف الجميع،
00:00:48أو معظم الناس، من أنت.
00:00:49- لقد سمعوا على الأقل بـ Vite أو Vue بكل تأكيد.
00:00:53- نعم، لقد ابتكرت Vue و Vite.
00:00:57الآن أدير شركة تسمى Voice Zero
00:00:59حيث نعمل على المزيد من المشاريع مفتوحة المصدر.
00:01:03هناك Rodeo و Vtest و OXC.
00:01:07ونعم، ربما Vue و Vite أكثر شهرة،
00:01:11ولكن بعض الأشياء التي نعمل عليها في Voice Zero
00:01:14رائعة جداً أيضاً.
00:01:15لأن Rodeo عبارة عن مجمع (bundler) يعتمد على Rust.
00:01:18و OXC هي سلسلة أدوات Rust كاملة تشمل
00:01:22كل شيء من المحلل (parser) إلى المعالج (resolver) والمحول (transformer)،
00:01:25والمصغر (minifier)، وما إلى ذلك.
00:01:28وعلى رأس OXC، لدينا OX Linked و OX Format،
00:01:32وهو أداة ربط متوافقة مع ESLint
00:01:35وأداة تنسيق متوافقة مع Prettier.
00:01:37وهناك المزيد من الأشياء التي لا نزال نعمل عليها، ولكن نعم.
00:01:41لذا نريد التحدث غالباً عن المصادر المفتوحة في الوقت الحالي.
00:01:45- بالتأكيد.
00:01:45بما أنك تعمل على الكثير من الأشياء،
00:01:47كيف تقسم وقتك؟
00:01:50- حسناً، أنا شخصياً لا أكتب الكود
00:01:52لكل هذه المشاريع.
00:01:53في الواقع، أكتب كوداً أقل بكثير هذه الأيام
00:01:56منذ أن بدأت الشركة.
00:01:58لدينا في الشركة العديد من المهندسين
00:02:01الذين يتفوقون عليّ بمراحل في لغة Rust
00:02:03وجميعهم الآن منخرطون تماماً في الذكاء الاصطناعي.
00:02:05الأمر وكأن نصف الكود منهم والنصف الآخر من Cloud Code أو Codex
00:02:10التي تنفذ الكثير من أكواد Rust.
00:02:12وعليّ أن أتخذ القرارات بشأن ما يجب فعله
00:02:17فيما يتعلق بتجربة المطور (DX)،
00:02:22وتحديد ما نريد التركيز عليه تالياً.
00:02:25وبالطبع هناك أيضاً المنتجات،
00:02:28مثل كيف نحول هذا إلى منتج
00:02:31يدر المال،
00:02:32وهو أمر لا نزال نعمل عليه.
00:02:34نعم، إنها كل تلك المهام التي تحتاجها
00:02:39لإدارة شركة هذه الأيام.
00:02:41- من أين تأتي هذه الأفكار
00:02:43للمشاريع الجديدة مفتوحة المصدر؟
00:02:45هل تأتي غالباً من احتياجات داخلية
00:02:48تدركون أنها قد تساعد
00:02:49في حل مشاكل الآخرين أيضاً؟
00:02:53- في الواقع، كل شيء يبدأ من Vite، أليس كذلك؟
00:02:56عندما ابتكرت Vite، كنت أعمل عليه بشكل عفوي.
00:03:01بدأ كنموذج أولي
00:03:03ثم فكرت: نحن بحاجة إلى مجمع (bundler).
00:03:07بدأنا بهذا الخادم الخاص بالتطوير
00:03:10الذي يعتمد على ESM الأصلي غير المجمع.
00:03:13ونجحت هذه الفكرة بشكل رائع مع الأكواد البسيطة،
00:03:16ولكن عندما بدأنا في إدراج بعض التبعيات الكبيرة
00:03:18أدركنا أن هذا لن يتوسع بشكل جيد
00:03:21إذا قمت بتحميل جميع التبعيات دون تجميعها.
00:03:24على سبيل المثال، إذا كان لديك شيء مثل SES،
00:03:26الذي يحتوي على حوالي 700 ملف.
00:03:28فقلنا: حسناً،
00:03:30نحن بحاجة لشيء يجمع التبعيات.
00:03:34في ذلك الوقت كان هناك Rollup و esbuild و Webpack.
00:03:41و Webpack لا يخرج ESM، لذا لا يمكننا استخدامه.
00:03:47لذا نظرت إلى Rollup، وهو بطيء نوعاً ما.
00:03:50إنه بطيء جداً مقارنة بـ esbuild، أليس كذلك؟
00:03:53إنه أسرع من Webpack، لكنه بطيء مقارنة بـ esbuild.
00:03:56لذا استخدمنا esbuild للتجميع المسبق للتبعيات،
00:03:59وهو سريع كالبرق.
00:04:00ثم نقوم بتقديم الكود المصدري كـ ESM غير مجمع
00:04:02وقد نجح ذلك بشكل رائع.
00:04:04وعندما وصلنا لمرحلة الإنتاج،
00:04:06فكرنا في البداية: حسناً،
00:04:08دعونا نستخدم esbuild لتجميع المشروع بالكامل
00:04:10من أجل مرحلة الإنتاج.
00:04:11ثم أدركنا أن esbuild لديه تحكم محدود للغاية
00:04:14في كيفية تقسيم الأجزاء (chunks).
00:04:17وهي حاجة شائعة جداً عند بناء تطبيقات كبيرة
00:04:19لأنك تريد أن تكون قادراً على التحكم،
00:04:21مثلاً أريد وضع تبعيات هذه المكتبة
00:04:24في جزء خاص بالمورد (vendor chunk)، ليتم تخزينه مؤقتاً بشكل أفضل.
00:04:26لا أريد أن يتغير هذا الجزء أبداً، صحيح؟
00:04:28بحيث يحتفظ ببصمة (hash) ثابتة.
00:04:32لذا حتى لو قمت بتغيير الكود المصدري الخاص بي،
00:04:33يجب أن تظل بصمة ذلك الجزء كما هي.
00:04:35وبالتالي يحصل المستخدمون دائماً على ذلك الجزء مخزناً
00:04:38عندما يزورون الموقع.
00:04:39هناك الكثير من هذه الأنواع من التحسينات
00:04:41التي لا يسمح بها esbuild على الإطلاق.
00:04:44لديه سلوك افتراضي واحد لتقسيم الأجزاء
00:04:47وهذا كل شيء.
00:04:49كما أن نظام الإضافات الخاص به أقل مرونة.
00:04:53فإذا قررت إضافة واحدة أنها
00:04:56ستعالج هذا الملف، ينتهي الأمر.
00:04:59لا يمكن لأي إضافات أخرى لمسه بعد ذلك.
00:05:02بينما كنا نستخدم Rollup كثيراً،
00:05:05وكنا معتادين على نظام الإضافات في Rollup.
00:05:08لذا ما انتهى بنا الأمر إليه هو، حسناً،
00:05:10سنستخدم Rollup لتجميع الإنتاج،
00:05:13و esbuild للتجميع المسبق أثناء التطوير.
00:05:15كان الأمر كما لو أن كل أداة قامت
00:05:20بأفضل ما لديها في هذا المزيج.
00:05:23وفي الواقع، حتى اليوم Vite 6 لا يزال يعتمد
00:05:26على هذا المزيج.
00:05:27وهذا يعمل بشكل جيد للكثير من الناس، أليس كذلك؟
00:05:31ولكن من الواضح أن هناك مشاكل لأن esbuild
00:05:35مكتوب بلغة Go، بينما Rollup مكتوب بلغة JavaScript،
00:05:40مما يعني أن بناء الإنتاج
00:05:41لا يزال بطيئاً جداً مقارنة مثلاً
00:05:43بالمجمعات القائمة بالكامل على Rust مثل RSPack.
00:05:47وبالنسبة لخادم التطوير، ولأن esbuild
00:05:52و Rollup لديهما أنظمة إضافات مختلفة،
00:05:55لا يمكننا تطبيق نفس مجموعة الإضافات
00:05:57على التبعيات أثناء التطوير،
00:05:59بينما يتم تطبيقها على التبعيات
00:06:01أثناء بناء الإنتاج.
00:06:03وهناك أيضاً مشاكل طفيفة في التوافق.
00:06:07فعندما يكون لديك مزيج من ESM و CJS،
00:06:10يتعامل معها esbuild و Rollup بشكل مختلف قليلاً.
00:06:13هناك فروقات في سلوك التخلص من الكود غير المستخدم (tree shaking).
00:06:15ورغم أنهما يقومان بعمل جيد،
00:06:18إلا أننا نقوم أيضاً بترقيع كل التناقضات السلوكية
00:06:22وكل ذلك.
00:06:22جعلنا الأمور تعمل، لكننا في قرارة أنفسنا نعلم،
00:06:25أنهما مجرد شيئين مختلفين قمنا
00:06:29بطريقة ما بجمعهما معاً.
00:06:31لذا، أولاً لجعل بناء الإنتاج أسرع
00:06:35وثانياً لجعل بناء التطوير والإنتاج أكثر اتساقاً،
00:06:40أفضل شيء هو أن يكون هناك مجمع واحد
00:06:42يقوم بالأمرين معاً.
00:06:44لكن المشكلة هي أن esbuild سريع،
00:06:47لكنه ليس قابلاً للتوسع بشكل كبير.
00:06:50قاعدة الكود مكتوبة بالكامل بلغة Go.
00:06:54إيفان والاس، وهو مؤلف esbuild،
00:06:57هو بوضوح عالم مجنون وعبقري
00:06:59وقد جعل esbuild سريعاً للغاية،
00:07:02لكنه ليس مناسباً تماماً للآخرين
00:07:05لتوسعته أو اشتقاق نسخة منه (fork)
00:07:07أو حتى صيانة طبقة فوقه.
00:07:10ليس من السهل القيام بذلك.
00:07:12ومن الصعب أيضاً إقناع إيفان والاس
00:07:15بفعل أشياء لا يريد القيام بها
00:07:17لأنه ليس بحاجة للمال ولا يكترث.
00:07:21لذا قلنا: حسناً، وماذا عن Rollup؟
00:07:27هل يمكننا جعل Rollup أسرع؟
00:07:28كانت هناك بعض التجارب،
00:07:30ولكن بشكل أساسي Rollup مكتوب بلغة JavaScript
00:07:33و JavaScript تعني أنه يعمل بخيط معالجة واحد.
00:07:36حاولنا أشياء مثل مجمعات العمال (worker pools)، والإضافات في العمال.
00:07:41وحاول مطور Rollup وضع محلل Rust،
00:07:47محلل SWC داخل Rollup.
00:07:50لكن ذلك لم يحسن الأداء بشكل ملحوظ
00:07:54لأنه عندما يكون لديك نظام مختلط بين Rust و JS،
00:07:57هناك دائماً تكلفة تمرير البيانات.
00:07:59أنت تمرر كتلًا كبيرة من النصوص ذهاباً وإياباً.
00:08:02وإذا اضطررت لنسخ الذاكرة، يصبح الأمر أبطأ.
00:08:05اتضح أن مكاسب الأداء الخام من Rust،
00:08:09عندما يكون لديك محلل Rust فقط
00:08:12بينما كل شيء آخر بلغة JavaScript،
00:08:13فإن مكاسب الأداء تتبخر بسبب تكلفة تمرير البيانات.
00:08:16لذا انتهى الأمر بنفس الأداء تقريباً.
00:08:19لذا قلنا: حسناً، جعل Rollup أسرع بشكل جذري
00:08:23غير ممكن تقنياً.
00:08:26والخيار الوحيد هو إعادة كتابة هذا الشيء،
00:08:30إعادة كتابة مجمع مصمم خصيصاً
00:08:33من أجل Vite، ويجب أن يكون سريعاً كونه البرق.
00:08:37هذا ما بدأ رحلة التفكير في: حسناً،
00:08:40ماذا يجب أن نفعل؟
00:08:42لذا قررنا جوهرياً،
00:08:44كانت الفكرة الأصلية هي اشتقاق نسخة من Rollup بلغة Rust.
00:08:48ليس اشتقاقاً، بل نقلاً (porting).
00:08:49أردنا نقل Rollup إلى Rust.
00:08:51لهذا السبب يسمى المشروع Rolldown.
00:08:53فهناك Rollup، وهناك Rolldown.
00:08:54وبدأ الأمر كنقل مباشر،
00:08:58ولكننا أدركنا أن الكود المكتوب بلغة JavaScript
00:09:02ليس من السهل نقله مباشرة إلى Rust
00:09:06لأن JavaScript لغة ديناميكية للغاية.
00:09:08إنها لغة ديناميكية، أليس كذلك؟
00:09:11حتى لو استخدمت TypeScript،
00:09:13لا يزال بإمكانك تغيير الأشياء كما تشاء.
00:09:16بينما Rust صارمة جداً بشأن الذاكرة.
00:09:19وصارمة بشأن دورات الحياة والملكية وما إلى ذلك.
00:09:23لذا عليك هيكلة الأمور بشكل مختلف تماماً
00:09:25مقارنة بـ JavaScript.
00:09:27لذا لن يكون من السهل أبداً
00:09:29نقل كود JavaScript موجود حالياً
00:09:31إلى لغة مثل Rust.
00:09:33الأمر أشبه بإعادة كتابة كاملة.
00:09:35وانتهى بنا الأمر في الواقع،
00:09:37أردنا أيضاً الحصول على أفضل ما في العالمين.
00:09:42Rollup نفسه جوهره بسيط جداً.
00:09:45لذا إذا أردت تحويل Rollup
00:09:47إلى إعداد جاهز للإنتاج،
00:09:49فالأمر يتطلب جهداً كبيراً
00:09:51لأنك بحاجة لأشياء مثل إضافة معالج Node (node resolver)،
00:09:54لأن معالجة وحدات node ليست ميزة مدمجة.
00:09:56يجب إضافتها عبر إضافة (plugin).
00:09:58وتحتاج لإضافة CommonJS لدعم وحدات CommonJS
00:10:03لأن جوهر Rollup يدعم ESM فقط.
00:10:06ثم عليك إضافة مجموعة من الإضافات
00:10:10مثل define و inject و replace.
00:10:14الكثير من هذه الميزات مدمجة في esbuild،
00:10:17لكنها تتطلب إضافات في Rollup.
00:10:20والأسوأ من ذلك أن معظم هذه الإضافات في عالم JavaScript
00:10:25تنفذ عملية تحليل AST وتحويل وتوليد كود كاملة إضافية.
00:10:30لذا كل إضافة تقوم فعلياً بالعملية كاملة،
00:10:33تأخذ الكود من الإضافة السابقة،
00:10:36وتحلله مجدداً، وتحوله،
00:10:38وتولد كوداً جديداً، وخريطة مصدر (source map) جديدة.
00:10:41ثم عليك دمج كل خرائط المصدر معاً.
00:10:43لهذا السبب تصبح أنظمة بناء JavaScript أبطأ وأبطأ
00:10:46لأن كل إضافة تكرر هذه العملية مراراً وتكراراً.
00:10:49لذا قلنا: حسناً، نحتاج لأن تكون هذه الميزات مدمجة أيضاً.
00:10:53لذا انتهى بنا الأمر بتبني نطاق esbuild،
00:10:56ولكن بشكل واجهة برمجة تطبيقات (API) الخاصة بـ Rollup، وهذا هو Rolldown.
00:11:01ولكن من أجل بناء Rolldown، قلنا:
00:11:03نحتاج لمحلل، ونحتاج لكل التحويلات، صحيح؟
00:11:07نحتاج لمصغر (minifier)، ونحتاج لمعالج (resolver).
00:11:10فكيف نحصل على ذلك؟
00:11:12وهنا يأتي دور OXC.
00:11:14OXC هي مجموعة من أدوات اللغة منخفضة المستوى
00:11:17التي تمنحك كل ذلك.
00:11:20كان مؤلف OXC يعمل في ByteDance في ذلك الوقت
00:11:25وكنت أراقب المشروع منذ فترة طويلة.
00:11:28بوشين (Borshin)، هو مؤلف OXC
00:11:30وهو الآن نائب رئيس الهندسة لدينا في Voice Zero.
00:11:33لم ينضم للشركة فور تأسيسها.
00:11:36كنت أحاول إقناعه بالانضمام، لكنه كان متردداً،
00:11:38مثل: لا أعلم،
00:11:39لكننا بدأنا في بناء Rolldown فوق OXC على أي حال.
00:11:44قلنا: هذا عمل رائع.
00:11:45أؤمن أن هذا هو المسار،
00:11:47لأنني نظرت في كل الخيارات المتاحة.
00:11:51أريد شيئاً قابلاً للتركيب.
00:11:54أريد شيئاً يكون فيه كل جزء من سلسلة الأدوات
00:11:57قابلاً للاستخدام بشكل منفرد كمكتبات (crates).
00:12:00وأريده أيضاً أن يكون سريعاً للغاية.
00:12:03لذا قارنا بين OXC و SWC.
00:12:06محلل OXC أسرع بثلاث مرات
00:12:09من محلل SWC رغم أن كليهما مكتوب بلغة Rust،
00:12:12بسبب الكثير من القرارات التصميمية
00:12:15والتفاصيل التقنية منخفضة المستوى
00:12:18التي أدت إلى هذا الفرق في الأداء.
00:12:20السبب الرئيسي هو أن بوشين كان مهووساً
00:12:24بأداء المحلل وأداء الربط
00:12:27لفترة طويلة قبل انضمامه للشركة.
00:12:30على سبيل المثال،
00:12:32يستخدم OXC ما يسمى بمخصص الحلبة (arena allocator)،
00:12:34الذي يضع كل تخصيصات الذاكرة للـ AST
00:12:39في كتلة ذاكرة متصلة.
00:12:41يقوم بحجز كتلة كبيرة من الذاكرة
00:12:43ويضع الـ AST فيها مباشرة.
00:12:45وبالتالي تستغرق عملية تحرير الذاكرة وقتاً أقل.
00:12:50كما يفتح آفاقاً لأشياء مثيرة قمنا بها
00:12:53تسمح بعمل إضافات JS سريعة في OXLint،
00:12:57لأن اتساق الذاكرة يسمح لنا
00:12:59بتمرير كتلة الذاكرة بالكامل إلى JavaScript
00:13:01دون نسخها، ثم تفكيكها (deserialize) في جانب JS.
00:13:05هناك الكثير من الفوائد،
00:13:06وعندما كنت أنظر للمشروع حينها،
00:13:10أعجبت به حقاً،
00:13:10وقررنا بناء Rolldown فوقه
00:13:13وأقنعنا بوشين بالانضمام في النهاية.
00:13:16والآن أصبح نطاق الشركة جوهرياً
00:13:21هو امتلاكنا لهذه البنية الرأسية من Rust
00:13:24التي تبدأ من المحلل.
00:13:26وتغطي كل شيء حتى التجميع في Vite،
00:13:29ولدينا أداة فحص (Linter)، ومنسق (Formatter)، ومشغل اختبارات (Test Runner).
00:13:33لدينا سلسلة أدوات كاملة.
00:13:34وما سنقوم به تالياً،
00:13:37والذي نعمل عليه منذ فترة،
00:13:40هو وضع كل هذه الأشياء معاً في حزمة واحدة متماسكة
00:13:43حتى لا تضطر لتثبيت خمسة أشياء منفصلة
00:13:47فقط لتشغيل تطبيق أساسي.
00:13:50ولن تحتاج أيضاً لوجود
00:13:51ستة أو سبعة ملفات إعداد مختلفة.
00:13:55سنضعها جميعاً في ملف إعداد واحد،
00:13:57ونضمن أنها ستعمل معاً
00:13:59لأنها تعتمد جميعاً على نفس المحلل،
00:14:02ونفس مسار التحويل، ونفس المعالج.
00:14:05لذا لن تكون هناك مفاجآت.
00:14:07على سبيل المثال، إذا استخدمت Webpack و Jest،
00:14:10عليك ضبط منطق المعالجة الخاص بكل منهما بشكل منفصل
00:14:14لأنهما ببساطة لا يستخدمان نفس الأداة.
00:14:16لذا، الرؤية حقاً هي،
00:14:19حسناً، لنقم ببناء بنية رأسية
00:14:22تعمل باتساق في كل مكان.
00:14:25ونجعل تجربة التطوير مباشرة
00:14:29وسريعة قدر الإمكان.
00:14:30الأداء أمر بالغ الأهمية.
00:14:32لقد اعتبرت ذلك أمراً مسلماً به،
00:14:34ولكن ربما رأيتم تغريدات حول كيف أن Rolldown
00:14:39أسرع بـ 20 مرة من Rollup.
00:14:43و OX link أسرع بـ 50 إلى 100 مرة من ESLint.
00:14:47و OX format أسرع بـ 30 إلى 40 مرة من Prettier.
00:14:51هدفنا هو جعلها متوافقة حقاً
00:14:57حتى تتمكن من الانتقال إليها دون إعادة هيكلة كبرى،
00:15:00لكنك ستحصل على هذه القفزات الهائلة في الأداء
00:15:04والآن ستصبح دورة الاختبار، وفحص الأخطاء
00:15:08وكل شيء أسرع وأكثر سلاسة بكثير.
00:15:12وهذا سيسمح للناس
00:15:15ببناء المزيد من التطبيقات بشكل أسرع.
00:15:17- أحببت كيف يتصاعد الأمر بسرعة
00:15:20من: نحن بحاجة لأداة بناء لـ Vue، إلى:
00:15:22أريد تحسين هذا الجزء الآن.
00:15:24ثم: أريد تحسين ذلك الجزء أيضاً.
00:15:25وكما قلت، أنتم تمتلكون فعلياً
00:15:27البنية الرأسية الكاملة.
00:15:29هذا مبهر جداً وسريع للغاية.
00:15:32كنت أخبر الشباب قبل أن نبدأ
00:15:33أنه في إحدى وظائفي السابقة،
00:15:35بدأنا العمل على مشروع قديم
00:15:37وكان يستخدم Webpack واستغرق بناؤه 50 دقيقة.
00:15:40لم يكن لدي أدنى فكرة عما يحدث،
00:15:42لكن أول شيء قلته لهم هو:
00:15:43نحن بحاجة للانتقال إلى Vue فوراً.
00:15:46لأنه حتى عند تغيير ملف CSS،
00:15:47كان عليك الانتظار لدقيقتين
00:15:49لإعادة البناء وكل شيء.
00:15:49وقلت: هذا ليس جيداً.
00:15:52نحن بحاجة لاستخدام خاصية تبديل الوحدات الفورية (HMR).
00:15:54عندما أحفظ الملف، يجب أن يظهر التغيير مباشرة.
00:15:57لذا ساعدت Vue بالتأكيد في ذلك.
00:15:59وأعتقد أن التقدم ومعدل
00:16:02انتشار Vue مذهل حقاً.
00:16:05لقد رأيت أنها وصلت لـ 200 مليون تحميل من NPM
00:16:07شهرياً أو رقم جنوني كهذا.
00:16:09إنه—
00:16:10- نعم، لقد تجاوزنا 50 مليوناً أسبوعياً منذ فترة قصيرة.
00:16:13- هذا مذهل.
00:16:15- كنت أفكر في الـ 50 مليوناً هذه.
00:16:19ربما هناك بعض التضخم
00:16:21من تلك التطبيقات التي يتم إنشاؤها عبر الذكاء الاصطناعي.
00:16:23تلك التي تكون مجرد هياكل للتجربة ثم يتم التخلص منها.
00:16:26ومع ذلك، هذا يظهر أن الكثير من الناس
00:16:29أو ربما الكثير من وكلاء الذكاء الاصطناعي يستخدمونها.
00:16:33- كنت سأقول إن الفريق الهندسي
00:16:34في Betaslack من كبار المعجبين بـ Vue.
00:16:36يستخدمون Rails في الخلفية مع Vue في الواجهة الأمامية.
00:16:40ولديهم بعض الأسئلة التي سأطرحها
00:16:42خلال البودكاست حسب سياق الحديث.
00:16:46لكنك ذكرت شيئاً عن التجميع (bundling)
00:16:48وأحد أسئلتهم كان،
00:16:49بما أنهم يستخدمون خرائط الاستيراد (import maps) في Rails،
00:16:52أين ترى مستقبل التجميع؟
00:16:54لأنك لست مضطراً للتجميع كثيراً
00:16:56إذا كنت تستخدم خرائط الاستيراد.
00:16:57لذا، إلى أين ترى الأمور تتجه؟
00:17:00- في الواقع، لدي صفحة مخصصة
00:17:02في توثيق Rolldown،
00:17:04عنوانها هو،
00:17:07“لماذا لا نزال بحاجة للمجمعات؟”
00:17:10- هل سُئلت هذا السؤال كثيراً؟
00:17:13- نعم، أعني أن DHH صريح جداً
00:17:16بشأن عدم الحاجة للتجميع أو البناء.
00:17:18لذا كان علينا الاهتمام بذلك.
00:17:20وخرائط الاستيراد تعمل إلى حد معين،
00:17:24ولكن عدم التجميع بشكل عام مفهوم
00:17:29يعمل فقط حتى حجم معين.
00:17:35إذا كان تطبيقك يحتوي على أقل من ألف وحدة (module)،
00:17:39فمن المحتمل أن يتم تحميل مخطط الوحدات بالكامل
00:17:41خلال بضع مئات من الأجزاء من الثانية
00:17:43وهذا مقبول تماماً.
00:17:45وإذا كنت تعلم أنك تعمل ضمن هذا النطاق،
00:17:48فهذا أمر رائع فعلاً.
00:17:50إنه يعتمد على التحميل الكسول (lazy) افتراضياً،
00:17:53مما يعني أنه إذا كان لديك تطبيق كبير
00:17:56وكل صفحة فيه معزولة نوعاً ما،
00:17:58فلديك هذا المخطط الفرعي للوحدات،
00:18:00وهو يعمل بشكل جيد.
00:18:01لهذا السبب يعمل Vite بشكل جيد أثناء التطوير.
00:18:05لكنه ليس حلاً سحرياً
00:18:07لأن ما لاحظناه مع Vite نفسه
00:18:09والسبب في أننا نعمل على شيء
00:18:12يسمى وضع التجميع الكامل في Rolldown
00:18:15هو أن وضع عدم التجميع له حدوده،
00:18:18وهي أن العائق الحقيقي هو عدد الوحدات.
00:18:21هناك الكثير والكثير من التطبيقات التي
00:18:25تقوم بتحميل آلاف الوحدات
00:18:29أثناء التطوير، صحيح؟
00:18:32قد تقوم بتحميل حوالي 3000 وحدة
00:18:33وهذا قد يسبب اختناقاً للمتصفح.
00:18:36العائق يكون على مستوى الشبكة
00:18:38لأنه مع ESM الأصلي،
00:18:40أنت ترسل طلب HTTP لكل وحدة لجلبها.
00:18:44وإذا كان لديك مخطط استيراد عميق،
00:18:46فعليه جلب الوحدة الأولى
00:18:49ليكتشف: حسناً، أحتاج لهذه الوحدات الإضافية
00:18:52فيقوم بجلبها.
00:18:53ثم يجلب التي تليها،
00:18:54عليك تتبع المخطط بالكامل بشكل مسبق
00:18:57قبل أن تتمكن فعلياً من تشغيل وحدة الاستيراد الأولى.
00:19:00فإذا كنت على شبكة ضعيفة،
00:19:04هناك احتمال لحدوث عدة رحلات ذهاب وإياب عبر الشبكة
00:19:06قبل أن تتمكن من عرض أول شيء.
00:19:09وإذا كان لديك آلاف الوحدات،
00:19:13فإن الوضع يتفاقم بسبب الشبكة.
00:19:17حتى في التطوير المحلي، في خادم تطوير Vite،
00:19:20إذا كان لديك أكثر من 3000 وحدة،
00:19:23سيستغرق الأمر ثانية أو ثانيتين لتحميلها محلياً.
00:19:27فتخيل ما الذي سيفعله ذلك في الإنتاج
00:19:29عبر الشبكة، أليس كذلك؟
00:19:31أنت حقاً لا تريد ذلك لأنه إذا قمت بتجميعها،
00:19:35فربما سيستغرق الأمر حوالي 100 مللي ثانية.
00:19:38لذا فهو تحسين مجاني متاح
00:19:40يجب عليك دائماً استغلاله
00:19:41عندما تتخطى عتبة معينة.
00:19:45أعتقد أن الحجة الرئيسية لتجنب التجميع
00:19:47وأدوات البناء تماماً هي أن الناس سئموا
00:19:52من إعداد الأدوات، صحيح؟
00:19:55ربما واجهوا أخطاء برمجية،
00:19:56أو مشاكل في الإعدادات لم يستطيعوا حلها.
00:20:01ولأن Webpack جعل الأمر معقداً للغاية،
00:20:04أصبح الجميع، كما تعلم،
00:20:06عندما يفكرون في ضبط المجمع،
00:20:08يقولون: هذه ليست مهمتي، لا أريد فعل ذلك.
00:20:11لذا أعتقد أن الناس لديهم هذا الاستياء
00:20:14عندما يسمعون بمرحلة البناء،
00:20:16ويشعرون أنها أمر سيء يريدون تجنبه.
00:20:19لذا، ما نريد فعله بهذه الأدوات
00:20:22ومجموعة الأدوات التي نطورها هو،
00:20:24أننا نريد جعل هذه المفاهيم بسيطة للغاية،
00:20:28ولن تكون بسيطة أبداً
00:20:32بالنسبة للتطبيقات الكبيرة والمعقدة،
00:20:34ولكننا نريد جعلها بسيطة بما يكفي لتطبيق جديد
00:20:37حتى لا تضطر للتفكير في الأمر كثيراً
00:20:41إذا لم يكن تطبيقك معقداً جداً.
00:20:45يجب أن تكون قادراً على القول: حسناً، سأشغل هذا التطبيق،
00:20:48إنه يستخدم Vite وأنا أعلم أن الأمور ستكون رائعة.
00:20:50في الواقع، أعلم أن هناك مجتمعاً قام بعمل
00:20:55إضافة تسمى Ruby Vite أو Vite Rails
00:20:59تجعل Vite يعمل بشكل جيد جداً في Rails.
00:21:05أعتقد أن إعدادات “بدون بناء” لها فوائدها،
00:21:12فهي تجعلك تشعر بالراحة لأنك تعلم
00:21:14أنه يمكنك تجنب الكثير من التبعيات
00:21:17والأمور غير المؤكدة التي قد تسبب أعطالاً.
00:21:20أعتقد أيضاً أن فقدان البعض للثقة
00:21:23في نظام البناء هو أنهم يشعرون
00:21:26بأنه سيحدث دائماً خطأ ما.
00:21:29البناء سيفشل عندما أقوم بتحديث تبعية ما،
00:21:33وهم يريدون حقاً تجنب كل ذلك، وهو أمر مغرٍ.
00:21:36ولكنني أعتقد في نهاية المطاف،
00:21:37إذا كانت التقنية جيدة ومستقرة بما يكفي،
00:21:41فأنت تريد دائماً أفضل تجربة مستخدم ممكنة
00:21:45واعتماد أسلوب عدم التجميع بالكامل يعني الالتزام
00:21:48بقيود محدودة جداً فيما يخص حجم تطبيقك.
00:21:52وعليك القلق بشأن التحسين أيضاً،
00:21:54لأن عليك التفكير في:
00:21:57هل قمت عن طريق الخطأ باستيراد الكثير من الأشياء
00:22:01في صفحة معينة يتم زيارتها؟
00:22:03وكيف أقوم بتخزين وحداتي مؤقتاً بذكاء؟
00:22:06أعتقد أنه حتى مع Rails غير المجمع،
00:22:08لا تزال بحاجة للقيام بشيء يشبه مرحلة المعالجة المسبقة
00:22:11لوسم الوحدات ليتم تخزينها مؤقتاً بشكل صحيح.
00:22:15لذا، لا مفر من ضرورة الاهتمام
00:22:18بالتحسين من أجل جعل الأمور تعمل.
00:22:21أود أن أقول إن الأمر ينجح بالتأكيد في
00:22:24عدد لا بأس به من الحالات، ولكنه ليس كذلك،
00:22:29لن يغطي جميع حالات الاستخدام.
00:22:31وبعض الناس يبنون تطبيقات ضخمة حقاً،
00:22:35تحتوي على الكثير من الميزات.
00:22:37لذا لا يمكنك ببساطة إجبارهم على عدم التجميع
00:22:39ثم حبسهم في هذا الموقف
00:22:42الذي لا يمكن فيه تحسين الأداء.
00:22:45- بالنسبة لأولئك الذين ليسوا على دراية بالأمر كثيراً،
00:22:49ما الفرق بين Vite و +Vite؟
00:22:54وما الذي سيحصل عليه الناس من ذلك؟
00:22:57- بالنسبة لـ +Vite، نحن نمر الآن بنوع من
00:23:02تغيير المسار البسيط حول ما يجب أن يكون عليه +Vite حالياً.
00:23:06الفكرة هنا هي إذا كنت قد بدأت للتو
00:23:11في تطوير JavaScript من الصفر تماماً،
00:23:14كأن تكون جديداً على تطوير JavaScript،
00:23:17ولديك جهاز جديد لم يثبت عليه أي شيء.
00:23:21كيف تنتقل من الصفر إلى تطبيق يعمل
00:23:25مع ميزة التبديل الفوري للوحدات، وكل الممارسات الفضلى،
00:23:28والتنسيق، والاختبار، وكل شيء جاهز لك؟
00:23:33في الوقت الحالي، هذا يتطلب الكثير من التعلم.
00:23:36أول شيء عليك تعلمه هو:
00:23:38ما هو Node.js؟
00:23:39وكيف أقوم بتثبيته؟
00:23:40ما هو مدير إصدارات Node؟
00:23:42أي مدير حزم يجب أن أستخدم؟
00:23:44أي أداة بناء يجب أن أستخدم؟
00:23:45أي أداة فحص (linter) يجب أن أستخدم؟
00:23:47عليك الإجابة على كل هذه الأسئلة.
00:23:49نحن نريد إزالة كل هذه الأسئلة.
00:23:50نريد أن نمنحك نقطة انطلاق جاهزة
00:23:52وهي، كما تعلم،
00:23:54أنك لن تحتاج حتى لتثبيت Node.js، صحيح؟
00:23:57لذا، نحن نجرب هذه الطريقة الجديدة
00:23:59للعمل مع +Vite وهي عبر أمر curl،
00:24:03مثل curl [https://vplus.dev](https://www.google.com/search?q=https://vplus.dev) | bash.
00:24:08ثم vp dev، أو vp new، ويكون لديك مشروع جديد
00:24:15ثم تشغل vp dev ويكون لديك،
00:24:17مجموعة كاملة من الأشياء تم إعدادها لك.
00:24:21لديك أداة الفحص، ومنسق الملفات،
00:24:25ومشغل الاختبارات، والمجمع، وكل شيء، ويمكنك استخدامه أيضاً
00:24:28لإنشاء هيكل مستودع ضخم (monorepo).
00:24:31وفيه تجميع للمكتبات.
00:24:32ونخطط لإضافة ميزات مدمجة مثل الربط بمراحل Git (link stage)،
00:24:39وإدارة سجل التغييرات.
00:24:41إذا كنت تعمل على مكتبات monorepo كبيرة،
00:24:44وهناك أيضاً شيء يسمى vp run
00:24:49وهو مشغل مهام، يشبه pnpm run،
00:24:52ولكنه أكثر تطوراً نوعاً ما،
00:24:57يشبه NX حيث يمكنه معرفة
00:24:59الترتيب الصحيح لتشغيل مهامك
00:25:03وكذلك تخزينها مؤقتاً بذكاء.
00:25:04وهذا اختياري بالطبع.
00:25:07فهو عبارة عن مجموعة كاملة، كما تعلم،
00:25:11إذا لم تكن بحاجة لهذه الإضافات،
00:25:13يمكنك استخدامه تماماً مثل Vite الأساسي، صحيح؟
00:25:17تجربة التطوير ستكون مطابقة تماماً
00:25:18لما هو عليه Vite اليوم.
00:25:20ولكن إذا أردت المضي قدماً،
00:25:24والتوسع لمستوى المؤسسات وإنتاج
00:25:27monorepo جاهز للعمل، فهو متاح لك طوال الطريق.
00:25:31وأيضاً، لأنه مبني على
00:25:33تقنيات مثبتة ومستخدمة بالفعل
00:25:35من قبل أشخاص في مثل تلك المواقف.
00:25:39هذا ما نأمل تقديمه، صحيح؟
00:25:44نحن نقوم بتحويل الكثير من المستخدمين الحاليين
00:25:47إلى عروضنا مفتوحة المصدر،
00:25:48حيث ينتقل الناس من Webpack إلى Vite،
00:25:52وينتقلون من ESLint إلى OXLint.
00:25:54وما نأمله من +Vite هو أن يجيب على،
00:25:57ذلك السؤال: ماذا أفعل
00:26:00إذا كنت قد بدأت للتو في JavaScript؟
00:26:02ما هي أسرع وأبسط طريقة للبدء؟
00:26:05أريد الإجابة على هذا السؤال
00:26:07وكذلك جعله يعمل بشكل رائع جداً مع الذكاء الاصطناعي.
00:26:11- هل هدف الشركة إذاً،
00:26:14وأعتقد أن الكثيرين يقلقون عندما يسمعون
00:26:15أن هناك شركة تقف وراء مشاريع مفتوحة المصدر
00:26:17لأنك قد تبدأ في جعل بعض الميزات مدفوعة،
00:26:20ولكن هل الهدف هو كما كان دائماً،
00:26:23بإمكانك دائماً فعل ما يفعله +Vite بنفسك.
00:26:25إنه فقط يتطلب الكثير من الإعدادات
00:26:26و +Vite هو مجرد وسيلة للراحة
00:26:29ويجمعها كلها في أداة واحدة، كما قلت.
00:26:31لذا لن تجعل أي ميزة مدفوعة أبداً.
00:26:34- نعم، لقد طرحنا فكرة
00:26:37حول ترخيص +Vite، أليس كذلك؟
00:26:39قلنا: حسناً، إذا كانت شركتك
00:26:41فوق عتبة معينة، فعليك الدفع مقابل استخدامه.
00:26:44هذا التفكير يتطور باستمرار
00:26:46لأننا نتحدث مع الكثير من الشركات المهتمة
00:26:50ونحاول رؤية التوازن المناسب
00:26:53بين وضعه في أيدي أكبر عدد من الناس
00:26:56وخلق قيمة، وبين السماح لنا بجني بعض القيمة
00:27:00لنتمكن من الاستمرار، صحيح؟
00:27:02أعتقد أننا سنرفع تلك العتبة كثيراً.
00:27:07بحيث تضطر فئة صغيرة جداً فقط من الشركات
00:27:11للدفع مقابله.
00:27:14بينما الغالبية العظمى من المستخدمين سيستمتعون به
00:27:17مجاناً، ولأننا أيضاً،
00:27:20نعمل على بعض الأفكار التي تشبه الخدمات أكثر
00:27:25بدلاً من مجرد الدفع مقابل الميزات، صحيح؟
00:27:27خدمة تقترن بـ +Vite
00:27:31تعمل على تحسين جودة الكود
00:27:35وتراقب جودة الكود الخاص بك
00:27:37وتعطيك أفكاراً أو نصائح تساعدك في تحسين بعض الأشياء.
00:27:39لأن هناك الكثير من المعرفة المتخصصة
00:27:41التي يمكننا الآن جعلها متاحة عبر وكلاء الذكاء الاصطناعي.
00:27:44هذا هو الاتجاه الذي نستكشفه.
00:27:48- حسناً، كنت أتساءل أيضاً،
00:27:51مع قيام +Vite بجعل كل شيء مريحاً،
00:27:53هل تعتقد أن الذكاء الاصطناعي يمكنه فعل ذلك بالحلول الحالية؟
00:27:56أم هل وجدت، من خلال تجربتك،
00:28:00عند الطلب من الذكاء الاصطناعي تجميع أجزاء
00:28:02من أداة الفحص والبناء وكل شيء،
00:28:05هل تعتقد أنه سيعتمد على تقنيات قديمة
00:28:07بسبب بيانات التدريب الخاصة به وسيخلق فوضى؟
00:28:09- نعم، نرى الكثير من التطبيقات المنشأة بالذكاء الاصطناعي
00:28:13لا تزال تستخدم Vite 4 مثلاً، صحيح؟
00:28:17لأن الأمر يتطلب وقتاً عند إصدار نسخة جديدة
00:28:20أو شحن ميزات جديدة، لكي تتدرب النماذج
00:28:26على تلك البيانات، صحيح؟
00:28:29النماذج ستظل دائماً متأخرة عن أحدث الأخبار
00:28:31والتقنيات، وهذا جزء مما نريد فعله،
00:28:34مثلاً إذا أصدرنا نسخة جديدة من +Vite،
00:28:37ستأتي ومعها، أولاً،
00:28:41ملف تعليمات (MD) ومهارات خاصة بالوكلاء.
00:28:44فعندما تقوم بتحديث +Vite، سيقوم هو بالتحديث،
00:28:47وسيرقع الجزء المتعلق به في ملف الوكيل الخاص بك
00:28:50ويربط بالمهارات التي تم تحديثها
00:28:54في حزمة npm الخاصة بك.
00:28:58وهناك أيضاً،
00:29:00يمكننا تزويدك بموجه (prompt) يخبرك:
00:29:05إذا أردت الترقية من هذا الإصدار لهذا الإصدار،
00:29:08فإن هذا الموجه سيساعد وكيلك على القيام بذلك بسلاسة.
00:29:10لذا الكثير من هذا يجب أن يأتي
00:29:13من مؤلفي الأدوات أنفسهم، صحيح؟
00:29:17لأنك لا تستطيع، وأحد الأشياء التي لاحظناها
00:29:19هي أن لدينا OX Link و OX Format و Vtest،
00:29:22وهي مستخدمة في OpenClaw، صحيح؟
00:29:26و OpenClaw عبارة عن قاعدة كود جنونية.
00:29:29فهي تضم 54,000 سطر من JavaScript
00:29:31وتتحرك بوتيرة مجنونة.
00:29:34والمؤلف يدمج التعديلات دون قراءتها حتى.
00:29:36وهناك الكثير من الأشياء
00:29:40التي لا تبدو منطقية هناك.
00:29:43فنحن ننظر لبعض طلبات الدمج (PRs) التي تحدث OX Link
00:29:45أو تبدأ في اعتماده.
00:29:46فنجد خيارات وهمية ليست موجودة أصلاً.
00:29:51فنقول: انتظر، ليس لدينا هذا الخيار،
00:29:54علينا—.
00:29:57وعندما يقوم بفحص الأنواع (type checking)،
00:29:59يقوم ببساطة بتعديل الفحص.
00:30:00كأن يقول: حسناً، سأغلق هذه القاعدة
00:30:04لكي تنجح عملية الفحص.
00:30:06لذا فالذكاء الاصطناعي سيتخذ طرقاً مختصرة
00:30:07إذا لم تضع له حواجز حماية، صحيح؟
00:30:09والأمر الأكثر أهمية هو أن بيتر،
00:30:12مؤلف OpenClaw،
00:30:15ليس مطور TypeScript.
00:30:18لقد اختار TypeScript فقط للعمل بها.
00:30:20لذا فهو ليس خبيراً في الأدوات.
00:30:22وليس لديه خبرة في هذا المجال.
00:30:25الذكاء الاصطناعي ساعده في القيام بذلك.
00:30:26لكننا كمؤلفين للأدوات التي يستخدمها الذكاء الاصطناعي،
00:30:29نلاحظ مواطن القصور.
00:30:30ونقول: حسناً، إذا واصلت فعل هذا
00:30:35دون أن ننبهك لذلك،
00:30:38فسوف ينهار الكود الخاص بك خلال ثلاثة أشهر.
00:30:41نعم، هذا هو نوع القيمة
00:30:44التي نعتقد أننا نستطيع تقديمها في عصر الذكاء الاصطناعي:
00:30:46كيف تتأكد من أنك تشحن الميزات بسرعة
00:30:50دون كسر أي شيء؟
00:30:54وكيف يمكنك مواصلة شحن الميزات بسرعة بالذكاء الاصطناعي؟
00:30:58لأن سرعة شحن الكود
00:30:59تتزايد بشكل هائل بسبب الوكلاء، صحيح؟
00:31:03يمكن للناس شحن ميزات أسرع بكثير مما يستطيعون يدوياً.
00:31:06ولكن هل تتم مراجعة كل هذه الميزات بشكل صحيح؟
00:31:11وعندما تدمج 20 طلب دمج يومياً،
00:31:14هل تظل قاعدة الكود، كما تعلم،
00:31:19تتم صيانتها كما ينبغي؟
00:31:22صحة الكود تصبح متقلبة للغاية.
00:31:25لذا عليك التوقف من وقت لآخر
00:31:26لتفعل ما نفعله في التطوير البشري، صحيح؟
00:31:30تشحن ميزات لفترة،
00:31:33ثم تتوقف لتفكر:
00:31:36حسناً، نحتاج لتنظيف الأمور.
00:31:37نحتاج لتسديد الديون التقنية التي تراكمت.
00:31:38ومع وكلاء الذكاء الاصطناعي، نحن نشحن أسرع بكثير الآن.
00:31:40ونحن أيضاً نراكم الديون التقنية أسرع بكثير، صحيح؟
00:31:42لذا عليك استغلال الذكاء الاصطناعي لتسديد هذا الدين أيضاً.
00:31:45نعم، أعتقد أن هذا هو الجزء
00:31:49الذي يتغاضى عنه الناس
00:31:53وبحاجة لحل في الوقت الحالي.
00:31:56- نعم، لقد ألقيت نظرة على قاعدة كود OpenClaw،
00:31:57وكما قلت، هي فوضوية نوعاً ما.
00:32:00إنها بالتأكيد مثال رائع لما يحدث
00:32:03عندما تطلق العنان للذكاء الاصطناعي
00:32:05وتتركه يفعل ما يريد
00:32:07دون أي نوع من الإشراف.
00:32:09لقد كانت أسابيع ممتعة على الإنترنت
00:32:11بينما يتصدر ذلك المشهد ونرى كل ما كان يفعله.
00:32:13ولكني كنت سأطرح سؤالاً أيضاً حول دور الذكاء الاصطناعي،
00:32:16هل تغير طريقتك في بناء المنسق (formatter)
00:32:19والأداة الفاحصة (linter) لكي يستخدمهما وكلاء الذكاء الاصطناعي بشكل أفضل؟
00:32:22هل يشكل ذلك المستقبل
00:32:26أم تعتقد أن الطريقة التي بنيتم بها المنسقات
00:32:29والأدوات الفاحصة لتكون سريعة ساعدت بطبيعتها في عصر الذكاء الاصطناعي؟
00:32:31أعتقد بوضوح أن كونها سريعة يساعد الوكلاء على استخدامها.
00:32:34- أعتقد أن هذا تفكير جيد حقاً،
00:32:38لأننا بدأنا نفكر في تلك المشكلة
00:32:40لأن النطاق الأصلي لهذه الأدوات
00:32:45ضخم جداً، لأننا نحاول أن نكون متوافقين
00:32:48مع أشياء مثل ESLint و Prettier،
00:32:50والتي كانت قيد الإنتاج لسنوات، لعقد من الزمان،
00:32:53حيث يمتلك الناس كل هذه القواعد المخصصة،
00:32:54وحالات الاستخدام القديمة،
00:32:56ونحن نحاول أن نكون متوافقين معها بنسبة 100%.
00:33:00إنه عمل ضخم جداً
00:33:03أنجزناه أخيراً لأننا حققنا مؤخراً
00:33:06توافقاً تاماً مع إضافات ESLint.
00:33:09اجتزنا جميع اختبارات إضافات ESLint
00:33:13كما حققنا مطابقة تامة بنسبة 100%
00:33:17مع Prettier في المنسق الخاص بنا، صحيح؟
00:33:21لذا فإن هذين الإنجازين يعنيان، حسناً،
00:33:23يمكننا الآن أن نوصي الناس بثقة
00:33:25بالانتقال إلى أدواتنا، وماذا بعد؟
00:33:28هذا هو السؤال الجيد.
00:33:31كيف يجب أن تتكيف الأدوات الفاحصة والمنسقات
00:33:34عندما يستخدمها الوكلاء؟
00:33:38إنه سؤال نعمل عليه بنشاط هنا.
00:33:40نعم.
00:33:44- ننتظر إجابة على هذا السؤال إذاً.
00:33:49الأمر لا يزال يتطور، نعم.
00:33:53الذكاء الاصطناعي يغير الكثير من الأشياء
00:33:54في عالم البرمجة، لذا من المثير مراقبة ذلك.
00:33:57- بالعودة لموضوع +Vite،
00:33:59لقد استعرضته في مؤتمر ViteConf 2025
00:34:01وعرضت ميزة كانت Vite install.
00:34:04سؤالي هو، هل لا تزال هذه الميزة موجودة؟
00:34:06وإلى أي مدى ستتقاطع +Vite
00:34:10مع شيء مثل BUN؟
00:34:14- هذا سؤال جيد.
00:34:17الأمور تغيرت قليلاً منذ ViteConf،
00:34:19أود أن أقول إن النسخة
00:34:21العامة النهائية من +Vite ستشبه
00:34:23شيئاً مثل BUN نوعاً ما، أليس كذلك؟
00:34:27تجربة البدء، كما قلت،
00:34:30إذا كان لديك جهاز جديد،
00:34:33وتريد البدء في بناء تطبيق ويب
00:34:38بأسرع ما يمكن.
00:34:41تقوم فقط بتشغيل أمر curl لجلب النصوص البرمجية
00:34:43وتحصل على ملف تنفيذي عام يسمى vp وتستخدمه،
00:34:45عندما تكون داخل مشروع ما.
00:34:46إذا كان لديك ملف node-version.
00:34:51وحقل مدير الحزم في ملف package.json،
00:34:56وهي الأشياء الشائعة التي نستخدمها لتحديد بيئة JS التي تعمل فيها.
00:35:02فعندما تقول vp run build،
00:35:04سيستخدم تلقائياً،
00:35:06حتى لو لم تكن تستخدم +Vite في ذلك المشروع،
00:35:11طالما أنك تستخدم
00:35:15مصادر البيئة التقليدية هذه،
00:35:20يمكنك استخدام +Vite كبديل لـ NVM.
00:35:22ويمكنك استخدامه كبديل لـ core pack.
00:35:26ببساطة ستتوقف عن التفكير في الإصدارات.
00:35:28الفكرة هي أنه عندما تقوم بتشغيل سير عملك،
00:35:31ستفعل ذلك من خلاله، وستتوقف أيضاً عن استخدام npm run.
00:35:36ستستخدم vp run.
00:35:40الفكرة هنا هي أنه عندما تستخدم vp run،
00:35:44سيستخدم نسخة node الصحيحة،
00:35:45ونسخة مدير الحزم الصحيحة.
00:35:48ويقوم بالأشياء المطلوبة.
00:35:52أمر install يعني أنه سيقوم فقط بـ،
00:35:55نحن ليس لدينا مدير حزم خاص بنا في البداية، صحيح؟
00:35:59الأمر أشبه ببديل لـ core pack
00:36:02لا أعرف إن كنت قد استخدمت حزمة تسمى NI،
00:36:05وهي من ابتكار أنتوني فو.
00:36:06NI تعني ببساطة أنه عندما تشغل NI،
00:36:10سيستنتج تلقائياً مدير الحزم الصحيح لاستخدامه،
00:36:14سواء كنت تقوم بالتشغيل أو التثبيت أو الحذف،
00:36:16أياً كان.
00:36:19أمر Vite install هو ذلك تماماً،
00:36:24بالإضافة إلى جزء إدارة الحزم.
00:36:27هذا ما تفعله core pack، صحيح؟
00:36:30حتى لو لم يكن لديك أي شيء آخر مثبتاً،
00:36:34تدخل لمشروع وملف package.json
00:36:36يحتوي على pnpm كمدير حزم
00:36:41بإصدار معين.
00:36:45تشغل Vite install، سيتحقق تلقائياً
00:36:48إذا كان ذلك الإصدار من pnpm مثبتاً.
00:36:49وإذا لم يكن كذلك، سيقوم بتثبيته
00:36:51ويشغل عملية التثبيت باستخدام pnpm install.
00:36:56نعم، الفكرة هي أننا نريد
00:36:58حل مشاكل تتجاوز مجرد الفحص والتنسيق.
00:37:01إنها تتعلق بكل المهام الشائعة التي تحتاجها
00:37:03في سير عمل JavaScript الخاص بك.
00:37:07نريد القضاء على هذه المشاكل الشائعة لكي
00:37:08لا يضطر المبتدئ للتفكير فيها أصلاً.
00:37:12في أول مرة تقوم فيها بإنشاء مشروع،
00:37:14سنستخدم أحدث نسخة مستقرة (LTS) من node ونوصي بـ pnpm.
00:37:16وسنقوم أيضاً بكتابة تلك المعلومات في مشروعك.
00:37:20بحيث في المرة القادمة التي تعود فيها لهذا المشروع،
00:37:25سيستخدم دائماً المزيج الصحيح من الأدوات.
00:37:31- لماذا توصي بـ pnpm، فضولاً فقط؟
00:37:34- لأنه ببساطة يمتلك التوازن الصحيح بين مجموعة الميزات
00:37:36والدقة وكفاءة استهلاك القرص والسرعة
00:37:40ودعم جيد لمساحات العمل (workspaces)، مثل الفهارس،
00:37:43كما تعلم، عندما
00:37:45قارنا بين جميع ميزات مساحات العمل،
00:37:50وجدنا أن pnpm لا يزال يقدم أفضل توازن.
00:37:53ونحن نعلم أن BUN سريع بشكل مذهل،
00:37:55لكن pnpm سريع بما يكفي للكثيرين منا.
00:37:59وأيضاً، نحن لا نستبعد حقاً إمكانية
00:38:02دعم BUN في وقت التشغيل لدينا
00:38:06وإدارة إصدارات مدير الحزم، صحيح؟
00:38:10لذا يمكنك القول: أريد استخدام BUN
00:38:15وسنقوم بتشغيل الأشياء باستخدام BUN.
00:38:19- بخصوص Vite 6، أعتقد أنك قلت أنه من المفترض صدوره
00:38:21بعد السنة القمرية الجديدة، صحيح؟
00:38:25- نعم.
00:38:29- ما هي بعض الأشياء في النسخة التجريبية (beta)
00:38:33التي تركز عليها قبل إطلاقه رسمياً؟
00:38:35- الأمر يتعلق كلياً بالاستقرار.
00:38:37لذا، نظام الدمج المستمر (CI) للنظام البيئي،
00:38:40لدينا نظام CI ضخم جداً للنظام البيئي
00:38:42حيث نشغل Vite 6 في المشاريع التابعة التي تعتمد عليه.
00:38:44أحد الأشياء التي فعلناها مؤخراً هو أننا،
00:38:49كل اختبارات SvelteKit تمر الآن بنجاح على Vite 6.
00:38:52وهذا إنجاز كبير لنا
00:38:54لأن الاستقرار هو حقاً أهم شيء
00:38:58لأنك إذا فكرت في الأمر،
00:39:00فنحن نستبدل مجمعين
00:39:04بمجمع جديد بنيناه من الصفر.
00:39:06كأننا نستبدل محركات طائرة وهي تحلق
00:39:10ونأمل أن تواصل الطيران بسلاسة بعد ذلك.
00:39:15لذا علينا أن نكون في غاية الحذر.
00:39:17- كنت سأطرح سؤالاً سابقاً في الواقع، اختيار لغة Rust،
00:39:21هل كان ذلك لمجرد أن أعضاء فريقك
00:39:24لديهم معرفة بـ Rust؟
00:39:27لأنني أرى الكثيرين في عالم TypeScript
00:39:28يفضلون Go لأنني أعتقد أنها أقرب للانتقال إليها
00:39:30ولهذا السبب فريق TypeScript يتجه لـ Go
00:39:33من أجل ذلك المترجم.
00:39:36- نعم، أعتقد أن اختيار فريق TypeScript
00:39:40للانتقال لـ Go هو، كما قلت،
00:39:43لأن Go لغة أسهل بكثير لنقل TypeScript إليها، صحيح؟
00:39:46لأن النموذج الذهني متشابه جداً.
00:39:48أعتقد أن أحد الأسباب الكبيرة التي كانت عائقاً لنا
00:39:49هو أن Go لديها دعم دون المستوى لـ WebAssembly.
00:39:51فهي تنتج ملفات WebAssembly ضخمة
00:39:55وأداؤها في WebAssembly
00:39:57ليس رائعاً مقارنة بـ Rust.
00:39:58ومع Rust، الأمر هو،
00:40:02نعم، الكثير منه يتعلق بالمواهب المتاحة،
00:40:04أشخاص شغوفون بالفعل
00:40:09ومستثمرون في هذا النظام البيئي.
00:40:13على سبيل المثال، عندما بحثنا حولنا
00:40:17عن أسس نبني عليها،
00:40:21لم نجد مجموعة من المحللات أو سلاسل الأدوات
00:40:26منفذة بشكل جيد وقابلة للتركيب مثلها.
00:40:29وأساساً OXC بنيت ليتم البناء فوقها، صحيح؟
00:40:32فهي هذه الأدوات المساعدة منخفضة المستوى.
00:40:35لم نجد ما يعادل ذلك في عالم Go.
00:40:39esbuild لديه محلله الخاص وكل شيء،
00:40:41لكنه نظام واحد ضخم.
00:40:44لا يمكنك ببساطة استخراج المحلل الخاص به واستخدامه.
00:40:46ولكن أيضاً جميع الميزات في esbuild،
00:40:48مثل التحويلات والترميز.
00:40:54للحصول على أفضل أداء،
00:40:59يتم تنفيذها في ثلاث مراحل AST،
00:41:04مما يعني أنه في نفس المرحلة،
00:41:08قد تكون لديك اهتمامات مختلطة من،
00:41:11إجراء بعض التحويلات هنا،
00:41:14وإجراء بعض ميزات الحقن هنا،
00:41:18وهذا يجعله غير مثالي لنظام قابل للتوسع
00:41:23حيث نريد مثلاً
00:41:25القدرة على شحن المزيد من التحويلات
00:41:30والسماح للناس بتبديلها.
00:41:33نريد السماح للناس بكتابة تحويلاتهم الخاصة.
00:41:36نريد نظام فحص (linter) يمكننا،
00:41:37نريده أن يكون ذا طبقات واضحة
00:41:39حتى نتمكن من جعل المزيد من الأشخاص يعملون عليه في نفس الوقت.
00:41:41لذا فالأمر يتعلق كثيراً بما هو متاح لدينا.
00:41:42Rust أيضاً ذات أداء عالٍ جداً.
00:41:45من الصعب بعض الشيء كتابة تحويلات جيدة بـ Rust.
00:41:51اضطررنا لقضاء وقت طويل
00:41:54في اكتشاف بنية جيدة
00:41:57لمسار الزوار (visitors) والمحولات،
00:42:01بسبب مشكلة ملكية الذاكرة،
00:42:03مثل عندما تتنقل بعمق في الشجرة
00:42:07وتحتاج لتغيير الشجرة الأب،
00:42:09يصبح الأمر معقداً جداً، صحيح؟
00:42:13لكننا وجدنا حلاً.
00:42:16الأمر أسهل بكثير في Go، ولكن عندما فكرنا في الأمر،
00:42:22أردنا أن تكون أدواتنا قابلة للتجميع
00:42:26لـ WebAssembly والعمل في المتصفح.
00:42:28لذا، Rolldown قادر على العمل في المتصفح
00:42:31وبسرعة جيدة جداً.
00:42:34أعني أن esbuild قادر على العمل في المتصفح،
00:42:37ولكن WebAssembly الخاص بـ Rust أفضل ببساطة.
00:42:39- السؤال الآخر الذي كنت سأطرحه
00:42:42بناءً على موضوع الفريق الذي يبني بـ Rust وكذا،
00:42:44كيف تستخدم أنت وفريقك الذكاء الاصطناعي؟
00:42:45ذكرت سابقاً أن الكثير من الناس
00:42:49في الفريق يستخدمون الذكاء الاصطناعي.
00:42:51هل تجد أن الذكاء الاصطناعي جيد في العمل الذي تقومون به؟
00:42:53لأنني أشعر أن تطوير الويب وبناء المواقع،
00:42:57هناك الكثير من الأمثلة عليها في GitHub.
00:42:59لذا فالذكاء الاصطناعي مدرب عليها جيداً.
00:43:01لكنني أشعر أن ما تفعلونه هو نوع من العمل منخفض المستوى
00:43:05أو بمستوى عالٍ من التقنية على الأقل.
00:43:07فهل الذكاء الاصطناعي مفيد هناك أم أنكم لا تزالون
00:43:09تعتمدون على البرمجة اليدوية المكثفة؟
00:43:12- إنه مفيد بالتأكيد.
00:43:14الأمر هو أن المجال يتغير بسرعة كبيرة.
00:43:16أعتقد أنه في مثل هذا الوقت من العام الماضي، كنت متشككاً.
00:43:19قلت لنفسي: لقد جربته، وهو لا يعمل معي
00:43:21لأن العمل الذي أقوم به منخفض المستوى جداً، صحيح.
00:43:23ثم، بوشين وهو قائد OXC،
00:43:25هو على الأرجح الشخص الأكثر تعمقاً في الذكاء الاصطناعي
00:43:28في الشركة حالياً.
00:43:30لقد بدأ في إجراء تجارب جنونية.
00:43:32وفي الشهر الماضي، كان هناك أسبوع
00:43:34شحن فيه حوالي 60 طلب دمج (PR) بالذكاء الاصطناعي
00:43:38عبر تشغيل الوكلاء بالتوازي.
00:43:41ثم بدأنا في إجراء تجارب جنونية
00:43:45مثل نقل مترجم Angular إلى Rust لنرى،
00:43:49ألقيناه للذكاء الاصطناعي لنرى إن كان سينجح.
00:43:52وبطريقة ما، الأمر ينجح.
00:43:59لذا ربما سيكون لدينا شيء في هذا الاتجاه مستقبلاً.
00:44:03نعم، فنحن دائماً ما نحدث
00:44:04تصورنا لمدى قدرات الذكاء الاصطناعي
00:44:07وهي تتجدد كل بضعة أشهر
00:44:11مع صدور نماذج جديدة،
00:44:13ومع تنفيذ أدوات تحكم أفضل
00:44:16وممارسات جديدة مثل استخدام وضع التخطيط (plan mode)
00:44:19وكتابة ملفات تعليمات الوكلاء.
00:44:24باستخدام هذه النصائح والحيل.
00:44:27فعندما تطبق هذه الأشياء الصغيرة، تدرك، حسناً،
00:44:29الأمور تتحسن فعلاً باستمرار.
00:44:33ومع ذلك لا يزال الاعتماد والاستخدام يختلف من شخص لآخر، صحيح؟
00:44:39نحن لا نجبر أحداً، بل نشجع الجميع في الشركة
00:44:43على استخدامه بالقدر الذي يرونه مناسباً.
00:44:46نمنحهم رصيداً شهرياً
00:44:48ليتمكنوا من استخدام أحدث النماذج إذا أرادوا.
00:44:51أعتقد أن بعضهم سعيد جداً بذلك
00:44:55بل ويتحدثون عن ذلك صراحة.
00:45:00وبالطبع هم يقدمون طلبات دمج جيدة جداً، صحيح؟
00:45:03أعتقد أن الأمر يعتمد حقاً على مدى براعتك في استخدامه.
00:45:06جزء منه هو القدرة الخام للنموذج.
00:45:08وجزء منه هو الأدوات التي تستخدمها،
00:45:13ولكنني أرى أن طبقة الأدوات
00:45:18تشبه إطارات عمل JavaScript في الماضي.
00:45:22الجميع يقوم بنسخته الخاصة منها.
00:45:24وهم يفعلون الشيء نفسه تقريباً.
00:45:27ربما تمتلك هذه الأداة بعض الحيل المختلفة،
00:45:33لكن بعد بضعة أشهر، الجميع سيفعل الشيء نفسه.
00:45:36سيكون هذا المجال تنافسياً جداً، والنماذج كذلك.
00:45:40كل بضعة أشهر،
00:45:45تسمع أن Sonnet 3.5 على وشك الصدور.
00:45:49أو أن DeepSeek ستصدر نموذجاً جديداً.
00:45:52الأمر سيتحسن أكثر فأكثر.
00:45:54وأعتقد أنه من الواضح أن الذكاء الاصطناعي قادر للغاية
00:45:57مع التوجيه الصحيح،
00:46:00ولكن جزء التوجيه لا يزال بالغ الأهمية.
00:46:03لا يمكنك توقع أن يتمكن شخص ليس لديه معرفة بـ Rust
00:46:08من العمل في قاعدة كود OXC، حتى مع الذكاء الاصطناعي.
00:46:11لن يعرف حتى كيف يكتب الموجهات الصحيحة.
00:46:13لكن شخصاً متمكناً بالفعل في OXC
00:46:17كمهندس Rust سيصبح مع الذكاء الاصطناعي
00:46:18أكثر إنتاجية بمراحل
00:46:21ويمكنه شحن ميزات أكثر وبسرعة أكبر.
00:46:23هذا هو رأيي العام في الموضوع.
00:46:26أما أنا، فربما أكون الشخص الذي
00:46:32ينتج أقل كمية من الكود باستخدام الذكاء الاصطناعي،
00:46:34بشكل ضئيل جداً مقارنة ببقية المهندسين.
00:46:37أستخدمه أكثر للبحث وكوسيلة لمناقشة الأفكار.
00:46:41- هذا عالم غريب حقاً،
00:46:45الذي تتجه إليه البرمجة،
00:46:50وأجد من الصعب مواكبة تعلم
00:46:54عدد الوكلاء الفرعيين الذين يجب استخدامهم،
00:46:58والوكلاء المتوازيين، وما هو ملف الـ markdown الذي يجب وضعه
00:47:00في مستودع الكود الآن.
00:47:03نعم، الأمور تتغير طوال الوقت.
00:47:08من المثير أن نرى أين سنستقر
00:47:13في المستقبل.
00:47:16- لنعد إلى Vite قليلاً.
00:47:20في Vite 6، أصدرتم دعماً لمكونات خادم React.
00:47:25وفي رأيي، مكونات خادم React
00:47:27لم تحقق النجاح الساحق الذي توقعه الفريق.
00:47:29أعني أن هناك بعض الأطر التي لم تتقبلها،
00:47:32مثل TanStack.
00:47:34وأعتقد أن Remix قد سلكت اتجاهاً مختلفاً تماماً.
00:47:37فما رأيك في مكونات خادم React
00:47:38ولماذا تعتقد أنها لم تنجح كما كان متوقعاً؟
00:47:40- نعم، لقد كنت دائماً متحفظاً جداً بشأنها
00:47:43أو كنت متشككاً منذ اليوم الأول.
00:47:43لهذا السبب لم نفكر أبداً في تنفيذ
00:47:47شيء مشابه في Vue.
00:47:52أعتقد أن الفكرة الأساسية هنا هي: ما هي المشكلة
00:47:54التي تحاول حلها بالضبط؟
00:47:57وأعتقد أن الطريقة التي تم الترويج لها بها،
00:48:00في محاولة لإثارة حماس الناس،
00:48:01تم تصويرها كحل سحري.
00:48:04سيجعل كل شيء أفضل على الإطلاق.
00:48:07وسيجعل كل مواقع الويب أسرع.
00:48:10واتضح عند إطلاقها أن الناس أدركوا،
00:48:14ربما لا ينبغي عليّ استخدامها في جميع الحالات.
00:48:17إنها تنطبق فقط على أنواع معينة من الحالات
00:48:20التي ستفيدك فيها.
00:48:23وفي حالات أخرى، هي مجرد مجموعة من التنازلات.
00:48:28لأن الأجزاء التي تعيش على الخادم،
00:48:30أصبحت كل التفاعلات الآن تضطر للذهاب
00:48:35في رحلة ذهاب وإياب عبر الشبكة.
00:48:38وهذا في رأيي أمر سيء جداً
00:48:40لتجربة الاستخدام دون اتصال بالإنترنت.
00:48:42ولا يمكنك حقاً الهروب من تكاليف عملية الإنعاش (hydration)،
00:48:44في رأيي.
00:48:48أنت تقوم بنقل الكثير من تكاليف الإنعاش في جانب العميل،
00:48:51وتحملها للخادم، صحيح؟
00:48:54الآن أنت تتحمل تكلفة كل طلب
00:48:56بإجراء المزيد من العمل على الخادم.
00:48:59لذا ظهرت نظريات مؤامرة لدى البعض،
00:49:04بأن Vercel تروج لها لزيادة مبيعات قدرات الحوسبة لديها.
00:49:06لا أعتقد حقاً أن هذا هو السبب،
00:49:08ولكن من الصحيح أيضاً أن استخدام RSC
00:49:10يعني زيادة العبء على الخادم.
00:49:14أنت تشغل المزيد من الأشياء على الخادم،
00:49:20وتستخدم المزيد من دقائق الحوسبة.
00:49:21وفي النهاية هناك فوائد أخرى مثل،
00:49:26إذا وضعت جزءاً من تطبيقك على الخادم،
00:49:29ستقلل حجم الحزمة (bundle).
00:49:31ولكن هناك طرقاً مختلفة كثيرة لحل تلك المشكلة،
00:49:33لا تتطلب بالضرورة
00:49:38تشغيل خادم Node.js، صحيح؟
00:49:44والكثير من هذا هو رأيي الشخصي،
00:49:47في الواجهة الأمامية، نميل للقول إن
00:49:51البنية المعمارية هي ما يهم حقاً.
00:49:52هل تريد استخدام SPA؟
00:49:54هل تحتاج للعرض من جانب الخادم (SSR)؟
00:49:56RSC هي حالة أكثر تخصصاً.
00:49:59سؤال “هل تحتاج لـ RSC” هو سؤال مهم جداً
00:50:01وصعب الإجابة عليه.
00:50:02وعندما تقول نعم،
00:50:06عليك أيضاً أن تكون مدركاً للثمن الذي تدفعه
00:50:07لأنني أعتقد أن أحد الأسباب
00:50:10التي جعلت اعتمادها ضعيفاً هو أنها أولاً،
00:50:14معقدة للغاية.
00:50:17الشيء نفسه يصعب شرحه.
00:50:19وكيفية عملها يصعب شرحها.
00:50:21اضطررنا للتعمق كثيراً
00:50:24لأنها تتطلب تنسيقاً على مستوى أداة البناء
00:50:27لجعل النظام بأكمله يعمل، صحيح؟
00:50:31وبالتالي، قلة قليلة من الناس يفهمون
00:50:33كيفية عمل RSC الخام.
00:50:35معظم الناس يعرفونها من خلال تنفيذها
00:50:37في Next.js لأن RSC الخام شيء لا يستطيع المستخدم العادي
00:50:39إعداده بنفسه، صحيح؟
00:50:43عليك حقاً فهم كيف يتناسب كل شيء معاً
00:50:46لتتمكن من بناء شيء من الصفر
00:50:48باستخدام React و Vite أو Webpack.
00:50:50هذا ليس للتطوير اليومي، صحيح؟
00:50:52لذا ستحتاج لاستخدام إطار عمل.
00:50:56وهذا هو الغرض من بنائه.
00:50:58ولكن لاستخدام RSC في إطار عمل،
00:51:02على إطار العمل اتخاذ قرارات تصميمية
00:51:04حول كيفية تقديم RSC
00:51:07بطريقة توفر تجربة مطور جيدة.
00:51:11وأعتقد أن Next.js لم ينجح تماماً في ذلك، في رأيي.
00:51:14مثل الارتباك بين use server و use client،
00:51:17والمخطط المختلط حيث عندما تجعل شيئاً ما use server
00:51:20وشيئاً آخر، تتوقف هذه الأشياء عن العمل.
00:51:23وتصبح محدوداً باستخدام هذه الأشياء فقط
00:51:27ثم تضطر لاستيراد تبعية
00:51:29والتبعية لا تعمل مع use server.
00:51:30فتضطر لاستخدام use client مجدداً.
00:51:33هذا النوع من الذهاب والإياب،
00:51:36أعتقد أنها مجرد مجموعة من هذه المضايقات الصغيرة
00:51:39في تجربة المطور تجعل الناس يفكرون:
00:51:42للحصول على تلك الفوائد المزعومة،
00:51:47عليّ الآن تحمل هذا الإزعاج في تجربة التطوير
00:51:51طوال الوقت، وإلى الأبد في المستقبل.
00:51:55هل الأمر يستحق ذلك حقاً؟
00:51:58لذا أجد أنه من الطبيعي أن يتساءل الناس:
00:52:01هل أريد استخدامه حقاً؟
00:52:03وحتى بالنسبة لمؤلفي أطر العمل،
00:52:06Vercel لديها علاقة وثيقة جداً مع فريق React
00:52:08ليتمكنوا من التعاون والتطوير بسرعة.
00:52:10ولكن بالنسبة للطرف الثالث، لن أقول حتى طرف ثالث
00:52:12لأن Vercel تقنياً طرف ثالث، صحيح؟
00:52:15لكن بالنسبة لأطر العمل الأخرى مثل Remix و TanStack،
00:52:20ليس من السهل عليهم العمل
00:52:24على هذه المشكلة لأن الكثير من تطويرات الواجهة البرمجية
00:52:27من فريق React تعطي الأولوية لـ Next.js.
00:52:28أنا لا أنتقدهم على ذلك
00:52:35لأن Vercel هي شريكهم في التصميم.
00:52:37هم يريدون الشراكة مع Vercel
00:52:40لصقل هذه الميزة وشحنها،
00:52:42وهذا منطقي، صحيح؟
00:52:45ولكن بسبب ذلك،
00:52:49كانت Next.js هي الطريقة الحقيقية الوحيدة
00:52:52للناس لاستخدام RSC.
00:52:57وتلك التجربة لم تكن رائعة جداً.
00:53:02لهذا السبب لم تسر الأمور كما كان ممكناً.
00:53:06وأيضاً، أعتقد أن الفرضية العامة
00:53:08حتى في عالم مثالي تتمتع فيه RSC بتجربة مطور مثالية،
00:53:13لا أظن أنها ستكون حلاً سحرياً
00:53:15في كل الحالات، صحيح؟
00:53:17عليك أن تكون ملماً تماماً
00:53:19بأين يكون استخدامها منطقياً وأين لا يكون.
00:53:21هناك الكثير من التنازلات.
00:53:25- أفترض أنه لم تكن هناك أي ضغوط
00:53:29لتنفيذ شيء مشابه في Vue
00:53:31لأنه من الواضح أن هناك صلة بـ Vercel.
00:53:33لقد استحوذوا على Nuxt Labs،
00:53:38وهي إطار العمل فوق Vue
00:53:41الذي يجمع كل شيء معاً.
00:53:46كيف كانت العلاقة بين Nuxt و Vue
00:53:49الآن بعد أن امتلكتهم Vercel؟
00:53:50- بصراحة، لم يتغير الكثير.
00:53:52أعتقد أن Vercel كانت بعيدة عن التدخل المباشر منذ الاستحواذ
00:53:54وفريق Nuxt سعيد بتمكنه
00:53:57من مواصلة فعل ما يفعلونه.
00:53:59ربما هناك بعض الجهود لجعل
00:54:01Nuxt يعمل بشكل أفضل على Vercel،
00:54:03وجعله مواطناً من الدرجة الأولى هناك.
00:54:05لكنني أعتقد أن Vercel تدرك
00:54:08الصورة الذهنية عنها في المجتمع
00:54:09وسيكونون حذرين جداً من ألا يسيئوا إليها أكثر.
00:54:13لذا بعد الاستحواذ على Nuxt،
00:54:14آخر شيء قد يرغبون في فعله
00:54:18هو إجبار Nuxt على فعل أشياء لا يحبها الناس.
00:54:21- لسوء الحظ، اضطر إيفان للمغادرة مبكراً
00:54:24لتلقي مكالمة هامة،
00:54:25لكننا نقدر حقاً وقته
00:54:30وكل آرائه الثرية حول كل الأسئلة التي طرحناها.
00:54:32إذا كان لديكم أي ضيوف تودون رؤيتهم في البودكاست مستقبلاً،
00:54:34يرجى إخبارنا في التعليقات.
00:54:38وإذا كان لديكم أي ملاحظات عامة،
00:54:43أخبرونا بها أيضاً.
00:54:47نود سماع آرائكم.
00:54:50يمكنكم العثور علينا في أي منصة تستمعون فيها للبودكاست
00:54:52مثل Spotify أو Apple Podcasts.
00:54:54وحتى المرة القادمة، وداعاً مني.
00:54:56- وداعاً مني.
00:54:58- وداعاً مني.
00:55:00- لقد كان من دواعي سروري، شكراً لكم جميعاً.
00:55:04- شكراً جزيلاً لانضمامك إلينا.
00:55:06please let us know in the comments.
00:55:08And if you have any feedback in general,
00:55:10also let us know too.
00:55:11We'd love to hear it.
00:55:12Find us on anywhere you listen to podcasts
00:55:15like Spotify or Apple Podcasts.
00:55:17And until next time, it's a bye from me.
00:55:20- Bye from me.
00:55:21- Bye from me.
00:55:21- It's a pleasure, thank you all.
00:55:23- Thank you very much for joining us.