React-Native ماتت... بفضل الذكاء الاصطناعي.

BBetter Stack
컴퓨터/소프트웨어경제 뉴스AI/미래기술

스크립트

00:00:00كانت Shopify من أكبر الداعمين لـ React Native لنصف عقد من الزمان، لكنها أعلنت هذا الأسبوع
00:00:05عودتها إلى التطوير الأصيل (Native)، وإذا فهمت السبب فقد ترغب في الانتقال أيضاً. إن أكبر
00:00:10مزاعم منصات مثل React Native هي أنه يمكنك بناء تطبيقك مرة واحدة وإطلاقه على كل من Android
00:00:15و iOS؛ كود برمجي واحد، ولغة واحدة، وصيانة أقل بكثير. وكانت Shopify مقتنعة تماماً بهذه الفكرة،
00:00:21إذ تضمن صيانة حزم React Native التي تتجاوز تنزيلاتها الأسبوعية مليوني تنزيل.
00:00:26ووحتى في عام 2025، نشروا مقالات تجدد دعمهم لهذه التقنية. ولكن بعد عام واحد
00:00:32فقط، شهدوا تغيراً جذرياً في موقفهم؛ حيث يتم التخلي عن جميع المستودعات مفتوحة المصدر تلك،
00:00:37وعادت الشركة بالكامل إلى التطوير الأصيل. والسبب الرئيسي هو التطورات في الذكاء الاصطناعي مع
00:00:44أحدث النماذج وبعض التقنيات الذكية الداخلية، إذ لم يعد عبء بناء تطبيقين منفصلين قائماً.
00:00:49يمكنك فقط توجيه النموذج إلى تطبيق iOS الخاص بك وتقول له: “ابنِ لي هذا لنظام Android”، وسيعمل! لذا
00:00:55سنتعرض اليوم بالتفصيل لكيفية بناء Shopify للتطبيقات الأصيلة، وأنا أتفق معهم تماماً
00:01:00في هذا الطرح. فعلى الرغم من أنني بنيت باستخدام React Native لجزء كبير من العقد الماضي، فقد
00:01:06عدت أيضاً إلى التطوير الأصيل وفوجئت سروراً بالنتيجة. لذا آمل أن أقنعك في هذا الفيديو
00:01:12بفعل الشيء نفسه. نشرت Shopify الأسبوع الماضي مقالاً يقدم التطوير الأصيل كمستقبل لتطبيقات الهاتف
00:01:23في Shopify، وهو مليء بمعلومات قيّمة للغاية. يتحدثون عن منع كود الذكاء الاصطناعي الرديء عبر بناء نظام يُدعى
00:01:29Helix لتقسيم عمل الوكيل الذكي إلى أجزاء أصغر، وكيفية التعامل مع حلقات التغذية الراجعة السريعة حتى تتمكن الوكلاء من الاختبار
00:01:36بسرعة. وبعد البناء باستخدام التطوير الأصيل خلال الأشهر القليلة الماضية بنفسي، غير ذلك سير العمل الخاص بي تماماً.
00:01:42لذا دعونا نستعرض كل شيء، ولكن أولاً: لماذا هذا التحول؟ لأنهم هم أنفسهم قالوا في عام 2025
00:01:48فقط: “كتبت أن مستقبل React Native كان مشرقاً وأن Shopify تخطط لمواصلة الاستثمار
00:01:54فيه”، ولكن منذ ذلك الحين تحسنت نماذج البرمجة بشكل مذهل. وبالنسبة للتطبيقات وفريقنا،
00:01:59لم يعد بناء الميزة نفسها بـ Swift و Kotlin يتطلب التكلفة التي كان يحتاجها سابقاً، وبالتالي فإن فوائد
00:02:05React Native في البناء مرة واحدة لكلا المنصتين لم تعد قائمة بفضل الذكاء الاصطناعي. بدايةً، قاموا ببناء هذا
00:02:11النظام المسمى Helix لحل القصور في النماذج الحالية. وقالوا إنه من المغري مجرد توجيه نموذج لغوي كبير إلى
00:02:17الكود البرمجي لـ React Native ومحاولة تنفيذ نفس الميزة دفعة واحدة بلغة أصيلة، لكن هذا لا يعمل مجدياً.
00:02:23حتى لو طلبت منه جمع أكبر قدر ممكن من المعلومات، وتفريغ ذلك في مواصفات وملفات مهام،
00:02:29ثم تطبيقها، سينتهي بك المطاف بقدر هائل من الكود غير القابل للصيانة والذي لا يمكن إطلاقه. بدلاً من ذلك، يتوقع Helix
00:02:34أن المحاولة الأولى لن تكون مثالية، ويبني حلقة لا يمكن للمحاولة غير المثالية فيها
00:02:41المضي قدماً حتى تصبح نتيجة جيدة. يوجه المطور نظام Helix أولاً إلى شاشة معينة، فيقرأ
00:02:46كود React Native ويقترح تسلسلاً من نقاط التحقق؛ وهي أجزاء صغيرة ومرتبة من العمل الذي
00:02:52يمكن مراجعته في دقائق، ثم يبني كل نقطة تحقق على حدة. يجب على كل نقطة إثبات سلوكها بالاختبارات،
00:03:00ومطابقة التطبيق الشغال في مراجعة بصرية، واجتياز مراجعتين صارمتين للكود، والحصول على موافقة مطور بشري
00:03:05قبل اعتمادها وبدء النقطة التالية. وتتم التوصية بالحفظ التلقائي للملاحظات من كل مراجعة من هذه المراجعات
00:03:11لتصبح الحلقة أكثر استقلالية مع تقدم عملية الانتقال. هذا النهج يقضي بشكل فعال على الكود الرديء،
00:03:18ولكن مع وجود كل هذا، ظل هناك مشكلة ضخمة؛ لأن التجميع والاختبار للتطبيقات الأصيلة
00:03:23بطيء. يمكن للوكلاء إجراء تغييرات في ثوانٍ، لكن الأمر يستغرق منهم عدة دقائق لاختبار النتيجة.
00:03:29وهذا يجعل التكرار بطيئاً ويدوياً للغاية؛ إذ لا يهم حقاً مدى جودة النموذج إذا
00:03:34لم يكن بإمكانه اختبار عمله بسرعة، وهو أمر صعب بشكل خاص على الهواتف. قامت Shopify بحل هذا بطريقتين
00:03:40محددتين: أولاً، يجب فصل منطق العمل تماماً عن واجهة المستخدم. وهذا يعني إمكانية تشغيل المنطق
00:03:46بدون واجهة على أجهزة سطح المكتب وإتاحته للوكلاء لتشغيله عبر واجهة السطر البرمجي (CLI)، مما يسمح لهم بالتكرار في
00:03:52أجزاء من الثانية بدلاً من دقائق عن طريق عدم إشراك المحاكيات. ومن منظور تطوير الويب، تشبه هذه العملية
00:03:58الاحتفاظ بحالة التطبيق بالكامل في صيغة JSON ثم إطلاق أوامر لتحديث مخزن JSON هذا. أما واجهة المستخدم فليست
00:04:04سوى تمثيل لهذه الحالة، لذا ليس هناك حاجة أبداً لمعالجة شجرة إمكانية الوصول أو فحص
00:04:10الشاشة أو العثور على أي عناصر والنقر عليها. يمكن تشغيل كل شيء بدون واجهة مستخدم على الإطلاق. وفي الحالات
00:04:16التي تحتاج فيها بالفعل إلى عرض واجهة المستخدم، يمكنك الاستمرار في إدارة جميع التفاعلات من واجهة السطر البرمجي،
00:04:22ليظل كل شيء سريعا. هذا هو الوكيل الذكي يختبر تطبيقاً في الوقت الفعلي، وهذا الفيديو ليس مسرعاً على الإطلاق.
00:04:28لقد أعددت عرضاً توضيحياً بسيطاً يفعل الشيء نفسه، والذي يمكنه عبر واجهة السطر البرمجي فتح YouTube و
00:04:32الاشتراك في قناة Better Stack، لكنك لا تحتاج حتى إلى وكيل لفعل ذلك؛ يمكنك فقط الاشتراك
00:04:36باستخدام الزر الموجود أسفل هذا الفيديو. بدون إعداد مثل هذا، ستحتاج إلى استخدام أداة
00:04:41XCUI Test من Apple، لكن هذه الأداة تعمل خارج العمليات البرمجية وتجد العناصر عن طريق فحص تسلسل إمكانية الوصول،
00:04:46ويقوم بإنشاء النقرات ثم يُعيد الاستعلام عن التسلسل الهرمي للتحقق، وهو أمر بطيء للغاية وغير مستقر على العكس تمامًا.
00:04:53باتباع هذه التقنيات، أُطلق تطبيق Shop أصيلاً بالكامل بالفعل، وهو تطبيق بـ 3 ملايين
00:04:59تنزيل شهرياً. التحفظ هنا بالطبع هو أن Shopify شركة ضخمة، وستظل بحاجة إلى
00:05:06صيانة تطبيقين بنفسك، لكنني أقول إن هذا هو الممكن مع النماذج اليوم. وعلى مدى الأشهر والسنوات
00:05:11القليلة القادمة، سيصبح هذا أسهل فقط، وأعتقد أن هذا يبدأ بالفعل في إضعاف قيمة
00:05:17React Native أكثر. تتولى Shopify صيانة حزم رئيسية مفتوحة المصدر، بما في ذلك FlashList بـ 2 مليون
00:05:23تنزيل أسبوعياً، و React Native Skia و Restyle. ويجري تسليم جميع هذه الحزم الآن إلى
00:05:30مطورين من أطراف خارجية، مما يشير إلى أن Shopify تتخلى تماماً عن React Native.
00:05:36ومن الجدير بالذكر أيضاً أن Airbnb غادرت React Native منذ سنوات عديدة؛ لأن صيانة iOS و Android والجسر البرمجي
00:05:43كانت تعني إدارة ثلاث منصات وليس منصة واحدة. لقد أحببت التطوير بـ React Native لسنوات، وأمضيت معظم حياتي المهنية
00:05:50في ذلك المجال، لكنني أعتقد أن هذه بداية النهاية للتقنيات متعددة المنصات. ومع تحسن الوكلاء الذكيين،
00:05:56لماذا لا ترغب في تحسين الأداء والاستفادة من الوظائف الأصيلة الأفضل للمنصة مثل CloudKit
00:06:02و SwiftUI؟ بالطبع يمكنك التفاعل مع هذه الأنظمة من خلال React Native، لكن الأداء
00:06:08لن يكون بنفس الجودة أبداً. شاركني برأيك في التعليقات، واشترك في القناة إن لم تكن مشتركاً بالفعل؛
00:06:13فنحن ننشر محتوى التقنية والذكاء الاصطناعي باستمرار، وأراك في المرة القادمة.

핵심 요약

تتراجع الشركات الكبرى عن تقنيات تحويل الكود مثل React Native لصالح التطوير الأصيل المباشر، مستفيدة من وكلاء الذكاء الاصطناعي لتوليد أكواد Swift و Kotlin واختبارها عبر السطر البرمجي بسرعة فائقة.

하이라이트

  • تتخلى Shopify عن التقنيات متعددة المنصات وتنتقل بالكامل إلى التطوير الأصيل (Native) لمدعوم بالذكاء الاصطناعي.

  • يلغي التطور في نماذج الذكاء الاصطناعي عبء صيانة كود منفصل بلغتي Swift و Kotlin للتطبيقات.

  • يبني نظام Helix تسلسلاً من نقاط التحقق المراجعة بشرياً لمنع إنتاج كود برمجي عشوائي أو غير قابل للصيانة.

  • فصل منطق العمل عن واجهة المستخدم يتيح للوكلاء الذكيين تشغيل الاختبارات عبر واجهة السطر البرمجي في أجزاء من الثانية.

  • تخلت Shopify عن نقل ملكية حزمها مفتوحة المصدر مثل FlashList ذات الـ 2 مليون تنزيل أسبوعياً إلى مطورين خارجيين.

  • تطوير تطبيق Shop الأصيل بالكامل يخدم أكثر من 3 ملايين تنزيل شهرياً دون الحاجة إلى React Native.

타임라인

التحول الهيكلي من React Native إلى التطوير الأصيل

  • أعلنت Shopify التخلي عن دعم React Native والعودة إلى التطوير الأصيل المباشر.
  • تطور نماذج البرمجة بالذكاء الاصطناعي خفض تكلفة بناء الميزات المزدوجة بلغتي Swift و Kotlin.
  • فوائد كتابة الكود مرة واحدة للمنصتين لم تعد تجدي نفعاً أمام كفاءة الذكاء الاصطناعي.

استمر دعم Shopify لمنصة React Native لنصف عقد من الزمان مع تقديم حزم مفتوحة المصدر تجاوزت تنزيلاتها الملايين. ورغم تجديد هذا الدعم في عام 2025، أدى التطور السريع لنماذج الذكاء الاصطناعي إلى تحول كامل في موقف الشركة؛ حيث أصبحت إعادة كتابة التطبيقات لتتناسب مع iOS و Android عملية أسهل وأقل تكلفة من صيانة جسر برمجي متعدد المنصات.

نظام Helix للتحكم في جودة الكود المولد

  • التوليد المباشر للكود الأصيل من React Native ينتج كوداً غير قابل للصيانة.
  • يقسم نظام Helix المهام إلى نقاط تحقق صغيرة يتم فحصها واختبارها تسلسلياً.
  • تتطلب كل نقطة تحقق اختبارات سلوكية ومراجعة بصرية وموافقة مطور بشري.

توجيه النماذج اللغوية الكبيرة لتحويل التطبيقات دفعة واحدة يؤدي إلى تراكم كود ردئ لا يمكن إطلاقه. يعالج نظام Helix هذه المشكلة عبر تقطيع العمل إلى نقاط تحقق صغيرة يستغرق فحصها دقائق معدودة، حيث يتوجب على كل جزء اجتياز مراجعتين صارمتين للكود واختبارات قياسية وتأكيد بشري قبل الانتقال إلى الجزء التالي.

تسريع حلقات التغذية الراجعة للاختبار البرمجي

  • تجميع التطبيقات الأصيلة واختبارها بوسائل المحاكاة التقليدية يستغرق عدة دقائق.
  • فصل منطق العمل عن واجهة المستخدم يتيح التشغيل بدون واجهة على أجهزة سطح المكتب.
  • تنفيذ الاختبارات عبر واجهة السطر البرمجي يقلل زمن التكرار إلى أجزاء من الثانية.

بطء عملية إعادة التجميع واختبار الواجهات على الهواتف والمحاكيات يعطل سرعة وكلاء الذكاء الاصطناعي. عالجت Shopify هذا العائق بتمثيل حالة التطبيق بالكامل بصيغة JSON وفصل المنطق عن واجهة المستخدم، مما يسمح للوكلاء بالتحقق من السلوك وتعديل البيانات عبر واجهة السطر البرمجي دون الحاجة لمعالجة تسلسل إمكانية الوصول أو انتظار أدوات مثل XCUI Test.

نهاية عصر المنصات المتقاطعة وتأثيرها على السوق

  • أطلقت Shopify تطبيق Shop الأصيل بالكامل الذي يسجل 3 ملايين تنزيل شهرياً.
  • تخلت الشركة عن صيانة حزم مكتبية شهيرة مثل FlashList و React Native Skia.
  • تفضيل الأداء الأصيل واستغلال خصائص النظام مثل SwiftUI و CloudKit يتفوق على أطر العمل الهجينة.

إطلاق تطبيق Shop الأصيل يثبت نجاح التحول على نطاق واسع. نقل ملكية المكتبات مفتوحة المصدر إلى أطراف خارجية يشير إلى التخلي النهائي عن النظام البيئي لـ React Native، وهو ما يكرر تجارب شركات أخرى مثل Airbnb التي غادرت سابقاً لتجنب التعقيد الناتج عن إدارة ثلاث منصات في وقت واحد.

커뮤니티 글

아직 글이 없습니다. 이 영상에 대한 첫 번째 글을 작성해 보세요!

이 영상에 대해 글쓰기