Progressive Enhancement و مواقع Zero-JS في 2026
قمت بشحن موقع تسويقي في الشهر الماضي يسجل 100 في جميع فئات Lighthouse. إجمالي JavaScript المرسل إلى العميل: صفر بايت. ليس "تقريبًا صفر" أو "الحد الأدنى" -- حرفيًا بلا شيء. النماذج تعمل، الملاحة تعمل، هناك تبديل الوضع الداكن، وانتقالات الصفحة تشعر بأنها سريعة. قبل خمس سنوات كان هذا يتطلب تنازلات جادة. في 2026، لقد اتسعت المنصة إلى نقطة حيث zero-JS ليس قيدًا -- إنه خيار معماري شرعي.
لكن إليك الشيء الذي تخطئ فيه معظم المقالات حول progressive enhancement: إنها ليست عن أن تكون نقيًا أو تكره JavaScript. إنها عن اتخاذ قرارات مقصودة حول ما يعمل حيث. دعني أرشدك عبر كيفية تعاملنا مع هذا في Social Animal، وما الذي تغير في 2026 الذي يجعل zero-JS قابلة للتطبيق في مشاريع أكثر من أي وقت مضى، ومتى يجب عليك بالتأكيد الوصول إلى كود من جانب العميل.
جدول المحتويات
- ما يعنيه Progressive Enhancement بالفعل في 2026
- المنصة غيرت كل شيء
- أنماط CSS فقط التي تحل محل JavaScript
- التفاعلية الأولى HTML
- أطر العمل من جانب الخادم التي تشحن Zero JS
- متى يكون Zero JavaScript الخيار الخاطئ
- مقاييس الأداء: JS مقابل Zero-JS
- بناء استراتيجية Progressive Enhancement
- العمارة في العالم الحقيقي لمواقع Zero-JS
- الأسئلة الشائعة

ما يعنيه Progressive Enhancement بالفعل في 2026
كانت progressive enhancement موجودة منذ أوائل 2000s، لكن معظم المطورين الذين أتحدث إليهم يسيئون فهمها. يعتقدون أنها تعني "بناء نسخة HTML سيئة أولاً، ثم اجعلها جيدة مع JavaScript." هذا معكوس.
Progressive enhancement تعني أن تجربتك الأساسية تعمل. نقطة. HTML هو أساسك. CSS تضيف الطبقة البصرية. JavaScript -- إذا كنت بحاجة إليها -- تضيف التفاعلية على الأعلى. كل طبقة إضافية. إذا فشلت أي طبقة، فإن الطبقات أدناه لا تزال تعمل.
في 2026، أصبحت هذه الفلسفة أكثر عملية من أي وقت مضى لأن القدرات الأساسية لـ HTML و CSS قد توسعت بشكل كبير. الأشياء التي تطلبت JavaScript قبل خمس سنوات لديها الآن حلول منصة أصلية:
- الأكورديونات وأدوات الكشف →
<details>و<summary> - الوسائط والحوارات → عنصر
<dialog> - التحقق من النماذج → Constraint Validation API
- الانتقال السلس →
scroll-behavior: smooth - الوضع الداكن →
@media (prefers-color-scheme)مع خدع منتقي:has() - دوارات الصور → CSS scroll snap مع
scrollbar-width - القوائم المنبثقة والتلميحات → Popover API
- تحديد الموضع الراسي → CSS Anchor Positioning
- انتقالات العرض → View Transitions API (المستوى 2 للمستندات المتقاطعة)
منصة الويب في 2026 ليست منصة الويب في 2020. لقد شهدنا توسعًا ضخمًا في ما هو ممكن بدون scripting.
المنصة غيرت كل شيء
Popover API
حققت Popover API دعمًا متقاطعًا كاملاً في 2024 وبحلول الآن فهي جاهزة للإنتاج في كل مكان مهم. قبل هذا، كل تلميح، قائمة منسدلة، وإخطار toast احتاج إلى JavaScript. الآن:
<button popovertarget="my-menu">Menu</button>
<nav popover id="my-menu">
<a href="/about">About</a>
<a href="/work">Work</a>
<a href="/contact">Contact</a>
</nav>
هذا كل شيء. انقر على الزر، يظهر popover. انقر بالخارج، يختفي. اضغط Escape، يختفي. إدارة التركيز يتم التعامل معها. يمكن الوصول إليها افتراضيًا. صفر JavaScript.
CSS Anchor Positioning
هذا هو الذي فتح الأشياء حقًا. تحديد موضع تلميح بالنسبة لمحفزه اعتاد أن يتطلب JavaScript لقياس مواضع DOM. CSS Anchor Positioning (الخط الأساسي في 2025، مستقر تمامًا الآن) يتعامل معها بشكل إعلاني:
.trigger {
anchor-name: --my-trigger;
}
.tooltip {
position: fixed;
position-anchor: --my-trigger;
top: anchor(bottom);
left: anchor(center);
translate: -50% 8px;
}
قم بدمج هذا مع Popover API وحصلت على تلميحات مواضع بالكامل وقابلة للوصول بدون كود من جانب العميل.
انتقالات العرض عبر المستندات
View Transitions Level 2 هي التي تجعل مواقع zero-JS تشعر مثل SPAs. تضيف CSS at-rule وفجأة الملاحة بين الصفحات لها انتقالات متحركة سلسة:
@view-transition {
navigation: auto;
}
::view-transition-old(root) {
animation: fade-out 0.2s ease;
}
::view-transition-new(root) {
animation: fade-in 0.2s ease;
}
Chrome و Edge و Safari تدعم هذا الآن. من المتوقع أن يدعمها Firefox لاحقًا في العام. هذه الميزة الواحدة تزيل أحد أكبر الأسباب التي جعلت الفرق تختار SPAs -- الأداء المتصورة من خلال الانتقالات المتحركة.
منتقي `:has()`
mنتقي :has() (يسمى أحيانًا "منتقي الأب") كان مستقرًا منذ 2024 وهو تحويلي حقيقي للتفاعلية CSS فقط:
/* تبديل الوضع الداكن بدون JS */
html:has(#dark-mode:checked) {
color-scheme: dark;
--bg: #1a1a2e;
--text: #eee;
}
مع صندوق مخفي و <label>، لديك toggle وضع داكن عامل. لا JavaScript. تستمر الحالة خلال الجلسة ويمكنك حتى مزامنتها إلى localStorage عبر سكريبت تحسين صغير إذا كنت تريد الاستمرارية عبر الزيارات.
أنماط CSS فقط التي تحل محل JavaScript
دعني أصنف الأنماط التي نستخدمها بانتظام. لا أتحدث عن فن CSS أو عروض توضيحية جديدة -- هذه أنماط إنتاجية نشحنها إلى عملاء حقيقيين.
| النمط | النهج القديم (JS) | نهج 2026 (CSS/HTML) | دعم المتصفح |
|---|---|---|---|
| قوائم منسدلة | مستمعو الأحداث، فخاخ التركيز | Popover API + :has() |
95%+ |
| الأكورديونات | فئات التبديل، إدارة ARIA | <details> + ::details-content |
96%+ |
| الوسائط | مكتبات فخ التركيز، قفل الانتقال | <dialog> + ::backdrop |
97%+ |
| علامات التبويب | إظهار/إخفاء اللوحات، علامات التبويب ARIA | أزرار الراديو + :has() + scroll-snap |
95%+ |
| دوارات الصور | Swiper.js, Flickity | scroll-snap + scroll-timeline |
93%+ |
| التلميحات | Popper.js, Floating UI | Popover API + Anchor Positioning | 90%+ |
| التحقق من النماذج | منطق التحقق المخصص | Constraint Validation + :user-valid |
95%+ |
| رسوم متحركة الانتقال | Intersection Observer, GSAP | animation-timeline: scroll() |
88%+ |
| تبديل المظهر | localStorage + معالجة DOM | صندوق اختيار + :has() + color-scheme |
96%+ |
| انتقالات الصفحة | توجيه من جانب العميل | انتقالات العرض عبر المستندات | 85%+ |
هذا الجدول يمثل ربما 80٪ من الأنماط التفاعلية على موقع تسويقي نموذجي أو منصة محتوى. كل شيء قابل للتحقيق بدون شحن بايت واحد من JavaScript.
نمط علامات التبويب
إليك واحد أنا معجب به بشكل خاص. علامات التبويب CSS فقط باستخدام أزرار الراديو:
<div class="tabs">
<input type="radio" name="tab" id="tab1" checked>
<label for="tab1">Features</label>
<input type="radio" name="tab" id="tab2">
<label for="tab2">Pricing</label>
<input type="radio" name="tab" id="tab3">
<label for="tab3">FAQ</label>
<div class="panels">
<div class="panel" id="panel1">Features content...</div>
<div class="panel" id="panel2">Pricing content...</div>
<div class="panel" id="panel3">FAQ content...</div>
</div>
</div>
.tabs:has(#tab1:checked) .panels { --active: 0; }
.tabs:has(#tab2:checked) .panels { --active: 1; }
.tabs:has(#tab3:checked) .panels { --active: 2; }
.panels {
display: flex;
overflow: hidden;
translate: calc(var(--active) * -100%) 0;
transition: translate 0.3s ease;
}
.panel {
min-width: 100%;
}
تبديل علامات تبويب سلس ومتحرك بدون JavaScript. أضف role="tablist" وسمات ARIA المناسبة للإمكانية الوصولية، وحصلت على مكون جاهز للإنتاج.

التفاعلية الأولى HTML
بعيدًا عن CSS، أصبح HTML نفسه أكثر قدرة. دعني أسلط الضوء على الأنماط التي نستخدمها.
عنصر `
أعلم أن <dialog> موجودة منذ فترة، لكن العديد من الفرق لا تزال تصل إلى مكتبة modal. لا تفعل. يتعامل dialog الأصلي مع فخاخ التركيز، قفل الانتقال، Escape للإغلاق، وزائف ::backdrop للتراكبات.
الالتقاط الوحيد: تحتاج إلى قليل جدًا من JavaScript لفتح dialog modal (استدعاء .showModal()). لكن للتحسين التدريجي، يمكنك جعل المحفز رابطًا إلى صفحة منفصلة، ثم تحسن مع JS إذا كان متاحًا:
<a href="/contact" class="js-dialog-trigger" data-dialog="contact-form">
Get in touch
</a>
<dialog id="contact-form">
<form method="dialog">
<!-- form fields -->
<button type="submit">Send</button>
</form>
</dialog>
بدون JavaScript: ينتقل المستخدم إلى /contact. مع JavaScript: يفتح dialog بشكل مضمن. كلاهما يعمل. هذا هو progressive enhancement.
النماذج بدون JavaScript
النماذج هي أكبر فائدة لنهج zero-JS. تقدم نماذج HTML أصلية البيانات إلى الخوادم. هذا ما تم تصميمها للقيام به. مع أطر عمل الخادم الحديثة، لا تحتاج إلى استدعاءات e.preventDefault() و fetch():
<form action="/api/contact" method="POST">
<input type="email" name="email" required>
<textarea name="message" required minlength="10"></textarea>
<button type="submit">Send</button>
</form>
فئات الكذب :user-valid و :user-invalid (الآن في الخط الأساسي) تتيح لك تصميم حالات التحقق بدون JS، لكن فقط بعد تفاعل المستخدم -- لا مزيد من الحدود الحمراء عند تحميل الصفحة.
input:user-invalid {
border-color: var(--error);
outline-color: var(--error);
}
input:user-valid {
border-color: var(--success);
}
أطر العمل من جانب الخادم التي تشحن Zero JS
اختيار الإطار الصحيح مهم بشكل كبير لـ progressive enhancement. إليك كيف يقف اللاعبون الرئيسيون في 2026.
Astro
يبقى Astro معيار الذهب لـ zero-JS output. يشحن HTML و CSS افتراضيًا، وتختار JavaScript لكل مكون مع توجيهات client:. نستخدمه بكثرة لمواقع التسويق والتوثيق والمنصات الغنية بالمحتوى.
---
// هذا المكون يشحن صفر JavaScript
const posts = await fetch('https://api.example.com/posts').then(r => r.json());
---
<ul>
{posts.map(post => <li><a href={post.url}>{post.title}</a></li>)}
</ul>
أضاف Astro 5 (مستقر منذ أوائل 2025) جزائر الخادم وتحسين واجهات برمجة تطبيقات طبقة المحتوى. النموذج الذهني بسيط: كل شيء يتم تقديمه من قبل الخادم ما لم تقول صراحة خلاف ذلك.
Eleventy (11ty)
يستمر Eleventy 3.0 في أن يكون ممتازًا لمواقع zero-JS. إنه مولد موقع ثابت بحت -- بدون آراء حول JavaScript من جانب العميل على الإطلاق. إذا كنت تريده، فأنت تضيفه يدويًا. وجدنا أنها مثالية للمواقع الأصغر والمدونات حيث تهم بساطة وقت الإنشاء.
Next.js مع مكونات الخادم
Next.js مثيرة للاهتمام هنا. مكونات الخادم (الافتراضي في App Router) لا تشحن JavaScript إلى العميل. لكن وقت تشغيل Next.js نفسه يضيف حمولة JS أساسية للترطيب والتوجيه والمعاينة المسبقة. لا يمكنك الوصول إلى zero-JS الحقيقي مع Next.js، لكن يمكنك الاقتراب بشكل ملحوظ للتطبيقات التفاعلية.
SvelteKit
يتيح SvelteKit لك تعطيل JavaScript لكل صفحة مع export const csr = false. الإخراج هو HTML/CSS بحتة. إنه توازن رائع -- تحصل على خبرة المطورين في مكونات Svelte لكن يمكنك تعطيل عرض من جانب العميل بشكل انتقائي.
| الإطار | إخراج JS الافتراضي | Zero-JS ممكن؟ | الأفضل لـ |
|---|---|---|---|
| Astro 5 | 0 KB | نعم (افتراضي) | مواقع المحتوى والتسويق |
| Eleventy 3 | 0 KB | نعم (افتراضي) | المدونات والمستندات والمواقع البسيطة |
| Next.js 15 | 85-100 KB | لا (وقت التشغيل مطلوب) | تطبيقات الويب والمحتوى الديناميكي |
| SvelteKit 2 | 15-25 KB | نعم (اختيار إلغاء لكل صفحة) | المواقع الهجينة |
| Fresh (Deno) | 0 KB | نعم (عمارة الجزيرة) | مشاريع قائمة على Deno |
| Enhance | 0 KB | نعم (HTML-first) | مواقع مكونات الويب |
متى يكون Zero JavaScript الخيار الخاطئ
سأكون أقصر نفسي إذا تحدثت فقط عن متى يعمل zero-JS. إليك متى لا يعمل:
التعاون في الوقت الفعلي. إذا كنت تبني شيئًا مثل Figma أو Google Docs أو تطبيق دردشة، فأنت بحاجة إلى WebSockets وإدارة حالة من جانب العميل. لا توجد طريقة حول هذا.
تصور البيانات المعقد. D3 أو Observable Plot أو deck.gl للخرائط -- هذه تحتاج JavaScript. يمكنك تقديم الرسوم البيانية الثابتة كـ SVG من جانب الخادم (ونحن نفعل ذلك)، لكن أي شيء تفاعلي يحتاج إلى كود العميل.
محررات النصوص الغنية. ProseMirror أو TipTap أو Lexical -- هذه تطبيقات من جانب العميل بطبيعتها. التحسين التدريجي هنا يعني توفير بديل <textarea>، وهو معقول جدًا.
البحث من جانب العميل. إذا كنت تريد بحثًا فوريًا بحيث أنت تكتب بدون الضغط على الخادم في كل ضغطة مفاتيح، فأنت بحاجة إلى فهارس بحث من جانب العميل (Pagefind أو Lunr أو Fuse.js). Pagefind يستحق الإشارة على وجه التحديد -- إنه فهرس بحث وقت الإنشاء الذي يحمل فقط ~5 KB في البداية.
تدفقات المصادقة. تعمل عمليات إعادة توجيه OAuth بدون JS، لكن تحديث الرمز وإدارة الجلسة والمسارات المحمية من جانب العميل عادة ما تحتاج إلى بعض النصوص.
مشغلات الفيديو/الصوت. مشغلات مخصصة تحتاج JavaScript. لكن عناصر <video> و <audio> مع عناصر تحكم أصلية تعمل بشكل مثالي بدونها.
النمط الذي أوصي به: ابدأ بـ zero-JS وأضف JavaScript جراحيًا حيث تتطلب تجربة المستخدم ذلك حقًا. هذا بالضبط ما تمكنه عمارة جزيرة Astro -- 95٪ من الصفحة هي HTML ثابت، والأداة التفاعلية الوحيدة يتم ترطيبها.
مقاييس الأداء: JS مقابل Zero-JS
كنا نتتبع الأداء عبر مشاريع عملائنا. إليك أرقام حقيقية من مواقع الإنتاج التي بنيناها في 2025-2026.
| المقياس | React SPA النموذجي | Next.js (App Router) | Astro (Zero-JS) | التحسن |
|---|---|---|---|---|
| First Contentful Paint | 1.8s | 0.9s | 0.4s | أسرع 78٪ |
| Largest Contentful Paint | 2.5s | 1.3s | 0.6s | أسرع 76٪ |
| Time to Interactive | 3.2s | 1.8s | 0.4s | أسرع 87٪ |
| Total Blocking Time | 450ms | 180ms | 0ms | تقليل 100٪ |
| JS Transfer Size | 280 KB | 105 KB | 0 KB | تقليل 100٪ |
| Lighthouse Performance | 65-75 | 85-95 | 100 | -- |
| Core Web Vitals Pass Rate | 55٪ | 82٪ | 99٪ | -- |
تهم هذه الأرقام لنتائج الأعمال الحقيقية. كان Google شفافًا بشكل متزايد حول تأثير CWV على تصنيفات البحث. وجدت دراسة Searchmetrics 2025 أن المواقع التي تمرر جميع Core Web Vitals كانت بها 24٪ من متوسط مواضع التصنيف أعلى من تلك الفاشلة. وهذا الفجوة تتسع.
بالنسبة لعملائنا، رأينا تحسينات قابلة للقياس: رأت علامة تجارية للتجارة الإلكترونية زيادة بنسبة 15٪ في حركة البحث العضوي بعد الهجرة من React SPA إلى متجر Astro مع ترطيب انتقائي. ظلت عمارة headless CMS الخاصة بهم كما هي -- لقد غيرنا فقط كيفية استهلاك الواجهة الأمامية للمحتوى.
بناء استراتيجية Progressive Enhancement
إليك دليل العمل العملي الذي نتبعه:
الخطوة 1: قم بتدقيق JavaScript الخاص بك
قبل بناء أي شيء جديد، انظر إلى JavaScript الذي تشحنه حاليًا واسأل: هل يحتاج هذا إلى الجري على العميل؟
# طريقة سريعة للتحقق من استخدام JS في Chrome DevTools
# Coverage tab → Reload → انظر إلى مقدار JS الذي يعمل بالفعل
نجد بانتظام أن 40-60٪ من JavaScript المشحون لا ينفذ أبدًا عند التحميل الأول. إنها رمز ميت أو polyfills غير مستخدمة أو ميزات لم يتم تشغيلها.
الخطوة 2: تصنيف التفاعلية الخاصة بك
ضع كل ميزة تفاعلية في أحد الدلاء الثلاثة:
- منصة أصلية -- يمكن القيام به مع HTML/CSS وحدها (استخدم المنصة)
- تحسين -- يعمل بدون JS، أفضل معها (progressive enhancement)
- يتطلب JS -- مستحيل حقًا بدون كود من جانب العميل (شحنه)
كن صادقًا مع نفسك. تنتهي معظم الأشياء في الدلو 1 أو 2.
الخطوة 3: اختر الإطار الصحيح
إذا كنت تبني موقع محتوى أو توثيق أو صفحات تسويق أو مدونة -- استهدف Astro أو Eleventy. لا تختر Next.js لموقع تسويق فقط لأن فريقك يعرف React. عدم التطابق المعماري يكلفك الأداء.
إذا كنت تبني تطبيقًا مع تفاعل من جانب العميل كبير، فإن Next.js أو SvelteKit مع عرض انتقائي من جانب الخادم منطقي أكثر. استخدم مكونات الخادم حيث يكون ممكنًا ومكونات العميل فقط حيث لزم الأمر.
نساعد الفرق على اتخاذ هذه القرارات بالضبط -- إذا كنت تريد مناقشة موقفك المحدد، فلا تتردد في الاتصال بنا.
الخطوة 4: اختبر بدون JavaScript
هذه هي الخطوة التي يتخطاها الجميع. عطل JavaScript في متصفحك وانتقل إلى موقعك. هل يعمل؟ هل يمكن للمستخدمين:
- قراءة المحتوى؟ ✓
- الملاحة بين الصفحات؟ ✓
- إرسال النماذج؟ ✓
- الوصول إلى المعلومات الحرجة؟ ✓
إذا لم يكن كذلك، فإن استراتيجية التحسين الخاصة بك بها ثقوب.
العمارة في العالم الحقيقي لمواقع Zero-JS
دعني أشارك عمارة ملموسة استخدمناها في عدة مشاريع عميل:
┌─────────────────────────────────────────┐
│ CDN (Cloudflare) │
│ Static HTML/CSS assets │
├─────────────────────────────────────────┤
│ Astro SSG / SSR Layer │
│ Fetches content at build/request │
├─────────────────────────────────────────┤
│ Headless CMS │
│ (Sanity / Storyblok / Payload) │
├─────────────────────────────────────────┤
│ Form Handler Service │
│ (Cloudflare Workers / Resend) │
└─────────────────────────────────────────┘
يعيش المحتوى في headless CMS. يسحب Astro المحتوى في وقت الإنشاء (أو وقت الطلب للمحتوى المتحدث بتكرار). الإخراج هو HTML و CSS بحتة، منتشرة في حافة CDN. تنبثق النماذج إلى دالة بدون خادم تتعامل مع التحقق والتسليم البريدي.
لدى الواجهة الأمامية بأكملها صفر JavaScript. يعطي CMS محررو المحتوى تجربة رائعة. تعمل النماذج بدون كود من جانب العميل. انتقالات الصفحة تستخدم View Transitions عبر المستندات. إنها سريعة وسهلة الوصول ومرنة.
للمواقع التي تحتاج إلى تفاعل انتقائي -- قل، محرر منتج على صفحة واحدة -- نستخدم عمارة جزيرة Astro لترطيب هذا المكون فقط. يبقى باقي الموقع ثابتًا.
هذا هو نوع العمارة التي نبنيها بانتظام. إذا كنت فضوليًا بشأن التسعير لهذا النهج، فاطلع على صفحة التسعير الخاصة بنا -- عادة ما تكون مواقع zero-JS أسرع في البناء وأرخص في الاستضافة.
الأسئلة الشائعة
هل progressive enhancement لا يزال ذا صلة في 2026؟
أكثر صلة من أي وقت مضى. مع 95٪+ دعم المتصفح لميزات مثل Popover API و CSS :has() و View Transitions و <dialog>، يمكن لمنصة الويب التعامل مع التفاعلية التي تطلبت JavaScript سابقًا. Progressive enhancement ليست فلسفة من الماضي -- إنها استراتيجية هندسية عملية تؤدي إلى مواقع أسرع وأكثر مرونة وأكثر قابلية للوصول.
هل يمكنك بناء موقع ويب كامل بدون JavaScript؟ بالتأكيد. يمكن بناء مواقع التسويق والمدونات والتوثيق والمحافظ وحتى متاجر التجارة الإلكترونية بدون JavaScript من جانب العميل. تنبثق النماذج بشكل أصلي، والملاحة تستخدم روابط قياسية (مع View Transitions للبريق)، والمكونات التفاعلية مثل الأكورديونات والوسائط والتلميحات لديها جميعها حلول أصلية HTML/CSS. المواقع التي لا يمكنك بناؤها بدون JS هي تطبيقات الوقت الفعلي وأدوات تحرير النصوص الغنية وتصورات البيانات المعقدة.
كيف يؤثر zero JavaScript على SEO؟ إيجابي، في معظم الحالات. يمكن لمحركات البحث فهرسة محتوى HTML على الفور بدون انتظار تنفيذ JavaScript. درجات Core Web Vitals تتحسن بشكل كبير -- خاصة Total Blocking Time، الذي ينخفض إلى صفر. تكافئ أنظمة تصنيف Google الصفحات السريعة والسهلة الوصول، وتحقق مواقع zero-JS باستمرار درجات Lighthouse أعلى ومعدلات CWV أفضل.
ما أفضل إطار لمواقع zero-JavaScript في 2026؟ Astro هو الخيار الأقوى لمعظم مشاريع zero-JS. يخرج zero JavaScript افتراضيًا ويتيح لك إضافة التفاعلية من جانب العميل لكل مكون عند الحاجة. Eleventy خيار ممتاز آخر للمواقع الأبسط. كلاهما يحتوي على أنظمة بيئية ناضجة وتوثيق جيد ومجتمعات نشطة. يعتمد الاختيار بينهما عادة على ما إذا كنت تريد تأليف قائم على المكونات (Astro) أو بساطة قائمة على القالب (Eleventy).
هل مكونات التفاعل CSS فقط تعمل للإمكانية الوصولية؟
عناصر HTML الأصلية مثل <details> و <dialog> و Popover API يمكن الوصول إليها افتراضيًا -- فهي تتعامل مع إدارة التركيز والملاحة بلوحة المفاتيح ودلالات ARIA تلقائيًا. تحتاج الأنماط القائمة على CSS فقط إلى مزيد من العناية: يجب أن تضيف أدوار ARIA المناسبة وتتأكد من التشغيل عبر لوحة المفاتيح. بشكل عام، حلول HTML الأصلية يمكن الوصول إليها أكثر من تطبيقات JavaScript المخصصة لأن بائعي المتصفحات قاموا بعمل الإمكانية الوصولية لك.
كيف تعمل View Transitions بدون JavaScript؟
تعمل انتقالات العرض عبر المستندات (المستوى 2 من المواصفات) بالكامل من خلال CSS. تضيف قاعدة CSS، والمتصفح يقوم تلقائيًا بإنشاء انتقالات متحركة بين الملاحة بالصفحات. يمكنك تخصيص الرسوم المتحركة مع الدول الزائفة ::view-transition-old() و ::view-transition-new(). لا يلزم JavaScript. يدعم Chrome و Edge و Safari هذا في 2026، مع دعم Firefox متوقع قريبًا.
ما نسبة المستخدمين الذين لديهم JavaScript معطل؟ فقط حوالي 1-2٪ من المستخدمين يعطلون JavaScript بنشاط. لكن هذا ليس النقطة. يفشل JavaScript للعديد من المستخدمين أكثر من ذلك -- الاتصالات غير المستقرة وجدران الحماية بالشركات وملحقات المتصفح وانقطاعات CDN وأخطاء التحليل تتسبب جميعها في فشل JS. وجدت خدمة الحكومة الرقمية بالمملكة المتحدة أن 1.1٪ من المستخدمين لم يحصلوا على تحسينات JavaScript على الرغم من تفعيل JS. يحمي Progressive enhancement جميع هؤلاء المستخدمين.
هل يمكنني استخدام headless CMS مع واجهة أمامية zero-JavaScript؟ نعم، وهو أحد أفضل المجموعات. يوفر CMS تجربة تحرير غنية لفرق المحتوى، بينما تستهلك الواجهة الأمامية (المبنية مع Astro أو Eleventy) المحتوى في وقت الإنشاء عبر API وتخرج HTML/CSS بحتة. يعمل JavaScript من CMS في متصفح المحرر، وليس في متصفحات الزائرين. يمنحك هذا الفصل أفضل ما في العالمين: تجربة تأليف رائعة والأداء الكاملة zero-JS للمستخدمين النهائيين.