لماذا الشبكة معقدة للغاية؟

أصبحت مناقشة نتائج السنة في الواجهة فجأة موضوعًا للمناقشة . سأضيف رأيي ، وسأكون سعيدًا لسماع رأي الآخرين.

يبدو لي أنه من المنطقي أن نتحدث عما يحدث على الويب الحديث ، يُنظر إليه من الخارج والداخل مختلف تمامًا. نعم ، و "الداخل" لديها عدة مستويات. إن وجهة نظر "إنهم يعقدون التصميم مرة أخرى" صحيحة تمامًا من ناحية وخاطئة ومفسدة من ناحية أخرى ، ولكن الرأي "لا تمنعنا من بناء التجريدات" غير فعال أيضًا.

عندما يشكو شخص ما من أن الويب الحديثة أصبحت معقدة للغاية ، في كل مرة أريد أن أذكر هذا الشخص بأن هذا الموقع الحديث يثق بأمواله في البنوك عبر الإنترنت وشراء النماذج والمراسلات الشخصية في الشبكات الاجتماعية وإصدارات الويب من برامج المراسلة الفورية ، والملفات الشخصية في السحب. والأرجح أنه يريد حقًا أن تكون عملية تطوير هذه الأنظمة معقدة وصعبة ولكنها موثوقة وليست فاشلة.

مصدر الصورة

تحت الواجهة الحديثة وأصدقائه الآن يفهمون أكثر بكثير مما يبدو من الخارج. هذه هي المواقع الكلاسيكية و SPA ، والتطبيقات على الإلكترون ، وتطبيقات الهاتف المحمول على cordova ، NativeScript ، React Native ، وحتى على Flutter. هذه بنية تحتية معقدة تشتمل على شبكات CDN والخدمات اللامركزية الجغرافية ونقاط الدردشة على JS وحتى أدوات التعلم الآلي لتحسين التجميع وحتى إنشاء المخططات.

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

لماذا؟

في الوقت الحالي ، تعد حزمة HTML + CSS + JS واحدة من أقوى البرامج من حيث بناء واجهات - ليس فقط بسبب إمكاناتها ، ولكن أيضًا عدد الحلول المبنية عليها - أطر عمل css ومكتبات المكونات المرئية وواجهات لعدد كبير من الخدمات و SAAS . فيما يتعلق بالكفاءة في ساعات التطوير للجمهور وإمكانية الوصول المحتملين ، فإن تقنيات الويب تتقدم في كل من حلول الأجهزة المحمولة وسطح المكتب. والآن انقسمت إلى ثلاثة مجالات:

• تطوير مواقع ثابتة تمامًا وشبه ثابتة مع محتوى ديناميكي جزئيًا (المعارض والنوافذ المنبثقة وما إلى ذلك)
• تطوير تطبيقات الويب "الكلاسيكية" على أطر الخادم (django ، القضبان)
• تطوير عميل الويب

ولكل منهم خصوصية مختلفة تماما.

كان تطور JS مؤلمًا جدًا ، لذا بدأت الحلول تظهر هذا الألم.

إذا نظرت إليهم ، يمكنك أن ترى شيئًا مثيرًا للاهتمام: أولاً ، بدأت تظهر حلول مثل jQuery و CoffeeScript ، مما يقلل من التكرار واللفظ في اللغة. لكن سرعان ما تلاشت ، وجاءت في مكانها الأدوات التي مكنت من إعادة استخدام الشفرة بأكبر قدر ممكن من الكفاءة ، واكتشاف الأخطاء بشكل ثابت ، وبناء التجريدات الفعالة ، و "إخفاء" مستويات فردية من التعقيد خلف واجهات بسيطة وصفها جيدًا.

ظهر GraphQL ، الذي يحل المشكلات المتعلقة بتعقيد وصف REST وتوثيقه وصيانته. ظهر TypeScript و Flow ، مما أدى إلى حل مشاكل عدم وجود الكتابة. ظهرت كيانات لغوية جديدة تتيح لك العمل بفعالية مع العمليات غير المتزامنة والفئات وتدفقات البيانات. لقد ظهر WebAssembly ، مما يسمح لك بإعادة استخدام التعليمات البرمجية من لغات أخرى ، والقيام بذلك بسرعة.

تهدف كل هذه الحلول إلى نفس الشيء: إعادة استخدام الرمز وإمكانية إنشاء فرق "مسطحة". يقومون بحل المشكلة من أجل أخذ رمز شخص آخر والبدء في استخدامه.

هذا دليل واضح على أن الويب يتطور نحو العمل في فرق كبيرة ، فقد أصبح منصة لحلول "الكبار".

أصبحت سلسلة من الأحداث التي حدثت أكثر دليلًا واضحًا: ظهرت React Native و NativeScript و Dart + Flutter وغيرها من الحلول لإعادة استخدام التعليمات البرمجية على الأنظمة الأساسية الأصلية. هذه نقطة مهمة للغاية: نظرًا للافتقار إلى القدرة على استخدام لغات أخرى على الويب ، بدأت الشركات في تحسين عملياتها بحثًا عن "رصاصة فضية" تتيح لها الحد من تكاليف التطوير الصغيرة والوقت اللازم لتوفير وظائف جديدة لجميع العملاء. من المهم أن يكون أي مشروع سريعًا ، وبدأ المتخصصون رفيعو المستوى في الاتحاد في البحث عن فرصة للعمل بفعالية على JS.

بالمناسبة ، للسبب نفسه ، بدأت محركات القوالب تموت جزئيًا: أثبت استخدام دلالات أخرى أنه أقل فعالية من استخدام HTML مألوف مع ملحقات صغيرة في JS (Angular ، Vue) أو باستخدام لغة لوصف التخطيط (React ، Flutter). أدت عدم القدرة على التوسع ، والحاجة إلى تعريف المطورين بلغة جديدة ، وخطر الموت على النظام الأساسي ، واللامركزية ، إلى حقيقة أنهم بدأوا في تفضيل إطارات الهيكل التي حاولت أن تكون أقرب إلى منصات HTML / DOM.

ومع ذلك ، بالإضافة إلى كتابة التعليمات البرمجية بكفاءة ، هناك أيضًا "معامل" لمزامنة أمر ما. إذا سمحت لك اللغة بالعمل بسرعة فائقة ، ولكن في نفس الوقت ، تؤدي مزامنة وظيفة فردية بين مطورين إلى إحداث ألم فظيع ، على الأرجح ستظل مكانة ملائمة. لذلك ، تهدف العديد من ميزات وحلول اللغة بشكل خاص إلى تقليل مشاكل المزامنة وعدم وجود مشاكل. إنها تقلل من هذا "المعامل" ، الذي يشير إلى عدد الصغار الذين يستطيعون التحكم في الوسط في وقت واحد ، وعدد السيطرة يمكن أن يتحكم فيها المطور الرئيسي. من أحدث الأمثلة على هذه الميزات ، تقوم واردات es6 بحل مشكلة التبعية الدورية جزئيًا ، بينما تتيح لك أجمل الحصول على الدمج المتوقع والمناسب تمامًا في كود git ، بصرف النظر عن كيفية قيام المطور بكتابة ذلك. لا ينبغي أن تكون جميلة ، يجب أن تكون متزامنة بشكل جيد.

ونتيجة لذلك ، خلال بضع سنوات فقط ، استحوذت الشركات الكبيرة والفرق الجادة على الإنترنت كمنصة ، ولهذا السبب عانت الأغلبية من "تعب جافا سكريبت" . بالمناسبة ، يكمن الادعاء الرئيسي في احتكار شركة Google تقريبًا على شبكة الإنترنت والذي يمثله Chromium في حقيقة أنها تدفع ما تحتاجه إلى قدرات منصة الويب و JS (على الرغم من أن هذا يتزامن عادة مع ما تحتاج إليه معظم الشركات).

نتيجة لذلك ، من ناحية ، حصلنا على منصة مبهجة للغاية لإعادة استخدام الشفرة في كل مكان ، وهي صيغة تسمح لك بالعمل باستخدام أوامر مسطحة كبيرة. لكن ...

أصبح كل شيء معقدًا وأصبح الجميع في حيرة من أمرهم

ولم يفهم أحد ماذا يفعل. ما هي في الواقع المشكلة؟ في هذه الفئات الثلاث المختلفة.

• تطوير مواقع ثابتة وشبه ثابتة تمامًا مع محتوى ديناميكي جزئيًا: يتميز هذا النوع من التطبيق بتنسيق HTML كنقطة دخول ، وسرعة تنزيل قصوى و JS اختياري
• تطوير تطبيقات الويب "الكلاسيكية" على أطر عمل الخادم (django ، القضبان): تتميز هذه الحلول حاليًا بالتحميل باستخدام HTML كنقطة دخول ، ولكن بدلاً من الحد الأقصى لسرعة التنزيل ، فإنها تركز على إعادة استخدام الكود ، DRY وتكامل الواجهة الخلفية. يتم إنشاء رمز JS جزئيًا بواسطة إطار العمل (الإشعارات والنماذج وروابط التوربو وما إلى ذلك) ، وتحتاج جزئيًا إلى كتابة نفسك
• تطوير تطبيق عميل الويب. هنا يحدث ما هو غير متوقع: يصبح HTML بدلاً من نقطة الإدخال بيانًا للتطبيق ومنصة تقديم ، ويصبح JS "نقطة دخول".

ما المقصود بنقطة إدخال: هذا كيان معين ، يكون تحميله مساوياً للحد الأدنى من التسليم لمستخدم المنتج. إذا احتاج المستخدم إلى إظهار المعلومات ، فسنحتاج إلى HTML + CSS ، وإذا قمنا بتشغيل التطبيق ، فسنحتاج إلى JS الذي يتم تشغيله من HTML.

ولإرباك الجميع تمامًا ، ظهرت فئة رابعة:

تطبيقات متجانسة

تحت عنوان "متماثل" في تطوير الويب عادة ما يعني شيئًا يعمل على كل من الخادم والعميل. في هذا الوضع ، تكون التطبيقات على رد الفعل ، الزاوي ، vue.js قادرة على العمل ، وهناك أطر جاهزة - التالي و Nuxt ، على سبيل المثال.

المهمتان مهمتان بالنسبة إليهما: يجب أن يقدم تطبيق الويب حالته الأولية للمستخدم في أسرع وقت ممكن ، ويعمل كالتطبيق. بمعنى آخر ، يجب عليهم تقديم كل من HTML و JS كنقطتي إدخال ، واحدة للمحتوى وواحدة للتطبيق. يؤدي هذا إلى إنشاء فقرتين متعارضتين: من ناحية ، يجب أن تكون كمية البيانات المقدمة ضئيلة ، ومن ناحية أخرى ، يلزم إعادة استخدام التعليمات البرمجية. بالنسبة لـ JS ، يتم حل ذلك عن طريق قطع حزم الويب وتقسيم الشفرة وتحميل الشفرة الديناميكية ، والقوالب المتبقية لـ JS ، ولكن لا يزال CSS قائما. والأهم من ذلك - أننا لا نريد تسليم بايت إضافي واحد للمستخدم. ثم طرح شخص ما الفكرة: تحتوي هذه التطبيقات حقًا على نقطتي دخول. يمكن معالجتها ككيانين مستقلين.

من هذا ، وُلد مفهوم CSS-in-JS ، مع التركيز على عمليتين منفصلتين: إنشاء ملف CSS للمحتوى الثابت ، وحفظ الأنماط بجانب المكونات.

كل شيء غادر لشبيبة.

الآن في JS ، يمكنك العثور على الأنماط والتخطيط والرمز الفعلي.

الآن كل شيء في شبيبة وهذا جيد

الأمر يستحق صنع استطرادا آخر - الآن إلى جانب البقالة.

من المهم لأي منتج في التطوير أو التطوير أن يكون قادرًا على "التحرك" في الاتجاه الآخر. يعمل على أي من المستويات:

• القدرة على تحويل مكون مرئي إلى مكون مع الحد الأدنى من المنطق عن طريق إضافة سطر من التعليمات البرمجية هو رائع جدا. الحاجة إلى إعادة كتابتها من الصفر ليست باردة.

  
  

• إن جعل استخدام SPA أو تطبيق جانب الخادم أمرًا رائعًا ، إلا أنه نادراً ما يكون ممكنًا. من الحكمة ، إذا لم تفرض التكاليف ، أن نبدأ من البداية بمثل هذه المنصة.

  
  

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

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

في حالة تطبيق على الزاوي / رد فعل / فيو ، وهذا هو بالضبط. من الصعب فهمها. بالطبع ليست معقدة مثل الزاوية 1 ، ولكن على أي حال - الطريق لفهمها طويل ، والدورات التدريبية التي تستغرق ستة أشهر ليست كافية لفهمها. لكنها توفر فرصة للقيام في غضون ساعات قليلة بما تم عمله قبل عدة أسابيع ، وفي بضعة أيام - ما كان يستغرق عدة أشهر.

ومع ذلك ، فإن العكس هو الصحيح أيضًا - فالعديد منهم لا يحتاجون إليها ، لكن يتم استخدامها لأنها "عصرية".

عندما يتحدث مهندس البنية التحتية لمجموعة تطبيقات الويب والجوال ومصمم التخطيط ، سيكون الأمر صعبًا بالنسبة لهما. الآن هذه هي اتجاهات مختلفة لدرجة أنها لن يكون لها تقاطعات في المعرفة ، باستثناء JS.

في المرة التالية التي تريد فيها أن تقول "الويب أصبحت معقدة للغاية ومتضخمة" - فكر في مدى صعوبة تصميم عميل بريد صندوق الوارد في google (مع الكيانات الذكية المضمنة اعتمادًا على الخطاب) أو IDE على الويب مثل Cloud9 أو الخدمات المصرفية عبر الإنترنت .

ولكن إذا جاء إليك المبرمج وبدأ في الحديث عن حقيقة أنه يحتاج إلى رد فعل ، لأنه يحتاج إلى طباعة صارمة وديكور لتخطيط الصفحة المقصودة ، فلا تستسلم للإقناع.