DEV Community: David Vargas

Las promesas y async await lógicamente no son iguales. Y te explico el porqué

David Vargas — Mon, 24 Feb 2020 19:36:28 +0000

¿Alguna vez te has preguntado el por qué existe async await si ya se tiene las promesas? Muchos desarrolladores ya están usando esta funcionalidad. Sin embargo, no saben cómo funciona o cómo es diferente de las promesas. Eso es exactamente lo que abarcará este post. Empezaremos recordando por qué llegaron las promesas y cómo es que funciona, luego será el turno de async await y su funcionamiento. Finalmente veremos un ejemplo de cómo aplicar estas dos formas de manejar la asíncronia en conjunto.

¿Por qué Promesas?
La llegada de Async Await
Async Await y Promesas trabajando juntos

Para poder entender varios términos que se va a usar, es necesario tener cierto conocimiento previo de Javascript y su asíncronia. Por eso, te recomiendo leer estos posts. Son muy buenos!

Ya tenemos todo lo necesario y ya estás listo para seguir leyendo este post. Esta es una oportunidad de entender mejor la asíncronia en Javascript. A por ello!

¿Por qué Promesas?

Las promesas llegan en ECMAscript 2016 como solución a uno de los problemas que generaba los callbacks, el callback hell. Este hacía que el código asíncronico se apile horizontalmente a la derecha. Por lo cual esto hacía que el código se vuelva muy complicado de leer. Lo que planteaba las promesas era una mejor sintaxis. En vez de que el código esté horizonal, pues que esté vertical y encadenado. Veamos un ejemplo para entenderlo mejor.

En estos trozos de código hacemos unas llamadas a un api para conseguir el id de un usuario, conseguir sus seguidores y haces más cosas. Haciendo esto con tan solo callbacks, nos resulta como en la imagen. Imagínate que haya muchos más callbacks. ¿Difícil de leer, no?

    callEndpoint('api/getidbyusername/davos', function (results) {
        callEndpoint('api/getfollowersbyid' + results.userId, function (results) {
            callEndpoint('api/someothercall', function (results) {
                callEndpoint('api/someothercall', function (results) {
                    callEndpoint('api/someothercall', function (results) {
                        callEndpoint('api/someothercall', function (results) {
                        // do things here
                        })
                    })
                })
            })
        })
    })

Pero con las promesas todo es diferente, el código se vuelve vertical y más legible.

    callEndpoint('api/getidbyusername/davos')
        .then(results => callEndpoint('api/getfollowersbyid' + results.userId))
        .then(results => callEndpoint('api/someothercall'))
        .then(results => callEndpoint('api/someothercall'))
        .then(results => callEndpoint('api/someothercall'))
        .then(results => callEndpoint('api/someothercall'))

Entonces, ¿Las promesas es solo sintaxis y funcionan igual que los callbacks?

No exactamente. Es cierto que las promesas manejan código que será ejecutado en algún futuro al igual que los callbacks. Nótese aquí la incertidumbre de cuándo será ejecutado este código. Sin embargo, la diferencia está en el mecanismo de las promesas. Pero antes, repasemos un poco para entender este mecanismo. El código síncrono inmediatamente se va a un lugar llamado el Call Stack, aquí la última función que entra al stack es el primero que se ejecuta y que sale del stack así hasta la primera que ingreso. Por otro lado, el asíncrono se va a una cola de tareas para su respectiva ejecución. Una vez que el Call Stack esté vacío, el Event Loop moverá las funciones que ya estén listas de la cola de tareas al Call Stack y luego pasarán a mostrar su resultado. Con esto en mente retomemos las promesas. Estas se dirigen a una cola de tareas diferente a las que van los callbacks. Los callbacks se van al Task Queue y las promesas al PromiseJobs o también llamado MicroTask Queue. Estos son manejadores de tareas, básicamente son los que deciden qué funciones son las que entran y las que salen.

Referencia: https://medium.com/@jitubutwal144/javascript-how-is-callback-execution-strategy-for-promises-different-than-dom-events-callback-73c0e9e203b1

Si te has confundido o si aún así quieres saber un poco más de los Tasks, MicroTasks y queues, te dejo este post muy bueno para profundizar estos conceptos.

Tasks, microtasks, queues and schedules

Ahora ya tenemos una idea de cómo funciona las promesas. ¿Y async await? Pues vamos a ello.

La llegada de Async Await

En ECMAscript 2017 es cuando Async Await entra al juego. Este nuevo feature de Javascript planteaba un mejor manejo de las promesas. Estos ya no estarían encadenados uno del otro volviendo la sintaxis más entendible y fácil de usar. Sobre todo fácil de usar. Para usarlo tan solo se necesita async functions y la keyword await. Este keyword permite que una promesa se resuelva y retorne su valor, esto permite que podamos guardarlo en variables. Pero no todo podía ser oro. await solo funciona en async functions. Este tipo de funciones simplemente se aseguran que lo que sea que retornen sea una promesa. Dicho de otro modo, estas funciones siempre retornan una promesa. Veámoslo en un ejemplo.

Tomaremos el ejemplo de las promesas y convertiremos su sintaxis usando async await

    // usando Promesas
    callEndpoint('api/getidbyusername/davos')
        .then(results => callEndpoint('api/getfollowersbyid' + results.userId))
        .then(results => callEndpoint('api/someothercall'))
        .then(results => callEndpoint('api/someothercall'))
        .then(results => callEndpoint('api/someothercall'))
        .then(results => callEndpoint('api/someothercall'))

    // usando Async Await
    async function callEndpoints() {
        const userResults = await callEndpoint('api/getidbyusername/davos')
        const followersResults = await callEndpoint('api/getfollowersbyid' + userResults.userId)
        const someResults = await callEndpoint('api/someothercall')
        const moreResults = await callEndpoint('api/someothercall')
        const anotherResults = await callEndpoint('api/someothercall')
        const finalResults = await callEndpoint('api/someothercall')

        return finalResults
    }

    callEndpoints()

Después de ver la sintaxis creo que estamos de acuerdo que es mucho más simple y entendible de usar. Sin embargo, el manejo de async await es diferente a la de las promesas. Sabemos que await hace una pausa hasta que la promesa se resuelva. Literalmente, hace que la ejecución del async function espere hasta que la promesa se resuelva y retorne un valor, aúnque esto no detiene el engine del lenguaje, este aún puede ejecutar otros scripts o eventos, esto significa que está volviendo el código asíncrono en síncrono. Y tal vez habrás pensado en qué sentido tiene esto si ya no va a ser asíncrono o no sea de utilidad y que mejor sigues trabajando con las promesas. Pues, esto no es totalmente cierto. Async Await puede brillar en ciertos casos de uso donde necesitemos esperar y saber cuándo alguna función asíncrona se ejecute, por ejemplo en el caso de pedidos a una api, donde necesitemos que primero la página se llene de datos para que el usuario pueda interactuar.

Pero, y si te dijera que podemos ir aún más allá y combinar lo mejor de ambos mundos. Podemos aprovechar la pausa de async await y las utilidades de las promesas como Promise.all . Esto lo veremos en el siguiente tema en un caso de uso donde sean necesario tener ambas.

Async Await y Promesas trabajando juntos

Vamos a suponer que estamos programando una carga inicial del perfil de usuario y que uno de los requerimientos sea que debamos mostrar la información básica del usuario, los cursos que ha tomado en la plataforma y la lista de sus amigos antes de que termine la carga. Estos recursos se consiguen por medio de una api, y cada recurso está en una diferente url. Y las url del api de los cursos y la de amigos vienen en la información del usuario en la propiedad links.

Información del usuario: api/user/1234
Cursos que ha tomado: api/user/1234/courses
Lista de sus amigos: api/user/1234/friends

Este es un ejemplo de la respuesta a un pedido a la url de la información del usuario

    {
        user: {
            id: 1234,
            ...
            links: ['api/user/1234/courses', 'api/user/1234/friends']
        }
    }

Entonces tenemos que hacer 3 pedidos a la api y debemos tener acceso a su data antes de que termine la carga. Está claro lo que debemos usar, async await y promesas.

Vamos a crear una async function donde en primera instancia haremos un pedido a la url del usuario para obtener la información básica y los links que están como propiedad del usuario. Luego, usaremos una utilidad de las promesas, Promise.all. Esto hará que los pedidos se ejecuten paralelamente, por lo tanto el tiempo de espera se disminuye al no tener que ejectuar los pedidos de los links consecutivamente. Un detalle es que si alguno de estos pedidos falla en el Promise.all, todos fallarán. O todo o nada.

Dentro de Promise.all, iteraremos sobre los links con la función de los arreglos, map . Este recibe una función que tiene como argumento el elemento del arreglo en cada iteración, en este caso el link. Luego dentro de la función, aplicamos un arrow function que retorna un fetch al link en cada iteración. Esto hará que en cada iteración se retorne una promesa. Al final, tendremos un arreglo de estas promesas sin resolver. Para esto aplicamos await al Promise.all para que resuelva todas las promesas paralelamente. Una vez ya resueltos, obtendremos todas las respuestas de los pedidos si todo fue bien y lo guardamos en una variable userResponse. Por último aplicamos todo esto de nuevo para parsear las respuestas en data de tipo objeto para que Javascript pueda hacer operaciones sobre la data.

    async function getAllUserInfo(id) {
        const user = await fetch('api/user/' + id)

        const userResponse = await Promise.all(user.links.map(link => fetch(link)))

        const userData = await Promise.all(userResponse.map(response => response.json()))

        return userData
    }

Por último obtenemos la data requerida para el usuario, y logramos hacer que la información se visualice por el usuario final.

Conclusión

Para resumir, las promesas y async await resuelven la asincronía de distinta forma. Con las promesas no sabemos cuándo se va a resolver y con async await forzamos una espera en la función. No siempre se va a usar uno, el otro o ambos, por ello lo primero es entender el caso de uso y después empezamos a implementar todo lo que hemos aprendido aquí.

5 tips para html que te salvarán la vida

David Vargas — Wed, 19 Feb 2020 19:23:52 +0000

Hay veces que te toca revisar aquellos archivos HTML. Tú, como desarrollador, dispuesto a hacer tu trabajo rápidamente, esperas que el código esté bien estructurado, semánticamente claro, y sin estilos en línea. Bueno, hay veces que no vas a encontrar el código así, pero puedes comenzar a cambiar eso, aplicando una serie de buenas prácticas para que otros devs encuentren tu código HTML de lo más limpio posible. Y he aquí 5 tips que harán que tu código sea más prolijo y claro para otros devs.

El HTML importa
Indentación
¿Tabs o Espacios?
HTML semántico
Separar el CSS en archivos externos

En este post, voy a ir explicando cómo aplicar estas técnicas y el porqué partiendo de un código ilegible hasta volverlo código prolijo y claro. Entonces, si estás interesado en mejorar en buenas prácticas o si tan solo quieres repasar tus fundamentos, te recomiendo seguir leyendo este post. Aquí vamos!

El HTML importa

HTML en sí no es un lenguaje de programación. Es un lenguaje de marcado, significa que HTML define la estructura del contenido de un sitio web. Esto, algunas veces, hace que no sea tan relevante en comparación con lenguajes de programación, como Javascript, y por tanto, es descuidado en el desarrollo. Pero, realmente importa. Si nosotros como desarrolladores descuidamos el HTML, no podremos reconocer las secciones de nuestra web, por tanto, esto hará que nuestro código no sea mantenible y no pueda escalar en el tiempo.

Vamos a comenzar con un código HTML con muchas malas prácticas y poco a poco, convertiremos el código a uno de calidad aplicando buenas prácticas.


<!DOCTYPE html>
<html>
<head>
<title>Tu Blog</title>
</head>
<body style="margin: 0">
<div style="display: grid; height: 100vh; grid-gap: 5px; grid-template-columns: repeat(2, 1fr); grid-template-rows: 100px 90px 1fr 90px; grid-template-areas: 'header header' 'nav nav' 'aside main' 'footer footer';"> 
<div style="display: flex; justify-content: center; align-items: center; font-size: 2em; font-weight: 700; font-family: 'arial'; color: #c0c0c0; grid-area: header; background-color: lightblue;">HEADER</div>
<div style="display: flex; justify-content: center; align-items: center; font-size: 2em; font-weight: 700; font-family: 'arial'; color: #c0c0c0; grid-area: nav; background-color: #cccc;">NAV</div>
<div style="display: flex; justify-content: center; align-items: center; font-size: 2em; font-weight: 700; font-family: 'arial'; color: #c0c0c0; grid-area: aside; background-color: yellow;">ASIDE</div>
<div style="display: flex; justify-content: center; align-items: center; font-size: 2em; font-weight: 700; font-family: 'arial'; color: #c0c0c0; grid-area: main; background-color: orange;">CONTENT</div>
<div style="display: flex; justify-content: center; align-items: center; font-size: 2em; font-weight: 700; font-family: 'arial'; color: #c0c0c0; grid-area: footer; background-color: peru;">FOOTER</div>
</div>
</body>
</html>

Indentación

El bloque de HTML previo puede funcionar sin problemas, el navegador es capaz de leerlo e interpretarlo. Pero, y nosotros? Probablemente sí, porque el código es pequeño y legible a simple vista. Sin embargo, imagínense ese código en mil o dos mil líneas. No podríamos saber qué elementos son padres o hijos de otros elementos, y aunque funcione, se vuelve tedioso para otros desarrolladores buscar la relación de cada elemento con los demás, por lo que es importante que se especifique a los elementos por niveles en el editor de código, solo así podremos saber quién es el ancestro, padre o hijo de cada elemento. Así que sé bueno e indenta tu código!

Tu reto es indentar el bloque HTML previo. Sabrás que lo habrás conseguido cuando puedas distinguir quién es el elemento padre y el elemento hijo. Dejaré el reto resuelto más abajo. Sin embargo, no bajes hasta que lo hayas intentado, en la práctica está la maestría.

    <!DOCTYPE html>
    <html>
      <head>
        <title>Tu Blog</title>
      </head>
      <body style="margin: 0">
        <div style="display: grid; height: 100vh; grid-gap: 5px; grid-template-columns: repeat(2, 1fr); grid-template-rows: 100px 90px 1fr 90px; grid-template-areas: 'header header' 'nav nav' 'aside main' 'footer footer';">
          <div style="display: flex; justify-content: center; align-items: center; font-size: 2em; font-weight: 700; font-family: 'arial'; color: #c0c0c0; grid-area: header; background-color: lightblue;">
                    HEADER
                </div>
          <div style="display: flex; justify-content: center; align-items: center; font-size: 2em; font-weight: 700; font-family: 'arial'; color: #c0c0c0; grid-area: nav; background-color: #cccc;">
                    NAV         
                </div>
          <div style="display: flex; justify-content: center; align-items: center; font-size: 2em; font-weight: 700; font-family: 'arial'; color: #c0c0c0; grid-area: aside; background-color: yellow;">
                    ASIDE
                </div>
          <div style="display: flex; justify-content: center; align-items: center; font-size: 2em; font-weight: 700; font-family: 'arial'; color: #c0c0c0; grid-area: main; background-color: orange;">
                    CONTENT
                </div>
          <div style="display: flex; justify-content: center; align-items: center; font-size: 2em; font-weight: 700; font-family: 'arial'; color: #c0c0c0; grid-area: footer; background-color: peru;">
                    FOOTER
                </div>
        </div>
      </body>
    </html>

¿Tabs o Espacios?

Tabs o espacios es uno de las discusiones eternas que se van a dar en cada foro de programación. Entre tantas opiniones, lo mejor es experimentar con ambos y ver con cuál te sientes más cómodo, ~~en silencio, sino se quiere terminar como en la imagen~~, o simplemente escoger lo que viene por defecto en tu editor de código 🤷‍♂️. A partir de ahí, sugiero que te quedes con esa configuración en solo tus proyectos personales. Esto es porque cuando se comienza a trabajar en equipo se suele llegar a un acuerdo entre todos, y la configuración se vuelve única para todo el equipo.

No a la divitis, sí a la semántica

Divitis es un término que se ha creado para indicar que un desarrollador está abusando del uso de las etiquetas div y span como contenedores genéricos en lugar de usar elementos estructurales y semánticos de HTML.

Antes de profundizar, debemos saber que las etiquetas div son elementos de agrupación, se supone que están hechos para agrupar las secciones de una página en divisiones. Por ejemplo, una división en la parte superior como un header con un logo y unos links, un sidebar o hasta un footer. Los divs son elementos de agrupación con ningún estilo por defecto. No tienen margin, padding o border, el único estilo por defecto es que es un elemento de tipo bloque. display: block;

Si bien se puede maquetar una página usando divs y spans, esto es considerado una mala práctica, no es escalable y se vuelve una tortura para los desarrolladores al tener tantos divs y spans en un archivo. Afortunadamente, desde HTML5 han aparecido etiquetas con semántica, estos tienen un significado, una razón del porqué están ahí. Así, se vuelve sencillo para nosotros el poder diferenciar cada bloque de código.

Mencionando algunos elementos semánticos de HTML5 son:

<main></main> indica el contenido principal y el más importante de una página web.
<header></header> es el encabezado de una página, es donde se ubicará el logo y links principales
<section></section> sirve para indicar qué contenido corresponde a qué parte de un esquema
<article></article> funciona para contener información de entradas de blog, mensajes de foro o artículos de revistas.
<footer></footer> es el pie de página, es la última parte de toda web. Se ubican los links restantes, sitios de mapas y redes sociales.

Continuando con nuestro bloque HTML, el reto es reemplazar todos los divs del código por etiquetas semánticas. Colocaré la solución en la parte inferior. Aún así, no dudes en intentarlo!

<!DOCTYPE html>
<html>
  <head>
    <title>Tu Blog</title>
  </head>
  <body style="margin: 0">
    <section style="display: grid; height: 100vh; grid-gap: 5px; grid-template-columns: repeat(2, 1fr); grid-template-rows: 100px 90px 1fr 90px; grid-template-areas: 'header header' 'nav nav' 'aside main' 'footer footer';">

      <header style="display: flex; justify-content: center; align-items: center; font-size: 2em; font-weight: 700; font-family: 'arial'; color: #c0c0c0; grid-area: header; background-color: lightblue;">
        HEADER
      </header>

      <nav style="display: flex; justify-content: center; align-items: center; font-size: 2em; font-weight: 700; font-family: 'arial'; color: #c0c0c0; grid-area: nav; background-color: #cccc;">
        NAV
      </nav>

      <aside style="display: flex; justify-content: center; align-items: center; font-size: 2em; font-weight: 700; font-family: 'arial'; color: #c0c0c0; grid-area: aside; background-color: yellow;">
        ASIDE
      </aside>

      <main style="display: flex; justify-content: center; align-items: center; font-size: 2em; font-weight: 700; font-family: 'arial'; color: #c0c0c0; grid-area: main; background-color: orange;">
        CONTENT
      </main>

      <footer style="display: flex; justify-content: center; align-items: center; font-size: 2em; font-weight: 700; font-family: 'arial'; color: #c0c0c0; grid-area: footer; background-color: peru;">
        FOOTER
      </footer>

    </section>
  </body>
</html>

Separa el CSS y Javascript del HTML

Existen tres formas de aplicar estilos al HTML, estos son en línea, dentro de una etiqueta <style></style> y en archivos CSS externos. La mejor práctica es mover nuestros estilos a archivos externos, así dejamos que cada archivo que tengamos tome una única responsabilidad. Nuestros archivos .html harán la estructura y el marcado, nuestros archivos .css aplicarán los estilos y adornarán la página, y los archivos .js harán que exista interacciones en nuestra página.

Para terminar nuestro bloque de HTML, el reto es mover nuestros estilos a archivos externos, y aplicar clases a nuestros elementos. Atrévete!

    <!DOCTYPE html>
    <html>
      <head>
        <title>Tu Blog</title>
        <link rel="stylesheet" href="estilos.css">
      </head>
      <body>
        <section class="layout">

          <header class="container header">
            HEADER
          </header>

          <nav class="container nav">
            NAV
          </nav>

          <aside class="container aside">
            ASIDE
          </aside>

          <main class="container main">
            CONTENT
          </main>

          <footer class="container footer">
            FOOTER
          </footer>

        </section>
      </body>
    </html>

    body {
      margin: 0;
    }

    .layout {
      display: grid;
      height: 100vh;
      grid-gap: 5px;
      grid-template-columns: repeat(2, 1fr);
      grid-template-rows: 100px 90px 1fr 90px;
      grid-template-areas: 'header header' 'nav nav' 'aside main' 'footer footer';
    }

    .container {
      display: flex;
      justify-content: center;
      align-items: center;
      font-size: 2em;
      font-weight: 700;
      font-family: 'arial';
      color: #c0c0c0;
    }

    .header {
      grid-area: header;
      background-color: lightblue;
    }

    .nav {
      grid-area: nav;
      background-color: #cccc;
    }

    .aside {
      grid-area: aside;
      background-color: yellow;
    }

    .main {
      grid-area: main;
      background-color: orange;
    }

    .footer {
      grid-area: footer;
      background-color: peru;
    }

Sé consistente

Lo dicho, en la práctica está la maestría. Ser consistente con cada tip aprendido aquí te ahorrará un montón de problemas, cada buena práctica aplicada te ayudará o al equipo en el que estés, porque escribirás código escalable y fácil de leer. Por ello, sigue practicando, práctica, nunca te rindas y nunca pares de aprender 🤓.

¿En qué se diferencian width, max-width y min-width?

David Vargas — Wed, 19 Feb 2020 03:26:35 +0000

Muchas veces cuando se está aplicando CSS, te topas con estas 3 propiedades parecidas, width, max-width y min-width. ¿Alguna vez te confundiste en usar alguna de estas pero en verdad debisteno usar unel max-width o un min-width? Pues, a todos nos ha pasado, seguramente. En este post te explicaré qué hace cada propiedad y en qué se diferencian con las demás. Pues, comencemos.

Sobre width

El más simple de los tres. Esta propiedad es la que define un ancho específico a un elemento. Sin esta, el elemento o bloque, si es que no tiene texto o algún contenido dentro, no podría ser visualizado por el usuario.

En términos del modelo de caja de CSS. El width vendría a definir al contenido del elemento. Lo que vendŕia a ser el Content en la imagen. Sin embargo, cuando se coloca a un elemento la propiedad box-sizing y se ponga como valor border-box, el width vendría a definir el Content, Padding y el Border.

Por el lado del Responsive Design, esta propiedad no puede adaptarse por sí mismo a los diferentes tamaños de otros dispositivos o si la pantalla hace un cambio de tamaño. Para esto, necesita respaldarse de otras propiedades.

Como se ve en el vídeo de abajo, un elemento no puede adaptarse al ancho de la pantalla con tan solo la propiedad width, para esto veremos las otras dos propiedades que si pueden manejar esto.

Sobre max-width

Según en la página de MDN, esta propiedad se define como:

La propiedad de CSS max-width coloca el máximo ancho a un elemento. Además, impide que el valor de width sea más largo que el valor especificado en max-width .

Esto quiere decir que cuando el valor que nosotros especifiquemos en width sea mayor que max-width, este último sobrescribirá el ancho del elemento al valor que tiene max-width. Así max-width define el ancho máximo que un elemento puede tener.

Tal como se ve en el vídeo/gif de la parte inferior, max-width cambia el tamaño del elemento si el valor de width es mayor que el de max-width. Sin embargo, si el width es menor entonces max-width no tendría que actualizar el tamaño ya que no se alcanzado el tamaño máximo del elemento.

Por el lado del Responsive Design, max-width es aplicado en los media queries. Si no sabes qué son los media queries, te sugiero leer este post. Entonces, max-width en un media query aplica estilos definidos en un determinado ancho de pantalla. Este ancho de pantalla parte desde 0 hasta lo que se haya colocado en max-width. Pasado este ancho máximo todos los estilos que se hayan puesto dejan de aplicarse en la pantalla.



@media only screen and (max-width: 600px) {
      body {
        background-color: lightblue; /* Aplicará solo desde 0 hasta 600px */
      }
    }

    /* Pasados los 600px, el background deja de ser lightblue */

Sobre min-width

A diferencia de max-width que define el tamaño máximo, min-width define el mínimo tamaño que un elemento puede tener.

Por ejemplo, en el vídeo/gif inferior. Primero se intenta hacer un resize sin min-width. Esto disminuye el ancho del elemento hasta el mínimo posible, haciendo que el elemento se distorsione. Luego, se coloca un valor al min-width del elemento. Con min-width ya puesto se comienza el resize. Sin embargo, a diferencia de la anterior vez, el elemento no se distorsiono a su máximo valor ya que tiene un ancho mínimo especificado. Esta propiedad permite que el contenido que tenga un elemento, no se vea comprometido cuando se haga un resize en la pantalla o si este es de otros dispositivos con diferentes tamaños.

Por el lado del Responsive Design, si en un media query se especifica el min-width, entonces todos los estilos especificados serán aplicados a partir del min-width hacia adelante.



@media only screen and (min-width: 800px) {
      .box {
        background-color: red; /* Aplicará a partir desde los 800px hacia adelante */
      }
    }

Conclusiones

A pesar que algunos elementos del desarrollo web se parezcan, es importante no frustrarse de ello, calmarse y aprender. Aprender a diferenciar y ver la utilidad de tus herramientas puede ser clave al momento de aplicar CSS o implementar un diseño responsivo a un sitio web, inclusive puede ahorrarte líneas de código y abrirte las puertas a otros conocimientos, como el patrón de diseño Mobile First. Pero, sobre todo a ser una mejor desarrolladora o desarrollador.