منذ حوالي 15 عامًا، كنت أعمل في شركة حيث قمنا ببناء تطبيقات لوكلاء السفر وعمال المطارات وشركات الطيران. لقد قمنا أيضًا ببناء إطار عمل داخلي خاص بنا لمكونات واجهة المستخدم وإمكانيات التطبيقات ذات الصفحة الواحدة. كان لدينا مكونات لكل شيء: الحقول، والأزرار، وعلامات التبويب، والنطاقات، وجداول البيانات، والقوائم، ومنتقيات البيانات، والتحديدات، والتحديدات المتعددة. حتى أنه كان لدينا مكون div. بالمناسبة، كان مكون div الخاص بنا رائعًا، فقد سمح لنا بعمل زوايا دائرية على جميع المتصفحات، وهو الأمر الذي، صدق أو لا تصدق، لم يكن بالأمر السهل في ذلك الوقت.
تم عملنا في مرحلة من تاريخنا عندما كان يُنظر إلى JS وAjax وHTML الديناميكي على أنها ثورة أوصلتنا إلى المستقبل. وفجأة، أصبح بإمكاننا تحديث الصفحة ديناميكيًا، والحصول على البيانات من الخادم، وتجنب الاضطرار إلى الانتقال إلى صفحات أخرى، وهو ما كان يُنظر إليه على أنه بطيء ويظهر مستطيل أبيض كبير على الشاشة بين الصفحتين. كانت هناك عبارة اشتهرت على يد جيف أتوود (مؤسس StackOverflow)، ونصها كما يلي: "أي تطبيق يمكن كتابته بلغة JavaScript سيتم كتابته في النهاية بلغة JavaScript." - جيف أتوود
بالنسبة لنا في ذلك الوقت، بدا الأمر وكأنه جرأة لإنشاء تلك التطبيقات. لقد بدا الأمر وكأنه موافقة شاملة على القيام بكل شيء باستخدام JS. لذلك قمنا بكل شيء باستخدام JS، ولم نأخذ الوقت الكافي للبحث عن طرق أخرى للقيام بالأشياء. لم نشعر حقًا بالحافز لتعلم ما يمكن أن تفعله HTML وCSS بشكل صحيح. لم نعتبر الويب حقًا منصة تطبيقات متطورة في مجملها. لقد رأينا ذلك في الغالب كشيء نحتاج إلى حله، خاصة عندما يتعلق الأمر بدعم المتصفح. يمكننا فقط استخدام المزيد من JS لإنجاز الأمور. هل كان من الممكن أن يساعدني تخصيص الوقت لمعرفة المزيد حول كيفية عمل الويب وما هو متاح على النظام الأساسي؟ بالتأكيد، ربما كان بإمكاني حلق مجموعة من التعليمات البرمجية التي لم تكن هناك حاجة إليها حقًا. لكن، في ذلك الوقت، ربما ليس كثيرًا. كما ترى، كانت الاختلافات في المتصفحات كبيرة جدًا في ذلك الوقت. كان هذا هو الوقت الذي كان فيه Internet Explorer لا يزال هو المتصفح المهيمن، وكان Firefox في المرتبة الثانية، لكنه بدأ يفقد حصته في السوق بسبب اكتساب Chrome لشعبية سريعة. على الرغم من أن Chrome وFirefox كانا جيدين جدًا في الاتفاق على معايير الويب، إلا أن البيئات التي كانت تعمل فيها تطبيقاتنا تعني أنه كان علينا دعم IE6 لفترة طويلة. حتى عندما سمح لنا بدعم IE8، كان لا يزال يتعين علينا التعامل مع الكثير من الاختلافات بين المتصفحات. ليس هذا فحسب، بل لم تكن شبكة الويب في ذلك الوقت تحتوي على العديد من الإمكانات المضمنة في النظام الأساسي.
تقدم سريعًا إلى اليوم. لقد تغيرت الأمور بشكل هائل. ولا يقتصر الأمر على أن لدينا المزيد من هذه القدرات أكثر من أي وقت مضى فحسب، بل إن معدل توفرها قد زاد أيضًا. اسمحوا لي أن أطرح السؤال مرة أخرى: هل سيساعدك تخصيص الوقت لمعرفة المزيد حول كيفية عمل الويب وما هو متاح على النظام الأساسي اليوم؟ نعم بالتأكيد. إن تعلم فهم منصة الويب واستخدامها اليوم يمنحك ميزة كبيرة مقارنة بالمطورين الآخرين. سواء كنت تعمل على الأداء أو إمكانية الوصول أو الاستجابة أو كل ذلك معًا أو مجرد شحن ميزات واجهة المستخدم، إذا كنت تريد القيام بذلك كمهندس مسؤول، فإن معرفة الأدوات المتاحة لك تساعدك على الوصول إلى أهدافك بشكل أسرع وأفضل. بعض الأشياء التي قد لا تحتاج إلى مكتبة لها بعد الآن وبمعرفة ما تدعمه المتصفحات اليوم، فإن السؤال إذن هو: ما الذي يمكننا التخلص منه؟ هل نحتاج إلى مكون div للقيام بزوايا مستديرة في عام 2025؟ بالطبع، نحن لا نفعل ذلك. لقد تم دعم الخاصية border-radius بواسطة جميع المتصفحات المستخدمة حاليًا لأكثر من 15 عامًا في هذه المرحلة. وسيأتي أيضًا شكل الزاوية قريبًا، حتى للزوايا الأكثر روعة. دعونا نلقي نظرة على الميزات الحديثة نسبيًا المتوفرة الآن في جميع المتصفحات الرئيسية، والتي يمكنك استخدامها لاستبدال التبعيات الموجودة في قاعدة التعليمات البرمجية الخاصة بك. لا يتمثل الهدف في التخلص فورًا من جميع مكتباتك المفضلة وإعادة كتابة قاعدة التعليمات البرمجية الخاصة بك. أما بالنسبة لكل شيء آخر، فستحتاج إلى أخذ دعم المتصفح في الاعتبار أولاً واتخاذ القرار بناءً على عوامل أخرى خاصة بمشروعك. يتم تنفيذ الميزات التالية في محركات المتصفح الرئيسية الثلاثة (Chromium وWebKit وGecko)، ولكن قد يكون لديك متطلبات مختلفة لدعم المتصفح تمنعك من استخدامها على الفور. لا يزال الوقت مناسبًا للتعرف على هذه الميزات، وربما التخطيط لاستخدامها في مرحلة ما. النوافذ المنبثقة ومربعات الحوار يمكن أن تساعدك واجهة Popover API وعنصر HTML
بالتأكيد، ربما زادت سرعة اتصالك بالإنترنت أيضًا، ولكن هذا ليس هو الحال بالنسبة للجميع. ولا يتمتع الجميع بنفس إمكانيات الجهاز أيضًا. إن سحب تعليمات برمجية خارجية للأشياء التي يمكنك القيام بها باستخدام النظام الأساسي، بدلاً من ذلك، يعني على الأرجح أنك تقوم بشحن المزيد من التعليمات البرمجية، وبالتالي الوصول إلى عملاء أقل مما تفعل عادةً. على الويب، يؤدي أداء التحميل السيئ إلى معدلات هجر كبيرة ويضر بسمعة العلامة التجارية. تشغيل تعليمات برمجية أقل على الأجهزة علاوة على ذلك، من المحتمل أن تعمل التعليمات البرمجية التي ترسلها على أجهزة عملائك بشكل أسرع إذا كانت تستخدم عددًا أقل من تجريدات JavaScript أعلى النظام الأساسي. ومن المحتمل أيضًا أن يكون أكثر استجابة ويمكن الوصول إليه بشكل افتراضي. كل هذا يؤدي إلى المزيد من العملاء وأكثر سعادة. راجع مدونة زميلي أليكس راسل السنوية حول فجوة عدم المساواة في الأداء، والتي توضح أن الأجهزة المتميزة غائبة إلى حد كبير عن الأسواق التي تضم مليارات المستخدمين بسبب عدم المساواة في الثروة. وهذه الفجوة تتزايد مع مرور الوقت.
تخطيط البناء المدمج إحدى ميزات منصة الويب التي ستتوفر قريبًا والتي أنا متحمس جدًا لها هي CSS Masonry.
اسمحوا لي أن أبدأ بشرح ما هي الماسونية. ما هي الماسونية البناء هو نوع من التخطيط الذي أصبح شائعًا بواسطة Pinterest منذ سنوات. يقوم بإنشاء مسارات مستقلة للمحتوى يتم من خلالها تجميع العناصر في أقرب وقت ممكن من بداية المسار.
يرى العديد من الأشخاص أن الماسونية هي خيار رائع للمحافظ ومعارض الصور، وهو ما يمكن أن تفعله بالتأكيد. لكن البناء أكثر مرونة مما تراه على موقع Pinterest، ولا يقتصر على التخطيطات التي تشبه الشلال فقط. في تخطيط البناء:
يمكن أن تكون المسارات أعمدة أو صفوفًا:
لا يجب أن تكون جميع مسارات المحتوى بنفس الحجم:
يمكن أن تمتد العناصر إلى مسارات متعددة:
يمكن وضع العناصر على مسارات محددة؛ ليس عليهم دائمًا اتباع خوارزمية الموضع التلقائي:
العروض التوضيحية فيما يلي بعض العروض التوضيحية البسيطة التي قمت بها باستخدام التطبيق القادم لـ CSS Masonry في Chromium. عرض توضيحي لمعرض الصور، يوضح كيف يمكن للعناصر (العنوان في هذه الحالة) أن تمتد إلى مسارات متعددة:
معرض صور آخر يعرض مسارات بأحجام مختلفة:
تخطيط موقع إخباري به بعض المسارات أوسع من غيرها، وبعض العناصر تمتد على عرض التخطيط بالكامل:
لوحة كانبان توضح أنه يمكن وضع العناصر على مسارات محددة:
ملحوظة: التم إنشاء العروض التوضيحية السابقة باستخدام إصدار من Chromium غير متاح بعد لمعظم مستخدمي الويب، نظرًا لأن CSS Masonry بدأ للتو في التنفيذ في المتصفحات. ومع ذلك، كان مطورو الويب يستخدمون المكتبات بسعادة لإنشاء تخطيطات البناء لسنوات عديدة بالفعل. المواقع التي تستخدم البناء اليوم في الواقع، أصبحت الماسونية شائعة جدًا على الويب اليوم. فيما يلي بعض الأمثلة التي وجدتها إلى جانب Pinterest:
وبعض الأمثلة الأخرى الأقل وضوحًا:
إذًا، كيف تم إنشاء هذه التخطيطات؟ الحلول إحدى الحيل التي رأيتها مستخدمة هي استخدام تخطيط Flexbox بدلاً من ذلك، وتغيير اتجاهه إلى عمود، وإعداده للالتفاف. بهذه الطريقة، يمكنك وضع عناصر ذات ارتفاعات مختلفة في أعمدة متعددة ومستقلة، مما يعطي انطباعًا بوجود تخطيط ماسوني:
ومع ذلك، هناك قيودان على هذا الحل البديل:
يختلف ترتيب العناصر عما سيكون عليه في تخطيط البناء الحقيقي. باستخدام Flexbox، تملأ العناصر العمود الأول أولاً، وعندما يمتلئ، انتقل إلى العمود التالي. مع البناء، سيتم تكديس العناصر في أي مسار (أو عمود في هذه الحالة) به مساحة أكبر متاحة. ولكن أيضًا، وربما الأهم من ذلك، يتطلب هذا الحل البديل أن تقوم بتعيين ارتفاع ثابت لحاوية Flexbox؛ وإلا فلن يحدث أي التفاف.
مكتبات الماسونية لطرف ثالث بالنسبة للحالات الأكثر تقدمًا، يستخدم المطورون المكتبات. المكتبة الأكثر شهرة وشعبية لهذا الغرض تسمى ببساطة Masonry، ويتم تنزيلها حوالي 200000 مرة في الأسبوع وفقًا لـ NPM. يوفر Squarespace أيضًا مكون تخطيط يعرض تخطيط Masonry، كبديل بدون تعليمات برمجية، وتستخدمه العديد من المواقع. يستخدم كلا الخيارين كود JavaScript لوضع العناصر في التخطيط. البناء المدمج أنا متحمس حقًا لأن Masonry بدأ الآن في الظهور في المتصفحات كميزة CSS مدمجة. بمرور الوقت، ستتمكن من استخدام Masonry تمامًا كما تفعل مع Grid أو Flexbox، أي دون الحاجة إلى أي حلول بديلة أو تعليمات برمجية من طرف ثالث. يقوم فريقي في Microsoft بتنفيذ دعم Masonry المدمج في مشروع Chromium مفتوح المصدر، والذي يعتمد عليه Edge وChrome والعديد من المتصفحات الأخرى. كانت Mozilla في الواقع أول بائع متصفح يقترح تطبيقًا تجريبيًا للماسونية في عام 2020. وكانت شركة Apple أيضًا مهتمة جدًا بجعل تخطيط الويب الجديد هذا بدائيًا. العمل على توحيد الميزة يمضي قدمًا أيضًا، مع الاتفاق داخل مجموعة عمل CSS حول الاتجاه العام وحتى عرض نوع العرض الجديد: ممرات الشبكة. إذا كنت تريد معرفة المزيد عن البناء وتتبع التقدم، راجع صفحة موارد CSS Masonry الخاصة بي. بمرور الوقت، عندما تصبح الماسونية ميزة أساسية، تمامًا مثل Grid أو Flexbox، سنكون قادرين على استخدامها ببساطة والاستفادة من:
أداء أفضل، استجابة أفضل، سهولة الاستخدام ورمز أبسط.
دعونا نلقي نظرة فاحصة على هذه. أداء أفضل إن إنشاء نظام تخطيط شبيه بالماسونية، أو استخدام مكتبة تابعة لجهة خارجية بدلاً من ذلك، يعني أنه سيتعين عليك تشغيل كود JavaScript لوضع العناصر على الشاشة. وهذا يعني أيضًا أن هذا الرمز سيتم حظره. في الواقع، إما لن يظهر أي شيء، أو لن تكون الأشياء في الأماكن الصحيحة أو بالأحجام الصحيحة، حتى يتم تشغيل كود JavaScript هذا. غالبًا ما يتم استخدام تخطيط البناء للجزء الرئيسي من صفحة الويب، مما يعني أن الكود سيجعل المحتوى الرئيسي الخاص بك يظهر في وقت متأخر عما كان يمكن أن يظهر بخلاف ذلك، مما يؤدي إلى تدهور LCP الخاص بك، أو مقياس الطلاء الأكبر للمحتوى، والذي يلعب دورًا كبيرًا في الأداء الملحوظ وتحسين محرك البحث. لقد اختبرت مكتبة Masonry JS بتصميم بسيط ومن خلال محاكاة اتصال 4G بطيء في DevTools. المكتبة ليست كبيرة جدًا (24 كيلو بايت، 7.8 كيلو بايت مضغوطة بصيغة gzipped)، لكن تحميلها استغرق 600 مللي ثانية في ظل ظروف الاختبار الخاصة بي. فيما يلي تسجيل أداء يوضح وقت التحميل الطويل الذي يبلغ 600 مللي ثانية لمكتبة Masonry، وعدم حدوث أي نشاط عرض آخر أثناء حدوث ذلك:
بالإضافة إلى ذلك، بعد وقت التحميل الأولي، يجب تحليل البرنامج النصي الذي تم تنزيله وتجميعه ثم تشغيله. وكل ذلك، كما ذكرنا من قبل، كان يمنع عرض الصفحة. مع تطبيق Masonry المدمج في المتصفح، لن يكون لدينا برنامج نصي للتحميل والتشغيل. سيقوم محرك المتصفح بعمله أثناء خطوة عرض الصفحة الأولية. استجابة أفضل كما هو الحال عند تحميل الصفحة لأول مرة، يؤدي تغيير حجم نافذة المتصفح إلى عرض التخطيط في تلك الصفحة مرة أخرى. ومع ذلك، في هذه المرحلة، إذا كانت الصفحة تستخدم مكتبة Masonry JS، فليست هناك حاجة لتحميل البرنامج النصي مرة أخرى، لأنه بالفعلهنا. ومع ذلك، يجب تشغيل التعليمات البرمجية التي تنقل العناصر إلى الأماكن الصحيحة. الآن يبدو أن هذه المكتبة المحددة سريعة جدًا في القيام بذلك عند تحميل الصفحة. ومع ذلك، فإنه يقوم بتحريك العناصر عندما تحتاج إلى الانتقال إلى مكان مختلف في تغيير حجم النافذة، وهذا يحدث فرقًا كبيرًا. وبطبيعة الحال، لا يقضي المستخدمون وقتًا في تغيير حجم نوافذ المتصفح الخاصة بهم بقدر ما نفعل نحن المطورين. لكن تجربة تغيير الحجم المتحرك هذه يمكن أن تكون مزعجة للغاية وتضيف إلى الوقت المتصور الذي تستغرقه الصفحة للتكيف مع حجمها الجديد. سهولة الاستخدام ورمز أبسط تعد مدى سهولة استخدام إحدى ميزات الويب ومدى بساطة مظهر الكود من العوامل المهمة التي يمكن أن تحدث فرقًا كبيرًا لفريقك. بالطبع، لا يمكن أن تكون بنفس أهمية تجربة المستخدم النهائية، لكن تجربة المطور تؤثر على قابلية الصيانة. يأتي استخدام ميزة الويب المضمنة مع فوائد مهمة على هذه الجبهة:
من المرجح أن يتمكن المطورون الذين يعرفون HTML وCSS وJS بالفعل من استخدام هذه الميزة بسهولة لأنها مصممة للتكامل بشكل جيد والتوافق مع بقية النظام الأساسي للويب. لا يوجد أي خطر لكسر التغييرات التي يتم إدخالها على كيفية استخدام الميزة. لا يوجد أي خطر تقريبًا في أن تصبح هذه الميزة مهملة أو غير قابلة للصيانة.
في حالة البناء المدمج، نظرًا لأنه تخطيط بدائي، يمكنك استخدامه من CSS، تمامًا مثل Grid أو Flexbox، دون الحاجة إلى استخدام JS. بالإضافة إلى ذلك، تعمل خصائص CSS الأخرى ذات الصلة بالتخطيط، مثل الفجوة، كما تتوقعها. لا توجد حيل أو حلول بديلة يجب معرفتها، والأشياء التي تتعلمها موثقة على MDN. بالنسبة إلى Masonry JS lib، تكون التهيئة معقدة بعض الشيء: فهي تتطلب سمة بيانات ذات بناء جملة محدد، إلى جانب عناصر HTML المخفية لتعيين أحجام الأعمدة والفجوات. بالإضافة إلى ذلك، إذا كنت تريد توسيع الأعمدة، فستحتاج إلى تضمين حجم الفجوة بنفسك لتجنب المشاكل:
<نمط> .track-sizer، .البند { العرض: 20%؛ } حجم الحضيض { العرض: 1ريم؛ } .البند { الارتفاع: 100 بكسل؛ نهاية كتلة الهامش: 1rem؛ } .العنصر:نث-طفل(غريب) { الارتفاع: 200 بكسل؛ } .العنصر--العرض2 { العرض: كالس (40% + 1ريم)؛ }
دعونا نقارن هذا بما سيبدو عليه تطبيق البناء المدمج: <نمط> .حاوية { العرض: ممرات الشبكة؛ ممرات الشبكة: كرر (4، 20٪)؛ الفجوة: 1ريم؛ } .البند { الارتفاع: 100 بكسل؛ } .العنصر:نث-طفل(غريب) { الارتفاع: 200 بكسل؛ } .العنصر--العرض2 { عمود الشبكة: يمتد 2؛ }
تعليمات برمجية أبسط وأكثر إحكاما يمكنها فقط استخدام أشياء مثل الفجوة وحيث تتم مسارات الامتداد باستخدام النطاق 2، تمامًا كما هو الحال في الشبكة، ولا يتطلب منك حساب العرض الصحيح الذي يتضمن حجم الفجوة. كيف تعرف ما هو متاح ومتى يكون متاحًا؟ بشكل عام، السؤال ليس حقًا ما إذا كان يجب عليك استخدام الماسونية المضمنة عبر مكتبة JS، بل متى. مكتبة Masonry JS مذهلة وقد سدت فجوة في منصة الويب لسنوات عديدة، ولعديد من المطورين والمستخدمين السعداء. لديها بعض العيوب إذا قارنتها بتطبيق Masonry المدمج، بالطبع، ولكن هذه ليست مهمة إذا لم يكن هذا التنفيذ جاهزًا. من السهل بالنسبة لي أن أقوم بإدراج ميزات منصة الويب الجديدة الرائعة هذه لأنني أعمل لدى أحد موردي المتصفحات، وبالتالي أميل إلى معرفة ما سيأتي. لكن المطورين غالبًا ما يشاركون، من خلال استطلاع تلو الآخر، في أن تتبع الأشياء الجديدة أمر صعب. يعد البقاء على اطلاع أمرًا صعبًا، ولا تعطي الشركات دائمًا الأولوية للتعلم على أي حال. للمساعدة في ذلك، إليك بعض الموارد التي توفر التحديثات بطرق بسيطة ومدمجة حتى تتمكن من الحصول على المعلومات التي تحتاجها بسرعة:
تتميز منصة الويب بموقع المستكشف: قد تكون مهتمًا بصفحة ملاحظات الإصدار الخاصة به. وإذا كنت تحب خدمة RSS، فاطلع على موجز ملاحظات الإصدار، بالإضافة إلى موجزات الأساس المتوفرة حديثًا والمتاحة على نطاق واسع.
الويبلوحة معلومات حالة المنصة: قد تعجبك صفحات السنة الأساسية المختلفة.
صفحة خريطة الطريق لحالة نظام Chrome الأساسي.
إذا كان لديك المزيد من الوقت، فقد تكون مهتمًا أيضًا بملاحظات إصدار موردي المتصفحات:
كروم الحافة فايرفوكس سفاري
لمزيد من الموارد، قم بمراجعة ورقة التنقل الخاصة بمنصة الويب. الشيء الخاص بي لا يزال لم يتم تنفيذه وهذا هو الجانب الآخر من المشكلة. حتى لو وجدت الوقت والطاقة والطرق للمتابعة، فلا يزال هناك إحباط من إيصال صوتك وتنفيذ ميزاتك المفضلة. ربما كنت تنتظر لسنوات حتى يتم حل خطأ معين، أو إضافة ميزة معينة إلى المتصفح حيث لا تزال مفقودة. ما سأقوله هو أن بائعي المتصفح يستمعون. أنا جزء من العديد من الفرق المشتركة بين المؤسسات حيث نناقش إشارات المطورين وتعليقاتهم طوال الوقت. نحن ننظر إلى العديد من مصادر التعليقات المختلفة، سواء الداخلية لدى كل مورد متصفح أو الخارجية/العامة في المنتديات والمشاريع مفتوحة المصدر والمدونات والاستطلاعات. ونحن نحاول دائمًا إنشاء طرق أفضل للمطورين لمشاركة احتياجاتهم وحالات الاستخدام الخاصة بهم. لذا، إذا كان بإمكانك، يرجى طلب المزيد من موردي المتصفحات والضغط علينا لتنفيذ الميزات التي تحتاجها. أدرك أن الأمر يستغرق وقتًا، ويمكن أن يكون مخيفًا أيضًا (ناهيك عن وجود عائق كبير أمام الدخول)، ولكنه يعمل أيضًا. فيما يلي بعض الطرق التي يمكنك من خلالها إيصال صوتك (أو صوت شركتك): شارك في استطلاعات حالة JS وحالة CSS وحالة HTML السنوية. إنهم يلعبون دورًا كبيرًا في كيفية قيام بائعي المتصفحات بتحديد أولويات عملهم. إذا كنت بحاجة إلى تنفيذ واجهة برمجة تطبيقات محددة قائمة على المعايير بشكل متسق عبر المتصفحات، ففكر في إرسال اقتراح في التكرار التالي لمشروع Interop. يتطلب الأمر مزيدًا من الوقت، ولكن فكر في كيفية مشاركة Shopify و RUMvision لقوائم أمنياتهم الخاصة بـ Interop 2026. يمكن أن تكون المعلومات التفصيلية مثل هذه مفيدة جدًا لموردي المتصفحات لتحديد الأولويات. لمزيد من الروابط المفيدة للتأثير على بائعي المتصفحات، قم بمراجعة ورقة التنقل الخاصة بمنصة الويب. الاستنتاج في الختام، آمل أن يكون هذا المقال قد ترك لك بعض الأشياء للتفكير فيها:
الإثارة للماسونية وميزات الويب الأخرى القادمة. بعض ميزات الويب التي قد ترغب في البدء في استخدامها. بعض الأجزاء من التعليمات البرمجية المخصصة أو التابعة لجهة خارجية قد تتمكن من إزالتها لصالح الميزات المضمنة. بعض الطرق لتتبع ما هو قادم والتأثير على بائعي المتصفحات.
والأهم من ذلك، أتمنى أن أكون قد أقنعتك بفوائد استخدام منصة الويب إلى أقصى إمكاناتها.
