تصميم وبناء تطبيق ويب تقدمي بدون إطار (الجزء الأول)

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

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

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

ألا تريد أن تعرف كيف تتم الحيل؟

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

لكني أتقدم على نفسي قليلاً ؛ القليل من الخلفية أولا.

قبل أن أبدأ هذه الرحلة ، كنت أعتبر نفسي بارعًا للغاية في HTML و CSS ولكن ليس JavaScript. نظرًا لأنني شعرت أنني قد قمت بحل أكبر الأسئلة التي كانت لدي حول CSS بما يرضي ، كان التحدي التالي الذي حددته لنفسي هو فهم لغة البرمجة.

الحقيقة هي أنني كنت مبتدئًا نسبيًا في JavaScript. وبغض النظر عن اختراق PHP الخاص بـ Wordpress ، لم أتعرض أو أتدرب على أي لغة برمجة أخرى أيضًا.

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

لم يكن لدي أي فهم لأنماط تصميم جافا سكريبت - الأساليب المعمول بها لحل مشكلات التعليمات البرمجية التي يتم مواجهتها كثيرًا. بالتأكيد لم يكن لدي إحساس بكيفية التعامل مع قرارات تصميم التطبيق الأساسية.

هل لعبت "توب ترامب" من قبل؟ حسنًا ، في إصدار مطور الويب ، ستبدو بطاقتي كما يلي (علامة من 100):

• CSS: 95
• نسخ ولصق: 90
• خط الشعر: 4
• HTML: 90
• جافا سكريبت: 13

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

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

أخذ تحدي شخصي في ذهني: تصميم وبناء تطبيق ويب JavaScript من جانب العميل.

في التعلم

لم يكن هناك المزيد من الموارد الرائعة لتعلم لغات الحوسبة. على وجه الخصوص جافا سكريبت. ومع ذلك ، فقد استغرق الأمر بعض الوقت للعثور على الموارد التي تشرح الأشياء بطريقة نقرت. بالنسبة لي ، كان كتاب كايل سيمبسون "You Don't Know JS" و "Eloquent JavaScript" من تأليف Marijn Haverbeke بمثابة مساعدة كبيرة.

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

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

كما أنه ليس من المعقول أنك ستستمتع بأي نوع من لحظات اليوريكا حيث "ينقر" كل شيء فجأة ؛ مثل الترميز المكافئ للحب من النظرة الأولى. من المرجح أن الأمر سيستغرق الكثير من المثابرة والتطبيق الكبير لما تعلمته لتشعر بالثقة.

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

إليك بعض الموارد التي وجدتها مفيدة على طول الطريق:

• قناة يوتيوب وظيفة ممتعة
• دورات Kyle Simpson Plural Sight
• JavaScript30.com ويس بوس
• Eloquent JavaScript بواسطة Marijn Haverbeke

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

لماذا لا تتفاعل ، Ember ، Angular ، Vue Et Al

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

هناك الكثير من أطر عمل JavaScript عالية الجودة ومدعومة جيدًا. تم تصميم كل منها خصيصًا لبناء تطبيقات الويب من جانب العميل. بالضبط نوع الشيء الذي كنت أتطلع إلى بنائه. أسامحك على التساؤل عما هو واضح: مثل ، أخطأ ، لماذا لا تستخدم واحدًا؟

هذا هو موقفي من ذلك. عندما تتعلم استخدام فكرة مجردة ، فهذا ما تتعلمه في المقام الأول - التجريد. أردت أن أتعلم الشيء وليس تجريد الشيء.

أتذكر أنني تعلمت بعض jQuery مرة أخرى في اليوم. في حين أن واجهة برمجة التطبيقات الجميلة تسمح لي بجعل معالجة DOM أسهل من أي وقت مضى بدونها. لم أتمكن حتى من تبديل الفئات على عنصر دون الحاجة إلى jQuery. كلفني ببعض التفاعلية الأساسية على صفحة بدون jQuery لأتكئ عليها وتعثرت في محرري مثل Samson المنزوعة.

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

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

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

دعنا ننتقل إلى ما سيكون عليه هذا الشيء.

فكرة تطبيق

كنت بحاجة إلى فكرة التطبيق. لا شيء طموح للغاية. لم يكن لدي أي أوهام حول إنشاء شركة ناشئة أو الظهور على Dragon's Den - كان هدفي الأساسي هو تعلم JavaScript وأساسيات التطبيق.

يجب أن يكون التطبيق شيئًا أتيحت لي فرصة قتالية للانسحاب من الناحية الفنية والقيام بوظيفة تصميم نصف لائقة للإقلاع.

الوقت الظل.

بعيدًا عن العمل ، أنظم وألعب كرة القدم في الأماكن المغلقة كلما أمكنني ذلك. بصفتي منظمًا ، من المؤلم أن ألاحظ عقليًا من أرسل لي رسالة ليقول إنه يلعب ومن لا يفعل. تحتاج لعبة ما إلى 10 أشخاص عادةً ، 8 دفعة واحدة. هناك قائمة تضم حوالي 20 شخصًا قد يكونون قادرين أو غير قادرين على لعب كل لعبة.

كانت فكرة التطبيق التي استقرت عليها شيئًا مكّنني من اختيار اللاعبين من قائمة ، مما أعطاني عددًا من اللاعبين الذين أكدوا أنهم يستطيعون اللعب.

عندما فكرت في الأمر أكثر ، شعرت أنه يمكنني توسيع النطاق أكثر قليلاً بحيث يمكن استخدامه لتنظيم أي نشاط بسيط يعتمد على الفريق.

من المسلم به ، أنني بالكاد كنت أحلم ببرنامج Google Earth. ومع ذلك ، فقد واجهت جميع التحديات الأساسية: التصميم ، وإدارة البيانات ، والتفاعل ، وتخزين البيانات ، وتنظيم الكود.

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

من المؤكد أن الفكرة الأساسية اتجهت إلى تطبيقات أسلوب "المهام المطلوبة" ، والتي كانت هناك أكوام من الأمثلة الحالية التي يجب البحث عنها للحصول على الإلهام مع وجود فرق كافٍ لتوفير بعض تحديات التصميم والتشفير الفريدة.

الميزات المقصودة

بدت قائمة النقاط الأولية للميزات التي كنت أنوي تصميمها والتشفير كما يلي:

• مربع إدخال لإضافة أشخاص إلى القائمة ؛
• القدرة على ضبط كل شخص على "الدخول" أو "الخروج" ؛
• أداة تقسم الناس إلى فرق ، بالتقصير إلى فريقين ؛
• القدرة على حذف شخص من القائمة ؛
• بعض واجهات "الأدوات". إلى جانب التقسيم ، يجب أن تتضمن الأدوات المتاحة القدرة على تنزيل البيانات المدخلة كملف ، وتحميل البيانات المحفوظة مسبقًا وحذف جميع اللاعبين دفعة واحدة ؛
• يجب أن يُظهر التطبيق العدد الحالي لعدد الأشخاص الموجودين في "In" ؛
• إذا لم يتم اختيار أشخاص للعبة ، فيجب أن تخفي مقسم الفريق ؛
• وضع الدفع. تبديل في الإعدادات التي تسمح للمستخدمين "في" أن يكون لديهم تبديل إضافي لإظهار ما إذا كانوا قد دفعوا أم لا.

في البداية ، هذا ما اعتبرته ميزات لأدنى منتج قابل للتطبيق.

تصميم

بدأت التصاميم على قصاصات من الورق. كان من المفيد (اقرأ: سحق) أن أكتشف كم عدد الأفكار التي كانت لا تصدق في رأسي والتي تبين أنها سخيفة عندما تعرضت حتى للتدقيق الضئيل الذي يوفره الرسم بالقلم الرصاص.

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

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

بمجرد أن أكون سعيدًا بشيء كرسم بالقلم الرصاص ، سأحاول إعادة إنشائه في حزمة التصميم ، Sketch. تمامًا كما سقطت الأفكار بعيدًا في مرحلة الورق والقلم الرصاص ، فشل عدد متساوٍ في اجتياز مرحلة الإخلاص التالية من Sketch. تم اختيار اللوحات التي بدت وكأنها صامدة كلوحات فنية في Sketch كمرشحين للتشفير.

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

على هذا النحو ، في النهاية ، التصميم الذي انتهيت منه مختلف تمامًا عن التصميم الذي كان لدي في الأصل في Sketch. فيما يلي نماذج Sketch الأولى:

حتى في ذلك الوقت ، لم أكن أعاني من الأوهام. كان تصميمًا أساسيًا. ومع ذلك ، في هذه المرحلة ، كان لدي شيء كنت واثقًا نسبيًا من قدرته على العمل وكنت أقضم بعض الشيء لمحاولة بنائه.

متطلبات تقنية

مع بعض متطلبات الميزات الأولية والتوجيه المرئي الأساسي ، فقد حان الوقت للنظر في ما يجب تحقيقه باستخدام الكود.

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

كنت حريصًا أيضًا على التأكد من أن التطبيق قد حدد جميع المربعات اللازمة للتأهل كتطبيق ويب تقدمي ، أو PWA كما هو معروف بشكل أكثر شيوعًا.

إذا كنت غير مدرك لما هو تطبيق الويب التقدمي ، فهذه هي "خطوة المصعد". من الناحية المفاهيمية ، تخيل فقط تطبيق ويب قياسي ولكنه يلبي بعض المعايير المحددة. يعني الالتزام بهذه المجموعة من المتطلبات الخاصة أن الجهاز الداعم (فكر في الهاتف المحمول) يمنح تطبيق الويب امتيازات خاصة ، مما يجعل تطبيق الويب أكبر من مجموع أجزائه.

على نظام Android ، على وجه الخصوص ، قد يكون من المستحيل تقريبًا التمييز بين PWA ، الذي تم إنشاؤه باستخدام HTML و CSS و JavaScript فقط ، من تطبيق تم إنشاؤه باستخدام كود أصلي.

فيما يلي قائمة التحقق من Google لمتطلبات التطبيق ليتم اعتباره تطبيق ويب تقدميًا:

• يتم تقديم الموقع عبر HTTPS ؛
• تستجيب الصفحات على الأجهزة اللوحية والأجهزة المحمولة ؛
• يتم تحميل جميع عناوين URL الخاصة بالتطبيقات أثناء عدم الاتصال بالإنترنت ؛
• البيانات الوصفية المتوفرة للإضافة إلى الشاشة الرئيسية ؛
• أول تحميل سريع حتى على شبكة الجيل الثالث ؛
• يعمل الموقع عبر المتصفح ؛
• لا تشعر انتقالات الصفحة بأنها تحظر على الشبكة ؛
• كل صفحة لها عنوان URL.

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

• تتم فهرسة محتوى الموقع بواسطة Google ؛
• يتم توفير البيانات الوصفية لـ Schema.org عند الاقتضاء ؛
• يتم توفير البيانات الوصفية الاجتماعية عند الاقتضاء ؛
• يتم توفير عناوين URL الأساسية عند الضرورة ؛
• تستخدم الصفحات واجهة برمجة تطبيقات التاريخ ؛
• لا يقفز المحتوى أثناء تحميل الصفحة ؛
• يؤدي الضغط على رجوع من صفحة التفاصيل إلى الاحتفاظ بموضع التمرير في صفحة القائمة السابقة ؛
• عند النقر عليها ، لا تحجب لوحة المفاتيح على الشاشة المدخلات ؛
• يمكن مشاركة المحتوى بسهولة من الوضع المستقل أو وضع ملء الشاشة ؛
• يستجيب الموقع عبر أحجام شاشات الهاتف والجهاز اللوحي وسطح المكتب ؛
• لا يتم استخدام أي مطالبات لتثبيت التطبيق بشكل مفرط ؛
• تم اعتراض موجه إضافة إلى الشاشة الرئيسية ؛
• التحميل الأول بسرعة كبيرة حتى على شبكة الجيل الثالث ؛
• يستخدم الموقع شبكات ذاكرة التخزين المؤقت أولاً ؛
• يقوم الموقع بإعلام المستخدم بشكل مناسب عندما يكون غير متصل بالإنترنت ؛
• توفير سياق للمستخدم حول كيفية استخدام الإخطارات ؛
• يجب ألا تكون واجهة المستخدم التي تشجع المستخدمين على تشغيل "إشعارات الدفع" شديدة العدوانية ؛
• يقوم الموقع بتعتيم الشاشة عند ظهور طلب الإذن ؛
• يجب أن تكون الإخطارات الفورية ودقيقة وذات صلة ؛
• يوفر ضوابط لتمكين وتعطيل الإخطارات ؛
• يتم تسجيل دخول المستخدم عبر الأجهزة عبر واجهة برمجة تطبيقات إدارة بيانات الاعتماد ؛
• يمكن للمستخدم الدفع بسهولة عبر واجهة المستخدم الأصلية من Payment Request API.

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

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

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

خيارات التكنولوجيا

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

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

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

أي شيء يمكن أن يشير إلى أخطائي (التي من المؤكد أن تكون كثيرة) أثناء مسيرتي يجب أن يكون شيئًا جيدًا ، أليس كذلك؟

إذا لم تكن معتادًا على TypeScript ، ففكر في الكود التالي في Vanilla JavaScript:

 console.log(`${count} players`); let count = 0;

شغّل هذا الرمز وسيظهر لك خطأ مثل:

 ReferenceError: Cannot access uninitialized variable.

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

ومع ذلك ، إذا كتبت نفس الرمز في TypeScript ، فسيحدث هذا في المحرر:

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

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

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

هناك مزايا أخرى توفرها TypeScript سنأتي إليها في المقالة التالية في هذه السلسلة ، لكن إمكانات التحليل الثابت كانت كافية لوحدها لأرغب في استخدام TypeScript.

كانت هناك اعتبارات غير مباشرة للخيارات التي كنت أقوم بها. يعني اختيار إنشاء التطبيق كتطبيق ويب تقدمي أنني سأحتاج إلى فهم عمال الخدمة إلى حد ما. قد يعني استخدام TypeScript إدخال أدوات بناء من نوع ما. كيف يمكنني إدارة هذه الأدوات؟ تاريخيًا ، كنت قد استخدمت NPM كمدير حزم ولكن ماذا عن Yarn؟ هل كان الأمر يستحق استخدام الغزل بدلاً من ذلك؟ التركيز على الأداء يعني التفكير في بعض أدوات التصغير أو التجميع ؛ أصبحت أدوات مثل webpack أكثر شيوعًا وستحتاج إلى تقييم.

ملخص

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

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

سأحتاج إلى أدوات بناء ، ومدير حزم ، وبالتالي ، قدر كبير من الصبر.

في النهاية ، في هذه المرحلة ، بقي السؤال الأساسي: هل كان هذا شيئًا يمكنني إدارته بالفعل؟ أم أنني سأكون متواضعا بسبب عدم كفائتي؟

آمل أن تنضم إلي في الجزء الثاني حيث يمكنك أن تقرأ عن أدوات البناء وأنماط تصميم JavaScript وكيفية جعل شيء "يشبه التطبيق".