Lovable تعيد كتابة Vite בלغة Rust... (نوعاً ما)
BBetter Stack
Computing/SoftwareSmall Business/StartupsInternet Technology
Transcript
00:00:00يمكنكم إضافة إنجاز جديد إلى قائمة إعادة الكتابة بلغة Rust، وهذه المرة جاء الدور على خادم تطوير Vite
00:00:03الذي أعاد فريق Lovable الرائع كتابته بلغة Rust، ويُزعم أنه يحقق تحسينًا في استهلاك الذاكرة
00:00:07بمقدار أربعة أضعاف وسرعة أكبر بمرتين في التشغيل الأولي. دعونا نتحرى صحة هذا الادعاء إذ قد يكون
00:00:12مضللاً القليل، ثم نرى ما إذا كان هذا شيئًا ينبغي أن تنتقلوا إليه مستقبلاً،
00:00:15بالإضافة إلى رأي مبتكر Vite حول ما يعنيه هذا لمستقبل البرمجيات مفتوحة المصدر.
00:00:24المشروع الذي أتحدث عنه يُدعى OJ، اختصارًا لـ Orange Juice، والفكرة منه أنه ملف تنفيذي واحد
00:00:29بلغة Rust يمكنني توجيهه إلى مشروع Vite الحالي ليشغّله فورًا. فهو يقرأ إعدادات Vite
00:00:33ويظل يشغّل إضافات Vite الحالية، لكن خادم التطوير الداخلي—أي مراقب الملفات،
00:00:38ومخطط الوحدات، وإعادة التحميل السريع للمكونات، وميزة React Fast Refresh—قد أُعيدت كتابتها بالكامل بلغة Rust.
00:00:44ومن المثير للاهتمام أن هذا تم باستخدام Rolldown وOxc اللذين يستخدمهما Vite نفسه وتصونهما VoidZero.
00:00:49وتقوم void zero بصيانتهما. ولأختبر ذلك بنفسي، قمت ببناء تطبيق TanStack لمعرفة ما إذا كانت هناك أي فروق
00:00:53بين تشغيله باستخدام Vite dev أو OJ dev. ظاهرياً، يبدو أنهما يعملان بشكل متطابق تقريباً،
00:00:58وكل شيء يعمل، مثل العرض على جانب الخادم، وتنشيط الصفحة (Hydration)، ودوال الخادم، والتحديث السريع،
00:01:03والمسارات الديناميكية للملفات، ومسارات الخادم، وTailwind، واستيراد الأصول، ولكن عند التعمق أكثر،
00:01:07لاحظت بعض الاختلافات الطفيفة. الأول كان في التحديث السريع هنا. إذا قمت بتعديل ملف،
00:01:13يحافظ العداد في Vite على حالته، لكن تحت OJ، يعاد ضبط العداد إلى الصفر،
00:01:17مما يشير إلى أن OJ يقوم بإعادة تحميل كاملة بدلاً من تحديث المكون الذي تغير فقط. وقررت في الواقع
00:01:22تجربة واختبار السلوك نفسه في تطبيق React عادي لم يكن يعتمد على TanStack Start،
00:01:26والغريب أنه يبدو أنه يعتمد ويعمل هنا بشكل جيد. نفس التعديل هنا يبقي القيمة كما هي،
00:01:30ولا يقوم بتحديث الصفحة بأكملها، لذلك يبدو أنه يقوم بتحديث سريع حقيقي. لذا لا أعرف لماذا
00:01:35يوجد فرق هناك بين TanStack Start وتطبيق React عادي، ربما تكون إحدى تلك
00:01:39الحالات الاستثنائية التي لم يفكروا بها بعد. الاختلاف الثاني الذي لاحظته كان في
00:01:42دالة الخادم. تقيس دالة الخادم هذه ذاكرة شجرة العمليات بالكامل لخادم التطوير من
00:01:46داخل التطبيق، وفي هذا التطبيق تحت Vite، تبلغ حوالي 380 ميجابايت عبر عمليتين، وتحت OJ،
00:01:53تبلغ حوالي 320 ميجابايت عبر عمليتين أيضاً. لذا في تطبيق صغير مثل هذا، يبدو أن استهلاك
00:01:59الذاكرة متماثل تقريباً، حيث يتقدم OJ بفارق ضئيل جداً. هل يعني هذا أن هذا المشروع
00:02:04عديم الفائدة تماماً؟ بالطبع لا، لأن هذا ليس الغرض الحقيقي الذي بُني من أجله OJ. في الواقع، يعمل OJ
00:02:09بشكل أفضل في التطبيقات الكبيرة جداً. عندما اختبرت هذا على تطبيق React يحتوي على 5000 مكون، باستخدام برنامج نصي
00:02:14ينشئ كود كل خادم تطوير، ويفتح الصفحة في متصفح Chrome حقيقي، ويوقف المؤقت عندما
00:02:19يظهر أعمق مكون في الـ DOM، ثم يأخذ عينة من ذاكرة شجرة العمليات بأكملها، فإن الوضع العادي لـ OJ
00:02:24أسرع بنحو 1.7 مرة في عرض الصفحة مقارنة بـ Vite الافتراضي، ويستهلك حوالي ربع
00:02:29الذاكرة فقط. ولنكون منصفين لـ Vite، فإن الإصدار Vite 8.1 قدم ميزة تجريبية تسمى وضع التطوير المجمع (bundled dev mode)،
00:02:34وإذا قمت بتفعيلها، يصل Vite في الواقع إلى 1.18 ثانية، أي أسرع قليلاً من الوضع العادي
00:02:40لـ OJ، لكنه لا يوفر لك في الذاكرة. ويوفر OJ وضع التجميع أيضاً، والذي عند استخدامه
00:02:45يجعله أسرع مجدداً، بنحو 0.89 ثانية، ويحافظ على الذاكرة عند حوالي ربع استهلاك Vite.
00:02:51لذا يبدو أن لـ OJ فوائد حقيقية في إدارة الذاكرة، وهذا هو السبب الرئيسي وراء قيام فريق Lovable
00:02:55بإنشاء هذا المشروع. معاينات Lovable تشغل خادم تطوير Vite حقيقي، وتذكر Lovable أنها تشغل نحو
00:03:00مليون من بيئات الاختبار تلك يومياً، وعلى نطاق واسع كهذا، يصبح استهلاك الموارد
00:03:04أمراً مهماً للغاية. لذلك قامت Lovable بإنشاء OJ للحصول على معاينات تبدأ فوراً وتظل خفيفة،
00:03:09دون الحاجة إلى التخلي عن النظام البيئي الذي يجعل التطبيق يعمل في المقام الأول.
00:03:13كما اتخذوا قراراً تصميمياً رائعاً جداً حول حالة الاستخدام تلك، أي وكلاء الذكاء الاصطناعي (agents). عند التعديل،
00:03:17عادةً ما يحفظ الشخص ملفاً واحداً في كل مرة، لكن الوكيل يمكنه كتابة 10 ملفات أو نحو ذلك في دفعة واحدة،
00:03:22وكان Vite سيعامل كل عملية حفظ من هذه على أنها تحديث منفصل، لكن في OJ، فإن المراقب،
00:03:26ومخطط الوحدات، والمترجم، والتحديثات السريعة تعمل كأنبوب معالجة واحد، فتدمج الدفعة في تحديث واحد.
00:03:32هناك أيضاً بوابات يمكنك تفعيلها حيث يتم تعليق التحديثات حتى يقوم الوكيل نفسه
00:03:35بإرسال طلب لنقطة نهاية التفريغ (flush endpoint)، بحيث تطبق المعاينة التغيير المكتمل فقط. كما ترون، هذا
00:03:40مشروع مخصص جداً لحل حالات الاستخدام الخاصة بـ Lovable، وهذا ما أقر به أيضاً Evan You،
00:03:45منشئ Vite. نقطته الأولى في هذه التغريدة هي أنه مشروع مثير للإعجاب حقاً ويحل
00:03:49مشكلة Lovable بشكل جيد، ولكنه ليس إعادة كتابة كاملة لـ Vite. إنه مجرد خادم التطوير،
00:03:54كما أنه مبني على Rolldown و Oxc، اللذين تصونهما void0، لذا فهو لا يحل محلهما.
00:04:00المحلل، والمحول، ومجمع الإنتاج في OJ جميعها من void0،
00:04:04وقام فريق Lovable فقط بكتابة الخادم حولها. يمكنك التفكير في الأمر أساساً كأن Vite عبارة عن عملية
00:04:08Node تقود Rust، بينما OJ هو عملية Rust تقود Rust، مع وجود طبقة في المنتصف
00:04:13من JavaScript حتى تتمكن من التواصل مع واجهة برمجة الإضافات لـ Vite. ثم يواصل Evan الإشارة إلى
00:04:17أن OJ سريع لأنه يدعم شكلاً واحداً فقط من التطبيقات. في الواقع، يعمل OJ فقط مع
00:04:22تطبيقات React، أي تلك التي تقوم Lovable بإنشائها. أما Vite، من ناحية أخرى، فيجب عليه
00:04:27دعم كل إطار عمل، وكل إعداد غريب، وكل أداة بنيت حوله، وهو يترك عمداً
00:04:31أشياء مثل ESBuild أو إضافة React كحزم منفصلة، لتتمكن من إضافتها بنفسك إذا كنت
00:04:36بحاجة إليها. بعد ذلك، يوضح أيضاً العيوب في اختبار الأداء. فميزة Vite Coldstart في المدونة
00:04:40تتضمن Vite plugin checker، الذي يشغل TypeScript في عملية خلفية، لكن OJ لا يدعم
00:04:45تلك الإضافة في الواقع، لذا فهو يتخطى هذا العمل تماماً. كما يشير إلى أنه في Vite، مع وضع التطوير
00:04:50المجمع، تصبح السرعة أقرب إلى التشغيل البارد لـ OJ، وهو تماماً ما رأيناه في أرقامنا، لكنه يعترف
00:04:55بأن OJ يستخدم ذاكرة أقل بشكل ملحوظ، ويجب على Vite على الأرجح أن يهدف إلى تحسين ذلك.
00:04:59النقطة الأخيرة لـ Evan في هذه التغريدة هي النقطة التي أجدها الأكثر إثارة الاهتمام. ديناميكيات البرمجيات المفتوحة
00:05:03المصدر تتغير، وتكلفة إعادة إنشاء أي شيء تراجعت بسبب الذكاء الاصطناعي، لذا سنرى المزيد
00:05:08مما يسمى بالنسخ المخصصة لأدوات المصادر المفتوحة، وهي نفس التبعيات، المجمعة وفقاً
00:05:13لقيود مكون واحد لنتناسب مع حالة استخدام واحدة. ويعطي مشروع Redact من Tanstack كمثال آخر. من المستقبل
00:05:19المحتمل أنه بدلاً من إرهاق المطورين بآلاف طلبات السحب الخاصة بالثغرات، سيقوم كل شخص
00:05:23بصيانة النسخة المفرعة الخاصة به. ويقول بصراحة إنه غير متأكد مما إذا كان ذلك أمراً جيداً، لكنه
00:05:28يعتقد أن من المرجح جداً أن يحدث ذلك خلال بضع سنوات. فمن ناحية، تُعد التفرعات المخصصة أفضل
00:05:33للمطورين القائمين على المشاريع مقارنة بكم هائل من طلبات السحب، لكننا نغامر بتجزئة النظام البيئي. وأعتقد
00:05:39أن الوقت وحده هو الذي سيكشف كيف سيتطور هذا، وما سيكون عليه مستقبل المصادر المفتوحة.
00:05:43بشكل عام، هذه ليست أداة قد يستخدمها أي شخص بخلاف Lovable، إلا إذا كنت
00:05:47تواجه على ما يبدو المتاعب نفسها الناتجة عن ملايين خوادم تطوير Vite في بيئات الاختبار، وأعني،
00:05:52هل لاحظت حقاً أن Vite بطيء على جهازك المحمول أو يستهلك الكثير من الذاكرة؟ شخصياً
00:05:57لم ألاحظ ذلك، ولكن هذا يظل بالتأكيد مشروعاً رائعاً، ومن الرائع أنهم قاموا به،
00:06:01لذا أخبروني برأيكم حول ذلك في التعليقات. وأثناء وجودكم هناك، اشتركوا في القناة، وكالعادة،
00:06:04أراكم في الفيديو القادم.
00:06:09أراكم في الفيديو القادم.
Community Posts
No posts yet. Be the first to write about this video!
Write about this video