Native و PWA: خيارات ، وليس منافسين!
نشرت: 2022-03-10من الصعب معرفة بالضبط أين بدأ الخلاف بين "أصلي" و "ويب". أشعر أنها واحدة من تلك الأشياء التي كانت تتأرجح تحت السطح منذ الأيام الأولى لـ Flash ، فقط لتندلع مؤخرًا مع ظهور منصات الهواتف المحمولة. وبغض النظر عن ذلك ، فقد نجح المطورون في تجاوز هذه "الهوة الكبيرة" ، حيث قاموا بإلقاء الشتائم على بعضهم البعض في محاولة لدعم جانبهم.
ليس لدي مصلحة في تلك المعركة. بالتأكيد ، أنا "رجل ويب" ، لكن هذا لا يعني أنني لا أستطيع رؤية جاذبية التطوير المحلي ؛ أنا أيضًا مطور برمجيات. قبل كل شيء ، أنا براغماتي. أدرك أن كل مشروع مختلف وأن نهجنا لكل منها يجب أن يكون مفصلاً وفقًا لاحتياجات المشروع وأهدافه.
نظرًا لأن تطبيقات الويب التقدمية (PWAs) تتعدى على مجال التنمية المحلية ، فقد اعتقدت أن هذا قد يكون الوقت المناسب للتراجع وتقييم هذين النهجين لبناء المنتجات. آمل أن نبتعد جميعًا بالقدرة على رؤية نقاط القوة في كل نهج بوضوح على أمل العثور على المنتج المناسب للمنتجات التي نصنعها.
مقارنة سريعة لاطلاق النار
منذ البداية تقريبًا ، تمت مقارنة التجارب المستندة إلى الويب بكل شيء بدءًا من برامج سطح المكتب ("التطبيقات الأصلية" الأصلية) إلى الأقراص المضغوطة التفاعلية إلى Flash ، ومؤخراً ، إلى تطبيقات الأجهزة المحمولة. على الرغم من إعلان وفاته في مناسبات عديدة ، استمرت شبكة الإنترنت. في كثير من الحالات ، نجا من القتل المزعوم (RIP Flash).
واحدة من نقاط القوة الرئيسية للويب في هذا الصدد هي قدرتها على التكيف. لقد كان قادرًا على الذهاب إلى أي مكان يوجد به اتصال بالإنترنت ويستمر في اكتساب إمكانات جديدة. تتطور جميع لغات البرمجة ، لذا فهي ليست غير متوقعة ، ولكن بمرور الوقت استمرت حدود الويب المتزايدة في التعدي على مجال البرامج التقليدية.
مع ذلك ، كانت إحدى المجالات التي كانت شبكة الويب فيها عاجزة تاريخيًا هي مجال الأداء. البرامج المثبتة قادرة على الارتباط بنظام التشغيل الأساسي بطرق لا تستطيع الويب القيام بها. إنها مكتوبة بلغة مشتركة لمضيفها ، مع إمكانية الوصول المباشر إلى الأجهزة أو "أقرب إلى المعدن" كما نقول غالبًا. واجه الويب ، الذي يعمل دائمًا تقريبًا طبقة تجريدية واحدة أو أكثر فوق ذلك ، صعوبة في المنافسة عندما يتعلق الأمر بالأداء. بينما تضيق فجوة الأداء بمرور الوقت ، من المرجح أن يستمر تشغيل الكود الأصلي بشكل أسرع من كود الويب ، على الأقل حتى يصبح الويب قادرًا على تفسير الإشارات مباشرة من أطراف الجهاز.
جنبًا إلى جنب مع ميزة الأداء ، يتمتع التطوير الأصلي بوصول أكبر (وأقدم) إلى ميزات الجهاز مثل NFC و Bluetooth ومستشعرات القرب والضوء المحيط والمزيد. تكتسب الويب بشكل ثابت إمكانية الوصول إلى هذه الميزات أيضًا ، ولكنها ستتخلف دائمًا عن كونها أصلية لأن واجهات برمجة التطبيقات الأصلية تحتاج إلى التطوير قبل أن يتمكن الويب من الاستفادة منها ويستغرق التوحيد عبر نطاق المتصفح وقتًا.
بالإضافة إلى ذلك ، يمكن ربط الكود الأصلي بميزات على مستوى نظام التشغيل مثل دفتر العناوين والتقويمات. كانت الإشعارات الفورية واحدة أخرى كبيرة ، لكن عمال الخدمة الآن يمكّنون الويب من الاستفادة من هذه الميزة أيضًا. تم تحسين معالجة الدفع بالمثل على الويب مؤخرًا. ربما سيصل الوصول إلى دفتر العناوين والتقويم في النهاية على الويب أيضًا.
بالعودة إلى عمال الخدمة للحظة ، فإن هذه الإضافة الحديثة إلى مجموعة أدوات مطور الويب بها عدد من الحيل الأخرى في جعبتها أيضًا. بادئ ذي بدء ، فإنه يوفر نظام تخزين مؤقت أقوى بكثير مما كانت عليه شبكة الويب سابقًا باستخدام AppCache. يمكنك استخدام عمال الخدمة لإدارة الطلبات في وضع عدم الاتصال ، وتخزين موارد محددة مؤقتًا ، ومزامنة البيانات مع خادم بعيد عندما لا يكون الموقع مفتوحًا للمستخدم ، وأكثر من ذلك بكثير. ربما أكثر من أي تقنية مفردة أخرى ، مكّن العاملون في الخدمة الويب من تقديم تجربة أشبه بالتطبيقات.
عمال الخدمة هم أحد المحاور التقنية الثلاثة لـ PWAs. واحد آخر هو Web App Manifest. في حين أنه قد يبدو مملًا بعض الشيء ، فإن Web App Manifest هو في الواقع أداة قوية بشكل لا يصدق من حيث أنه يمكّن موقع الويب من الإعلان عن نفسه كتطبيق. يوفر تنسيق ملف JSON المباشر نسبيًا هذا ثروة من المعلومات حول موقع الويب الذي يصفه ويمكّن المتصفحات وأنظمة التشغيل المدركة لـ PWA من تثبيت الموقع كما لو كان برنامجًا أصليًا.
حتى أن بعض متاجر التطبيقات بدأت في فهرسة PWAs ، باستخدام Manifest لملء الإدخالات المرتبطة بها. من منظور المستخدم ، لا تختلف تطبيقات الويب الشخصية (PWA) في متاجر التطبيقات عن التطبيقات الأصلية المحيطة بها. إنها قابلة للتثبيت وغير قابلة للتثبيت ، ويمكنها حتى عرض إعداداتها لأداة إدارة تطبيقات نظام التشغيل الأساسية. تجدر الإشارة أيضًا إلى أن PWAs لا تحتاج فعليًا إلى مستخدم لتثبيتها بشكل صريح من أجل استخدامها لأنها ، حسناً ، تعيش على الويب.
إن كونك على الويب وعلى الويب يعني أيضًا أن PWAs محدثة دائمًا. لن يحتاج المستخدمون إلى تنزيل أي شيء جديد بشكل نشط للوصول إلى الوظائف الجديدة. وحتى عندما يتم طرح محتوى وميزات جديدة ، فمن غير المرجح أن يحتاج المستخدم إلى إعادة تنزيل ملف PWA بالكامل كما هو الحال في معظم التطبيقات الأصلية. إذا كان هناك أي شيء ، فقد يحصلون على بعض الأصول الجديدة وبعض HTML الجديد ، وسيحدث ذلك على الفور إلى حد كبير ، ولا يلزم وجود متجر تطبيقات. بالطبع ، لا يزال لديك خيار الاكتشاف والتوزيع الذي توفره متاجر التطبيقات ، لذا فهو حقًا الأفضل في كلا العالمين.
إن التواجد في متاجر التطبيقات يضع PWAs على قدم المساواة مع التطبيقات المحلية من حيث الاكتشاف والتوزيع وتحقيق الدخل. في الواقع ، قد يتم تخزين الويب عبر الويب الأصلي حيث يمكن أيضًا اكتشاف PWAs عبر محركات البحث وتكون أكثر قابلية للمشاركة من التطبيقات لأنها موجودة على عنوان URL. عندما تكون PWAs جيدة البناء ، فإنها أيضًا قابلة للتشغيل المتبادل عبر المتصفحات والأنظمة الأساسية والأجهزة. تعمل PWAs حتى في المتصفحات التي لا تدعم ميزات مثل عمال الخدمة ، لأن ميزات PWA هي تحسينات تقدمية.
يوفر الويب أيضًا دعمًا ناضجًا جدًا لإمكانية الوصول ، مما يجعل من السهل نسبيًا ضمان أن مشاريعك قابلة للاستخدام من قبل أكبر عدد من المستخدمين. تتطلب الواجهات المعقدة مزيدًا من العناية عندما يتعلق الأمر بالبرمجة ، ولكن مزايا إمكانية الوصول التي يوفرها HTML الدلالي تتعامل مع إمكانية الوصول الأساسية مع الثقة بالنفس - خاصةً عندما يتعلق الأمر بالنص الثقيل أو بالمعلومات أو المنتجات البسيطة المستندة إلى النموذج. على النقيض من ذلك ، تحتاج دائمًا تقريبًا إلى أن تكون على دراية بواجهات API الخاصة بإمكانية الوصول وتضمينها في التعليمات البرمجية الأصلية الخاصة بك.
فيما يتعلق بموضوع التنمية ، لا أعتقد أن هناك فائزًا واضحًا عندما يتعلق الأمر بتجربة التطوير. كل لغة لها معجبوها ، ويمكن قول الشيء نفسه عن أدوات المطورين. أنت تحب ما تحب ، وتميل إلى أن تكون أكثر كفاءة باستخدام الأدوات واللغات التي تعرفها وتتحمس لها. لا يوجد أي ميزة واضحة هناك لا للويب ولا للتطوير المحلي.
ومع ذلك ، يتألق التطوير المحلي عندما يتعلق الأمر بضمان مستوى ثابت من الجودة لواجهات المستخدم ، التي تم إنشاؤها باستخدام SDKs (مجموعات تطوير البرامج). توفر معظم حزم SDK الأصلية أدوات لاختبار الأداء والتصميم والوظائف والمزيد. وهي تشمل أيضًا التعليمات البرمجية المعيارية وأنظمة التصميم والأدوات الأخرى التي تساعد في رفع المستوى العام لعروض البرامج الأصلية. بالتأكيد ، هناك أدوات مماثلة للويب ، لكنها مبعثرة عبر الويب وليست عالمية في جميع بيئات التطوير المختلفة التي يستخدمها الأشخاص لبناء مواقع الويب. لا يوجد كيان واحد يحدد تجارب الويب عالية الجودة ويوفر الأدوات اللازمة لإنشائها (على الرغم من أن الكثيرين قد حاولوا).
عندما يتعلق الأمر بتوظيف تطوير منتج ما ، فمن الأسهل بالتأكيد توظيف أشخاص يعرفون كيفية البناء للويب. أثناء الكتابة ، يصنف فهرس لغة البرمجة حاليًا JavaScript باعتبارها اللغة الأكثر شيوعًا ، مع وجود Java خلفها مباشرةً. C # في المركز الخامس ، HTML في المركز السابع ، CSS في المرتبة التاسعة ، و Swift في المركز الخامس عشر. يقوم هذا الفهرس بإحالة إشارات Stack Overflow ذات الخطوط التي تم تغييرها في المستودعات العامة على GitHub ، لذا يجب أخذها بحذر ، ولكنها توفر إشارة واضحة إلى أن العديد من الأشخاص يعرفون (ويستخدمون) تقنيات الويب. على الجانب الآخر ، غالبًا ما يكون من الصعب العثور على مطورين محليين موهوبين وتوظيفهم لأن هناك عددًا أقل منهم ويزداد الطلب عليهم.
الموهبة النادرة تعني أنك ستنتهي على الأرجح بدفع المزيد من أجل التنمية المحلية. من الواضح أن كل مشروع مختلف وله ميزات ومتطلبات مختلفة ، ولكن قد يكون من التوضيح النظر إلى متوسط تكاليف التطوير على سبيل المقارنة. يقترح Comentum أن بناء تطبيق ويب متوسط الحجم يتراوح من أقل من 10،000 دولار أمريكي إلى 150،000 دولار أمريكي. في النهاية الأصلية ، تقدر شركة Appster أن مشاريع تطبيقات الأجهزة المحمولة متوسطة الحجم تكلف ما بين 110.000 دولار أمريكي و 305.000 دولار أمريكي لإنشائها. ربما يكون من الآمن افتراض أن تكلفة تطوير المشاريع المحلية تبلغ ضعف تكلفة تطوير مشروع ويب. وهذا لكل منصة. عادةً ما يستغرق تطوير التطبيقات الأصلية وقتًا أطول.
تجدر الإشارة إلى أن هناك خيارات لإنشاء برامج أصلية باستخدام تقنيات الويب دون إنشاء PWA. تمكّنك الأطر مثل React Native و PhoneGap و Ionic و Appcelerator Titanium من إنشاء كود أصلي من HTML و CSS و JavaScript. يمكن أن يؤدي استخدام إحدى هذه الأدوات إلى خفض تكاليف التوظيف والتطوير عند مقارنتها بتعيين فريق من المطورين الأصليين ، ولكن فيما يتعلق بالوصول إلى ميزات الجهاز ، سيقتصر مشروعك على تلك التي طبقها إطار العمل. خطط وفقًا لذلك.
بمجرد تطوير التطبيق ، يجب عليك أيضًا حساب تكاليف الصيانة المستمرة للتطبيق أو التطبيقات المذكورة. استجابةً لمسح أجرته Clutch ، يوصي Dom & Tom بوضع ميزانية بنسبة 50٪ من السعر الأولي للمنتج في السنة الأولى ، و 25٪ في السنة الثانية ، وما بين 15-25٪ لكل عام بعد ذلك.
بمجرد أن يكون لديك فهم جيد لكيفية مقارنة وتباين تطوير الويب والتطوير المحلي ، يمكنك البدء في تقييم نقاط القوة والضعف ذات الصلة بمشروعك. من المحتمل أن تقوم ببعض المقايضات ، وهذا أمر متوقع. لا يوجد حل واحد يناسب الجميع. وإذا كان هناك ، فلن يناسب أي شخص بشكل جيد.
دعونا نجري في مشروعين افتراضيين لإبراز الفروق بين التطوير المحلي و PWA بشكل أكثر وضوحًا.
المشروع رقم 1: تطبيق أصلي موجود
لنفترض أنك مررت بالفعل بعملية إنشاء تطبيق محلي. إذا كان كل شيء يسير على ما يرام ، فلا داعي لتغيير المسار. لا تتخلص من كل عملك الحالي للتبديل إلى PWA ما لم يكن لديك سبب وجيه للقيام بذلك. يمكنني فقط التفكير في سيناريو واحد قد يستدعي التفكير في التبديل إلى PWA: تقديم الدعم لنظام تشغيل جديد في هذا المزيج. وحتى مع ذلك ، من المنطقي حقًا فقط إذا كان من الممكن تلبية احتياجات تطبيقك عن طريق الويب وحده.
إذا كنت تضيف دعمًا لمنصة جديدة إلى منتج ما ، فإنها تخلق فرصة مثالية لتقييم احتياجات وأهداف المشروع فيما يتعلق بتكلفة تلبية تلك الاحتياجات. إذا لم يكن الويب على مستوى المهمة ، فالتزم بالاصلي. إذا كان الأمر كذلك ، فتوقف مؤقتًا وفكر في ما يلي: ستسمح لك إضافة دعم للنظام الأساسي الجديد باستخدام PWA بدعم منصات إضافية (بما في ذلك الويب) على الطريق وقد تمكنك حتى من استبدال التطبيق الأصلي الحالي بمجرد أن يكون PWA لديه تم اختباره بدقة.
إذا كان استبدال تطبيق أصلي حالي بـ PWA يبدو غير وارد بالنسبة لك ، فضع في اعتبارك أن Starbucks و Twitter يستكشفان هذه الفكرة بالفعل.
إذا كانت هناك أسباب محددة تحتاجها للحفاظ على تطبيقاتك أصلية ، فلا يزال من المفيد التفكير في "الاستعانة بمصادر خارجية" لبعض ميزات التطبيقات على الويب. قبل بضع سنوات ، كنت أعمل في مشروع لشركة خدمات مالية كبيرة ، وقد اختاروا نقل تدفق تسجيل الدخول لتطبيقاتهم الأصلية إلى الويب لتمكينهم من طرح ميزات الأمان بسرعة أكبر من متجر التطبيقات النموذجي عملية الموافقة مكنتهم من تحقيق. ربما يكون لمشروعك احتياجات مماثلة يمكن للويب أن يمكّن تطبيقك المحلي من تلبيتها.
المشروع رقم 2: تطبيق موجود عبر الأنظمة الأساسية
إذا كان لديك تطبيق حالي يعمل عبر الأنظمة الأساسية ، فمن المحتمل أنك تنفق الكثير من الأموال من أجل التطوير المستمر لهذا التطبيق وصيانته. من المحتمل أيضًا أنك ترى بعض ميزات الاختلاف داخل التطبيق لأن كل منصة أصلية تميل إلى أن يكون لها جدول زمني للتطوير الخاص بها. على سبيل المثال ، يتيح التطبيق الخاص ببائع التجزئة Target حاليًا للمستخدمين إدارة قائمة التسوق على نظام iOS ، لكن إصدار Android لا يحتوي على هذه الميزة. إنه مشابه من نواح كثيرة للاختلاف الذي نراه أحيانًا بين إصداري "سطح المكتب" و "الجوال" لموقع الويب.
إذا كان الويب بالفعل جزءًا من مزيج الأنظمة الأساسية الخاص بك ، فإنه يوفر فرصة جيدة لمضاعفة استثماراتك هناك والنظر في استبدال تطبيقاتك الأصلية بـ PWAs. يمكن أن توفر لك أدوات مثل السونار والمنارة نظرة ثاقبة حول مدى جودة إعداد موقعك الحالي لتهيئة PWA ويمكنها أيضًا إخبارك بما تحتاج إلى العمل عليه. من هناك ، يعد تحويل موقع الويب الخاص بك إلى PWA أمرًا بسيطًا نسبيًا. حتى أن هناك أدوات مجانية يمكن أن تساعدك في ترقية موقعك إلى PWA في بضع دقائق قصيرة. إذا لم يكن الأمر كذلك ، فليس هناك حافزًا كبيرًا للقيام بهذه الخطوة ما لم يصبح اختلاف الميزات بين الأنظمة الأساسية فظيعًا حقًا أو إذا كنت تفكر في إضافة نظام أساسي آخر (أو الويب) إلى هذا المزيج.
المشروع رقم 3: منتج جديد متعدد المنصات
إذا كنت تبدأ مشروعًا جديدًا يستهدف أكثر من منصة واحدة ، فإن إنشائه وصيانته في مكان واحد حيث يجب أن يكون PWA بالتأكيد على الطاولة. اعتمادًا على ميزانيتك وموظفيك ، من المحتمل أن تزيد ميزانيتك إلى أبعد الحدود. ومع ذلك ، إذا كان منتجك يتطلب اتصالاً مباشرًا بالأجهزة أو نظام التشغيل الأساسي ، فقد لا تزال بحاجة إلى أن تصبح أصليًا. ولكن قبل أن تسلك هذا الطريق ، قم بعمل قائمة بجميع متطلباتك ثم تحقق مما يمكن أن يفعله الويب (وما لا يمكنه القيام به). تأكد من التحقق من الدعم في أكثر من متصفح واحد أيضًا.
المشروع رقم 4: منتج جديد شديد التركيز
إذا كنت تقوم ببناء منتج جديد وجزء من الغرض الكامل لهذا المنتج هو اتصاله العميق بمنصة معينة ، فبكل الوسائل ، قم ببناء هذا النظام الأساسي. على سبيل المثال ، إذا كان منتجك يعتمد على نظام رسائل Apple أو التكامل مع HomeKit ، فبكل الوسائل ، صمم لنظام iOS و / أو macOS في Swift. إذا كان منتجك سيلبي احتياجات المستخدم بشكل أفضل عبر عنصر واجهة مستخدم أو كنت تقوم ببناء مشغل مخصص ، فمن الأفضل لك إنشاء Android ، وستحتاج إلى استخدام Java.
ومع ذلك ، ليست كل السمات الأصلية عبارة عن حدائق مسورة. بينما تتطلب كل من Alexa من Amazon و Apple's Siri ومساعد Google رمزًا أصليًا (أو واجهة برمجة تطبيقات JSON) للتكامل مع تطبيقك ، فمن المثير للاهتمام أن Cortana من Microsoft ستقوم بتمكين PWA الخاص بك باستخدام ملف XML مرتبط من head HTML الخاص بك. ربما سيتبع الآخرون قيادتهم.
PWA أم أصلي؟ الخيار لك
كل من الويب والأصلي لديهم الكثير ليقدمه. إذا سألتني أيهما أفضل ، فسأجيب ببساطة "يعتمد الأمر" لأنه كذلك. أنا لست مراوغا أو غير ملزم. يعتمد اكتشاف الخيار المناسب لمشروعك كليًا على الاحتياجات المحددة لمشروعك. يتطلب الأمر مراعاة ما تقوم ببنائه ، وتكوين الفريق الحالي المكلف ببنائه أو الفريق الذي ستحتاج إلى تعيينه للقيام بذلك ، والميزانية التي يتعين عليك العمل بها. في كثير من الحالات ، يقدم الويب على الأرجح كل ما تحتاجه لتحقيق أهداف مشروعك ، ولكن هناك دائمًا استثناءات. إذا كنت ترغب في استكشاف الاحتمالات التي يوفرها الويب ، فقد قمت بتضمين بعض الموارد في نهاية هذه المقالة.
أهم شيء يمكنك القيام به عند الموازنة بين الأساليب المختلفة لتطوير البرامج - أو الأطر المختلفة ، والمكتبات ، واللغات ، وأنظمة التصميم ، وما إلى ذلك - هو النظر في خياراتك فيما يتعلق بالمشروع المطروح. قم ببحثك ووزن خياراتك. ولا تسمح لنفسك بالتأثير بطريقة أو بأخرى من خلال التسويق الذكي أو العروض التوضيحية المثيرة أو المعجبين المسعورين. بما في ذلك هذا.
الموارد ذات الصلة بـ PWA
- منشئ PWA
أداة إنشاء من موقع ويب إلى PWA من 3 خطوات مع توصيات ووصفات مفيدة. كما أنه يمكّنك من تحويل PWA إلى تطبيقات أصلية قابلة للتثبيت لأنظمة Windows و Android و iOS. - خريطة طريق تقدمية لتطبيق الويب التقدمي الخاص بك
تحدث Jason Grigsby عن كيفية بدء فريقه بدمج جوانب PWAs في موقع الويب الخاص بهم على مدار عدة أشهر ، موضحًا بشكل جيد كيف يمكن إضافة الميزات المختلفة قليلاً في كل مرة. - نعم ، يجب أن يكون مشروع الويب هذا PWA
نظرة عامة على فرص تجربة المستخدم (ومخاطرها) الخاصة بـ PWAs ، مكتوبة بواسطتك حقًا. - تطبيقات الويب التقدمية على MDN
محور لجميع البتات التقنية التي تحتاج إلى معرفتها حول ما يميز PWA عالي الجودة. - ما يمكن أن يفعله الويب اليوم
ألقِ نظرة على واجهات برمجة التطبيقات التي تدعم جهازك ونظام التشغيل والمتصفح. ما تجده قد يفاجئك. - هل بإمكاني استخدم
قاعدة البيانات النهائية لماهية واجهات برمجة التطبيقات والميزات المتوفرة في كل متصفح رئيسي وكيف يقيس هذا الدعم بالنسبة للمتصفحات التي يستخدمها الأشخاص بالفعل. يمكن أن يمنحك أيضًا عرضًا ممتازًا للوراء في الوقت المناسب لمعرفة مدى توافق ميزات معينة مع الإصدارات السابقة.