هندسة UI في عصر الذكاء الاصطناعي

في 12/12/2025، أغلق مهندس Zed، mikayla-maki، طلب PR يقترح إضافة shader مخصص إلى GPUI. كان الرد مهذبًا. شكر صاحب المساهمة، ثم قال: “we’re shifting focus to core product work at Zed, and without a Zed use case, I can’t validate this code”. وأنهى الرد بوجه مبتسم.

GPUI هو إطار واجهات GPU الذي طوّرته Zed بنفسها. ويتكرر ذكره عند مناقشة بدائل Electron. وقبل ذلك بأقل من أربعة أشهر، كانت Zed قد أعلنت جمع 32,000,000 دولار في جولة بقيادة Sequoia، ليتجاوز إجمالي تمويلها 42,000,000 دولار.

بعد أكثر من تسعة أشهر، في 26/9/2026، أنشأ المطوّر egoist مستودعًا باسم MyGo. وبعد 39 يومًا، ضم المستودع 1,042 عملية commit، حملت 890 منها توقيع Claude.

Claude من تطوير Anthropic. وتطبيق Anthropic المكتبي نفسه يستخدم Electron.

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

ما زالت تطبيقات سطح المكتب مثل Claude وCodex تستخدم Electron: منظومة Web ناضجة، وقاعدة شيفرة واحدة تدعم منصات متعددة، والنماذج تعرفها جيدًا. يقلل الذكاء الاصطناعي تكلفة التطوير، لكن التوافق بين المنصات والصيانة ما زالا يتطلبان جهدًا.

يوفر الرسم الذاتي عبر GPU مسارًا آخر، لكن GPUI ما زال يعطي الأولوية لـ Zed. يحتاج الرسم عبر المنصات ومنظومة المكونات إلى استثمار طويل الأجل. يوضح MyGo كيف يسرّع الذكاء الاصطناعي والمكونات الجاهزة الانطلاق، لكن النضج في الإنتاج وقابلية الصيانة طويلة الأجل لم يُثبتا بعد.

تتبنى Flutter وCompose وSlint وegui وiced مفاضلات مختلفة. اختبرنا 10 أطر بالسيناريوهات نفسها، وقسنا السلاسة وCPU والذاكرة ودقة مطابقة التصميم لمعرفة التكلفة الفعلية لكل مسار.

اختبرنا 10 أطر بالسيناريوهات نفسها على Apple M4 Max وThinkPad T14 Gen6. قسنا CPU والذاكرة على المنصتين؛ ولـ Windows أيضًا قياسات خارجية للإطارات عبر PresentMon. تختلف تعريفات استدعاءات الإطارات في Mac بين الأطر، فلا نستخدمها للمقارنة. كما تختلف الأجهزة ومقاييس الذاكرة، لذا نحصر المقارنة داخل كل منصة.

مشهد الحركة كثيف: 500 بطاقة بحجم 96×64 بكسل منطقي، موزعة بتداخل على 25 عمودًا. لكل بطاقة زوايا بنصف قطر 12 وتدرج بزاوية 135° وظل بقيمة blur 16 وإزاحة لأسفل قدرها 4. تتحدث مواضع جميع البطاقات مع كل إطار، وتدور حول مراكزها بنصف قطر 12 ودورة مدتها 4 ثوانٍ. نعرض وسيط خمس جولات مدة كل منها 30 ثانية.

نقيس أساسًا تكلفة CPU لتحديث الواجهة وتجهيز الرسم وإرسال التصيير أثناء حركة عناصر كثيرة ذات تأثيرات باستمرار، ومدى انتظام إخراج الإطارات. تشمل CPU شجرة عمليات التطبيق، وليست استخدام GPU أو تفصيل زمن كل مرحلة. يجب قراءتها مع فواصل الإطارات؛ فإخراج إطارات أقل قد يخفض CPU أيضًا. العدد 500 هو عدد البطاقات في المشهد، لكن التداخل والقص عند حدود النافذة يعنيان أنها لا تُرسم كلها بالكامل في كل إطار.

Windows

واكبت جميع الأطر تمرير القائمة. ظهر الفرق في الحركة: مع 500 بطاقة بظلال وتدرجات، حافظت أطر الرسم الذاتي المكتوبة بـ Rust وGo عمومًا على 120Hz. أما Flutter وElectron وTauri وCompose فوصلت فواصل الإطارات فيها إلى 80–160ms. جاءت نتيجة WPF البالغة 684ms من 500 تأثير ظل مستقل. وعادت إلى 8.3ms عند إيقافها، لذا ليست مشكلة عامة.

تحرير النص عقبة أخرى. عند إدخال 10 محارف في الثانية في مستند من 5,000 سطر، استهلك كل من Flutter وCompose وSlint نواة كاملة. وفقد Flutter على Windows ثلاثين بالمئة من المدخلات أيضًا.

Mac

على Mac، بلغ CPU للحركة نحو 15%–20% لدى GPUI وMyGo وegui وiced، مقابل 237% لدى Flutter ونحو 100% لدى Electron وCompose. عند تحرير النص، ظل Flutter وCompose قريبين من استهلاك نواة كاملة. سجل Slint نسبة 52%، أقل من نسبته البالغة 99% على Windows.

في مشهد القائمة، تصف أرقام SwiftUI نحو 40 MiB وGPUI نحو 340 MiB وegui نحو 800 MiB بصمة عمليات التطبيق أولًا. يمكن للواجهة الأصلية استخدام خدمات تصيير النظام خارج العملية: توضح Apple أن AppKit يفضل تصيير شجرة الطبقات خارج العملية، لذا يجري جزء من الرسم والتركيب خارج التطبيق. تستخدم محركات الرسم المخصصة تركيب النظام أيضًا، لكن أرقام التطبيق وحدها لا تقارن توزيع العمل بين المسارين. تعني الذاكرة الموحدة في شرائح M اشتراك CPU وGPU في الذاكرة الفعلية، لا احتساب كل التكاليف ضمن phys_footprint للتطبيق.

في خمسة تتبعات GPU قصيرة لكل من مشهدي القائمة والحركة في SwiftUI، لم تُرصد أحداث تنفيذ GPU لمعرّف عملية التطبيق، بينما كان WindowServer نشطًا. لا يعني ذلك أن SwiftUI لا يستخدم GPU، ولا يجوز نسب نشاط سطح المكتب كله إليه. تقلب خط أساس ذاكرة WindowServer بنحو 205 MiB؛ وعدم ظهور كائنات مشتركة كبيرة في اللقطات لا يستبعد إعادة استخدام موارد النظام الموجودة. تثبت البيانات انخفاض بصمة عملية SwiftUI فقط، لا انخفاض التكلفة الكاملة للتصيير ولا تحمّل النظام كامل الفارق.

هذه الأرقام تخص هذين الجهازين وهذه الإصدارات وبرامج الاختبار التي كتبناها فقط. المنهج والبيانات الكاملة في القسم 05.

تختلف متطلبات المحررات وأدوات التطوير وتطبيقات الأعمال في إدخال النص والحركة والذاكرة والتوزيع عبر المنصات ومنظومة المكونات. لكل منها سيناريوهاته، واختيار إطار يعني تحديد المفاضلات المقبولة.

تستخدم أطر كثيرة أيضًا الاحتفاظ والتخزين المؤقت والتحديثات الجزئية لتجنب تكرار التخطيط والرسم. يجمع GPUI بين النمطين الفوري والمحتفظ به. نموذج الواجهة والعمل الذي يمكن إعادة استخدامه وزمن رسم الإطار مسائل مختلفة.

تواكب MyGo وiced وGPUI وSlint وegui متطلبات الحركة، مع استخدام منخفض لـ CPU. يستهلك Slint أقل قدر من الذاكرة، بينما يستهلك egui قدرًا مرتفعًا نسبيًا، ويجب توفير عناصر التحرير في GPUI بنفسك. يُستخدم MyGo حاليًا بشكل أساسي في تطبيقات المؤلف، ولم يخضع بعد لاختبار واسع النطاق في بيئات الإنتاج.

كما كانت فواصل الإطارات واستهلاك الموارد لدى Flutter وElectron وCompose غير مرضية في اختبار ضغط الحركة هذا. لا يتجاوز حجم حزمة Tauri مقدار 11 MB، لكن استهلاكها للذاكرة أثناء التشغيل قريب من استهلاك Electron.

نرى الآن أن التحقق أهم من الرسم.

أصبحت كتابة الكود أقل كلفة، لكن التأكد من صحته لا يزال يحتاج إلى وقت. في استطلاع مطوري Stack Overflow لعام 2025، واجه 66% حلولًا من الذكاء الاصطناعي كانت “almost right, but not quite”، وقال 45.2% إن تصحيح أخطاء كوده يستغرق وقتًا أطول. وفي استطلاع نشرته Sonar في 01/2026، لم يثق 96% تمامًا بالصحة الوظيفية للكود المولّد، وقال 48% فقط إنهم يفحصونه دائمًا قبل commit. تبيع Sonar أدوات فحص الكود، لذا ينبغي قراءة أرقامها بشيء من التحفظ، لكنها تتسق مع الاستطلاع السابق.

لم يثر إصدارا Slint وegui ضجة كبيرة. ونراهما أهم من التقدم في الرسم. يحتاج الوكيل إلى حقن المدخلات والتقاط صور الشاشة كي يعدّل، وينظر، ثم يعدّل مجددًا. كان التحقق من الواجهة يتطلب شخصًا يجلس أمام الجهاز وينقر العناصر واحدًا واحدًا. والآن بدأت الآلة تتولى هذا العمل.

توجد حاليًا ثلاث طرق. يملك Web متعدد المنصات أكبر رصيد من الأدوات والخبرات. لا يحتاج الرسم الذاتي عبر GPU إلى حمل متصفح، وأصبحت عتبة بنائه أقل من قبل. أما بناء تطبيق أصلي لكل منصة فهو النهج الأقدم. في السابق لم تستطع تحمل كلفة عدة فرق إلا الشركات الكبرى. وتتمثل الصعوبة الآن في تضاعف عدد الأخطاء ونطاق الدعم ثلاث مرات كما وصف Breunig. إذا انخفضت كلفة التحقق وارتفعت الجودة، فقد ينجح أيضًا توليد تطبيق أصلي لكل منصة مباشرة.

نجرّب نحن أيضًا GPU UI خاصًا بنا. والفارق هو نقل جزء كبير من DX في تطوير Web: مكونات شبيهة بـ JSX، وأنماط شبيهة بـ CSS، وتخطيط flexbox، وحالة تفاعلية، وDevTools تشبه أدوات المتصفح، ثم الترجمة إلى كود أصلي. ما زال المشروع في بدايته.

لا نعرف أي إجابة ستفوز، وقد تتعايش عدة إجابات طويلًا. لم تتغير الوقائع الثلاث في البداية حتى اليوم. ما زال PR مغلقًا، وMyGo ينمو، وتطبيق Claude المكتبي لا يزال يستخدم Electron. إنه وقت مثير للاهتمام.

أُجريت الاختبارات من 4 إلى 6 نوفمبر 2026. نُفّذت السيناريوهات نفسها في كل إطار عمل باستخدام الأساليب الموصى بها والإعدادات الافتراضية وبُنى الإصدار. بعد تصحيح التمويه في Compose، أعدنا قياس صفحة التصميم ومشهد الخمول الذي يستخدم التنفيذ نفسه.

شغّلنا كل سيناريو 5 مرات لكل إطار، مدة كل مرة 30 ثانية، بالتتابع وبترتيب مختلط. جميع القيم أدناه وسيطة. بلغ وسيط المدى بين الجولات الـ5 نحو 3%، وكانت تسعة أعشارها ضمن 24%. أعدنا قياس القائمة والحركة بعد توحيد المواصفات، لذا لم تُجمع الأعمدة في الفترة نفسها. نواة منطقية واحدة تعادل 100% من CPU. تشمل التطبيقات متعددة العمليات جميع العمليات التابعة. ولـ Tauri على Mac احتسبنا أيضًا عمليات WebKit التي أطلقها النظام له. في بيانات إطارات Windows، استخدمنا فقط الجولات المنسوبة بشكل فريد إلى swapchain واحد، دون فقد سجلات.

راجعنا الحجم المنجز فعليًا في البث والتحرير: أكمل Flutter على Windows نسبة 68% فقط من التحرير، بينما تجاوز الجميع 99%.

مطابقة التصميم

يتطلب اختبار التمويه تنعيم الانتقالات بين الأشرطة الملونة في لوحة محددة داخل النافذة. عند تطبيق Modifier.blur بقيمة 24 dp على طبقة الأشرطة في Compose 1.12.2، ظهرت انتقالات ناعمة في لقطات النوافذ الأصلية على Mac وWindows. ويُموّه SwiftUI بدوره طبقة الأشرطة المعروفة قبل تغطيتها بطبقة بيضاء شبه شفافة. اقتصر التحقق في الطريقتين على هذه الطبقة. واجهة Compose Desktop

أضافت تطبيقات الاختبار في GPUI وiced وegui وSlint طبقة شبه شفافة فوق الأشرطة. وظلت حدود الألوان حادة عند إعادة الاختبار. يؤثر Blurred في GPUI وwindow::Settings::blur في iced على المحتوى خلف النافذة. لم نجد في واجهات الرسم المضمّنة في الإصدارات المختبرة تمويهًا موضعيًا للخلفية. يتيح iced رسم تأثيرات موضعية بعارض مخصّص، ويمكن لـ egui استدعاء محرك العرض عبر PaintCallback. GPUI · إعدادات نافذة iced · رد نداء الرسم في egui

اختبرنا Slint بالإصدار 1.18.1 مع FemtoVG. لم يوفّر ذلك الإصدار خاصية backdrop-blur للعناصر. أضافها المشروع لاحقًا لعارض Skia. وتعرض اللقطات مسار FemtoVG في الإصدار 1.18.1. سجل Slint

تضم صفحة التصميم 11 فحصًا. لم يُعِد GPUI وegui وiced وSlint وCompose إنتاج عينة P3 في خرج Mac المختبر. لا تحتوي لقطات Windows على ملف ألوان، لذا لا نحكم على P3؛ وتظهر رموز الأعلام حروفًا.

تتقارب أساليب التخطيط، ويبقى النص أكبر موضع اختلاف. عندما طلب iced استخدام PingFang 700 على macOS، استُخدم Menlo Bold بديلًا للحروف اللاتينية.

القيود:

• جهاز واحد فقط لكل منصة. نتائج الحركة مأخوذة من GPU مدمج من Intel، وقد لا تنطبق على وحدات GPU المنفصلة.
• لم يكن Mac خاملًا أثناء الاختبار. بيانات الإطارات من استدعاءات التطبيق الراجعة فقط، ولا نستخدمها للمقارنة بين الأطر.
• تختلف دلالة blur في الظلال. تستخدم egui وiced وGPUI تنفيذات تقريبية. وعناصر التحرير ليست متكافئة أيضًا؛ يستخدم GPUI محررًا من الأمثلة بعد تعديله.
• تشمل جداول CPU والذاكرة التطبيق والعمليات المساعدة المدرجة فقط. لم توزع تكاليف WindowServer وبرنامج التشغيل حسب النافذة، ولم تُقَس فوائد إعادة استخدام موارد النظام المشتركة؛ لذلك لا ترتب هذه الجداول التكلفة الكلية للتصيير على مستوى النظام.
• لم نحصل على نتائج صالحة لنوافذ مرشحات طريقة الإدخال أو شجرة إمكانية الوصول على Mac أو استهلاك الطاقة.