Desarrollar la conciencia de la dependencia

 

 

 

  • SmashingConf Nueva York 2024

  • Índice
    1. No todos los botones son iguales
      1. Valoro tuinput
      2. lindo como unbutton
      3. ¡Anclas lejos!
      4. La caja de vainilla
    2. Dependencias de botones de un vistazo
    3. Espera lo mejor, planifica lo peor
      1. Otras lecturas

    Las dependencias están en todas partes. Son inevitables. No son intrínsecamente malos, pero si no considera la posibilidad de que no se cumpla una determinada dependencia, corre el riesgo de frustrar a sus usuarios. La reducción de las dependencias mejora la probabilidad de que su sitio sea utilizable por la mayor cantidad de personas en la más amplia variedad de escenarios. Sin embargo, incluso sabiendo esto, es fácil pasar por alto las dependencias más básicas que tienen nuestros proyectos, lo que socava su resiliencia en el proceso. Para ilustrar este punto, considere el humilde botón de enviar.

     

    Estoy seguro de que probablemente hayas escuchado muchas veces el proverbio: “Una cadena es tan fuerte como su eslabón más débil”. Su origen escrito se remonta al siglo XVIII, pero no me sorprendería que fuera mucho, mucho más antiguo. Y aunque el trabajo que hacemos tiene poco que ver con cadenas reales, este proverbio es igualmente relevante para nosotros.

    ¿ Recuerdas cuando Azer Koçulu eliminó más de 250 de sus módulos de npm (Node Package Manager)? Si ese nombre no le suena, quizás el nombre de esta función lo haga: left-pad. En caso de que todavía te estés rascando la cabeza preguntándote de qué diablos estoy hablando, Azer eliminó un montón de funciones de la biblioteca canónica de código reutilizable Node.js y, al hacerlo, puso de rodillas a miles de proyectos, incluidos los de alto perfil como Babel y React. Verá, cada una de estas bibliotecas más grandes incluía su left-padmódulo como una dependencia. Cuando esa dependencia ya no estuvo disponible, construir e implementar estos proyectos se volvió imposible.

    Y left-padfueron solo once líneas de JavaScript las que agregaron relleno al lado izquierdo de una cadena. Las dependencias son un gran motivo de preocupación.

    Pero quizás no seas usuario de Node.js. Si ese es el caso, ¿te gusta jQuery? ¿Qué tal las CDN? ¿La CDN de jQuery? Bueno, aquí hay una pequeña historia sobre eso.

    A última hora de la noche del 25 de enero de 2014, el filtro parental utilizado por Sky Broadband, uno de los proveedores de servicios de Internet (ISP) más grandes del Reino Unido, comenzó a clasificar code.jquery.com como un sitio web de “malware y phishing”. El CDN de jQuery está en esa URL. No es gran cosa: jQuery es sólo la biblioteca de JavaScript en la que confían casi las tres cuartas partes de los 10.000 sitios web más importantes del mundo para que sus páginas web funcionen.

     

    Con ese dominio tan tristemente caracterizado, el firewall de Sky entró en acción y comenzó a proteger a sus clientes de este código malicioso. De repente, grandes extensiones de la web dejaron de funcionar abruptamente para todos y cada uno de los clientes de Sky Broadband que no habían optado explícitamente por no participar en esta protección. Para decirlo de otra manera: cualquier sitio que dependiera de una versión de jQuery alojada en jQuery CDN para cargar contenido o permitir a los usuarios hacer cosas estaba muerto al llegar.

    En este caso particular, el eslabón débil no era jQuery per se ; era el CDN. Verá, como dependencia, jQuery existía externamente a los documentos HTML y requería una solicitud por separado (suponiendo que no estuviera ya en el caché). El firewall de Sky rechazaba cualquier solicitud de este tipo, por lo que el archivo nunca se entregó. La dependencia no se cumplió y puso de rodillas a numerosos sitios.

    Las redes son bestias volubles y los firewalls no son lo único que puede hacer que una solicitud sea rechazada o quede sin respuesta. Las redes móviles, por ejemplo, dependen de la transmisión por aire a través de varias longitudes de onda. Dependiendo de la topografía de la región, los edificios circundantes, los materiales de los que están hechos e incluso otras redes, su usuario podría aventurarse (o incluso residir en) una zona muerta donde la cobertura móvil es irregular o inexistente. O está el escenario del túnel al que se hace referencia con frecuencia, que puede provocar que se corte una conexión móvil.

    De manera similar, las redes lentas a menudo pueden dar la impresión de pérdida de conectividad. Las redes móviles suelen sufrir una alta latencia, lo que significa que las solicitudes y respuestas pueden retrasarse. El Wi-Fi de los hoteles y otros puntos de acceso públicos también suelen verse afectados por límites de velocidad de transferencia o uso elevado. En numerosas ocasiones, he esperado varios minutos a que se cargue una página. A veces, esa página es incluso la pantalla de presentación "Únete a esta red".

    Para combatir los problemas provocados por las redes de alta latencia, se convirtió en una buena práctica incorporar CSS y JavaScript en páginas destinadas a dispositivos móviles. Si bien este enfoque aumentó el tamaño de los archivos HTML que se entregan, mitigó el riesgo de que la red provocara que su sitio se rompiera al minimizar las dependencias externas. Curiosamente, esta práctica ha vuelto a estar de moda, y muchas personas recomiendan que incorporemos CSS y JavaScript críticos para reducir los tiempos de renderizado e incrustar gráficos utilizando URI de datos .

    La reducción de las dependencias mejora la probabilidad de que su sitio sea utilizable por la mayor cantidad de personas en la más amplia variedad de escenarios. Sin embargo, incluso sabiendo esto, es fácil pasar por alto las dependencias más básicas que tienen nuestros proyectos, lo que socava su resiliencia en el proceso. Para ilustrar este punto, considere el humilde botón de enviar.

     

    No todos los botones son iguales

    Hay varias formas de marcar un botón de envío. El más simple usa el inputelemento:

    input type="submit" value="Sign Up"

    Otra opción es el buttonelemento:

    button type="submit"Sign Up/button

    Prefiero button[type=submit]hacerlo input[type=submit]porque el texto del botón se puede mejorar con otros elementos semánticos como emy strong, pero ese es un tema para otro día.

    Otra opción que vemos a menudo en la web utiliza un ancla ( a):

    a href="#"Sign Up/a

    Como buttonarriba, el aelemento puede contener otras marcas, lo cual es útil.

    Para los propósitos de esta discusión, el patrón de marcado final del que voy a hablar utiliza un elemento de división ( div):

    divSign Up/div

    Este es un patrón de marcado que Gmail popularizó y se ha vuelto bastante común en el espacio de las aplicaciones de una sola página.

    Si nos suscribimos al conocimiento común, todas estas son opciones válidas para codificar botones. Pueden serlo , pero cómo llegar allí es mucho más complicado. Analicemos cada uno y veamos dónde terminamos.

    Valoro tuinput

    An input[type=submit]es lo más simple posible. Visualmente, parece un botón, incluso en un navegador basado en texto. La tecnología de asistencia ve este elemento como un botón. Es capaz de recibir foco y se puede activar mediante el mouse, el tacto y el teclado (usando la barra espaciadora o Enterla tecla). Y finalmente, y lo más importante, el uso de este marcado crea un botón capaz de enviar cualquier formulario que lo contenga.

    Obtienes toda esta funcionalidad de forma gratuita. No input[type=submit]tiene dependencias aparte de un navegador que admite formularios HTML, lo cual todos tienen (los formularios se introdujeron en HTML 2.0).

    lindo como unbutton

    A button[type=submit]tiene exactamente el mismo conjunto de características con el mismo número de dependencias: cero, nada, nada. Claro, puede darle vida al diseño con un poco de CSS o secuestrar el envío del formulario para publicarlo de forma asincrónica con JavaScript, pero esas son mejoras al diseño básico y la funcionalidad que obtiene de forma inmediata con estos elementos.

    ¡Anclas lejos!

    El aelemento es una historia completamente diferente. En primer lugar, de forma predeterminada, un ase representa como texto en línea con un subrayado; necesitarás involucrar CSS para que parezca un botón. Esa es la dependencia número uno. De forma predeterminada, la tecnología de asistencia verá esto acomo un elemento genérico porque es un vínculo de anclaje a ninguna parte; necesitarás usar el roleatributo para exponerlo como un botón. Esa es la dependencia número 2.

     

    a href="#" role="button"Sign Up/a

    Como un verdadero botón, aes inherentemente capaz de recibir enfoque, por lo que estás bien allí. Un problema, sin embargo, es que alos elementos sólo se pueden activar mediante la Entertecla, mientras que los botones verdaderos también se pueden activar con la barra espaciadora; necesitarás usar JavaScript para escuchar si se presiona una tecla en la barra espaciadora. Esa es la dependencia número 3. Finalmente, ano se puede enviar un formulario, lo que significa que también necesitarás usar JavaScript para eso. Esto eleva el número total de dependencias para este patrón a cuatro, lo que implica marcado adicional, CSS y JavaScript.

    La caja de vainilla

    El patrón final que mencioné usaba un div, pero podría ser fácilmente un spanelemento u otro sin ningún (o pocos) estilos predeterminados del navegador aplicados. Este patrón de marcado tiene todas las dependencias de la aetiqueta y trae algunas propias. En cuanto al CSS, probablemente querrás representarlo como un inline-blockelemento y definitivamente necesitarás darle un cursorpuntero para que parezca interactivo para los usuarios videntes (aunque en realidad no lo será hasta que se active JavaScript). .

    A diferencia del aelemento, a div(o span, etc.) no se puede enfocar. Para agregarlo al orden de pestañas predeterminado de la página, deberá asignarle uno tabindexde 0:

    div role="button" tabindex="0"Sign Up/div

    Si bien no es una dependencia en el mismo sentido que lo son CSS, JavaScript y ARIA (a lo que llegaremos en un momento), este marcado adicional es una dependencia en el proceso de desarrollo porque debe recordar agregarlo. De no hacerlo, el divteclado quedará completamente inaccesible para los usuarios.

    Dependencias de botones de un vistazo

    Dado que era una cantidad sustancial de información a seguir, aquí hay una descripción general rápida del estado predeterminado de las cosas.

    Patrón Mostrar Semántica ¿Enfocable? Activar por Envía formularios
    input
    [type=submit]
    Botón Botón Ratón, toque, Entertecla, barra espaciadora
    button
    [type=submit]
    Botón Botón Ratón, toque, Entertecla, barra espaciadora
    a Enlace Nombrado genérico Ratón, toque, Entertecla No
    div Bloquear No expuesto No Nada No

    Ahora veamos los mismos patrones a través de la lente de las dependencias necesarias para lograr la función de botón.

     

    Patrón Mostrar Semántica Enfocar Activación Envío de formulario
    input
    [type=submit]
    Ninguno Ninguno Ninguno Ninguno Ninguno
    button
    [type=submit]
    Ninguno Ninguno Ninguno Ninguno Ninguno
    a CSS ARIA Ninguno javascript javascript
    div CSS ARIA HTML javascript javascript

    Si bien puede parecer superficialmente que estos enfoques son similares, al usar cualquiera de los dos últimos patrones ( ay div), estamos aumentando considerablemente la cantidad de dependencias que nuestro botón requiere para realizar su único trabajo: permitir a los usuarios enviar un formulario. .

    Algunos de ustedes se preguntarán por qué esto es tan importante. Después de todo, todo el mundo tiene al menos CSS y JavaScript, ¿verdad? Bueno no. No necesariamente. Probablemente se podría argumentar que la mayoría de los usuarios hoy en día tienen acceso a un navegador que tiene cierta cantidad de soporte para CSS y JavaScript, pero eso de ninguna manera es un visto bueno para depender de que esté ahí cuando lo necesite.

    Aquí hay algunas cosas que pueden hacer que su dependencia de CSS permanezca insatisfecha:

    • El navegador no soporta CSS.
    • El usuario deshabilitó CSS ​​por motivos de rendimiento.
    • El usuario está aplicando una hoja de estilo de usuario (que prevalece sobre sus reglas) para mejorar la accesibilidad o por alguna otra preferencia personal.
    • Un problema de red provocó que el CSS externo no estuviera disponible.
    • El selector que estás utilizando es demasiado avanzado para el navegador.
    • Las reglas están contenidas en una consulta de medios y el navegador no las admite o la consulta no se aplica.

    En el lado de JavaScript, existen algunos bloqueadores potenciales similares y algunas otras cosas a considerar:

    • El navegador no soporta JavaScript.
    • JavaScript fue deshabilitado por el usuario.
    • Un problema de red provocó que JavaScript no estuviera disponible.
    • Un firewall bloqueó las solicitudes de JavaScript.
    • Un complemento del navegador bloqueó la descarga o ejecución de JavaScript.
    • Un error de JavaScript de terceros provocó que el programa JavaScript se detuviera.
    • Un error en su código provocó que el programa JavaScript se detuviera.
    • El navegador falló una prueba de detección de funciones y salió del programa antes de tiempo.
    • El usuario todavía está esperando que el navegador descargue, analice y ejecute su programa JavaScript.

    Incluso ARIA no está exenta de dificultades. Si el navegador y la tecnología de asistencia no están sincronizados en términos de su nivel de soporte, pueden suceder cosas extrañas. Otro problema potencial es que si se entiende y aplica ARIA role, pero JavaScript no está disponible para hacer que afuncione divcomo un botón verdadero, sus usuarios se sentirán bastante frustrados cuando parezca que deberían poder usar un botón y no pueden. t.

     

    Espera lo mejor, planifica lo peor

    No controlamos dónde van nuestros productos basados ​​en la web ni cómo nuestros usuarios acceden a ellos. Todo lo que podemos hacer es imaginar tantos escenarios menos que perfectos como sea posible y hacer todo lo posible para garantizar que nuestras creaciones continúen haciendo lo que se supone que deben hacer. Una de las formas más sencillas de hacerlo es ser conscientes y limitar nuestras dependencias.

    ¿Solo desea agregar algunas mejoras a su sitio usando JavaScript? No se moleste con una biblioteca de JavaScript. JavaScript básico suele ser la mejor opción. Si es un código que solo pertenece a una sola página, considere insertarlo antes de la bodyetiqueta de cierre.

    ¿Tiene una gran dependencia de jQuery o de alguna otra biblioteca de JavaScript? Continúe y utilice una CDN pública para incluirlo, ya que eso le dará un aumento de rendimiento, pero recurra a una copia local si no está disponible. HTML5 Boilerplate hace esto de manera bastante elegante:

    script src="https://code.jquery.com/jquery-{{JQUERY_VERSION}}.min.js"/scriptscriptwindow.jQuery || document.write('script src="js/vendor/jquery-{{JQUERY_VERSION}}.min.js"/script')/script

    En este ejemplo de código simple, el primer scriptelemento solicita cualquier versión de jQuery que necesite de la CDN de jQuery. El segundo scriptelemento, que se ejecuta después de evaluar el primero, verifica que jQuery esté disponible. Si no es así, scriptse inserta otro elemento en el documento, haciendo referencia a una copia local en el servidor.

    Por supuesto, es posible que el navegador no pueda recuperar ambas copias de jQuery, por lo que cualquier complemento o código dependiente de jQuery que escriba también debe probar el objeto jQuery antes de intentar hacer algo:

    (function(window){ // Do we have jQuery? if(! 'jQuery' in window){ return; } // Phew! It’s safe to use jQuery now.}(this));

    Y, por supuesto, siempre debes asumir que habrá un escenario en el que un usuario no obtendrá ninguna mejora de JavaScript, ya sea basada en jQuery o no. Tener un respaldo que use HTML y el servidor. Puede parecer de la vieja escuela, pero garantizará que sus usuarios puedan registrarse en su servicio, comprar sus productos o publicar fotos de sus gatitos, pase lo que pase.

    Las dependencias están en todas partes . Son inevitables. No son intrínsecamente malos, pero si no considera la posibilidad de que no se cumpla una determinada dependencia, corre el riesgo de frustrar a sus usuarios. Incluso podrías llevarlos a los brazos de tu competencia. Así que tenga cuidado con las dependencias. Abordarlos de manera proactiva. Y haga todo lo que pueda para crear una experiencia básica sin ninguna dependencia y luego úsela para mejorar la experiencia a medida que se cumpla.

    Otras lecturas

    • Mejor gestión de la dependencia en proyectos de WordPress basados ​​en equipos
    • Paquete web: una introducción detallada
    • Cómo aprovechar las máquinas: ser productivo con los ejecutores de tareas
    • Comenzando con la ramificación de neón

    (rb, ml, og, il, mrn)Explora más en

    • Codificación
    • CSS
    • javascript
    • jQuery





    Tal vez te puede interesar:

    1. ¿Deberían abrirse los enlaces en ventanas nuevas?
    2. 24 excelentes tutoriales de AJAX
    3. 70 técnicas nuevas y útiles de AJAX y JavaScript
    4. Más de 45 excelentes recursos y repositorios de fragmentos de código

    Desarrollar la conciencia de la dependencia

    Desarrollar la conciencia de la dependencia

    SmashingConf Nueva York 2024 Índice No todos los botones son iguales

    programar

    es

    https://pseint.es/static/images/programar-desarrollar-la-conciencia-de-la-dependencia-891-0.jpg

    2024-04-04

     

    Desarrollar la conciencia de la dependencia
    Desarrollar la conciencia de la dependencia

    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