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

 

 

 

  • ¡Registro!
  • Patrones de diseño para interfaces de IA, con Vitaly Friedman

  • Índice
    1. Crear una aplicación web progresiva
    2. Retrospectivo
    3. El diseño es desarrollo
    4. Eres el otro desarrollador de tu proyecto
    5. Depuración
    6. ¿Quiere construir con datos? Aprenda métodos de matriz de JavaScript
    7. Mantenimiento y seguridad
    8. Proyectos paralelos
    9. Enviar algo es mejor que enviar nada
    10. Resumen
      1. Cosas de las que me arrepiento
      2. Mejorando dentro/fuera
      3. Posibilidades

    Este artículo concluye una serie de tres partes sobre las pruebas y tribulaciones de diseñar y escribir una aplicación web básica con JavaScript básico. En la primera parte cubrimos el por qué, la segunda parte trató principalmente del cómo y esta parte concluye analizando cómo se cerró el proyecto y qué se aprendió de la experiencia.

     

    En la primera parte de esta serie, explicamos por qué surgió este proyecto. Es decir, el deseo de aprender cómo se puede crear una pequeña aplicación web en JavaScript básico y lograr que un desarrollador que no sea diseñador trabaje un poco en sus habilidades de diseño.

    En la segunda parte, tomamos algunos diseños iniciales básicos y pusimos todo en funcionamiento con algunas opciones de herramientas y tecnología. Cubrimos cómo y por qué cambiaron partes del diseño y las ramificaciones de esos cambios.

    En esta parte final, cubriremos cómo convertir una aplicación web básica en una aplicación web progresiva (PWA) y "enviar" la aplicación antes de ver las lecciones más valiosas aprendidas al hacer la aplicación web simple In/Out:

    • El enorme valor de los métodos de matriz de JavaScript;
    • Depuración;
    • Cuando eres el único desarrollador, eres el otro desarrollador;
    • El diseño es desarrollo;
    • Problemas continuos de mantenimiento y seguridad;
    • Trabajar en proyectos paralelos sin perder la cabeza, la motivación o ambas;
    • Enviar algún producto es mejor que no enviar ningún producto.

    Entonces, antes de ver las lecciones aprendidas, veamos cómo convertir una aplicación web básica escrita en HTML, CSS y JavaScript en una aplicación web progresiva (PWA).

     

    En términos del tiempo total dedicado a crear esta pequeña aplicación web, calculo que probablemente sean entre dos y tres semanas. Sin embargo, como se hizo en fragmentos de 30 a 60 minutos por las noches, en realidad tomó alrededor de un año desde el primer compromiso hasta que subí lo que considero la versión '1.0' en agosto de 2018. Como obtuve la aplicación ' "feature complete", o más simplemente hablando, en una etapa con la que estaba contento, anticipé un gran empujón final. Verá, no había hecho nada para convertir la aplicación en una aplicación web progresiva. Resulta que esta fue en realidad la parte más fácil de todo el proceso.

    Crear una aplicación web progresiva

    La buena noticia es que cuando se trata de convertir una pequeña aplicación basada en JavaScript en una 'aplicación web progresiva', existen muchas herramientas que hacen la vida más fácil. Si recuerda la primera parte de esta serie, recordará que ser una aplicación web progresiva significa cumplir con un conjunto de criterios .

    Para tener una idea de cómo está a la altura su aplicación web, su primera parada probablemente debería ser las herramientas Lighthouse de Google Chrome. Puede encontrar la auditoría de la aplicación web progresiva en la pestaña "Auditorías".

    Esto es lo que me dijo Lighthouse cuando ejecuté In/Out por primera vez.

    Las puntuaciones iniciales de la aplicación web progresiva no fueron muy buenas. ( Vista previa grande )

    Al principio, In/Out solo obtenía una puntuación de 55100 para una aplicación web progresiva. Sin embargo, ¡desde allí llegué a 100100 en menos de una hora!

    La conveniencia de mejorar esa puntuación tuvo poco que ver con mi capacidad. ¡Fue simplemente porque Lighthouse me dijo exactamente lo que había que hacer!

    Algunos ejemplos de pasos necesarios: incluir un manifest.jsonarchivo (esencialmente un archivo JSON que proporcione metadatos sobre la aplicación), agregar una gran cantidad de metaetiquetas en el encabezado, cambiar las imágenes que estaban integradas en el CSS por imágenes referenciadas a URL estándar y agregar un montón de imágenes de la pantalla de inicio.

    Crear varias imágenes de la pantalla de inicio, crear un archivo de manifiesto y agregar un montón de metaetiquetas puede parecer mucho por hacer en menos de una hora, pero existen aplicaciones web maravillosas que lo ayudarán a crear aplicaciones web. ¡Qué lindo es eso! Usé https://app-manifest.firebaseapp.com . Indíquele algunos datos sobre su aplicación y su logotipo, presione enviar y le proporcionará un archivo zip que contiene todo lo que necesita. A partir de ahí, sólo es hora de copiar y pegar.

     

    Cosas que había pospuesto durante algún tiempo por falta de conocimiento, como un trabajador de servicios, también se agregaron con bastante facilidad gracias a numerosas publicaciones de blogs y sitios dedicados a trabajadores de servicios como https://serviceworke.rs . Con un trabajador de servicio implementado, la aplicación podía funcionar sin conexión, una característica necesaria de una aplicación web progresiva.

    Si bien no está estrictamente relacionado con convertir la aplicación en una PWA, la pestaña "cobertura" de Chrome Dev Tools también fue muy útil. Después de tantas iteraciones esporádicas sobre el diseño y el código durante meses, fue útil obtener una indicación clara de dónde había código redundante. ¡Encontré algunas funciones antiguas en el código base que simplemente me había olvidado!

    En poco tiempo, después de haber trabajado con las recomendaciones de la auditoría de Lighthouse, me sentí como la mascota del maestro:

    Lighthouse facilita la obtención de buenas puntuaciones al decirle exactamente qué cambiar. ( Vista previa grande )

    La realidad es que tomar la aplicación y convertirla en una aplicación web progresiva fue increíblemente sencillo.

    Una vez concluida esa parte final del desarrollo, subí la pequeña aplicación a un subdominio de mi sitio web y eso fue todo.

    Retrospectivo

    Han pasado meses desde que aparqué el desarrollo de mi pequeña aplicación web.

    He usado la aplicación de manera casual en los meses posteriores. La realidad es que gran parte de la organización de deportes de equipo que hago todavía se realiza a través de mensajes de texto. Sin embargo, la aplicación es definitivamente más fácil que anotar quién entra y quién sale que buscar un trozo de papel cada noche de juego.

    Entonces, la verdad es que no es un servicio indispensable. Tampoco establece límites para el desarrollo o el diseño. Tampoco podría decirte que estoy 100% contento con él. Llegué a un punto en el que estaba feliz de abandonarlo.

    Pero ese nunca fue el objetivo del ejercicio. Saqué mucho de la experiencia. Lo que sigue es lo que considero las conclusiones más importantes.

    El diseño es desarrollo

    Al principio no valoraba lo suficiente el diseño. Comencé este proyecto creyendo que el tiempo que pasaba dibujando con un bloc y un bolígrafo o en la aplicación Sketch era tiempo que podría dedicar mejor a la codificación. Sin embargo, resulta que cuando iba directamente al código, a menudo simplemente estaba siendo un tonto ocupado. Explorar los conceptos primero con la menor fidelidad posible ahorró mucho más tiempo a largo plazo.

    Al principio hubo numerosas ocasiones en las que se pasaron horas haciendo que algo funcionara en el código solo para darse cuenta de que era fundamentalmente defectuoso desde el punto de vista de la experiencia del usuario.

    Mi opinión ahora es que el papel y el lápiz son las mejores herramientas de planificación, diseño y codificación. Todos los problemas importantes que surgieron se resolvieron principalmente con papel y lápiz; el editor de texto es simplemente un medio para ejecutar la solución. Sin algo que tenga sentido en papel, no hay posibilidad de que funcione en código.

     

    Lo siguiente que aprendí a apreciar, y no sé por qué me tomó tanto tiempo descubrirlo, es que el diseño es iterativo. Subconscientemente había creído en el mito de un Diseñador con “D” mayúscula. Alguien dando vueltas, sosteniendo su portaminas en los bordes rectos, volviéndose lírico sobre los tipos de letra y bebiendo un blanco mate (con leche de soja, obviamente) antes de dar a luz casualmente a la perfección visual completamente formada en el mundo.

    Esto, al igual que la noción del programador "genio", es un mito. Si eres nuevo en el diseño pero estás probando suerte, te sugiero que no te obsesiones con la primera idea que despierte tu entusiasmo. Es muy barato probar variaciones, así que aprovecha esa posibilidad. Ninguna de las cosas que me gustan del diseño de In/Out estaban presentes en los primeros diseños.

    Creo que fue el novelista Michael Crichton quien acuñó la máxima: “Los libros no se escriben, se reescriben”. Acepte que todo proceso creativo es esencialmente el mismo. Tenga en cuenta que confiar en el proceso disminuye la ansiedad y la práctica perfeccionará su comprensión y juicio estéticos.

    Eres el otro desarrollador de tu proyecto

    No estoy seguro de si esto se aplica específicamente a proyectos en los que sólo se trabaja esporádicamente, pero hice la siguiente suposición imprudente:

    "No necesito documentar nada de esto porque soy sólo yo y obviamente lo entenderé porque lo escribí".

    ¡Nada mas lejos de la verdad!

    Hubo noches en las que, durante los 30 minutos que tuve que trabajar en el proyecto, no hice más que intentar comprender una función que había escrito hace seis meses. Las principales razones por las que la reorientación del código tomó tanto tiempo fue la falta de comentarios de calidad y variables y argumentos de funciones mal nombrados.

    Soy muy diligente comentando código en mi trabajo diario, siempre consciente de que alguien más podría necesitar darle sentido a lo que estoy escribiendo. Sin embargo, en este caso, yo era esa otra persona. ¿De verdad crees que recordarás cómo funciona el bloque de código que escribiste dentro de seis meses? No lo harás. Créeme en esto, ¡tómate un tiempo y comenta eso!

    Desde entonces leí una publicación de blog titulada Su resaltador de sintaxis es incorrecto en el tema de la importancia de los comentarios. La premisa básica es que los resaltadores de sintaxis no deberían atenuar los comentarios, deberían ser lo más importante. Me inclino a estar de acuerdo y si no encuentro pronto un tema de editor de código que me quite esa picazón, ¡es posible que tenga que adaptar uno para ese fin yo mismo!

    Depuración

    Cuando encuentra errores y ha escrito todo el código, no es injusto sugerir que el error probablemente se origine entre el teclado y la silla. Sin embargo, antes de asumir eso, le sugiero que pruebe incluso sus suposiciones más básicas. Por ejemplo, recuerdo que me tomó más de dos horas solucionar un problema que supuse que se debía a mi código; en iOS simplemente no pude hacer que mi cuadro de entrada aceptara la entrada de texto. No recuerdo por qué no me había detenido antes, pero sí recuerdo mi frustración con el problema.

     

    Resulta que se debió a un error en Safari que aún no se ha solucionado. Resulta que en Safari si tienes:

    * { user-select: none;}

    En su hoja de estilo, los cuadros de entrada no aceptarán ninguna entrada. Puedes solucionar esto con:

    * { user-select: none;}input[type] { user-select: text;}

    ¿Cuál es el enfoque que adopto en mi restablecimiento de CSS de “ Restablecimiento de aplicación ”? Sin embargo, la parte realmente frustrante de esto fue que ya lo había aprendido y luego lo olvidé. Cuando finalmente pude verificar el seguimiento de errores de WebKit mientras solucionaba el problema, descubrí que había escrito una solución alternativa en el hilo del informe de errores hace más de un año, ¡completa con reducción!

    ¿Quiere construir con datos? Aprenda métodos de matriz de JavaScript

    Quizás el mayor avance que obtuvieron mis habilidades de JavaScript al realizar este ejercicio de creación de aplicaciones fue familiarizarme con los métodos de matriz de JavaScript. Ahora los uso a diario para todas mis necesidades de iteración y manipulación de datos. No puedo enfatizar lo suficiente lo útiles que son métodos como map(), filter(), every(), findIndex()y . Puedes resolver prácticamente cualquier problema de datos con ellos. Si aún no los tiene en su arsenal, agregue https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Array ahora y profundice tan pronto como pueda. Mi propio resumen de mis métodos de matriz favoritos está documentado aquí.find()reduce()

    SetES6 ha introducido otros ahorradores de tiempo para manipular matrices , como Resty Spread. Permítanme compartir un ejemplo; Solía ​​​​haber un montón de errores si querías eliminar duplicados incluso de una matriz plana simple. Ya no.

    Considere este ejemplo simple de una matriz con la entrada duplicada, "Mr Pink":

    let myArray = [ "Mr Orange", "Mr Pink", "Mr Brown", "Mr White", "Mr Blue", "Mr Pink"];

    Para deshacerse de los duplicados con ES6 JavaScript, ahora puede simplemente hacer:

    let deDuped = [...new Set(myArray)]; // deDuped logs ["Mr Orange", "Mr Pink", "Mr Brown", "Mr White", "Mr Blue"]

    Algo que solía requerir una solución manual o buscar una biblioteca ahora está integrado en el lenguaje. Es cierto que en un Array corto esto puede no parecer tan importante, pero imagina cuánto tiempo se ahorra al mirar arreglos con cientos de entradas y duplicados.

    Mantenimiento y seguridad

    Cualquier cosa que cree que haga uso de NPM, incluso si solo se utiliza para herramientas de compilación, conlleva la posibilidad de ser vulnerable a problemas de seguridad. GitHub hace un buen trabajo manteniéndote al tanto de posibles problemas, pero aún existe cierta carga de mantenimiento.

    Para algo que es un mero proyecto paralelo, esto puede resultar un poco molesto en los meses y años que siguen al desarrollo activo.

    La realidad es que cada vez que actualizas dependencias para solucionar un problema de seguridad, introduces la posibilidad de romper tu compilación.

     

    Durante meses, mi package.jsonaspecto era el siguiente:

    { "dependencies": { "gulp": "^3.9.1", "postcss": "^6.0.22", "postcss-assets": "^5.0.0" }, "name": "In Out", "version": "1.0.0", "description": "simple utility to see who’s in and who’s out", "main": "index.js", "author": "Ben Frain", "license": "MIT", "devDependencies": { "autoprefixer": "^8.5.1", "browser-sync": "^2.24.6", "cssnano": "^4.0.4", "del": "^3.0.0", "gulp-htmlmin": "^4.0.0", "gulp-postcss": "^7.0.1", "gulp-sourcemaps": "^2.6.4", "gulp-typescript": "^4.0.2", "gulp-uglify": "^3.0.1", "postcss-color-function": "^4.0.1", "postcss-import": "^11.1.0", "postcss-mixins": "^6.2.0", "postcss-nested": "^3.0.0", "postcss-simple-vars": "^4.1.0", "typescript": "^2.8.3" }}

    Y en junio de 2019, recibí estas advertencias de GitHub:

    Mantener las dependencias enumeradas en GitHub significa advertencias de seguridad poco frecuentes. ( Vista previa grande )

    Ninguno estaba relacionado con los complementos que estaba usando directamente, todos eran subdependencias de las herramientas de compilación que había usado. Ésta es el arma de doble filo de los paquetes de JavaScript. En términos de la aplicación en sí, no hubo ningún problema con In/Out; eso no estaba usando ninguna de las dependencias del proyecto. Pero como el código estaba en GitHub, me sentí en la obligación de intentar arreglar las cosas.

    Es posible actualizar los paquetes manualmente, con algunos cambios de elección en package.json. Sin embargo, tanto Yarn como NPM tienen sus propios comandos de actualización. Opté por ejecutar yarn upgrade-interactive, lo que te brinda un medio simple para actualizar cosas desde la terminal.

    Yarn hace que la actualización de las dependencias del proyecto sea un poco más predecible. ( Vista previa grande )

    Parece bastante fácil, incluso hay una pequeña tecla de color que le indica qué actualizaciones son más importantes.

    Puede agregar la --latestbandera para actualizar a la última versión principal de las dependencias, en lugar de solo la última versión parcheada. Por un centavo...

    El problema es que las cosas se mueven rápido en el mundo de los paquetes de JavaScript, por lo que actualizar algunos paquetes a la última versión y luego intentar una compilación resultó en esto:

    Error de compilación de Gulp ( vista previa grande )

    Como tal, revertí mi package.jsonarchivo y lo intenté nuevamente esta vez sin la --latestbandera. Eso resolvió mis problemas de seguridad. No es lo más divertido que he tenido un lunes por la noche, aunque seré honesto.

    Esto toca una parte importante de cualquier proyecto paralelo. Ser realista con tus expectativas.

    Proyectos paralelos

    No sé si a ti te pasa lo mismo, pero he descubierto que un optimismo vertiginoso y una emoción me hacen comenzar proyectos y, si algo lo hace, la vergüenza y la culpa me hacen terminarlos.

    Sería mentira decir que la experiencia de hacer esta pequeña aplicación en mi tiempo libre estuvo llena de diversión. Hubo ocasiones en las que desearía no haber abierto la boca a nadie. Pero ahora que está hecho, estoy 100% convencido de que valió la pena el tiempo invertido.

     

    Dicho esto, es posible mitigar la frustración con un proyecto paralelo de este tipo siendo realista acerca de cuánto tiempo llevará comprender y resolver los problemas que enfrenta. ¿Solo tienes 30 minutos por noche, algunas noches a la semana? Aún puedes completar un proyecto paralelo; pero no te enojes si tu ritmo se siente glacial. Si las cosas no pueden disfrutar de toda su atención, prepárese para un ritmo más lento y constante del que quizás esté acostumbrado. Eso es cierto, ya sea codificando, completando un curso, aprendiendo a hacer malabarismos o escribiendo una serie de artículos que explican por qué tomó tanto tiempo escribir una pequeña aplicación web.

    Establecimiento de objetivos sencillo

    No necesita un proceso sofisticado para establecer objetivos. Pero podría resultar útil dividir las cosas en tareas pequeñas o cortas. Cosas tan simples como "escribir CSS para el menú desplegable" se pueden lograr perfectamente en un espacio de tiempo limitado. Mientras que "investigar e implementar un patrón de diseño para la gestión estatal" probablemente no lo sea. Rompe las cosas. Luego, al igual que Lego, las pequeñas piezas se unen.

    Al pensar en este proceso como si estuviera socavando un problema mayor, recuerdo la famosa cita de Bill Gates:

    "La mayoría de la gente sobreestima lo que pueden hacer en un año y subestiman lo que pueden hacer en diez años".

    Esto lo dice un hombre que está ayudando a erradicar la polio . Bill sabe lo que hace. Escuchen a Bill todos ustedes.

    Enviar algo es mejor que enviar nada

    Antes de "enviar" esta aplicación web, revisé el código y me desanimé por completo.

    Aunque había emprendido este viaje desde un punto de completa ingenuidad e inexperiencia, había tomado algunas decisiones decentes en lo que respecta a cómo diseñar (si me perdonan un término tan grandioso) el código. Investigué e implementé un patrón de diseño y disfruté de todo lo que ese patrón tenía para ofrecer. Lamentablemente, a medida que me desesperaba más por concluir el proyecto, no pude mantener la disciplina. El código tal como está es una verdadera mezcolanza de enfoques y está plagado de ineficiencias.

    En los meses transcurridos desde entonces me he dado cuenta de que esas deficiencias realmente no importan. No precisamente.

    Soy fanático de esta cita de Helmuth von Moltke.

    "Ningún plan de operaciones se extiende con certeza más allá del primer contacto con la principal fuerza hostil".

    Eso ha sido parafraseado como:

    “Ningún plan sobrevive al primer contacto con el enemigo”.

    ¿Quizás podamos reducirlo aún más y decir simplemente “suceden cosas”?

    Puedo suponer que estoy aceptando lo que se envió a través de la siguiente analogía.

    Si un amigo anunciara que iba a intentar correr su primer maratón, lo único que importaría sería cruzar la línea de meta; no lo reprendería por su tiempo de finalización.

    No me propuse escribir la mejor aplicación web. El cometido que me propuse fue simplemente diseñar y fabricar uno.

    Más específicamente, desde una perspectiva de desarrollo, quería aprender los fundamentos de cómo se construye una aplicación web. Desde el punto de vista del diseño, quería intentar resolver algunos problemas de diseño (aunque simples) por mí mismo. Hacer esta pequeña aplicación superó esos desafíos y más. El JavaScript para toda la aplicación era de solo 5 KB (comprimido con gzip). Un tamaño de archivo pequeño al que me costaría llegar con cualquier marco. Excepto tal vez Svelte .

     

    Si se está planteando un desafío de esta naturaleza y espera en algún momento "enviar" algo, escriba desde el principio por qué lo está haciendo. Mantenga esas razones en primer plano en su mente y déjese guiar por ellas. En última instancia, todo es una especie de compromiso. No permita que ideales elevados le impidan terminar lo que se propuso hacer.

    Resumen

    En general, ya que ha pasado un año desde que trabajé en In/Out, mis sentimientos se dividen en tres áreas: cosas de las que me arrepiento, cosas que me gustaría mejorar/arreglar y posibilidades futuras.

    Cosas de las que me arrepiento

    Como ya se mencionó, me decepcionó no haberme apegado a lo que consideraba un método más elegante para cambiar el estado de la aplicación y representarla en el DOM. El patrón de observador, como se analiza en la segunda parte de esta serie , que resolvió tantos problemas de manera predecible, finalmente se dejó de lado cuando "enviar" el proyecto se convirtió en una prioridad.

    Al principio me avergonzaba mi código, pero en los meses siguientes me volví más filosófico. Si no hubiera utilizado más técnicas peatonales más adelante, existe una posibilidad muy real de que el proyecto nunca hubiera concluido. Sacar al mundo algo que necesita mejorar todavía se siente mejor que no haber nacido nunca en el mundo.

    Mejorando dentro/fuera

    Más allá de elegir el marcado semántico, no hice ninguna provisión para la accesibilidad. Cuando incorporé In/Out, confiaba en la accesibilidad estándar de la página web, pero no tenía los conocimientos suficientes para abordar una aplicación. He realizado mucho más trabajo/investigación en esa área ahora, por lo que disfrutaría tomarme el tiempo para hacer un trabajo decente para hacer que esta aplicación sea más accesible.

    La implementación del diseño revisado de la funcionalidad 'Agregar persona' se apresuró. No es un desastre, sólo un poco más duro de lo que me gustaría. Sería bueno hacerlo más pulido.

    Tampoco consideré las pantallas más grandes. Sería interesante considerar los desafíos de diseño que implica hacerlo funcionar en tamaños más grandes, más allá de simplemente convertirlo en un tubo de contenido.

    Posibilidades

    El uso de localStorage funcionó para mis necesidades simplistas, pero sería bueno tener un almacén de datos "adecuado" para que no fuera necesario preocuparme por hacer una copia de seguridad de los datos. Agregar la capacidad de iniciar sesión también abriría la posibilidad de compartir la organización del juego con otra persona. ¿O tal vez cada jugador podría simplemente marcar si está jugando él mismo? Es sorprendente cuántas vías de exploración se pueden imaginar a partir de unos comienzos tan simples y humildes.

    SwiftUI para el desarrollo de aplicaciones iOS también es intrigante. Para alguien que solo ha trabajado con lenguajes web, a primera vista, SwiftUI parece algo que ahora me animaría a probar. Probablemente intentaría reconstruir In/Out con SwiftUI, solo para tener algo específico para construir y comparar la experiencia de desarrollo y los resultados.

    Entonces, es hora de concluir y brindarles la versión TL;DR de todo esto.

    Si desea aprender cómo funciona algo en la web, le sugiero que se salte las abstracciones. Deshazte de los marcos, ya sea CSS o JavaScript, hasta que realmente comprendas para qué sirven.

    El diseño es iterativo, adopte ese proceso.

    Resuelve problemas en el medio de menor fidelidad a tu disposición. No vayas a codificar si puedes probar la idea en Sketch. No lo dibujes en Sketch si puedes usar lápiz y papel. Primero escribe la lógica. Luego escríbalo en código.

    Sea realista pero nunca desanimado. Desarrollar el hábito de tallar algo durante tan solo 30 minutos al día puede dar resultados. Ese hecho es cierto cualquiera que sea la forma que adopte su búsqueda.

    (dm, il, ra)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 2)
    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 3)

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

    ¡Registro! Patrones de diseño para interfaces de IA, con Vitaly Friedman Índice Crear una aplicación w

    programar

    es

    https://pseint.es/static/images/programar-diseno-y-construccion-de-una-aplicacion-web-progresiva-sin-marco-parte-3-995-0.jpg

    2024-04-04

     

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

    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