Native y PWA: ¡Opciones, no retadores!

Es difícil decir exactamente dónde comenzó realmente la brecha entre "nativo" y "web". Siento que es una de esas cosas que se han estado agitando bajo la superficie desde los primeros días de Flash, solo para estallar más recientemente con el surgimiento de las plataformas móviles. De todos modos, los desarrolladores se han enfrentado a través de este "gran abismo", lanzándose insultos entre sí en un intento de reforzar su propio lado.

No tengo ningún interés en esa pelea. Claro, soy un "chico web", pero eso no significa que no pueda ver el atractivo del desarrollo nativo; También soy desarrollador de software. Sobre todo, sin embargo, soy un pragmático. Me doy cuenta de que cada proyecto es diferente y que nuestro enfoque para cada uno debe adaptarse a las necesidades y objetivos del proyecto.

Con las aplicaciones web progresivas (PWA) invadiendo el territorio del desarrollo nativo, pensé que este podría ser un buen momento para dar un paso atrás y hacer un balance de estos dos enfoques para crear productos. Mi esperanza es que todos salgamos con la capacidad de ver claramente las fortalezas de cada enfoque con la esperanza de encontrar el ajuste adecuado para los productos que creamos.

Una comparación rápida

Prácticamente desde el principio, las experiencias basadas en la web se han comparado con todo, desde software de escritorio (las "aplicaciones nativas" originales) hasta CD-ROM interactivos, Flash y, más recientemente, aplicaciones móviles. A pesar de haber sido declarado muerto en numerosas ocasiones, la web ha persistido. En muchos casos, incluso sobrevivió a sus presuntos asesinos (RIP Flash).

Una de las principales fortalezas de la web en este sentido es su adaptabilidad. Ha sido capaz de ir prácticamente a cualquier lugar donde haya una conexión a Internet y continúa adquiriendo nuevas capacidades. Todos los lenguajes de programación evolucionan, por lo que no es inesperado, pero con el tiempo, las crecientes fronteras de la web han seguido invadiendo el territorio del software tradicional.

Sin embargo, un área en la que históricamente la web se ha quedado corta ha sido en el ámbito del rendimiento. El software instalado puede vincularse al sistema operativo subyacente de formas que la web simplemente no puede. Están escritos en la lingua franca de su host, con acceso directo al hardware o "más cerca del metal", como solemos decir. La web, que casi siempre opera una o más capas de abstracción por encima de eso, ha tenido dificultades para competir en lo que respecta al rendimiento. Si bien la brecha de rendimiento se ha reducido con el tiempo, es probable que el código nativo continúe ejecutándose más rápido que el código web, al menos hasta que la web sea capaz de interpretar señales directamente desde los pines del hardware.

Junto con la ventaja de rendimiento, el desarrollo nativo tiene un acceso mucho mayor (y más temprano) a funciones del dispositivo como NFC, Bluetooth, sensores de luz ambiental y de proximidad, y más. La web también está ganando acceso a estas funciones de manera constante, pero siempre se quedará atrás de las nativas porque las API nativas deben desarrollarse antes de que la web pueda acceder a ellas y la estandarización en todo el navegador lleva tiempo.

Además, el código nativo puede conectarse a funciones a nivel del sistema operativo, como la libreta de direcciones y los calendarios. Las notificaciones automáticas fueron otra importante, pero Service Workers ahora también permite que la web aproveche esa función. El procesamiento de pagos ha mejorado de manera similar en la web recientemente. Tal vez el acceso a la libreta de direcciones y al calendario también llegará a la web.

Volviendo a Service Workers por un momento, esta reciente incorporación a la caja de herramientas del desarrollador web también tiene otros trucos bajo la manga. En primer lugar, ofrece un sistema de almacenamiento en caché mucho más robusto que el que tenía la web anteriormente con AppCache. Puede usar Service Workers para administrar solicitudes fuera de línea, almacenar en caché recursos específicos, sincronizar datos con un servidor remoto cuando el usuario ni siquiera tiene el sitio abierto y mucho más. Quizás más que cualquier otra tecnología individual, Service Workers ha permitido que la web ofrezca una experiencia más similar a una aplicación.

Los Service Workers son uno de los tres ejes técnicos de las PWA. Otro es el manifiesto de la aplicación web. Si bien puede parecer un poco aburrido, un manifiesto de aplicación web es en realidad una herramienta increíblemente poderosa que permite que un sitio web se anuncie como una aplicación. Este formato de archivo JSON relativamente sencillo proporciona una gran cantidad de información sobre el sitio web que describe y permite que los navegadores y sistemas operativos compatibles con PWA instalen el sitio como si fuera un software nativo.

Algunas tiendas de aplicaciones incluso están comenzando a indexar PWA, utilizando su Manifiesto para completar sus entradas asociadas. Desde la perspectiva del usuario, las PWA en las tiendas de aplicaciones no son diferentes de las aplicaciones nativas que las rodean. Se pueden instalar, desinstalar e incluso pueden exponer su configuración a la herramienta de administración de aplicaciones del sistema operativo subyacente. También vale la pena señalar que los PWA en realidad no necesitan que un usuario los instale explícitamente para poder usarlos porque, bueno, viven en la web.

Estar tanto dentro como fuera de la web también significa que las PWA siempre están actualizadas. Los usuarios no necesitarán descargar activamente nada nuevo para acceder a la nueva funcionalidad. E incluso cuando se implementan nuevos contenidos y funciones, es muy poco probable que un usuario necesite volver a descargar toda su PWA como lo haría en el caso de la mayoría de las aplicaciones nativas. En todo caso, pueden obtener algunos activos nuevos y algo de HTML nuevo, y sucedería de manera bastante instantánea, sin necesidad de una tienda de aplicaciones. Por supuesto, todavía tiene la opción de descubrimiento y distribución proporcionada por las tiendas de aplicaciones, por lo que realmente es lo mejor de ambos mundos.

Estar en las tiendas de aplicaciones pone a las PWA en pie de igualdad con las aplicaciones nativas en términos de descubrimiento, distribución y monetización. De hecho, es posible que incluso salte la web sobre la nativa, ya que las PWA también se pueden descubrir a través de los motores de búsqueda y se pueden compartir infinitamente más que las aplicaciones porque existen en una URL. Cuando están bien construidos, los PWA también son interoperables entre navegadores, plataformas y dispositivos. Los PWA incluso funcionan en navegadores que no admiten funciones como Service Workers, porque las funciones de PWA son mejoras progresivas.

La web también ofrece soporte de accesibilidad muy maduro, lo que hace que sea relativamente fácil garantizar que sus proyectos sean utilizables por la mayor cantidad de usuarios. Las interfaces complejas requieren un poco más de diligencia cuando se trata de programación, pero los beneficios de accesibilidad que ofrece HTML semántico manejan la accesibilidad básica con aplomo, especialmente cuando se trata de productos basados ​​en formularios simples, informativos o con mucho texto. Por el contrario, casi siempre debe conocer e incorporar las API de accesibilidad en su código nativo.

Sobre el tema del desarrollo, no creo que haya un ganador claro cuando se trata de la experiencia de desarrollo. Cada idioma tiene sus fans, y lo mismo puede decirse de las herramientas para desarrolladores. Te gusta lo que te gusta y tiendes a ser más eficiente con las herramientas y los lenguajes que conoces y te apasionan. Ni la web ni el desarrollo nativo tienen ninguna ventaja clara allí.

Sin embargo, donde el desarrollo nativo brilla es cuando se trata de garantizar un nivel constante de calidad para las interfaces de usuario, creadas con sus SDK (kits de desarrollo de software). La mayoría de los SDK nativos ofrecen herramientas para probar el rendimiento, el diseño, la funcionalidad y más. También incluyen código repetitivo, sistemas de diseño y otras herramientas que ayudan a elevar el nivel general de las ofertas de software nativo. Claro, hay herramientas similares para la web, pero están dispersas en la web y no son universales en todos los diferentes entornos de desarrollo que la gente usa para crear sitios web. No existe una sola entidad que defina experiencias web de calidad y proporcione las herramientas para construirlas (aunque muchos lo han intentado).

Cuando se trata de contratar personal para el desarrollo de un producto, definitivamente es más fácil contratar personas que sepan cómo crear para la web. Mientras escribo, el Índice de lenguajes de programación actualmente clasifica a JavaScript como el lenguaje más popular, seguido de Java. C# está en el quinto lugar, HTML en el séptimo, CSS en el noveno y Swift en el decimoquinto. Este índice hace referencia cruzada a etiquetas de desbordamiento de pila con líneas cambiadas en repositorios públicos en GitHub, por lo que debe tomarse con cuidado, pero proporciona una indicación bastante clara de que muchas personas conocen (y usan) tecnologías web. Por otro lado, a menudo puede ser un desafío encontrar y contratar desarrolladores nativos talentosos porque hay menos de ellos y tienen una gran demanda.

La escasez de talento significa que probablemente terminará pagando más por el desarrollo nativo. Obviamente, cada proyecto es diferente y tiene características y requisitos diferentes, pero puede ser ilustrativo observar los costos de desarrollo promedio como una comparación. Comentum sugiere que la creación de una aplicación web de tamaño moderado oscila entre menos de 10 000 y 150 000 dólares estadounidenses. En el extremo nativo, Appster estima que la creación de proyectos de aplicaciones móviles de tamaño moderado cuesta entre 110 000 y 305 000 dólares estadounidenses. Probablemente sea seguro asumir que es probable que los proyectos nativos cuesten aproximadamente el doble de lo que cuesta desarrollar un proyecto web. Y eso es por plataforma. Las aplicaciones nativas también suelen tardar más en desarrollarse.

Vale la pena señalar que existen opciones para crear software nativo utilizando tecnologías web sin crear una PWA. Frameworks como React Native, PhoneGap, Ionic y Appcelerator Titanium le permiten generar código nativo a partir de HTML, CSS y JavaScript. El uso de una de estas herramientas podría reducir los costos de personal y desarrollo en comparación con la contratación de un equipo de desarrolladores nativos, pero en términos de acceso a las funciones del dispositivo, su proyecto se limitará a las implementadas por el marco. Planifique en consecuencia.

Una vez que se desarrolla la aplicación, también debe tener en cuenta los costos continuos de mantenimiento de dicha aplicación o aplicaciones. En respuesta a una encuesta realizada por Clutch, Dom & Tom recomienda presupuestar el 50 % del precio inicial del producto en el primer año, el 25 % en el segundo año y entre el 15 y el 25 % para cada año posterior.

Una vez que tenga una comprensión adecuada de cómo se comparan y contrastan el desarrollo web y nativo, puede comenzar a evaluar qué fortalezas y debilidades son relevantes para su proyecto. Es probable que tengas que hacer algunas concesiones, y eso es de esperar. No existe una solución única para todos. Y si lo hubiera, no le quedaría bien a nadie.

Repasemos un par de proyectos hipotéticos para enfocar más claramente las distinciones entre el desarrollo para nativos y PWA.

Proyecto n.º 1: una aplicación nativa existente

Supongamos que ya pasó por el proceso de creación de una aplicación nativa. Si todo va bien, no hay motivo para cambiar de rumbo. No deseche todo su trabajo existente para cambiar a un PWA a menos que tenga una muy buena razón para hacerlo. Realmente solo puedo pensar en un escenario que podría justificar considerar un cambio a PWA: traer soporte para un nuevo sistema operativo a la mezcla. E incluso entonces, solo tiene sentido si las necesidades de su aplicación pueden ser satisfechas solo por la web.

Si está agregando soporte para una nueva plataforma a un producto, crea la oportunidad perfecta para evaluar las necesidades y objetivos del proyecto con respecto al costo de satisfacer esas necesidades. Si la web no está a la altura de la tarea, quédese con nativo. Sin embargo, si es así, deténgase y considere esto: agregar soporte para la nueva plataforma usando un PWA le permitiría admitir plataformas adicionales (incluida la web) en el futuro e incluso podría permitirle reemplazar su aplicación nativa existente una vez que el PWA haya terminado. sido probado minuciosamente.

Si le parece impensable reemplazar una aplicación nativa existente con un PWA, considere esto: Starbucks y Twitter ya están explorando esta idea.

Si hay razones específicas por las que necesita mantener sus aplicaciones nativas, aún puede valer la pena considerar "externalizar" ciertas funciones de la aplicación a la web. Hace unos años, estaba trabajando en un proyecto para una gran empresa de servicios financieros, y optaron por mover el flujo de inicio de sesión de sus aplicaciones nativas a la web para permitirles implementar funciones de seguridad más rápidamente que la típica tienda de aplicaciones. proceso de aprobación les permitió lograr. Tal vez su proyecto tenga necesidades similares que la web podría permitir que su aplicación nativa satisfaga.

Proyecto n.º 2: una aplicación multiplataforma existente

Si tiene una aplicación existente que funciona en varias plataformas, es probable que esté gastando una gran cantidad de dinero en el desarrollo y mantenimiento continuos de esa aplicación. También es probable que vea algunas características divergentes en la aplicación, ya que cada plataforma nativa tiende a tener su propia línea de tiempo de desarrollo. La aplicación para el minorista Target, por ejemplo, actualmente permite a los usuarios administrar una lista de compras en iOS, pero la versión de Android no tiene esa función. En muchos sentidos, es similar a la divergencia que a veces vemos entre las versiones "de escritorio" y "móvil" de un sitio web.

Si la web ya es parte de su combinación multiplataforma, brinda una buena oportunidad para duplicar sus inversiones allí y considerar reemplazar sus aplicaciones nativas con PWA. Herramientas como sonar y Lighthouse pueden brindarle una idea de qué tan bien preparado está su sitio existente para la ificación de PWA y también pueden decirle en qué necesita trabajar. A partir de ahí, convertir su sitio web en una PWA es relativamente sencillo. Incluso hay herramientas gratuitas que pueden ayudarlo a actualizar su sitio a un PWA en unos pocos minutos. Sin embargo, si no es así, realmente no hay mucho incentivo para hacer este movimiento a menos que la divergencia de características entre plataformas se vuelva realmente notoria o esté considerando agregar otra plataforma nativa (o la web) a la mezcla.

Proyecto n.º 3: un nuevo producto multiplataforma

Si está iniciando un nuevo proyecto dirigido a más de una plataforma, crearlo y mantenerlo en un solo lugar como PWA definitivamente debería estar sobre la mesa. Dependiendo de su presupuesto y personal, es probable que estire más su presupuesto. Dicho esto, si su producto requiere una conexión directa al hardware o al sistema operativo subyacente, es posible que aún deba volverse nativo. Pero antes de seguir ese camino, haga una lista de todos sus requisitos y luego verifique qué puede hacer la web (y qué no). Asegúrese de buscar soporte en más de un navegador también.

Proyecto #4: Un Nuevo Producto Hiper-Enfocado

Si está creando un nuevo producto y parte del propósito de ese producto es su profunda conexión con una plataforma en particular, por supuesto, construya para esa plataforma. Por ejemplo, si su producto se basa en la plataforma de mensajes de Apple o la integración con HomeKit, por supuesto, construya para iOS y/o macOS en Swift. Si su producto satisfará mejor las necesidades del usuario a través de un widget o si está creando un iniciador personalizado, es mejor que cree Android y necesitará usar Java.

Sin embargo, no todas las características nativas son jardines amurallados. Si bien Alexa de Amazon, Siri de Apple y el Asistente de Google requieren código nativo (o una API JSON) para integrarse con su aplicación, curiosamente, Cortana de Microsoft habilitará la voz de su PWA utilizando solo un archivo XML vinculado desde el head de su HTML. Quizás otros sigan su ejemplo.

¿PWA o nativo? La decisión es tuya

Tanto la web como la nativa tienen mucho que ofrecer. Si me preguntaras cuál es mejor, simplemente respondería "Depende" porque así es. No estoy siendo evasivo o evasivo; averiguar cuál es el adecuado para su proyecto depende completamente de las necesidades específicas de su proyecto. Requiere tener en cuenta lo que está construyendo, la composición del equipo existente encargado de construirlo o el equipo que necesitará contratar para hacerlo, y el presupuesto con el que tiene que trabajar. En muchos casos, es probable que la web ofrezca todo lo que necesita para lograr los objetivos de su proyecto, pero siempre hay excepciones. Si desea explorar las posibilidades que ofrece la web, he incluido algunos recursos al final de este artículo.

Lo más importante que puede hacer al sopesar diferentes enfoques para el desarrollo de software, o diferentes marcos, bibliotecas, lenguajes, sistemas de diseño, etc., es considerar sus opciones en relación con el proyecto en cuestión. Investigue y evalúe sus opciones. Y no se deje influir por un marketing inteligente, demostraciones sexys o fanboys rabiosos. Incluido este.

Recursos relacionados con PWA

• Constructor de PWA
  Una herramienta de creación de sitio web a PWA de 3 pasos con recomendaciones y recetas útiles. También le permite convertir su PWA en aplicaciones nativas instalables para Windows, Android e iOS.
• Una hoja de ruta progresiva para su aplicación web progresiva
  Jason Grigsby sobre cómo su equipo comenzó a incorporar aspectos de las PWA en su sitio web en el transcurso de varios meses, demostrando muy bien cómo se pueden agregar las diferentes funciones poco a poco.
• Sí, ese proyecto web debería ser una PWA
  Una descripción general de las oportunidades (y riesgos) de UX de las PWA, escrita por su servidor.
• Aplicaciones web progresivas en MDN
  Un centro para todos los aspectos técnicos que necesita saber sobre lo que caracteriza a una PWA de calidad.
• Lo que la Web puede hacer hoy
  Eche un vistazo a las API compatibles con su dispositivo, sistema operativo y navegador. Lo que encuentres puede sorprenderte.
• Puedo usar
  La base de datos definitiva de qué API y funciones están disponibles en cada uno de los principales navegadores y cómo ese soporte se mide en relación con los navegadores que las personas realmente usan. También puede brindarle una excelente vista atrás en el tiempo para ver cuán compatibles con versiones anteriores son ciertas funciones.