Aplicar o no: Cuándo elegir Nativo o Web

Bueno, solo tengo unos 20 minutos pero tengo una oportunidad para todos ustedes y me gustaría invitarlos a unirse a mí. Así que estoy construyendo el último y mejor producto estos días. Tiene una atractiva biblioteca de interfaz de usuario que personalmente conozco y amo. Incluye un montón de IA para que podamos proporcionar información contextual a todos nuestros usuarios. Tengo que averiguar la última parte pero tiene que ver con cómo podemos hacer que esa aplicación llegue a todos. Y esa es la parte en la que me gustaría invitarlos a ayudarme a averiguar. ¿Cuál es la mejor manera de distribuir esto? Realmente al final del día quiero asegurarme de que esta aplicación esté disponible para todos. Es algo realmente muy difícil de averiguar porque hay múltiples caminos de distribución para cómo puedes enviar una aplicación y el camino que elijas va a influir en cómo realmente vas a construir la aplicación. Así que vamos a intentar recorrer este proceso. Vamos a averiguar si debemos hacer una aplicación o no, si debemos enviar esta aplicación como una aplicación nativa o como una aplicación web.

Soy Mike Hardington, trabajo en una empresa llamada Ionic. Puedes encontrarme básicamente en todas partes en línea como mhardington.

Antes de hacer eso, hagamos un viaje al pasado a la primera aplicación que construí. Esta es una aplicación, no te preocupes, los logotipos, los nombres de las empresas han sido un poco ofuscados. Pero esta fue una aplicación que construí alrededor de 2012. Fue un momento muy interesante en ese espacio, esto es antes de iOS 7, así que todavía estamos lidiando con algo de este esquemorfismo de bloques. Pero lo que tenemos es una aplicación que estaba cargando un montón de contenido de un servicio remoto. Estamos extrayendo imágenes, estamos extrayendo descripciones de productos. Quiero decir, incluso estamos extrayendo algunos de los estilos que se usaban en ese producto porque esta aplicación fue construida usando una carcasa de aplicación y cargando HTML, CSS y JavaScript. Esto era realmente como la vanguardia en ese momento, pero nos permitió construir este demo de producto completo que luego podríamos distribuir a todos nuestros vendedores y a todos nuestros formadores técnicos y darles la información que necesitan directamente en su dispositivo.

Ahora las preguntas que tenía eran, bueno, si estamos extrayendo todo este contenido web, ¿por qué necesitamos una aplicación móvil? Y en ese momento, el consenso general era, bueno, necesitas una aplicación para convertirte en una empresa seria. Y eso fue el fin de la discusión. Eso fue lo suficientemente fácil para el jefe de la empresa decirlo, pero yo, como un humilde desarrollador web, una de las cosas con las que tuve que lidiar fue aprender Xcode. Y este fue realmente el momento en que Xcode parecía iTunes. Había mucho de Objective C, incluso C, C++, como cosas realmente, realmente de bajo nivel. Y esto es que, como desarrollador de JavaScript, no estaba bien equipado para manejar esto. Básicamente me tropecé a través de ello. Afortunadamente, los tiempos han evolucionado desde entonces donde tenemos un IDE de aspecto mucho más agradable para el desarrollo de iOS, pero también tenemos mejores lenguajes que son más accesibles para las personas que vienen de lenguajes de sistema no de bajo nivel.

Android no era tan genial como, bueno, ni siquiera teníamos un IDE en ese momento. Estábamos usando cosas como Eclipse con el plugin del SDK de Android habilitado para que pudiéramos seguir adelante y hacer algo de desarrollo de Android. Esto no era el gran desarrollo de Android de Kotlin. Todavía estábamos escribiendo Java. Todavía estábamos lidiando con algunos de estos enfoques anticuados para construir aplicaciones de Android y hacer cosas para Android pre 4.0 era bastante desafiante. Afortunadamente, como iOS, Android también ha avanzado mucho, donde el Java que escribimos es en realidad mucho más familiar para las personas que han hecho JavaScript ahora y TypeScript, y el IDE es, si has usado cualquier producto de IntelliJ, va a ser el mismo IDE, porque está basado en toda su experiencia de editor principal.

Pero de nuevo, seguí presionando para, ¿por qué no hacemos esto como una aplicación web? Este es el momento de la web, ¿verdad? Todo va a ser genial. No necesitaba construir y desplegar mi aplicación web. Solo necesitaba agrupar todos mis scripts y luego abrir el cliente FTP. Tenía mis credenciales. Sabía dónde estaba la carpeta en mi escritorio. Podía simplemente arrastrarla a nuestro proveedor de hosting, subirla, y ya está, ¿verdad? Y eso fue en 2012.

Y, ya sabes, solo ha mejorado para la web, donde ahora, en lugar de tener que lidiar con FTP, podemos simplemente hacer un commit y subirlo a nuestro principal servicio Git y luego desencadenar una serie de acciones, ya sea que estemos usando algo como CircleCI, GitHub Actions. Todas nuestras compilaciones y despliegues pueden ser automatizados, de manera que, tan pronto como hagamos push Netlify, Vercel, Firebase, lo que sea, pueden recoger esos cambios y manejar todo lo demás por nosotros.

Entonces, es fácil ver que todas esas tres plataformas, Android, iOS e incluso la web, han mejorado mucho con el tiempo. Y todavía tenemos esta eterna pregunta como desarrolladores, ya sabes, ¿deberíamos construir una aplicación móvil o no? ¿Deberíamos construir una aplicación web o no? Y quiero repasar algunos de los pros y contras de cada una de estas plataformas. Soy un fan de largo tiempo de la web, así que intentaré no ser tan parcial hacia ella, pero hay muchas grandes capacidades de ambas plataformas que realmente deberíamos considerar a medida que empezamos a construir nuestros productos.

Entonces, echemos un vistazo a la web y lo que obtenemos cuando decidimos que queremos construir una aplicación web. Bueno, en primer lugar, tenemos que mencionar los lenguajes que estamos usando en la web. HTML, CSS, y JavaScript. Estos son los fundamentos básicos para construir una aplicación web que realmente nos ayudan a construir cosas increíbles y convincentes. Sí, podemos traer cosas como React o Next, pero si por alguna razón, React y Next desaparecieran, todavía tendríamos estos bloques de construcción básicos que podríamos utilizar y construir cosas bastante convincentes. Sé que la gente todavía está indecisa sobre los componentes web, pero una vez que empiezas a construir cosas en un modelo basado en componentes usando la funcionalidad incorporada del navegador y JavaScript, básicamente miras esto y dices, huh, ¿cuál es la razón para traer todas estas otras bibliotecas? La web es una plataforma bastante convincente en ese caso.

Y los lenguajes que conocemos para construir estas características y estas interfaces de usuario también son convincentes. Con esas herramientas y estos lenguajes en nuestro conjunto de habilidades, nuestra capacidad para construir algo en la web es increíblemente rápida. Comparado con lo que podemos hacer en nativo, no estamos gastando mucho tiempo con este ciclo de construcción, compilación. Literalmente estamos abriendo nuestro servidor de desarrollo y luego podemos ver los cambios que ocurren instantáneamente en la aplicación en el cliente. Lo cual es súper valioso. La capacidad de poder inspeccionar todo en el entorno en el que realmente se va a desplegar, y realmente mirar todos esos nodos, significa que estamos gastando menos tiempo teniendo que depurar la aplicación en sí y más tiempo simplemente averiguando, ¿cómo estamos construyendo el diseño? ¿Por qué este estilo no se está aplicando? ¿Dónde puedo hacer algunos cambios para optimizarlo para la usabilidad? Nuestra capacidad para tomar todo esto y simplemente iterar e iterar muy rápidamente, no puede ser subestimada.

Ahora, esto puede parecer el símbolo de USB, pero en realidad es el símbolo de universal. Al menos en mi canon personal. La capacidad de poder tomar algo para la web y desplegarlo, es bastante universal. Solo puedo pensar en quizás un puñado de dispositivos que realmente no pueden renderizar contenido web. Mientras que puedo pensar en tantos lugares donde el contenido web puede ser renderizado. Obviamente, tenemos nuestros entornos de escritorio, tenemos nuestros navegadores móviles, pero también tenemos quioscos de pago. También tenemos el centro de control de la NASA. Todos están usando tecnologías web para renderizar la interfaz de usuario. Porque es tan rápido, porque es universal, porque son cosas que todos conocen, y pueden ser productivos muy rápidamente.

Siguiendo con eso, tenemos cosas como, tenemos características poderosas dentro de la web que nos permiten construir mejores aplicaciones de las que hemos podido. Si echamos un vistazo a algunas de las características de lo que la web puede hacer, puedes mostrarnos que obviamente podemos hacer cosas como WebRTC, podemos hacer algunas notificaciones push, podemos hacer USB y NFC, todas estas características geniales que están incorporadas en el navegador que los desarrolladores nativos siempre han colgado sobre nuestras cabezas como, oh, la web nunca podrá hacer esto. Pero la web es una historia de siempre poder alcanzar. Y con esas características, estamos viendo que la web puede ser empujada hacia adelante para hacer cosas nuevas y increíbles.

Y no solo de una manera que nos brinda características poderosas, sino de una manera que nos va a proporcionar características muy eficientes. Vamos a ser conscientes de la huella energética de lo que construimos. No vamos a enviar cosas que puedan reducir la batería del dispositivo del usuario. Así como su escritorio. Porque simplemente no vamos a hacer eso. Es simplemente una mala experiencia para los usuarios.

Y probablemente, sabes, mi característica favorita de la web es que es simplemente divertida. No es necesariamente algo que puedas usar como un efecto medible. Pero encuentro que construir para la web es una experiencia agradable. Lo menciono porque si te lo estás pasando bien construyendo para la plataforma en la que estás, te va a importar. Realmente vas a querer construir para esa plataforma. Hemos oído hablar de cosas como usadas con ira o usadas con frustración. Me gusta pensar que la web me permite construir y usar una web con disfrute. Me divierto lidiando con CSS. Me divierto trabajando con los últimos frameworks de JavaScript. Me divierto siendo capaz de ver qué puede traer el futuro de la web y cómo puedo aprovechar eso ahora. Para mí, todas estas características realmente hacen de la web una plataforma súper atractiva.

Pero seríamos negligentes si no hablamos de las increíbles habilidades de lo nativo. Ahora, los dispositivos nativos siempre han tenido un conjunto de características principales que realmente se destacan de lo que hacemos en la web. En primer lugar, son características poderosas. Hay una intersección realmente interesante cuando ves el entorno en el que estos dispositivos funcionan, los lenguajes que se utilizan en estos dispositivos, y luego las personas que los construyen y básicamente los poseen. Son capaces de hacer muchas suposiciones sobre tu código. De esa manera, para cuando realmente presionas Construir, están haciendo cosas muy por delante, años luz de lo que podemos hacer en JavaScript en este momento. Eliminación de código, ser capaz de hacer reescrituras para asegurarse de que es más eficiente, optimizaciones y minificaciones.

Luego, al final del día, cuando están construyendo esa aplicación, no están enviando un montón de archivos que necesitan ser cargados y buscados. Están enviando un solo binario, lo cual es increíble, lo que significa que no tenemos que tener todo este extra, solo tenemos un solo binario que contiene todo el conocimiento de nuestra aplicación. Y, realmente, eso es todo. El aspecto de optimización de estas cadenas de construcción no puede ser subestimado. Puedes escribir Swift en Java realmente mal, y luego el optimizador va a entrar allí y realmente asegurarse de que se convierta un poco más eficiente. Lo cual es realmente agradable, especialmente si no sabes lo que estás haciendo, como yo.

Las aplicaciones nativas tienden a ser un poco más resistentes a los cambios de red. Si alguna vez has intentado cargar una aplicación nativa cuando no tienes Wi-Fi, ni red celular, todavía vas a obtener una instantánea de cualquiera que sea el último estado de tu aplicación, y vas a seguir siendo capaz de decir, si estás en Twitter, podrías desplazarte hacia arriba y hacia abajo, ver algunos de los tweets que la gente ha publicado, fotos de perfil. Es posible que no puedas entrar en detalles e interactuar con dichos tweets, pero todavía obtienes algo mejor que lo que tienes en la web. Ahora, la web tiene cosas como los trabajadores de servicio, que te permiten almacenar en caché todos tus activos y respuestas y poder mostrar a tus usuarios algo cuando la aplicación está sin conexión. Pero lo cierto es que necesitas poder almacenar en caché algo de eso antes de que tu aplicación realmente pueda mostrar un modo sin conexión. Con lo nativo, realmente puedes descargar una aplicación, apagar el Wi-Fi, apagar el celular, abrir la aplicación, y todavía vas a obtener alguna interfaz de usuario que se puede mostrar. No tiene que llamar a casa a alguna red para descargar algunos activos. Ya tiene todo instalado. Tienes la pantalla principal de la aplicación que la gente va a ver para iniciar sesión. Tienes toda la lógica de la barra de pestañas, toda la interfaz de usuario que se va a representar a tus usuarios, porque de nuevo, estamos compilando todo en un solo binario, y estamos enviando eso a los usuarios, no un montón de archivos JavaScript separados. Ahora, lo nativo también tiene la ventaja de poder obtener muchas características de dispositivo de bajo nivel, cosas como Bluetooth, NFC, geolocalización más refinada, y acceso al sistema de archivos. Estas son cosas que la web está tratando de obtener hoy en día, y si has estado siguiendo algunas de las características que se están intentando enviar en el navegador, es un debate bastante contencioso que se está teniendo. Muchos de esto está siendo liderado por personas que vuelan bajo una cierta bandera de navegador. Aunque el paso hacia el progreso es genial, se están perdiendo muchas características y alienando a muchos otros navegadores y proveedores de navegadores. Compáralo con lo nativo, que tiene todas estas características y luego es capaz de proporcionar un sistema de gestión de permisos para que los usuarios sepan exactamente por qué el dispositivo está pidiendo poder conectarse a cosas en Bluetooth, poder conectarse a cosas en NFC, o en tu red local, o incluso almacenar datos en el sistema de archivos. Hay un modelo de permisos que no existe en la web que es claro para los usuarios, y los desarrolladores tienen la capacidad de proporcionar descripciones significativas. Si resulta que un desarrollador está haciendo alguna acción nefasta, su aplicación puede ser terminada.

Existe una seguridad en el hecho de que estamos dando acceso privilegiado a esas características que las tiendas y los proveedores de la plataforma pueden proteger a los usuarios, lo cual es realmente, realmente, realmente agradable. Además de eso, lo Nativo también tiene un poco mejor historia de descubrimiento. Ahora, el descubrimiento puede significar muchas cosas. Puede significar simplemente, hey, aquí está el enlace a la aplicación, adelante y haz clic en él y automáticamente se descarga para ti desde la tienda. O puede significar simplemente entrar en la tienda y poder buscar la aplicación que quieres y la tienda dice, te tenemos cubierto, no necesitas proporcionar nada más, aquí están las sugerencias de búsqueda, aquí está la aplicación que quieres. Compara esto con el descubrimiento en la web. La gente realmente tiene que saber lo que está buscando para poder buscarlo a través de varios motores de búsqueda. Y si no has jugado realmente buenos juegos de SEO, no vas a clasificar bien. Tenemos que jugar el juego de clasificación dentro de estos motores de búsqueda. De lo contrario, simplemente no vamos a estar disponibles. Podrías ser tercero, cuarto, quinto, podrías estar en la temida página dos de tus resultados de búsqueda. Y si no eres el primero, eres el último. Así que el descubrimiento para las aplicaciones nativas tiende a ser un poco mejor. Y creo que lo más importante es la monetización. No me gusta hablar demasiado de la monetización porque sabes, es un tema muy sensible para la gente, pero construir una aplicación nativa realmente te da más oportunidades para monetizar tu trabajo. Mientras que en la web, una de las formas comunes de monetizar tu trabajo es con anuncios. Puedes cobrar por tu aplicación en la App Store, 99 centavos, $1.99, $4.99 he visto donde la gente realmente quiere subir, la gente realmente ve la cantidad de valor que proporcionas y se anima a pagar por ello. Y si esa no es tu forma de trabajar, podrías proporcionar una versión gratuita de tu aplicación y luego añadir características usando compras dentro de la aplicación. Ahora bien, tienes que pagar un poco de impuesto a las plataformas, tanto a Google como a Apple. Pero aún tienes la oportunidad de recuperar algo de dinero por el tiempo y esfuerzo que pusiste en construir tu producto versus una web donde, sí, tienes anuncios de terceros. A nadie le gustan realmente. Tienes bloqueadores de anuncios. Realmente no es una gran historia a menos que alguien te esté apoyando directamente a través de, ya sabes, Patreon u otros modelos de monetización directa de creadores. La web no tiene éxito aquí. Lo Nativo realmente hace un buen trabajo con esto. Así que volvemos a la pregunta. Hay muchas cosas buenas de ambos lados. ¿Hay alguna forma de que podamos combinar esos dos para crear los beneficios de la web pero con las capacidades, el alcance, la security de la plataforma, y los esfuerzos y detalles adicionales de lo Nativo? Bueno, sí, hay formas de hacerlo. Hay bibliotecas que existen hoy en día que te permiten tomar, digamos, tu simple aplicación de React, proporcionar alguna funcionalidad extra a través de bibliotecas adicionales donde puedes decir, hey, quiero tener acceso a un sistema de archivos. Quiero poder desplegar esto en iOS, en Android.

Y aquí, podemos ver que simplemente estamos llamando a file system.makdir, file system.readdir. Incluso podemos conectarnos a esos modelos de permisos usando file system.request.permissions. Ahora, esto es algo que se hace usando una biblioteca llamada Capacitor. Te permite tomar tu aplicación web, empaquetarla como una aplicación nativa, y aún tener acceso a toda la configuración del proyecto nativo y el código nativo que podrías agregar además de lo que estás haciendo en la web.

Y sería negligente si no mencionara cosas como React Native, donde puedes tomar tu aplicación nativa existente y empezar a espolvorear algo de ese código React también. Ahora, ambas opciones permiten a los desarrolladores crear no solo una aplicación web sino también una aplicación nativa y poder llegar a más usuarios y obtener lo mejor de ambos mundos.

Entonces, ¿cómo desglosamos esto de nuevo? Vamos a elegir la web si queremos lenguajes familiares, un entorno de desarrollo muy rápido, y un enfoque común y ubicuo para poder desplegar y cargar esa aplicación en todas partes. Bueno, también vamos a elegir Nativo si queremos algo que sea resistente a los cambios de red, tener acceso a características avanzadas como Bluetooth y NFC, y si queremos tener un buen modelo de monetización. Pero si queremos lo mejor de ambos mundos, vamos a querer optar por algo como Capacitor o React Native, donde podemos tomar nuestro conocimiento web existente, y realmente seguir adelante y cargar todo eso y construir un producto mejor.

Ahora, estoy sesgado porque trabajo en algunas de las cosas dentro de Capacitor, y te animaría mucho a que lo pruebes. Si vas a CapacitorJS.com, puedes ver lo fácil que es adoptar Capacitor en tus proyectos existentes sin tener que pasar por ninguna migración o corrección de errores. Evaluación de tus bibliotecas existentes. Puedes simplemente soltarlo allí, y estás listo para comenzar. Así que con eso, creo que tengo una buena idea de cómo quiero construir mi aplicación, así que animaría a todos ustedes a salir y construir cosas realmente geniales. Estoy curioso por ver lo que todos ustedes construyen, y mucha suerte. ¡Salud!