أطر JavaScript من الجيل التالي

الخلاصة — «الجيل التالي» هو وصفي لـ Qwik وSolidJS — وليس فئة رسمية — لأن كليهما يعالج عمل بدء تشغيل JavaScript بآليتين مختلفتين. قد يعني تشغيل قدر أقل من JavaScript عند التحميل صفحات أسرع وأكثر استجابة، وهو ما تكافئه Core Web Vitals. لكن لا يضمن أي من الإطارين أن يكون محتواك قابلًا للزحف أو أن تحقق نتائج جيدة في Core Web Vitals؛ فما يزال ذلك يعتمد على وضع التصيير في الإطار الشامل الذي تستخدمه فعليًا.

ما المقصود بـ «الجيل التالي» هنا؟

تبني معظم الأطر الشائعة (React وVue وAngular) قدرًا كبيرًا من الصفحة في متصفحك. وحتى عندما يرسل الخادم HTML مكتملًا، يحتاج الإطار عادةً إلى ترطيبه — أي إعادة تشغيل JavaScript الخاص به في المتصفح «لإيقاظ» الصفحة كي تعمل الأزرار والقوائم. ويُعد عمل الترطيب هذا من أكبر أسباب بطء الصفحة: فهو يستهلك وقت المعالج بينما يحاول المستخدم التفاعل.

ليست «الجيل التالي» فئة موحّدة في منصة الويب؛ إنها التسمية التي أستخدمها هنا لمشروعين يعالجان هذه التكلفة مباشرةً، ولكل منهما آليته:

• Qwik — يرسل HTML مكتملًا ثم يستأنف بدل أن يرطّب. يظل نص تمهيد صغير يعمل عند التحميل؛ لكنه لا يجلب الشيفرة المحددة لأحد التفاعلات إلا عندما تنقر شيئًا بالفعل.
• SolidJS — يرسل أيضًا HTML مكتملًا ويرطّبه، ولكن بنظام أخف وأذكى بكثير، ولذلك يكون العمل المطلوب أقل كثيرًا.

كلاهما هدف متحرك: يشحن Qwik حاليًا إصدار v2 تجريبيًا، كما تصف وثائق SolidStart نفسها بأنها تجريبية. تعامل مع الإعدادات الافتراضية والسلوكيات المحددة أدناه على أنها مرتبطة بالإصدار لا دائمة.

ما الذي يغيّره هذا فعليًا لتحسين محركات البحث؟

هناك حقيقتان مستقلتان إحداهما عن الأخرى:

1. يعتمد وجود محتواك في HTML على وضع التصيير الذي تختاره، لا على الإطار وحده. تستطيع أدوات الحزمة الكاملة الرسمية (QwikCity لـ Qwik وSolidStart لـ SolidJS) تصيير مسار على الخادم أو توليده ثابتًا، فتكون النصوص والروابط موجودة أصلًا في HTML؛ لكن SolidStart يدعم أيضًا التصيير الخالص من جانب العميل، الذي ينتج غلافًا فارغًا مثل أي SPA أخرى. اختر الوضع الخطأ ولن تمنحك تسمية «الجيل التالي» شيئًا للزحف. راجع JavaScript SEO لفهم الآليات العامة.
2. قد يساعد تشغيل قدر أقل من JavaScript في Core Web Vitals، لكنه لا يضمنها. تعتمد قيم INP وTBT الفعلية على شيفرة تطبيقك ونصوص الجهات الخارجية ووقت استجابة الخادم وظروف الجهاز، لا على نموذج التفاعلية في الإطار وحده. وتُعد Core Web Vitals عامل ترتيب، لذا يستحق الأمر القياس ميدانيًا بدل الافتراض.

الأمر الوحيد الذي ينبغي ألا تخلط فيه

يجمع الناس Qwik وSolidJS معًا بوصفهما «الإطارين القابلين للاستئناف». هذا خطأ. قابلية الاستئناف هي فكرة Qwik. لا يستخدم SolidJS قابلية الاستئناف؛ بل يستخدم الترطيب، وإن كان بكفاءة عالية جدًا. حافظ على وضوح هذا الفرق وسيستقيم ما بعده.

هل تريد الآليات الفعلية — قابلية الاستئناف مقابل الترطيب، والإشارات مقابل DOM الافتراضي، وكيف يقارنان بـ React وVue وAngular في الأداء وتحسين محركات البحث؟ انتقل إلى علامة التبويب Advanced.

الخلاصة — «أطر الجيل التالي» تجميع تحريري خاص بهذه المقالة لـ Qwik وSolidJS، وليس فئة موحّدة؛ فكلاهما يستهدف تكلفة تنفيذ JavaScript في المتصفح، ولكن بآليتين مختلفتين. يستخدم Qwik قابلية الاستئناف — يتوقف التطبيق على الخادم ويسلسل المستمعين وحدود المكوّنات والحالة داخل HTML، بحيث يستطيع المتصفح استئناف عمل محدد بدل إعادة تشغيل تمهيد ترطيب كامل؛ ومع ذلك يعمل نص تمهيد صغير (Qwikloader) عند التحميل ويحمّل شيفرة المعالج تحميلًا كسولًا عند التفاعل، لذلك لا يعني هذا حرفيًا انعدام JavaScript. يستخدم SolidJS التفاعلية دقيقة الحبيبات — الإشارات وعدم وجود DOM افتراضي، فتكون التحديثات جراحية الدقة — لكنه يظل يستخدم الترطيب (وليس قابلية الاستئناف؛ وهذه هي الخرافة التي يجب تصحيحها). وتختلف تفاعلية الإطار عن وضع التصيير في الإطار الشامل: يمكن لـ QwikCity وSolidStart إخراج HTML مصيّر على الخادم، لكن SolidStart يدعم أيضًا التصيير الخالص من جانب العميل، ولا يضم افتراضيًا مكتبة توجيه أو بيانات وصفية. تعتمد قابلية الزحف والفهرسة وCore Web Vitals المقاسة على وضع التصيير والتنفيذ اللذين تشحنهما فعليًا؛ فلا يضمنها إطار أو نموذج تفاعلية.

السبب الجذري الذي يستهدفانه

افتح محور JavaScript SEO وستجد أن أنماط الفشل تتعلق بما إذا كان Google يستطيع رؤية محتواك. هذا سؤال عن وضع التصيير — SSR أو SSG أو CSR — ويدعم كل من QwikCity وSolidStart مخرجات مصيّرة على الخادم أو مولّدة ثابتًا، مع أن أيًا منهما لا يفرض ذلك: اختر CSR وستعود إلى SPA ذات غلاف فارغ بصرف النظر عن الإطار الأساسي. أما ما يغيّره Qwik وSolidJS فعليًا فهو النصف الآخر من القصة: تكلفة JavaScript الذي يعمل بعد وصول HTML.

في تطبيق نموذجي يجمع SSR والترطيب، يرسل الخادم HTML مكتملًا — وهذا ممتاز لأول تصيير ولبرامج الزحف — ثم ينزّل الإطار شيفرة مكوّناته ويعيد تنفيذها في المتصفح لربط معالجات الأحداث وإعادة بناء حالته الداخلية. وتمثل عملية الترطيب هذه حملًا زائدًا محضًا من منظور المستخدم: تبدو الصفحة جاهزة لكنها ليست تفاعلية، ويُحجب مسار التنفيذ الرئيسي. وهذا أكبر مساهم منفرد في ارتفاع Total Blocking Time (TBT) في المختبر وسوء Interaction to Next Paint (INP) في الميدان.

وُجد كل من Qwik وSolidJS لتقليص هذه العملية أو إزالتها. ويسلك كل منهما طريقًا مختلفًا.

Qwik: قابلية الاستئناف (بلا ترطيب — ولكن ليس بلا JavaScript أيضًا)

فكرة Qwik الأبرز هي قابلية الاستئناف، وQwik (حاليًا في إصدار v2 تجريبي) هو الإطار الذي أشير إلى نموذج تفاعليته هنا؛ أما QwikCity فهو طبقة الإطار الشامل المنفصلة الموضحة أدناه. يعمل الإطار على الخادم ويصيّر HTML ثم يسلسل كل ما يحتاجه التطبيق للمتابعة — الحالة ومستمعي الأحداث وشجرة المكوّنات وموضع التنفيذ — مباشرةً داخل HTML. وعند تحميل الصفحة في المتصفح، لا يعيد Qwik تشغيل مكوّناتك لإيقاظها؛ بل يستأنف من الموضع الذي توقف عنده الخادم بدل إعادة تشغيل تمهيد ترطيب كامل.

يختلف ذلك حقًا عن الترطيب، لكنه لا يعني انعدام JavaScript. فما يزال نص تمهيد صغير، Qwikloader (تذكر وثائق Qwik أن حجمه المصغّر يقارب 1kb وأن تنفيذه يستغرق أقل من 5ms على الهاتف)، يعمل عند كل تحميل للصفحة. وهو:

• يسجّل مستمع أحداث عامًا واحدًا بدل ربط مستمع بكل عنصر تفاعلي،
• ويقرأ السمات المسلسلة على نمط on:click="./chunk.js#handler_symbol" التي كتبها Qwik داخل HTML (وهي QRLs، أي محددات موارد Qwik)،
• وعندما يقع حدث بالفعل، يحل QRL المطابق ويحمّل مقطع المعالج المحدد تحميلًا كسولًا قبل تشغيله.

النتائج العملية:

• JavaScript عند البدء صغير وثابت تقريبًا، لا معدوم. لا تنمو تكلفة Qwikloader نفسه مع حجم تطبيقك، ولا تعمل عملية ترطيب للتطبيق كاملًا؛ لكن Qwikloader نفسه JavaScript حقيقي يُنفّذ. لا تصف ذلك بأنه «لا JavaScript عند التحميل»، بل «تمهيد صغير ثابت الحجم بدل عملية ترطيب تتوسع مع حجم التطبيق».
• تحميل كسول حتى مستوى المعالج. لا تُحمّل شيفرة التطبيق إلا عند وقوع تفاعل فعلي، وهذا ما يقصده مؤلفو Qwik بعبارة «HTML أولًا».
• QwikCity هو الإطار الشامل لـ Qwik — التوجيه القائم على الملفات، ومحمّلات البيانات، والإجراءات، ونقاط النهاية — أي طبقة الحزمة الكاملة التي تنتج HTML قابلًا للاستئناف ومصيّرًا على الخادم أو ثابتًا. ولا تحدد قابلية الاستئناف في Qwik بمفردها رمز حالة المسار أو بياناته الوصفية أو حتى ما إذا كان مصيّرًا على الخادم؛ بل يحدد ذلك إعداد التوجيه والتصيير في QwikCity.

أين تتعطل قابلية الاستئناف عمليًا؟

لقابلية الاستئناف قيود حقيقية يجدر معرفتها قبل الاعتماد عليها (وفق وثائق Qwik الحالية للتسلسل والحالة):

• حدود التسلسل. لا تستطيع الشيفرة داخل حد $(...) التقاط إلا قيم قابلة للتسلسل — القيم الأولية، والبيانات القابلة للتسلسل المرتبطة بـ const، وبعض الأنواع المدمجة التي يعرف Qwik كيف يسلسلها (ومنها الوعود). ينجح مثيل لفئة مخصصة أو قيمة أخرى غير مدعومة في التحليل الثابت، لكنه يفشل وقت التشغيل عندما يحاول Qwik تسلسله؛ وهو نمط فشل يظل صامتًا حتى الشحن ويستحق الاختبار.
• لا تنجو قيم noSerialize() من الاستئناف. تتحول أي قيمة موسومة صراحةً بأنها غير قابلة للتسلسل إلى undefined بعد أن يستأنف العميل من حالة SSR/SSG، ويجب إعادة تهيئتها على العميل، عادةً داخل useVisibleTask$().
• useVisibleTask$ مخرج متعجل يعمل في المتصفح فقط. تسميه وثائق Qwik نفسها حلًا أخيرًا: فهو يعمل في المتصفح فقط بعد التصيير الأولي، و*“eagerly executes code on the client”* (ترجمة) «ينفّذ الشيفرة بشغف على العميل» — ويكون افتراضيًا مشروطًا بالظهور عبر مراقب تقاطع، لكنه يعمل فور التحميل إذا ضبطت { strategy: 'document-ready' }. ويعيد الإفراط في استخدامه إدخال تكلفة البدء التي صُممت قابلية الاستئناف لتجنبها.

بالنسبة إلى تحسين محركات البحث تحديدًا: إن تضمين مخرجات خادم مسار QwikCity لمحتواك وروابط <a href> في HTML الأولي مسألة وضع تصيير وتوجيه، وليست شيئًا تضمنه قابلية الاستئناف وحدها؛ افحص الاستجابة الفعلية لا اختيار الإطار فحسب. راجع الزحف لمعرفة ما يحتاجه Google هناك. وتكمن الفائدة الواقعية لآلية قابلية الاستئناف في جانب وقت التشغيل: قدر أقل من JavaScript عند البدء يحجب مسار التنفيذ الرئيسي، وهو عامل في Core Web Vitals — وليس ضمانًا لقيمة INP أو TBT بعينها.

SolidJS: التفاعلية دقيقة الحبيبات (ترطيب أذكى — وليست قابلية الاستئناف)

يعالج SolidJS التكلفة نفسها من زاوية مختلفة، ومع التحفظ نفسه المذكور أعلاه: Solid، أي محرك التفاعلية، منفصل عن SolidStart، أي الإطار الشامل. وتتمثل فكرة Solid الأساسية في تفاعلية دقيقة الحبيبات مبنية على الإشارات، ومن دون DOM افتراضي.

• إشارات، لا إعادة تصيير. في React، يؤدي تغير الحالة إلى إعادة تشغيل دالة المكوّن ومقارنة DOM افتراضي لمعرفة ما تغير. أما في Solid فتعمل دالة المكوّن مرة واحدة؛ وتتتبع الإشارات (أزواج getter/setter المنشأة باستخدام createSignal) والمشتركون (مثل createEffect) التبعيات مباشرةً، ولذلك عندما تتغير إشارة لا يعاد تشغيل إلا الشيفرة المشتركة فيها فعلًا — لا إعادة تنفيذ للمكوّن ولا مقارنة لـ DOM افتراضي. وهذا سبب وجود Solid باستمرار عند قمة معايير أداء الأطر أو قريبًا منها (حزمة js-framework-benchmark) في أعباء العمل كثيفة التحديث؛ راجع المعيار مباشرةً للأرقام الحالية بدل تثبيت ادعاء رقمي هنا، لأن النتائج تتغير بين إصدارات الأطر.
• ما يزال يستخدم الترطيب — SolidJS ليس إطار قابلية استئناف. ينتج مصيّر الخادم HTML ثم يرطّبه العميل؛ وهذه آلية مختلفة عن قابلية الاستئناف في Qwik وليست نوعًا منها. وتعني التفاعلية دقيقة الحبيبات وغياب DOM الافتراضي أن عملية الترطيب في Solid تعيد بناء عمل أقل من إطار VDOM نموذجي، لكن القول إن «الترطيب أرخص هنا» بيان على مستوى الآلية لا رقم ثابت؛ فما تزال تكلفة الترطيب الفعلية تعتمد على مقدار الشيفرة التفاعلية التي يشحنها المسار. لا تصف SolidJS بأنه «قابل للاستئناف».
• SolidStart هو الإطار الشامل لـ Solid — التوجيه ودوال الخادم وإعدادات النشر المسبقة، أي نظير QwikCity / Next.js لدى Solid. تسرد وثائق SolidStart الحالية (v1.0، موسومة بأنها تجريبية وآخر تحديث لها 2026-04-28) ثلاثة أوضاع تصيير تختارها لكل تطبيق: التصيير من جانب العميل (CSR) والتصيير من جانب الخادم (SSR — متزامن أو غير متزامن أو متدفق) وتوليد الموقع الثابت (SSG). تعمل التفاعلية دقيقة الحبيبات في Solid بالطريقة نفسها بصرف النظر عن الوضع الذي تختاره؛ ووضع التصيير هو ما يحدد أصلًا ما إذا كان HTML الأولي للمسار يحتوي على محتواك. وتنص وثائق SolidStart صراحةً على أنه لا يضم مكتبة توجيه أو بيانات وصفية افتراضيًا — بل تضيفها بنفسك، ولذلك لا تصبح إدارة البيانات الوصفية تلقائية لمجرد استخدام SolidStart.

بالنسبة إلى تحسين محركات البحث: يعتمد وصول محتوى مسار SolidStart وروابطه إلى HTML الأولي على أي من أوضاع التصيير الثلاثة يستخدمه؛ ينتج CSR وحده غلافًا فارغًا مثل أي SPA، تمامًا كما يحدث عند اختيار CSR في أي مكان آخر. أما SSR أو SSG فيضعان المحتوى داخل HTML بالطريقة التي يتطلبها JavaScript SEO. وفائدة CWV هنا على مستوى الآلية: يقلل وقت التشغيل الأصغر والتحديث دقيق الحبيبات العمل الذي يحتاجه الترطيب، لكنه لا يحدد بمفرده قيمة TBT أو INP بعينها.

الفرق بصياغة واضحة

هذا هو عمود الدقة الفقري للموضوع كله، لذا كن محددًا:

• Qwik = قابلية الاستئناف. لا تمهيد ترطيب. يعمل نص تمهيد صغير ثابت الحجم تقريبًا (Qwikloader) عند التحميل، وتُحمّل شيفرة التطبيق تحميلًا كسولًا عند التفاعل. ويستأنف من حالة الخادم المسلسلة.
• SolidJS = تفاعلية دقيقة الحبيبات + ترطيب. لا DOM افتراضي، وإشارات تتبع التبعيات، لكنه يستخدم الترطيب. وهو ليس قابلية الاستئناف.

يقلل كلاهما عمل JavaScript في المتصفح مقارنةً بتطبيق نموذجي يجمع VDOM والترطيب الكامل، لكن بآليتين مختلفتين، ولا يلغي أي منهما JavaScript في المتصفح كليًا. والخلط بين «قابلية الاستئناف» و«انعدام JavaScript»، أو اعتبار SolidJS قابلًا للاستئناف، هما الخطآن الأكثر شيوعًا في هذا الاقتران.

حد مقارنة مجاور: جزر Astro

يجدر ذكرها لأنها تظهر في النقاشات نفسها: تمثل بنية الجزر في Astro آلية ثالثة، وليست نوعًا من أي من الآليتين أعلاه. يشحن Astro افتراضيًا HTML عاديًا مصيّرًا على الخادم، ويتيح لك اختيار مكوّنات محددة لترطيبها على العميل («جزر») عبر توجيهات العميل؛ لذلك لا يشحن معظم الصفحة JavaScript خاصًا بالمكوّنات أصلًا. وهذا حد مقارنة مفيد لسؤال «ما مقدار الصفحة الذي يجب أن يكون تفاعليًا؟»، لكنه ليس قابلية الاستئناف (Qwik) ولا ترطيبًا بتفاعلية دقيقة الحبيبات (Solid)؛ بل ترطيب جزئي لصفحة ثابتة في ما عدا ذلك. وتفرّق وثائق Qwik نفسها صراحةً بين قابلية الاستئناف والترطيب الجزئي لهذا السبب.

كيف يقارنان بالأطر الراسخة؟

ليست الأطر الراسخة سيئة لتحسين محركات البحث افتراضيًا؛ فمع وضع التصيير الصحيح تضع أطرها الشاملة جميعًا المحتوى داخل HTML، وهذا ما تحتاجه برامج الزحف (وتلك هي قصة JavaScript SEO كلها)، وينطبق الأمر نفسه على SolidStart وQwikCity. ما يختلف بين الأعمدة أعلاه هو الآلية وراء تكلفة بدء التشغيل في المتصفح، لا نتيجة مضمونة؛ قِس TBT/INP على مساراتك الفعلية بدل افتراض أن اختيار الإطار يحسم الأمر.

وهناك تحفظ يستحق الصراحة: تتجه React وVue وAngular كلها نحو الإشارات والترطيب الأخف أيضًا (إشارات Angular وReact Server Components ووضع Vapor في Vue). تتغير تفاصيل الإصدارات وخرائط الطريق بسرعة تجعل أي لقطة هنا قديمة؛ راجع الوثائق الحالية لكل إطار قبل الاستشهاد بإمكانات محددة.

التحقق من كل ذلك على مساراتك

لا تتعامل مع سمعة الإطار بوصفها جوابًا لمسار محدد. افحص، لكل مسار:

• رمز الحالة وHTML الأولي — اجلب عنوان URL مباشرةً (لا عبر DOM الذي صيّره المتصفح) وتأكد من وجود محتواك وروابطك وبياناتك الوصفية بالفعل.
• المخرجات المتدفقة، إذا كان وضع التصيير يتدفق — تأكد من وصول المحتوى كاملًا، لا مجرد غلاف مع حالة تحميل.
• البيانات الوصفية والروابط — العنوان والوصف الوصفي وcanonical وأهداف <a href>، إذ لا تدير قابلية الاستئناف ولا التفاعلية دقيقة الحبيبات هذه الأمور نيابةً عنك.
• حجم الحالة المسلسلة (Qwik) — تضخّم الحالة المسلسلة الكبيرة حمولة HTML رغم أنها تتجنب تمهيد الترطيب.
• JavaScript الخاص بالمحمّل/وقت التشغيل والمنفّذ فعليًا في البداية — قِس ما يفعله Qwikloader أو وقت تشغيل Solid عند التحميل، لا ما تدعيه الوثائق فقط.
• الطلبات المسبقة وتلك التي يطلقها التفاعل — راقب لوحة الشبكة لمعرفة ما يُحمّل عند النقر في مقابل ما حُمّل مقدمًا.
• المهام التي تعمل في المتصفح فقط (useVisibleTask$ وما يعادلها) — تأكد من أنها لا تعمل بشغف عند كل تحميل.
• السلوك عند فشل JavaScript أو حجبه — هل يتدهور المسار بأمان إلى شيء قابل للاستخدام أم يتعطل بالكامل؟
• مخرجات ممثلة كما تصيّرها برامج الزحف — استخدم أداة URL Inspection في Search Console أو مصيّرًا مكافئًا، لا View Source وحده، لأن بعض المحتوى لا يظهر إلا بعد التصيير.

هذا هو انضباط التحقق نفسه الذي يحتاجه أي موقع مصيّر بـ JavaScript؛ راجع التصيير لفهم كيفية تعامل مسار Google مع ذلك عمومًا.

إلى أين تنتقل بعد ذلك؟

لكل إطار شرح متعمق مخصص:

• Qwik SEO — قابلية الاستئناف عمليًا، وتوجيه QwikCity وSSR، وضبط البيانات الوصفية، ونمط useDocumentHead، وحدود التحميل الكسول، وكيف تظهر قابلية الاستئناف في CWV الميدانية.
• SolidJS SEO — الإشارات والتفاعلية دقيقة الحبيبات، وSSR والتدفق في SolidStart، ولماذا ليس قابلًا للاستئناف، وإدارة الوسوم الوصفية، وسياق معايير الأداء.

يندرج كلاهما تحت مجموعة JavaScript SEO إلى جانب الأدلة الخاصة بـ React وVue وAngular وNext.js وNuxt وSvelte وAstro. ولجانب المقاييس راجع Core Web Vitals؛ ولكيفية رؤية Google للمحتوى المصيّر راجع التصيير.

ملخص الذكاء الاصطناعي

خلاصة مكثفة للنسخة المتقدمة:

• «الجيل التالي» تسمية تحريرية خاصة بهذه المقالة لـ Qwik وSolidJS، وليست فئة موحّدة؛ فكلاهما يقلل تكلفة تنفيذ JavaScript في المتصفح بآلية مختلفة. يشحن Qwik إصدار v2 تجريبيًا؛ أما وثائق SolidStart فموسومة بأنها تجريبية وآخر تحديث لها 2026-04-28، لذا تعامل مع التفاصيل على أنها مرتبطة بالإصدار.
• Qwik = قابلية الاستئناف، لا انعدام JavaScript. يسلسل التطبيق المستمعين وحدود المكوّنات والحالة داخل HTML على الخادم؛ ثم يستأنف المتصفح بدل إعادة تشغيل تمهيد ترطيب. ويظل نص تمهيد صغير، Qwikloader (نحو 1kb، وتوثّق المصادر أن تنفيذه يستغرق أقل من 5ms على الهاتف)، يعمل عند التحميل؛ فهو يسجّل مستمعًا عامًا ويحمّل شيفرة المعالج (QRLs) تحميلًا كسولًا عند التفاعل. ومن القيود: قد تفشل حدود التسلسل $ وقت التشغيل مع القيم الملتقطة غير المدعومة، وتتحول قيم noSerialize() إلى undefined بعد الاستئناف وتحتاج إلى إعادة تهيئة على العميل، ويُعد useVisibleTask$ مخرجًا متعجلًا يعمل في المتصفح فقط ويضيف تكلفة بدء إذا أُفرط في استخدامه. أما QwikCity فهو طبقة الإطار الشامل والتوجيه المنفصلة.
• SolidJS = تفاعلية دقيقة الحبيبات، وهو ليس قابلية الاستئناف؛ بل يرطّب، ولكن مع قدر أقل لإعادة بنائه (الإشارات + غياب DOM الافتراضي يعنيان تحديثات موجهة إلى DOM لا إعادة تشغيل المكوّن كاملًا). وSolidStart (v1.0، وثائقه تجريبية) هو الإطار الشامل المنفصل: يدعم CSR وSSR (متزامنًا وغير متزامن ومتدفقًا) وSSG بوصفها خيارات تصيير متميزة، ولا يضم افتراضيًا مكتبة توجيه أو بيانات وصفية.
• قابلية الزحف والبيانات الوصفية ورموز الحالة مسائل وضع تصيير وتوجيه، لا ضمانات من الإطار. ينتج وضع CSR في أي من الإطارين الشاملين غلافًا فارغًا مثل أي SPA؛ أما SSR/SSG فيضعان المحتوى داخل HTML. افحص الاستجابة الفعلية لكل مسار بدل الافتراض.
• لا تضمن أي من الآليتين Core Web Vitals أو الترتيب. يمثل تقليل JavaScript عند البدء عاملًا حقيقيًا في INP وTBT، لكن شيفرة التطبيق والجهات الخارجية ووقت استجابة الخادم وظروف الجهاز تظل تحدد النتيجة المقاسة؛ تحقّق ميدانيًا (CrUX/Search Console)، لا في المختبر وحده.
• مقارنةً بـ React/Vue/Angular: مع وضع التصيير الصحيح، تنفذ الأطر الراسخة SSR جيدًا لبرامج الزحف أيضًا؛ والفرق الآلي هو تكلفة JavaScript عند البدء، بينما تتبنى الأطر السائدة أفكارًا مشابهة (الإشارات وRSC ووضع Vapor). راجع الوثائق الحالية لكل إطار قبل ذكر تفاصيل بعينها، لأن هذه الأمور تتغير بسرعة.
• جزر Astro آلية ثالثة مرتبطة ولكن متميزة — HTML من الخادم افتراضيًا مع جزر عميلة اختيارية، وليست قابلية الاستئناف ولا ترطيبًا بتفاعلية دقيقة الحبيبات.

الوثائق الرسمية

وثائق المصدر الأول من الأطر نفسها.

Qwik (حاليًا v2 تجريبي — تحقق من الإصدار قبل الاستشهاد بإعدادات افتراضية محددة)

• وثائق Qwik — الصفحة الرئيسية للوثائق الرسمية.
• فكّر بمنطق Qwik / قابل للاستئناف — الشرح المرجعي لقابلية الاستئناف مقابل الترطيب، بما في ذلك تسلسل المستمعين والشجرة والحالة.
• Qwikloader — نص التمهيد الذي يعمل فعلًا عند التحميل: تسجيل المستمع العام، وحل QRL، وتحميل المعالج تحميلًا كسولًا.
• التسلسل وحدود التسلسل — حدود $ وما يفشل وقت التشغيل عندما لا تكون قيمة ملتقطة قابلة للتسلسل.
• الحالة / noSerialize — سبب تحول القيم غير القابلة للتسلسل إلى undefined بعد الاستئناف.
• المهام ودورة الحياة — الفرق بين useTask$ وuseVisibleTask$ وسلوك الحجب/الظهور.
• نظرة عامة على QwikCity — الإطار الشامل: التوجيه والمحمّلات والإجراءات ونقاط النهاية.
• useDocumentHead / DocumentHead — إدارة العنوان والوسوم الوصفية لتحسين محركات البحث.

SolidJS (وثائق SolidStart موسومة بأنها تجريبية، وآخر تحديث لها 2026-04-28 — تحقق قبل الاستشهاد بإعدادات افتراضية محددة)

• وثائق SolidJS — الصفحة الرئيسية للوثائق الرسمية.
• التفاعلية / الإشارات — التفاعلية دقيقة الحبيبات والإشارات والمشتركون.
• نظرة عامة على SolidStart — الإطار الشامل: أوضاع التصيير وعدم تضمين مكتبة توجيه/بيانات وصفية افتراضيًا.
• أوضاع التصيير في SolidStart — CSR وSSR (متزامن/غير متزامن/متدفق) وSSG بوصفها خيارات متميزة.

حد المقارنة

• Astro — بنية الجزر — HTML من الخادم مع جزر عميلة اختيارية، وهي آلية ثالثة تختلف عن قابلية الاستئناف وعن ترطيب Solid.

Google Search / معايير الأداء / خلفية

• فهم أساسيات JavaScript SEO — صياغة Google نفسها للجلب والتصيير والفهرسة بوصفها خطوات منفصلة.
• js-framework-benchmark — معيار الأداء واسع الاستشهاد بين الأطر؛ راجع نتائجه الحالية بدل رقم ثابت هنا.

اقتباسات من المصدر

صياغات معلنة من فرق الأطر. تحقق من الألفاظ في الوثائق المباشرة قبل اعتبار أي اقتباس منقول نهائيًا.

Qwik — قابلية الاستئناف

• يصف Qwik نفسه بأنه الإطار الذي يقدم “instant-on applications” (ترجمة) «تطبيقات تعمل فورًا» عبر قابلية الاستئناف، في مقابل الترطيب: تتيح قابلية الاستئناف للتطبيق “continue execution in the browser from where the server left off” (ترجمة) «متابعة التنفيذ في المتصفح من حيث توقف الخادم»، فلا حاجة إلى “download and execute the application” (ترجمة) «تنزيل التطبيق وتنفيذه» لجعل الصفحة تفاعلية. مفهوم قابلية الاستئناف
• يقدّم Qwik نفسه بوصفه “HTML-first” (ترجمة) «HTML أولًا» — فالصفحة قابلة للاستخدام فورًا، ويُجلب JavaScript تحميلًا كسولًا “only when needed” (ترجمة) «عند الحاجة فقط»، حتى مستوى التفاعلات الفردية بدل حزمة بدء كبيرة واحدة. فكّر بمنطق Qwik

SolidJS — التفاعلية دقيقة الحبيبات

• يصف SolidJS نموذجه بأنه تفاعلية دقيقة الحبيبات مع عدم وجود DOM افتراضي: فالمكوّنات “run once” (ترجمة) «تعمل مرة واحدة»، وتحدّث الإشارات “only the parts of the DOM that depend on them” (ترجمة) «أجزاء DOM التي تعتمد عليها فقط»؛ مقدمة إلى التفاعلية
• يُقدَّم SolidStart بوصفه إطارًا “renders on the server” (ترجمة) «يصيّر على الخادم» ويرطّب على العميل؛ وتعرض الوثائق ميزة Solid باعتبارها كفاءة ذلك الترطيب لا غيابه. SolidStart

قائمة لاختيار إطار من الجيل التالي أو تدقيقه

قبل اعتماد Qwik أو SolidJS لتحسين محركات البحث (أو أثناء تدقيقهما):

• تأكدت من وضع التصيير المضبوط فعليًا في الإطار الشامل (SolidStart: ‏CSR مقابل SSR مقابل SSG؛ وQwikCity: خادم مقابل ثابت)، ولم تفترض أنه يستخدم التصيير على الخادم افتراضيًا.
• تعرض View Source (أو عملية جلب مباشرة لعنوان URL) محتواك الحقيقي وروابط <a href> داخل HTML الخام (لا غلاف <div id="app"> فارغًا).
• تؤكد URL Inspection (Search Console) تطابق HTML المصيّر: المحتوى موجود، ولا يوجد noindex يحقنه JavaScript.
• تُضبط العناوين والوسوم الوصفية عبر واجهة head الخاصة بالإطار (useDocumentHead/DocumentHead لـ Qwik) أو مكتبة توجيه/بيانات وصفية مضافة صراحةً إلى SolidStart (فهي ليست مضمّنة افتراضيًا)، لا على العميل فقط.
• قست Core Web Vitals في الميدان (CrUX / Search Console)، لا في المختبر فقط؛ فلا تفترض أن الآلية تضمن الرقم.
• يستخدم التوجيه تنقلات حقيقية / History API كي يكون كل مسار عنوان URL قابلًا للزحف وله HTML خاص به مصيّر على الخادم.
• لم تصف SolidJS أو تضبطه بوصفه «قابلًا للاستئناف»؛ فهو يرطّب، وQwik وحده يستأنف.
• لم تصف Qwik بأنه «بلا JavaScript»؛ فما يزال Qwikloader يعمل عند التحميل؛ افحص ما ينفذه هو وأي استدعاء لـ useVisibleTask$ فعليًا.
• اختُبرت القيم الملتقطة عند حدود $ في Qwik للتأكد من قابليتها للتسلسل، وأي قيم noSerialize() لها إعادة تهيئة صريحة على العميل.
• JavaScript وCSS غير محجوبين في robots.txt (ما يزال ذلك مهمًا حتى مع القليل من JavaScript؛ إذ يجب أن يجلب Google ما هو موجود منه).
• تفهم مقايضة المنظومة: مجتمعات أصغر وتكاملات جاهزة أقل من React/Vue/Angular، فضلًا عن أن وثائق الإطارين موسومة حاليًا بأنها تجريبية.

أطر لتقييم JavaScript من الجيل التالي

افصل قابلية الزحف عن تكلفة وقت التشغيل

قيّم التنفيذ على محورين مستقلين:

1. اكتمال المستند: هل يعيد كل مسار عام محتواه وروابطه وبياناته الوصفية داخل HTML؟ يستطيع QwikCity أو SolidStart في وضع تصيير SSR/SSG تحقيق ذلك، لكن وضع CSR في أي منهما لا يحققه.
2. تكلفة التفعيل: كم من JavaScript يجب أن يعمل قبل أن يعمل التفاعل؟ يستأنف Qwik الحالة المسلسلة (لكن يظل يشغّل تمهيد Qwikloader)، بينما يرطّب Solid بتفاعلية دقيقة الحبيبات.

لا يصلح وقت تشغيل سريع على العميل مستندًا فارغًا، ولا يضمن HTML المكتمل استجابة جيدة. قِس الاثنين لكل مسار على الإصدار المنشور فعليًا، لا اعتمادًا على سمعة الإطار.

اختبار الآلية

استخدم لغة دقيقة عند مقارنة البنى:

• Qwik: قابلية الاستئناف — لا تمهيد ترطيب كامل، لكن Qwikloader (نص صغير ثابت الحجم تقريبًا) يظل يعمل عند التحميل، وتُحمّل شيفرة التطبيق حول حدود التفاعل.
• SolidJS: إشارات، بلا DOM افتراضي، وتحديثات موجهة؛ يظل SolidStart يرطّب المخرجات المصيّرة على الخادم — فهو ليس قابلية الاستئناف، كما أن وضع التصيير (CSR/SSR/SSG) اختيار منفصل عن نموذج التفاعلية.
• الأطر الشاملة الراسخة: تستخدم الترطيب عادةً، مع خيارات مختلفة لمكوّنات الخادم أو التدفق أو التفعيل الجزئي تتقارب مع بعض الأفكار نفسها.

اختر بناءً على نموذج التسليم الفعلي والمنظومة وقيود الفريق، لا على وصف عام مثل «بلا JavaScript» أو «الزحف مضمون».

أطر الجيل التالي — ورقة غش

الآليتان (لا تخلط بينهما)

ما الذي يعتمد عليه كل جانب من تحسين محركات البحث (وليس أمرًا مسلّمًا به)

خرافات شائعة ينبغي تصحيحها

• ❌ «SolidJS قابل للاستئناف.» ← إنه يرطّب؛ Qwik وحده يستأنف.
• ❌ «Qwik لا يشغّل أي JavaScript.» ← ما يزال Qwikloader يعمل عند التحميل ويحمّل شيفرة المعالج تحميلًا كسولًا عند التفاعل؛ صغير وثابت الحجم، لا غائب.
• ❌ «تصلح أطر الجيل التالي مشكلات زحف لا يستطيع React إصلاحها.» ← مع وضع التصيير الصحيح ينفذ React مع Next.js ‏SSR جيدًا أيضًا؛ الفرق الآلي هو تكلفة JavaScript عند البدء، لا قابلية الزحف.
• ❌ «يضمن QwikCity/SolidStart ‏HTML غنيًا بالمحتوى.» ← لا يصح ذلك إلا في وضع تصيير SSR/SSG؛ فكلاهما يدعم أيضًا التصيير الخالص من جانب العميل.

اختبر نفسك: أطر JavaScript من الجيل التالي

خمسة أسئلة سريعة عن قابلية الاستئناف والتفاعلية دقيقة الحبيبات وحجة تحسين محركات البحث لأطر الجيل التالي. اختر إجابة لكل سؤال ثم تحقق.

موارد تستحق وقتك

كتاباتي ذات الصلة

• JavaScript SEO: دليل شامل — دليلي الكامل للتصيير وتكافؤ DOM وفهرسة المحتوى المبني بـ JavaScript؛ وهو الأساس الذي تُبنى عليه هذه الأدلة الخاصة بالأطر.
• Core Web Vitals: دليل كامل — ما الذي تقيسه INP وLCP وCLS فعليًا وكيف تؤثر في تحسين محركات البحث؛ وهي المقاييس التي تحسّن أطر الجيل التالي أداءها.
• دليل المبتدئ إلى تحسين محركات البحث التقني — موضع اختيار الإطار والتصيير في الصورة الأكبر.

من أنحاء المجال

• Qwik — قابلية الاستئناف مقابل الترطيب — أوضح شرح من مصدر أول لسبب اختلاف قابلية الاستئناف عن الترطيب.
• SolidJS — مقدمة إلى التفاعلية — الإشارات والتفاعلية دقيقة الحبيبات مباشرةً من الوثائق.
• web.dev — التصيير على الويب — الصياغة المرجعية لفريق Chrome حول SSR والترطيب ومقايضاتهما (السياق الذي تستجيب له أطر الجيل التالي).
• js-framework-benchmark (النتائج الحالية) — معيار الأداء طويل الأمد الذي يحتل فيه SolidJS موقعًا قريبًا من القمة ومتقدمًا على React في أعباء العمل كثيفة التحديث.
• تكلفة JavaScript (Addy Osmani) — لماذا يمثل شحن JavaScript وتنفيذه عنق زجاجة في الأداء تستهدفه هذه الأطر.
• r/TechSEO — مجتمع لتصحيح مشكلات تصيير الأطر وفهرستها.

سجل التغييرات