Diseño y construcción de una aplicación web progresiva sin marco (Parte 1)

 

 

 

  • ¡Registro!
  • Clase magistral de tipografía, con Elliot Jay Stocks

  • Índice
    1. Sobre el aprendizaje
    2. ¿Por qué no reaccionar, Ember, Angular, Vue y otros?
  • Una idea de aplicación
  • Funciones previstas
  • Diseño
  • Requerimientos técnicos
  • Opciones de tecnología
  • Resumen
  • No es necesario ser licenciado en Ciencias de la Computación ni conocer un marco de JavaScript para crear una aplicación web progresiva. Con algunos conocimientos de HTML y CSS y competencia básica con JavaScript, tienes todas las habilidades que necesitas. En tres partes, compartiremos el viaje de diseño y construcción de una aplicación web progresiva simple llamada 'In/Out', construida sin un marco. Puedes verlo aquí .

     

    ¿Cómo funciona realmente una aplicación web? No me refiero desde el punto de vista del usuario final. Me refiero al sentido técnico. ¿Cómo se ejecuta realmente una aplicación web? ¿Qué es lo que inicia las cosas? Sin ningún código repetitivo, ¿cuál es la forma correcta de estructurar una aplicación? En particular, una aplicación del lado del cliente donde toda la lógica se ejecuta en el dispositivo del usuario final. ¿Cómo se gestionan y manipulan los datos? ¿Cómo se hace que la interfaz reaccione a los cambios en los datos?

    Este es el tipo de preguntas que son fáciles de eludir o ignorar por completo con un marco. Los desarrolladores buscan algo como React, Vue, Ember o Angular, siguen la documentación para comenzar a funcionar y listo. Esos problemas se manejan mediante la caja de trucos del marco.

    Puede que así sea exactamente como quieres las cosas. Podría decirse que es lo más inteligente si desea construir algo con un estándar profesional. Sin embargo, con la magia abstraída, nunca podrás aprender cómo se realizan realmente los trucos.

    ¿No quieres saber cómo se hacen los trucos?

    Hice. Entonces, decidí intentar crear una aplicación básica del lado del cliente, sin marco, para comprender estos problemas por mí mismo.

    Pero me estoy adelantando un poco; un poco de historia primero.

    Antes de comenzar este viaje, me consideraba muy competente en HTML y CSS, pero no en JavaScript. Como sentí que había resuelto satisfactoriamente las dudas más importantes que tenía sobre CSS , el siguiente desafío que me propuse fue comprender un lenguaje de programación.

    El hecho es que tenía un nivel relativamente principiante con JavaScript. Y, aparte de piratear el PHP de WordPress, tampoco tuve exposición ni formación en ningún otro lenguaje de programación.

     

    Permítanme calificar esa afirmación de "nivel principiante". Claro, podría hacer que la interactividad funcione en una página. Alternar clases, crear nodos DOM, agregarlos y moverlos, etc. Pero cuando llegó el momento de organizar el código para algo más allá de eso, no tenía ni idea. No estaba seguro de crear nada parecido a una aplicación. No tenía idea de cómo definir un conjunto de datos en JavaScipt, y mucho menos manipularlo con funciones.

    No entendía los 'patrones de diseño' de JavaScript: enfoques establecidos para resolver problemas de código que se encuentran con frecuencia. Ciertamente no tenía idea de cómo abordar las decisiones fundamentales de diseño de aplicaciones.

    ¿Has jugado alguna vez a 'Top Trumps'? Bueno, en la edición para desarrolladores web, mi tarjeta se vería así (puntuaciones sobre 100):

    • CSS: 95
    • Copiar y pegar: 90
    • Rayita: 4
    • HTML: 90
    • JavaSript: 13

    Además de querer desafiarme a nivel técnico, también me faltaban habilidades de diseño.

    Habiendo codificado casi exclusivamente diseños de otras personas durante la última década, mis habilidades de diseño visual no habían tenido ningún desafío real desde finales de los años noventa. Al reflexionar sobre ese hecho y sobre mis débiles habilidades en JavaScript, cultivé una creciente sensación de insuficiencia profesional. Ya era hora de abordar mis defectos.

    En mi mente tomó forma un desafío personal: diseñar y construir una aplicación web JavaScript del lado del cliente.

    Sobre el aprendizaje

    Nunca ha habido mejores recursos para aprender lenguajes informáticos. Particularmente JavaScript. Sin embargo, me tomó un tiempo encontrar recursos que explicaran las cosas de una manera que encajara. Para mí, 'You Don't Know JS' de Kyle Simpson y 'Eloquent JavaScript' de Marijn Haverbeke fueron de gran ayuda.

    Si estás empezando a aprender JavaScript, seguramente necesitarás encontrar tus propios gurús; personas cuyo método de explicación funcione para usted.

    La primera cosa clave que aprendí fue que no tiene sentido tratar de aprender de un maestro/recurso que no explica las cosas de una manera comprensible. Algunas personas miran ejemplos de funciones con fooy bardentro y asimilan instantáneamente el significado. No soy una de esas personas. Si usted tampoco lo es, no asuma que los lenguajes de programación no son para usted. Simplemente pruebe con un recurso diferente y siga intentando aplicar las habilidades que está aprendiendo.

    Tampoco es un hecho que disfrutes de algún tipo de momento eureka en el que de repente todo hace clic; como el equivalente codificado del amor a primera vista. Es más probable que se necesite mucha perseverancia y una aplicación considerable de lo aprendido para sentirse seguro.

     

    Tan pronto como te sientas un poco competente, intentar aplicar lo aprendido te enseñará aún más.

    Aquí hay algunos recursos que encontré útiles a lo largo del camino:

    • Función divertida y divertida Canal de YouTube
    • Cursos de Vista Plural de Kyle Simpson
    • JavaScript30.com de Wes Bos
    • JavaScript elocuente de Marijn Haverbeke

    Bien, eso es prácticamente todo lo que necesitas saber sobre por qué llegué a este punto. El elefante que ahora está en la habitación es: ¿por qué no utilizar un marco?

    ¿Por qué no reaccionar, Ember, Angular, Vue y otros?

    Si bien se aludió a la respuesta al principio, creo que es necesario ampliar el tema de por qué no se utilizó un marco.

    Hay una gran cantidad de marcos de JavaScript de alta calidad y con buen soporte. Cada uno de ellos diseñado específicamente para la creación de aplicaciones web del lado del cliente. Exactamente el tipo de cosa que estaba buscando construir. Te perdono por preguntarte lo obvio: ¿por qué no usar uno?

    Aquí está mi postura al respecto. Cuando aprendes a utilizar una abstracción, eso es principalmente lo que estás aprendiendo: la abstracción. Quería aprender la cosa, no la abstracción de la cosa.

    Recuerdo haber aprendido algo de jQuery en el pasado. Si bien la encantadora API me permitió hacer que las manipulaciones DOM fueran más fáciles que nunca, me volví impotente sin ella. Ni siquiera podía alternar clases en un elemento sin necesitar jQuery. Me encargaron algo de interactividad básica en una página sin jQuery en el que apoyarme y tropecé en mi editor como un Sansón esquilado.

    Más recientemente, mientras intentaba mejorar mi comprensión de JavaScript, intenté entender un poco sobre Vue y React. Pero, en última instancia, nunca estuve seguro de dónde terminaba JavaScript estándar y comenzaba React o Vue. Mi opinión es que estas abstracciones valen mucho más la pena cuando comprendes lo que hacen por ti.

    Por lo tanto, si iba a aprender algo quería entender las partes centrales del idioma. De esa manera, tenía algunas habilidades transferibles. Quería conservar algo cuando el marco actual del mes había sido dejado de lado para la próxima "novedad de moda".

    Bueno. Ahora, sabemos por qué se creó esta aplicación y también, nos guste o no, cómo se crearía.

    Pasemos a lo que iba a ser esto.

    Una idea de aplicación

    Necesitaba una idea para una aplicación. Nada demasiado ambicioso; No me hacía ilusiones de crear una nueva empresa o aparecer en Dragon's Den; aprender JavaScript y los conceptos básicos de las aplicaciones era mi objetivo principal.

    La aplicación tenía que ser algo que tuviera muchas posibilidades de lograr técnicamente y, además, hacer un trabajo de diseño medio decente.

    Tiempo tangente.

    Fuera del trabajo, organizo y juego fútbol sala siempre que puedo. Como organizador, es una molestia tener en cuenta mentalmente quién me ha enviado un mensaje para decirme que está jugando y quién no. Por lo general, se necesitan 10 personas para un juego, 8 de una vez. Hay una lista de aproximadamente 20 personas que pueden o no poder jugar cada juego.

     

    La idea de la aplicación que se me ocurrió fue algo que permitiera elegir jugadores de una lista, lo que me daría un recuento de cuántos jugadores habían confirmado que podían jugar.

    Al pensar más en ello sentí que podía ampliar el alcance un poco más para que pudiera usarse para organizar cualquier actividad simple en equipo.

    Es cierto que apenas había soñado con Google Earth. Sin embargo, tenía todos los desafíos esenciales: diseño, gestión de datos, interactividad, almacenamiento de datos, organización de códigos.

    En cuanto al diseño, no me preocuparía de nada más que de una versión que pudiera ejecutarse y funcionar bien en la ventana gráfica de un teléfono. Limitaría los desafíos de diseño a resolver los problemas solo en pantallas pequeñas.

    La idea central ciertamente se inclinaba hacia aplicaciones de estilo "tareas pendientes", de las cuales había muchos ejemplos existentes para buscar inspiración y al mismo tiempo tenían la diferencia suficiente para proporcionar algunos desafíos únicos de diseño y codificación.

    Funciones previstas

    Una lista inicial de características que pretendía diseñar y codificar se veía así:

    • Un cuadro de entrada para agregar personas a la lista;
    • La capacidad de configurar a cada persona para que esté "dentro" o "fuera";
    • Una herramienta que divide a las personas en equipos, por defecto 2 equipos;
    • La posibilidad de eliminar a una persona de la lista;
    • Alguna interfaz para 'herramientas'. Además de dividir, las herramientas disponibles deberían incluir la capacidad de descargar los datos ingresados ​​como un archivo, cargar datos previamente guardados y eliminar todos los reproductores de una sola vez;
    • La aplicación debería mostrar un recuento actual de cuántas personas están "dentro";
    • Si no hay personas seleccionadas para un juego, debería ocultar el divisor de equipos;
    • Modo de pago. Un interruptor en la configuración que permite a los usuarios "internos" tener un interruptor adicional para mostrar si han pagado o no.

    Al principio, estas son las características que consideré de un producto mínimo viable.

    Diseño

    Los diseños comenzaron con trozos de papel. Fue esclarecedor (léase: aplastante) descubrir cuántas ideas que eran increíbles en mi cabeza resultaron ridículas cuando las sometí incluso al escaso escrutinio que ofrece un dibujo a lápiz. Partyflauta: Partituras para flauta dulce

    Por lo tanto, muchas ideas fueron rápidamente descartadas, pero la otra cara de la moneda fue que al esbozar algunas ideas, invariablemente conducía a otras ideas que de otro modo nunca habría considerado.

    Ahora, los diseñadores que lean esto probablemente dirán: "Claro, por supuesto", pero esto fue una verdadera revelación para mí. Los desarrolladores están acostumbrados a ver diseños de etapas posteriores y rara vez ven todos los pasos abandonados en el camino antes de ese punto.

    Una vez satisfecho con algo como un dibujo a lápiz, intentaba recrearlo en el paquete de diseño, Sketch. Así como las ideas desaparecieron en la etapa de papel y lápiz, un número igual no logró pasar la siguiente etapa de fidelidad de Sketch. Los que parecían funcionar como mesas de trabajo en Sketch fueron elegidos como candidatos para codificar.

    A su vez, descubrí que cuando esos candidatos eran código integrado, un porcentaje tampoco funcionó por diversas razones. Cada paso de fidelidad expuso nuevos desafíos para que el diseño fuera aprobado o fracasado. Y un fracaso me llevaría literal y figurativamente de regreso a la mesa de dibujo.

     

    Como tal, en última instancia, el diseño que obtuve es bastante diferente al que tenía originalmente en Sketch. Aquí están las primeras maquetas de Sketch:

    Diseño inicial de la aplicación Who's In ( vista previa grande )
    Menú inicial de la aplicación Who's In ( vista previa grande )

    Incluso entonces no me engañaba; Era un diseño básico. Sin embargo, en este punto tenía algo en lo que estaba relativamente seguro de que podría funcionar y estaba ansioso por intentar construirlo.

    Requerimientos técnicos

    Con algunos requisitos de funciones iniciales y una dirección visual básica, llegó el momento de considerar qué se debía lograr con el código.

    Aunque la sabiduría popular dicta que la forma de crear aplicaciones para dispositivos iOS o Android es con código nativo, ya hemos establecido que mi intención era crear la aplicación con JavaScript.

    También quería asegurarme de que la aplicación cumpliera todos los requisitos necesarios para calificar como una aplicación web progresiva , o PWA, como se las conoce más comúnmente.

    En caso de que no sepa qué es una aplicación web progresiva, aquí tiene el "discurso del ascensor". Conceptualmente, imaginemos una aplicación web estándar pero que cumpla con algunos criterios particulares. El cumplimiento de este conjunto de requisitos particulares significa que un dispositivo de soporte (piense en un teléfono móvil) otorga a la aplicación web privilegios especiales, lo que hace que la aplicación web sea mayor que la suma de sus partes.

    En Android, en particular, puede resultar casi imposible distinguir una PWA, creada sólo con HTML, CSS y JavaScript, de una aplicación creada con código nativo.

    Aquí está la lista de verificación de Google de requisitos para que una aplicación sea considerada una Aplicación Web Progresiva:

    • El sitio se sirve a través de HTTPS;
    • Las páginas responden en tabletas y dispositivos móviles;
    • Todas las URL de las aplicaciones se cargan sin conexión;
    • Metadatos proporcionados para Agregar a la pantalla de inicio;
    • Primera carga rápida incluso en 3G;
    • El sitio funciona en varios navegadores;
    • Las transiciones de página no parecen bloquearse en la red;
    • Cada página tiene una URL.

    Ahora, además, si realmente quieres ser el favorito del profesor y que tu aplicación sea considerada una 'Aplicación web progresiva ejemplar', entonces también debe cumplir con los siguientes requisitos:

    • El contenido del sitio está indexado por Google;
    • Los metadatos de Schema.org se proporcionan cuando corresponde;
    • Se proporcionan metadatos sociales cuando corresponde;
    • Las URL canónicas se proporcionan cuando es necesario;
    • Las páginas utilizan la API de historial;
    • El contenido no salta cuando se carga la página;
    • Al presionar hacia atrás desde una página de detalles se conserva la posición de desplazamiento en la página de lista anterior;
    • Cuando se tocan, las entradas no quedan ocultas por el teclado en pantalla;
    • El contenido se puede compartir fácilmente desde el modo independiente o de pantalla completa;
    • El sitio responde a todos los tamaños de pantalla de teléfono, tableta y computadora de escritorio;
    • Las indicaciones de instalación de aplicaciones no se utilizan excesivamente;
    • Se intercepta el mensaje Agregar a la pantalla de inicio;
    • Primera carga muy rápida incluso en 3G;
    • El sitio utiliza redes de caché primero;
    • El sitio informa adecuadamente al usuario cuando está desconectado;
    • Proporcionar contexto al usuario sobre cómo se utilizarán las notificaciones;
    • La interfaz de usuario que anima a los usuarios a activar las notificaciones automáticas no debe ser demasiado agresiva;
    • El sitio atenúa la pantalla cuando se muestra la solicitud de permiso;
    • Las notificaciones push deben ser oportunas, precisas y relevantes;
    • Proporciona controles para habilitar y deshabilitar notificaciones;
    • El usuario inicia sesión en todos los dispositivos a través de la API de administración de credenciales;
    • El usuario puede pagar fácilmente a través de la interfaz de usuario nativa desde la API de solicitud de pago.

    ¡Caramba! ¡No sé ustedes, pero ese segundo montón de cosas parece mucho trabajo para una aplicación básica! Da la casualidad de que hay muchos elementos allí que de todos modos no son relevantes para lo que había planeado. A pesar de eso, no me avergüenza decir que bajé la mira para pasar sólo las pruebas iniciales.

     

    Para toda una sección de tipos de aplicaciones, creo que una PWA es una solución más aplicable que una aplicación nativa. Mientras que los juegos y SaaS posiblemente tienen más sentido en una tienda de aplicaciones, las utilidades más pequeñas pueden vivir felices y con mayor éxito en la web como aplicaciones web progresivas.

    Hablando del tema de que eludí el trabajo duro, otra decisión que tomé desde el principio fue intentar almacenar todos los datos de la aplicación en el propio dispositivo del usuario. De esa manera, no sería necesario conectarse a servicios y servidores de datos y ocuparse de los inicios de sesión y las autenticaciones. En cuanto a dónde estaban mis habilidades, descubrir la autenticación y el almacenamiento de datos del usuario parecía casi seguro que sería consumir más de lo que podía masticar y exagerar para el cometido de la aplicación.

    Opciones de tecnología

    Con una idea bastante clara de cuál era el objetivo, la atención se centró en las herramientas que podrían emplearse para construirlo.

    Desde el principio decidí usar TypeScript, que se describe en su sitio web como "... un superconjunto escrito de JavaScript que se compila en JavaScript simple". Lo que había visto y leído sobre el lenguaje me gustó, especialmente el hecho de que se aprendió tan bien al análisis estático.

    El análisis estático simplemente significa que un programa puede mirar su código antes de ejecutarlo (por ejemplo, cuando es estático) y resaltar los problemas. No necesariamente puede señalar problemas lógicos, pero puede señalar un código que no se ajusta a un conjunto de reglas.

    Cualquier cosa que pudiera señalar mis (seguro que habrá muchos) errores a medida que avanzaba tenía que ser algo bueno, ¿verdad?

     

    Si no está familiarizado con TypeScript, considere el siguiente código en JavaScript básico:

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

    Ejecute este código y obtendrá un error similar a:

    ReferenceError: Cannot access uninitialized variable.

    Para aquellos con incluso un poco de destreza en JavaScript, para este ejemplo básico, no necesitan una herramienta que les diga que las cosas no terminarán bien.

    Sin embargo, si escribes ese mismo código en TypeScript, esto sucede en el editor:

    TypeScript en acción ( vista previa grande )

    ¡Recibo algunos comentarios sobre mi idiotez incluso antes de ejecutar el código! Esa es la belleza del análisis estático. Esta retroalimentación a menudo era como tener un desarrollador más experimentado sentado conmigo detectando errores a medida que avanzaba.

    TypeScript principalmente, como su nombre lo indica, le permite especificar el 'tipo' esperado para cada elemento del código. Esto evita que, sin darte cuenta, "obligues" a un tipo a otro. O intentar ejecutar un método en un dato que no es aplicable (un método de matriz en un objeto, por ejemplo). Este no es el tipo de cosas que necesariamente resultan en un error cuando se ejecuta el código, pero ciertamente puede introducir errores difíciles de rastrear. Gracias a TypeScript, obtienes comentarios en el editor incluso antes de intentar ejecutar el código.

    Ciertamente, TypeScript no fue esencial en este viaje de descubrimiento y nunca alentaría a nadie a utilizar herramientas de esta naturaleza a menos que hubiera un beneficio claro. Instalar y configurar herramientas en primer lugar puede consumir mucho tiempo, así que definitivamente considere su aplicabilidad antes de sumergirse.

    Hay otros beneficios que ofrece TypeScript que abordaremos en el próximo artículo de esta serie , pero las capacidades de análisis estático fueron suficientes para querer adoptar TypeScript.

    Hubo consideraciones en cadena sobre las decisiones que estaba tomando. Optar por crear la aplicación como una aplicación web progresiva significaba que necesitaría comprender a los trabajadores de servicios hasta cierto punto. Usar TypeScript significaría introducir herramientas de compilación de algún tipo. ¿Cómo administraría esas herramientas? Históricamente, había usado NPM como administrador de paquetes, pero ¿qué pasa con Yarn? ¿Valió la pena usar Yarn en su lugar? Centrarse en el rendimiento significaría considerar algunas herramientas de minificación o agrupación; herramientas como webpack se estaban volviendo cada vez más populares y sería necesario evaluarlas.

    Resumen

    Había reconocido la necesidad de embarcarme en esta búsqueda. Mis poderes de JavaScript eran débiles y nada me fortalece tanto como intentar poner la teoría en práctica. Decidir crear una aplicación web con JavaScript básico fue mi bautismo de fuego.

    Pasé algún tiempo investigando y considerando las opciones para crear la aplicación y decidí que convertir la aplicación en una aplicación web progresiva tenía más sentido para mis habilidades y la relativa simplicidad de la idea.

    Necesitaría herramientas de compilación, un administrador de paquetes y, posteriormente, mucha paciencia.

    En última instancia, en este punto quedaba la pregunta fundamental: ¿era esto algo que realmente pudiera manejar? ¿O me sentiría humillado por mi propia ineptitud?

    Espero que me acompañes en la segunda parte cuando puedas leer sobre herramientas de compilación, patrones de diseño de JavaScript y cómo hacer algo más "parecido a una aplicación".

    (dm, yk, il)Explora más en

    • PWA
    • Marcos
    • javascript





    Tal vez te puede interesar:

    1. ¿Qué es Redux? Una guía para el diseñador
    2. Diseño y construcción de una aplicación web progresiva sin marco (Parte 3)
    3. Escribir un motor de aventuras de texto multijugador en Node.js: diseño del servidor Game Engine (Parte 2)
    4. Componentes de diseño en React

    Diseño y construcción de una aplicación web progresiva sin marco (Parte 1)

    Diseño y construcción de una aplicación web progresiva sin marco (Parte 1)

    ¡Registro! Clase magistral de tipografía, con Elliot Jay Stocks Índice Sobre el aprendizaje

    programar

    es

    https://aprendeprogramando.es/static/images/programar-diseno-y-construccion-de-una-aplicacion-web-progresiva-sin-marco-parte-1-993-0.jpg

    2024-05-20

     

    Diseño y construcción de una aplicación web progresiva sin marco (Parte 1)
    Diseño y construcción de una aplicación web progresiva sin marco (Parte 1)

    Si crees que alguno de los contenidos (texto, imagenes o multimedia) en esta página infringe tus derechos relativos a propiedad intelectual, marcas registradas o cualquier otro de tus derechos, por favor ponte en contacto con nosotros en el mail [email protected] y retiraremos este contenido inmediatamente

     

     

    Top 20