تطورت هيكلية تطبيقات الويب كثيرًا مع الوقت، حيث بدأت من صفحات ثابتة أو مصيّرة rendered من طرف الخادم، إلى ما بات يعرف بالتصيير من طرف العميل، أما المستقبل الآن فيبدو أنه يتوجه إلى التصيير من طرف الخادم مرةً أخرى، لكن هذه المرة عبر بث HTML من خلال مقابس الويب WebSockets.
أدى اعتماد هيكلية تطبيقات الصفحة الواحدة Single Page App، واختصارًا SPA، مع خدمة الواجهة البرمجية API لتصيير التطبيقات إلى صعوبات، من بينها التعامل مع ردود JSON للواجهة البرمجية، وإدارة حالة التطبيق بين طبقتين، ما يؤدي لزيادة كلفة وقت التطوير، ويبطئ إصدار النسخ الجديدة، ويعيق عجلة التطوير.
انتشرت بين المطورين طريقة جديدة، وهي الهيكلية الموجهة بمقابس الويب WebSocket driven، والتي تؤكد مجددًا أهمية التصيير من طرف الخادم، وتتيح تطوير النماذج الأولية prototype بسرعة، وتحول مسؤولية إدارة حالة التطبيق إلى الخادم مجددًا، وتسرع عملية إضافة المزايا الجديدة للتطبيقات، وتبسط إجراءات التحسين لمحركات البحث SEO، وتوفر التشاركية لعدة مستخدمين، وتبسط إمكانية تطوير تصاميم متجاوبة دون الحاجة لبناء تطبيقين منفصلين، حيث يكون التطبيق النهائي مستودعًا واحدًا، ويشعر مستخدمه بنفس التجاوب الذي يشعر به على تطبيقات جافاسكربت من طرف العميل، مع توفير قوالب بسيطة دون الحاجة للكثير من رموز التحميل، أو أخطاء في إدارة الحالة لأنها موجودة على الخادم في مكان واحد فقط، وتمهد كل الميزات السابقة لطريق تطوير أبسط وأسرع.
سنكسب الوقت الذي كان يُصرف عادةً على تحديد الهيكلية الأنسب للتطبيقات، وسنوفر المال والرواتب التي كانت تُصرف على تلك الأعمال، لنركز وقتنا ومالنا على الابتكار والتطوير في مزايا تنفع شركاتنا وعملاءنا.
قد يكون إطار عمل روبي أون ريلز Ruby on Rails أفضل إطار يركز على توفير وقت التطوير، كما يمكنك تطوير العروض ضمن بنية MVC باستخدام مكونات العروض ViewComponents، وكذلك الاستعانة بمكتبتي CableReady و StimulusReflex لإضافة التفاعلية لتطبيقاتك، وسنتحدث عن إطار ريلز لاحقًا.
البداية من أطر العمل
بدأت أطر العمل بالانتشار عام 2005 تقريبًا، وكان الشائع قبلها تجميع واستخدام عدة مكتبات مع بعضها، وعلى المطور أن يجد طريقته في تحديد هيكلية التطبيق، ثم نشره على خوادم أباتشي Apache التي يديرها المطورون يدويًا، لكن أطر العمل وعدت بتوفير طريقة جديدة لهيكلة التطبيقات دون الحاجة للمعاناة أو حتى لمس ما يتعلق بهيكلة التطبيق، مما أدى لتركيز المطورين على المفاهيم البرمجية العامة، وكتابة الشيفرات المقروءة، وتطوير المزايا التي يحتاجها السوق بسرعة أكبر، وما على المطور إلا أن يتعلم المفاهيم التي يقدمها إطار العمل، وكيفية استخدامها ليستطيع بناء تطبيقات ويب معقدة، بينما يبقى باقي المطورين مشغولون بإعداد طرق هيكلة تطبيقاتهم الخاصة.
على الرغم من النقد الذي تتعرض له كل فكرة جديدة، إلا أن أطر العمل التي تعتمد على التصيير من طرف الخادم أصبحت الخيار الأول للمطورين، وخصوصًا للشركات الناشئة التي تريد إنتاج منتجاتها بسرعة مع توفير مزايا غنية.
استخدمت جافاسكريبت في كل شيء
بدأت المفاهيم السابقة تتغير مع بداية عام 2010، إذ تنحّت أطر العمل التي تعتمد مبدأ التصيير من طرف الخادم جانبًا، واستخدمت بدلًا منها تطبيقات الصفحة الواحدة SPA، وهي تطبيقات مبنية كليًا باستخدام جافاسكريبت، وتعمل بالكامل على جهاز العميل، وأصبح غرض الخادم في العديد من الشركات استضافة الواجهة البرمجية للتطبيق API لتخديم البيانات فقط، أما باقي منطق العمل وتصيير HTML فموجود من طرف الخادم فقط، وعند أول زيارة للموقع سيحتاج الزائر لتحميل حزمة كبيرة من جافاسكريبت تحتوي على كل ذلك، وهنا أصبح الأمر مزعجًا قليلًا.
بدأنا نلاحظ مع دخول عام 2020 أن الويب عمومًا وصل إلى حد معين من السرعة ولم يعد يتطور أكثر، على عكس الأمل الذي وعدت به تطبيقات الصفحة الواحدة، فمثلًا أدى تحميل حزم بأحجام من فئة الميجابايت إلى هاتف محمول إلى تجربة مستخدم سيئة، عدا عن حاجة تطوير تطبيق ويب احترافي لموارد كثيرة، مع وجوب تطوير خدمة API وقناة تواصل بينهما، وفعليًا ليس لكل المستخدمين أجهزة قوية قادرة على معالجة 100 كيلو بايت من JSON وتصييرها إلى جدول معقد بترميز HTML أسرع من تصييرها على خادم بمواصفات متوسطة، كما أن تطوير تلك التطبيقات مكلف جدًا أيضًا، ففي الكثير من الأحيان ينتهي بنا الأمر ببذل جهد مضاعف، بل ودفع ضعف التكلفة للمطورين للحصول على نفس النتيجة التي حصلنا عليها سابقًا من تطوير تطبيقات طرف الخادم.
ذهلت تطبيقات أطر العمل الجميع في عام 2005 عندما أتاحت إمكانية بناء تطبيق مدونة كامل بربع ساعة فقط، ثم -وبعد 15 عام- صار تطوير نفس المدونة باستخدام طريقة تطبيقات الصفحة الواحدة سيحتاج لمستودعين وطبقة تحويل JSON إلى سلاسل، والكثير من مؤشرات التحميل ضمن التطبيق، كل هذا بهدف للحصول على أول صورة للمحتوى ضمن التطبيق خلال 50 ميلي ثانية، وفي هذه الأثناء ينتظر المستخدم -محدقًا في شاشة رمادية- تصيير المعلومات بصيغة JSON التي طلبها متصفحه إلى HTML.
انتهى بنا المطاف هنا إلى تخلينا عن التصيير من طرف الخادم الذي أسعد المطور حينها، واستبدلنا به طرقًا ضاعفت وقت التطوير وعدد المطورين، آملين بتوفير واجهات أجمل للمستخدمين، ربما كان هذا هو الخيار الصحيح، فنحن نطور التطبيقات للمستخدمين لا لنا، ولن يعجب المستخدم تحديث الصفحة بالكامل لتحديث المعلومات، ولا الأدوات المعقدة التي كانت متوفرةً، لذا كان خيار الانتقال إلى تطبيقات الصفحة الواحدة هو الخيار الصحيح، لكن المشكلة كانت أن التحسن بالنسبة للمستخدم كان بنسبة ضئيلة 5%، وليس بنسبة كبيرة 500% كما كنا نأمل.
الكلفة المضاعفة للتحسن الضئيل
بدت تطبيقات الوب -مع التطور الذي جرى عليها- جميلةً أكثر من وجهة نظر المستخدم، وإذا اهتممنا بتطويرها بالطريقة الصحيحة فسيشعر المستخدم أن التطبيق أكثر تفاعليةً وسرعةً، ويتيح إمكانية توفير مكونات تفاعلية غير أصلية، وكانت الخطوة التالية الصحيحة هي التركيز على تلك المكونات، فقد كنا سابقًا نهتم بالتفكير بكيفية تعديل مستند HTML بالكامل ليعطي المستخدم إحساس التفاعل مع مكون واحد داخل الصفحة، أما الآن فيمكن تضمين ذلك مباشرةً، ويمكننا تقسيم تجربة المستخدم إلى مكونات، لكن هذا سينعكس مباشرةً على الزيادة في الكلفة، فمثلًا يمكنك تطوير مكون تقييم يظهر بصورة نجوم، وإضافة حركات جميلة إليه، وجعل عملية وضع المؤشر عليه وضغطه تعطي شعورًا جميلًا، مما يحفز الأندورفين للمستخدم عندما يعطي تقييمه، لكن تلك العملية تحتاج لحفظ بيانات عن هذا التقييم ضمن قاعدة البيانات، ويجب على التطبيق أن يعكس حالة التخزين تلك ليشاهدها المستخدم.
كنا نظهر نفس المكون السابق عن طريق توفير عدة نجوم في صور GIF للمستخدم، ولكل منها رابط يشير لنفس المسار، مع اختلاف قيمة معامل التقييم لكل منها، وعلى طرف الخادم كنا نأخذ القيمة المرسَلة ونحفظها ضمن قاعدة البيانات، ونعيد إرسال صفحة HTML كاملة للمتصفح ليعيد تصييرها، حتى أنه كان بالإمكان استخدام أجاكس AJAX لإتمام هذه العملية في الخلفية دون الحاجة لإعادة تحديث الصفحة بالكامل، وإذا فرضنا أن الطريقة السابقة تكلف المطور قيمة x زمنيًا وماديًا، ولن نذكر كلفة الفرص الضائعة نتيجة التأخير في إطلاق المزايا الجديدة، فستكلف الطريقة التي تعتمد Ajax في التحديث x+n، حيث n كلفة برمجة وإدارة هذه الطريقة باستخدام جافاسكريبت، وستزيد كلما اعتمد تطبيقنا على جافاسكريبت أكثر، وكلما زاد تعقيده.
نكتب جافاسكريبت في طرف الخادم حاليًا في تطبيقات الصفحة الواحدة، ونستخدم قوالب JSX وHandlebar لتصيير المكونات، ونستخدم شيفرةً لحفظ حالة التطبيق في مستودع الواجهة الأمامية، ثم نرسل طلب PUT إلى واجهة برمجة التطبيق API، حيث سنكتب شيفرةً مسؤولةً عن معالجة الطلب، وطبقةً لتحويل JSON إلى سلاسل (ربما مع الشيرة الوهمية للنموذج) لتحزيم الرد، وشيفرةً في الواجهة الأمامية لتحديث -إعادة تصيير- المكون بعد تلقي الرد، وبعض منطق التفريع للتراجع وإعادة تصيير تغير الحالة من طرف العميل عند فشل الواجهة الخلفية، وسيزيد كل هذا من كلفة وقت وأجرة المطور أكثر من x+n، وإذا تكوّن فريق العمل من فريق للواجهات الأمامية وآخر للواجهات الخلفية، فستضاعف هذه الكلفة فورًا في الحالات التي ستحتاج فيها لعدة أشخاص لإنهاء التضمين، وستكون كل هذه المشاكل التي تأتي مع تطبيقات الصفحة الواحدة على حساب هدف العمل في السباق للتواجد في السوق، وتوفير منتجات تهمّ الأشخاص المحتاجين إليها.
إحدى وجهات النظر التي تدافع عن تطبيقات الصفحة الواحدة تقول إن من مزاياها توفير كلفة البنية التحتية، عن طريق تحميل العميل كلفة الاستضافة، مما يوفر كلفة الحلول السحابية المعتمدة، لكن وجهة النظر هذه قد تكون خاطئةً، لأننا مع ذلك مضطرون للدفع مقابل استضافة خدمة API وقاعدة البيانات، وقد نزيد عليها أيضًا كلفة موازنات الأحمال Load Balancers، وخادم نطاق الأسماء DNS وغيرها، وكل هذه الكلف ليست إلا جزءًا بسيطًا من مجموع رواتب المطورين التي تدفعها الشركات لهم، بل يتوقع المطورون مع الوقت زيادة رواتبهم، بينما تبقى كلفة خدمات الاستضافة على حالها، وتنخفض مع الوقت.
لا يحتاج توفير المال -خاصةً للشركات الناشئة التي يقيدها المال عمومًا- للتركيز على تخفيض كلفة الخوادم المستخدمة، بل يحتاج للتركيز على تطوير مزايا المنتجات سريعًا اعتمادًا على فريق عالي الإنتاجية، فقبل ظهور أطر العمل، كنت بحاجة للدفع لمطور لستة أسابيع قبل أن تحصل على صفحة تسجيل الدخول فقط، لكن -وبعد أن أتت أطر العمل- أصبحت صفحة تسجيل الدخول تقابل ساعة عمل واحدة فقط، وكانت الشركات الناشئة تطلق مشاريعها على الويب خلال أيام، أما الآن -ومع تطبيقات الصفحة الواحدة- فقد عدنا للحالة السابقة، وأصبحنا بحاجة للعمل أكثر مع كلفة أكبر، لأننا بحاجة إلى بناء تطبيقين بآن واحد للحصول على المنتج، لقد كلفنا تحسن الأداء بنسبة 5% الذي حصلنا عليه الكثير من المال، لكن ماذا لو أمكننا الاستفادة من أفكار ومزايا جافاسكريبت من طرف العميل والمكتبات من تلك الزيادة في الأداء، مع راحة المطور وتوفير الرواتب الذي يوفره مستودع التطبيق الواحد؟ ماذا لو استطعنا الجمع بين مكونات الواجهة الأمامية والترتيب في جافاسكريبت معًا في تطبيق مطور ضمن إطار عمل يعتمد التصيير من طرف الخادم؟ هل يكون ذلك الطريق إلى تحسن الأداء بنسبة 500%؟
قد يبدو ذلك مستحيلًا لكنه ممكن، ويوفر تطبيقات رائعةً في وقت قصير، فيمكننا مثلًا البث لكل المستخدمين المسجلين دخولهم حاليًا، وتحديث شجرة DOM من طرف الخادم فورًا، وتوفير حركات متجاوبة ثلاثية الأبعاد بواسطة جافاسكريبت، ونوافذ محادثة بالوقت الحقيقي، كل ذلك في مستودع واحد يعمل على نفس الخادم الذي يُستخدم للتطبيقات المصيرة من طرف الخادم، كما يمكن استخدام خادم بمواصفات أقل بما أننا نصيّر قطع HTML غالبًا، لا مستندات وصفحات كاملة، ولن نحتاج لتطبيق منفصل للواجهة الأمامية، وإنما مكونات جافاسكريبت وشيفرة من طرف الخادم تعمل مع بعضها بطريقة مثالية فقط.
مقابس الويب WebSockets
بدأت المتصفحات الحديثة بدعم مقابس الويب عام 2011، وهي الآن مدعومة في كل المتصفحات، ويمكنك الحصول على اتصال مزدوج عبر المقبس بين المتصفح والخادم بالاستعانة بالقليل من جافاسكريبت بجهة العميل، حيث يمكن للبيانات المرور بكلا الاتجاهين، ويمكن دفعها من كلا الطرفين في أي وقت، دون الحاجة لتدخل المستخدم، كما تطورت صناعة الألعاب، وذهبت باتجاه الألعاب السحابية، ولن يكون مستقبل تطبيقات الويب في الذهاب أكثر باتجاه نموذج خادم/عميل، بل على العكس سيذهب باتجاه جعل العميل يعمل مثل طرفية بطبقة رقيقة، تُصيِّر حالة التطبيق بترميز مفهوم للبشر، وتوفر مقابس الويب طبقة اتصال سهلةً وسريعةً، تتجه فيها البيانات من الخادم إلى البشر مباشرةً.
لم يتقبل المطورون تلك الفكرة بسهولة، كما لم تكن فوائدها واضحةً، بسبب تعودهم على حلقة طلبات HTTP من عشرات السنين، حيث يجب على الخادم أن يدعم تلك الطريقة في كافة المزايا المتضمنة فيه، لذا احتاج تبنّي مقابس الويب للتفكير من جديد لاستيعاب بنيته، وكما هو الحال في كل التقنيات والبروتوكولات الجديدة فهو بحاجة إلى طبقة تجريد عليا، تمكننا من توفير المزايا الجديدة بفعالية وسرعة إلى المستخدم.
HTML عبر مقابس الويب
إذا أردت الحصول على قائمة بيانات متجاوبة ومتزامنة مع قاعدة البيانات، فأرسل استعلام المستخدم عبر مقبس الويب إلى الخادم عند كل ضغطة مفتاح من لوحة المفاتيح، ليعيد لك عناصر option المناسبة لذلك الاستعلام.
وللتحقق من صحة البيانات على طرف العميل، يمكنك إرسال جميع قيم النموذج الذي يملؤه المستخدم عبر مقبس الويب عند كل تغير في قيمة حقل الإدخال، والتحقق من تلك البيانات من قبل إطار العمل على الخادم، وإرسال ترميز HTML الجديد للنموذج، متضمنًا أي أخطاء يجب إظهارها، ولا حاجة لاستخدام JSON وإرسال الخطأ بصيغة غرض، ويمكن ببساطة تضمين مكون للتحقق من حالة اتصال المستخدم عبر التحقق من حالة اتصال مقبس الويب لذلك المستخدم.
ويمكن إنشاء غرفة محادثة متعددة المستخدمين أو مستندات مشتركة، وهي ميزات نبتعد عنها في تطبيقات الصفحة الواحدة SPA لصعوبة تضمينها وكمية الحيل المطلوبة للتأكد من تزامن الحالة لدى جميع المستخدمين معًا، لكننا سنحتاج باستخدام طريقة إرسال HTML عبر مقابس الويب لإرسال كمية بسيطة من HTML للتجاوب مع التغيرات لدى كل مستخدم مشترك على نفس قناة الاتصال، وإذا حدّث المستخدم الصفحة كاملةً فلن يلاحظ فرقًا فيما سيراه في الصفحة المحدّثة، ويمكن أن تصل كل تلك التحديثات للمستخدم خلال 30 ميلي ثانية فقط.
يمكننا أيضًا تنفيذ مكونات ضمن طريقة الاعتماد على مقابس الويب، إذ يمكن أن ننظر إليها على أنها تجعل الخادم طبقةً كبيرةً والعميل طبقةً خفيفةً، وكذلك مكوناتنا، وكما كنا نفعل في السابق يمكننا جعل المكون جذابًا، وينفذ الكثير من الأمور المفيدة للمستخدم باستخدام جافاسكريبت، ثم نطلب من الخادم ترميز HTML بعد التحديث، ونغير شجرة DOM وفقًا لذلك، دون الحاجة لإدارة مخزن الحالة في طرف العميل لحالة المكونات، حيث أصبحت المكونات تٌُصيّر نفسها لتظهر تمامًا كما حددها الخادم، وسيُرسل الخادم لنا ترميز HTML فلا حاجة لاستخدام قوالب JSX أو Handlebar أو أي قوالب طرف عميل أخرى، فالمتحكم هو الخادم دومًا، حيث يُصيِّر حالة المكونات الأولية، ويحدّث شكلها مع كل تغيير في الحالة، وكل ذلك عبر المقبس.
لسنا مضطرين لإرسال ترميز HTML فقط عبر المقبس، إذ يمكن إرسال النصوص وترك طرف العميل لينفذ بالباقي، فمثلًا يمكن إرسال نص رسالة محادثة واردة من أحد المستخدمين إلى المستخدمين الباقين، وترك الأمر لهم لتصيير شكل تلك الرسالة بحسب السمة التي يفضلها كل مستخدم، ويمكنك تخيل الإمكانيات التي يتيحها ذلك.
هل هذه الطريقة معقدة أو مكلفة أو تحتاج لبنية تحتية ما؟
الجواب هو لا، إذ تدعمها مخدمات الويب مفتوحة المصدر دعمًا أصيلًا، دون الحاجة لإعدادها تقريبًا، وتوفر العديد من أطر عمل التصيير من طرف الخادم ضمنيًا شيفرة جافاسكريبت لطرف العميل لتتيح إمكانية التواصل عبر المقبس، فمثلًا في إطار عمل ريلز نعدّ التطبيق لاستخدام مقابس الويب بإعداد ActionCable المعتاد على نفس العتاد الذي نستخدمه عادةً، ويمكن لإجرائية مخدم ريلز تخديم 4000 اتصال معًا تقريبًا مع الحفاظ على أدائها، ويمكنك استخدام ActionCable لرفع العدد إلى 10000 اتصال لكل عقدة، وذلك بعدم الاعتماد على خادم ريلز لمقابس الويب، على نفس العتاد الذي تستخدمه عادةً، دون الحاجة لإضافة أي عتاد أو توسيع البنية السحابية لمشروعك.
انتشرت هذه الطريقة وأنشئت لها إضافات ومكتبات وإعدادات لمختلف اللغات وأطر العمل، فمثلًا يوجد Socketpuppet لإطار ديجانغو Django، وLiveView لإطار فونكس Phoenix، ويمكنك البحث عن مكتبات توفر دعمًا للاتصال عبر مقابس الويب لإطار العمل المفضل لديك، مما سيغير طريقة تفكيرك حول هيكلية التطبيقات، ثم حاول بناء تطبيق صغير بواسطة ذلك، وستشعر بمتعة وسرعة إرسال أجزاء HTML عبر المقبس، وستحتاج لعقلية جديدة وميزات منفَّذة جيدًا لنجاح شركتك الناشئة.
إطار عمل روبي أون ريلز Ruby on Rails
عند إضافة آخر إصدار كل من Turbolinks وStimulus وStimulusReflex وCableReady وViewComponent إلى إطار العمل روبي أون ريلز ستتمكن من العمل على تطبيق تفاعلي يشعرك أنك تبني تطبيق ريلز كلاسيكيًا وأكثر عصريةً، بالإضافة إلى مكونات تطبيقات الصفحة الواحدة ضمن مستودع واحد لكل التطبيقات، ومزايا التصيير من طرف الخادم، والتخزين المؤقت لقطع HTML، وتحسين محركات البحث، وكافة مزايا الأمان، وما يماثلها من مزايا، وستجد العديد من الأدوات التي ستخدمك لبناء مزايا كنت سابقًا تبتعد عنها لصعوبة بنائها.
يوفر Turbolinks مغلفات wrappers تمكن من بناء واجهات محلية أو هجينة مع HTML ضمن مستودع التطبيق نفسه، ومع استخدام حلول نشر سريعة، مثل هيروكو Heroku وهاتشبوكس Hatchbox، يمكن بناء تطبيقات متجاوبة وتفاعلية متعددة المنصات بوقت قصير.
لكن لماذا اخترنا إطار ريلز تحديدًا، أليس قديمًا ومملًا؟ قلنا سابقًا إن أي إطار عمل يمكنه الاستفادة من طريقة مقابس الويب مع تعديل شجرة DOM، وقد أثبت إطار ريلز جدارته وقدرته على بناء النماذج الأولية، وبيئة المكتبات القوية المتوفرة له، ولا زال يتيح مزايا جديدةً، حيث أتاح إصدار 6.1.3 الأخير منه العديد من المزايا.
إذا كان حجم فريقك محدودًا ومواردك قليلةً نسبيًا فسيقدم لك ريلز (وحتى لغة روبي بمفردها) دفعًا قويًا للابتكار والتطوير بسرعة، مما يفسر كيف أتيحت الفرصة لأرباح بقيمة 92 مليون دولار خلال السنين الماضية، ولكن طريقتنا الجديدة ستمنحك دفعًا أقوى إلى الأمام، فبينما يعاني منافسوك مع مُسلسِلات JSON ومؤشرات التحميل ضمن تطبيقاتهم، ستكون مشغولًا بالبناء وإطلاق ميزات تعاون جديدة بين المستخدمين كل أسبوع، بل كل يوم.
الجميع رابح هنا، أنت والمطورون والعمل عمومًا، وأهم من ذلك المستخدمون، هذا هو الوعد الذي قدمته ريلز منذ إطلاقها، وهو السبب وراء ظهور أطر عمل تحاول تقليدها في لغات البرمجة الأخرى، وأنها شهدت تبنيًا واسعًا في عالم الشركات الناشئة لسنوات، وستمهد روح تقديم النماذج الأولية بهذه السرعة مع طريقة إرسال HTML عبر مقابس الويب، لعودة قوية لإطار ريلز.
يشاركنا أوبي فرناندز Obie Fernandez صاحب كتاب "على طريقة روبي The Ruby Way" ذلك الرأي، ويؤمن راس هانيمان Russ Hanneman أن تلك الطريقة مع استخدام StimulusReflex هي المستقبل، وقدّم الأشخاص في بيزكامب Basecamp (مؤسسو ريلز الأوائل) وجهة نظرهم عن تلك الطريقة Hotwire.
يجب أن لا ندعو ذلك بعودة ريلز، لأنه بقي موجودًا طوال هذه السنين، لكنه مع هذه الهيكلية الجديدة، وإرسال HTML عبر مقابس الويب، والتفاعل ثنائي الاتصال لجافاسكريبت، سيصبح شيئًا جديدًا وجميلًا ويحتاج للانتباه من جديد.
يجب عليه الاطلاع على ريلز التفاعلي مع StimulusReflex وباقي المكتبات التي ستتيح مساحةً من التطبيقات الجديدة كليًا، لكل من يعاني مع مسارات JSON على الخادم أو مع JSX.
ترجمة -وبتصرف- للمقال "The Future of Web Software Is HTML-over-WebSockets" لصاحبه Matt E. Patterson.
أفضل التعليقات
لا توجد أية تعليقات بعد
انضم إلى النقاش
يمكنك أن تنشر الآن وتسجل لاحقًا. إذا كان لديك حساب، فسجل الدخول الآن لتنشر باسم حسابك.