Seguramente has leído o escuchado hablar sobre JavaScript y es que se puede considerar como el lenguaje estándar de programación, que te permite implementar funciones complejas en páginas web. Cada vez que una página web hace algo más que mostrar información estática para que la veas, muestra oportunas actualizaciones de contenido, mapas interactivos, animación de Gráficos 2D/3D, desplazamiento de máquinas reproductoras de vídeo, etc., puedes apostar que probablemente JavaScript está involucrado. Y dada su importancia, te mencionaremos todo lo que necesitas saber acerca de JavaScript.

Según estadísticas, JavaScript es una responsabilidad de rendimiento. Si la tendencia persiste, la página mediana enviará al menos 400 KB en poco tiempo, y eso es simplemente lo que se transfiere. Al igual que otros recursos basados ​​en texto, JavaScript casi siempre se publica comprimido, pero es posible que eso sea lo único que obtenemos de manera consistente en su entrega.

Desafortunadamente, si bien la reducción del tiempo de transferencia de recursos es una gran parte de todo ese asunto del rendimiento, la compresión no tiene ningún efecto sobre el tiempo que tardan los navegadores en procesar un script una vez que llega en su totalidad. Si un servidor envía 400 KB de JavaScript comprimido, la cantidad real que los navegadores tienen que procesar después de la descompresión sobrepasa un megabyte. La eficacia de los dispositivos para hacer frente a estas grandes cargas de trabajo depende del dispositivo. Se ha escrito mucho sobre lo hábiles que son varios dispositivos para procesar gran cantidad de JavaScript, pero la verdad es que la cantidad de tiempo que lleva procesar incluso una cantidad trivial varía mucho entre dispositivos.

Tomemos, por ejemplo, una MacBook Pro de mediados de 2017, Chrome mastica esta carga útil comparativamente pequeña en aproximadamente 25 ms. En un teléfono Nokia 2 con Android, sin embargo, esa cifra aumenta a alrededor de 190 ms. Esa no es una cantidad de tiempo insignificante, pero en cualquier caso, la página se vuelve interactiva razonablemente rápido.

Ahora la gran pregunta: ¿cómo crees que le va al pequeño Nokia 2 en una página promedio? Se ahoga. Incluso con una conexión rápida, navegar por la web es un ejercicio de paciencia, ya que las páginas web cargadas de JavaScript lo bloquean durante períodos de tiempo considerables. Si bien los dispositivos y las redes en las que navegan por la Web están mejorando en gran medida, nos estamos comiendo esos beneficios, tal como sugieren las tendencias. Necesitamos usar JavaScript de manera responsable. Eso comienza con la comprensión de lo que estamos construyendo y también de cómo lo estamos construyendo.

La mentalidad de “sitios” frente a “aplicaciones”.

La nomenclatura puede resultar extraña, ya que a veces identificamos vagamente cosas con términos que son inexactos, pero todos entienden implícitamente sus significados. A veces sobrecargamos el término “abeja” para que también signifique “avispa”, aunque las diferencias entre abejas y avispas son sustanciales.

Podemos ser igualmente rápidos y relajados al intercambiar los términos “sitio web” y “aplicación web”. Las diferencias entre ellos son menos claras que las que existen entre las avispas chaqueta amarilla y las abejas, pero combinarlas puede producir resultados dolorosos. El dolor viene en las posibilidades que nos permitimos cuando algo es simplemente un “sitio web” frente a una “aplicación web” con todas las funciones. Si está creando un sitio web informativo para una empresa, es menos probable que se apoye en un marco poderoso para administrar los cambios en el DOM ó implementar el enrutamiento del lado del cliente, al menos. El uso de herramientas tan inadecuadas para la tarea no solo perjudica a las personas que usan ese sitio, sino que posiblemente sea menos productivo.

Sin embargo, cuando creas una aplicación web, ten cuidado. Estás instalando paquetes que dan paso a cientos o miles de dependencias, algunas de las cuales no estás seguro de que sean seguras. También estás escribiendo configuraciones complicadas para paquetes de módulos. En este entorno de desarrollo frenético, pero omnipresente, se necesita conocimiento y vigilancia para garantizar que lo que se construye sea rápido y accesible.

Lo que tendemos a olvidar es que el entorno que ocupan los sitios web y las aplicaciones web es el mismo. Ambos están sujetos a las mismas presiones ambientales que impone el gran gradiente de redes y dispositivos. Esas limitaciones no desaparecen repentinamente cuando decidimos llamar “aplicaciones” a lo que creamos, ni los teléfonos de nuestros usuarios obtienen nuevos poderes mágicos cuando lo hacemos.

Es nuestra responsabilidad evaluar quién usa lo que hacemos y aceptar que las condiciones bajo las cuales acceden a Internet pueden ser diferentes a las que asumimos. Necesitamos saber el propósito al que estamos tratando de cumplir, y solo entonces podremos construir algo que sirva admirablemente a ese propósito, incluso si no es emocionante de construir.

Eso significa reevaluar nuestra dependencia de JavaScript y cómo su uso, en particular con exclusión de HTML y CSS, puede tentarnos a adoptar patrones insostenibles que dañan el rendimiento y la accesibilidad.

No dejes que los marcos te obliguen a seguir patrones insostenibles.

Han sido muchísimos los descubrimientos extraños en bases de código al trabajar con equipos que dependen de marcos para ayudarlos a ser altamente productivos. Una característica común entre muchos de ellos es que a menudo resultan en patrones de baja accesibilidad y desempeño.

Aquí hay algunos problemas de accesibilidad notables:

1.Un formulario que no usa un elemento <form> no es un formulario. De hecho, puede ocultar esto especificando role = “form” en el <div> principal, pero si está creando un formulario, y este seguro parece uno, use un elemento <form> con la acción y los atributos del método adecuados. . El atributo de acción es crucial, ya que asegura que el formulario aún hará algo en ausencia de JavaScript, siempre que el componente esté renderizado por el servidor, por supuesto.

2.Un <span> no sustituye a un elemento <label>, que proporciona beneficios de accesibilidad que <span> no.

3.Si tenemos la intención de hacer algo en el lado del cliente antes de enviar un formulario, entonces deberíamos mover la acción vinculada al controlador onClick del elemento <button> al controlador onSubmit de los elementos <form>.

4.Por cierto, ¿por qué usar JavaScript para validar una dirección de correo electrónico cuando HTML5 ofrece controles de validación de formularios en casi todos los navegadores desde IE 10? Aquí existe la oportunidad de confiar en el navegador y usar un tipo de entrada apropiado, así como el atributo requerido, pero tenga en cuenta que hacer que esto funcione correctamente con lectores de pantalla requiere un poco de conocimiento.

5.Si bien no es un problema de accesibilidad, este componente no depende de ningún método de ciclo de vida o estado, lo que significa que se puede refactorizar en un componente funcional sin estado, que usa considerablemente menos JavaScript que un componente React completo.

Este componente no solo es ahora más accesible, sino que también usa menos JavaScript. En un mundo que se está ahogando en JavaScript, eliminar líneas debería ser absolutamente terapéutico. El navegador nos ofrece muchas cosas gratis, y deberíamos intentar aprovecharlo con la mayor frecuencia posible.

Esto no quiere decir que los patrones inaccesibles se producen sólo cuando se utilizan marcos, sino que una preferencia exclusiva por JavaScript eventualmente mostrará lagunas en nuestra comprensión de HTML y CSS. Estas lagunas de conocimiento a menudo darán lugar a errores de los que ni siquiera somos conscientes. Los marcos pueden ser herramientas útiles que aumentan nuestra productividad, pero la educación continua en tecnologías web centrales es esencial para crear experiencias utilizables, sin importar qué herramientas elijamos usar.

Confíe en la plataforma web y llegará lejos, rápido.

Si bien estamos en el tema de los marcos, hay que decir que la plataforma web es un marco formidable por sí mismo. Como se mostró en la sección anterior, estamos mejor cuando podemos confiar en los patrones de marcado establecidos y las funciones del navegador. La alternativa es reinventarnos e invitar a todo el dolor que tales esfuerzos casi nos garantizan, o peor: simplemente asumir que el autor de cada paquete de JavaScript que instalamos ha resuelto el problema de manera integral y reflexiva.

Aplicaciones de una página.

Una de las compensaciones que los desarrolladores web se apresuran a hacer es adoptar el modelo de aplicación de una sola página (SPA), incluso si no es adecuado para el proyecto. Sí, obtiene una mejor percepción de rendimiento con el enrutamiento del lado del cliente de un SPA, pero ¿qué pierde? La propia funcionalidad de navegación del navegador, aunque sincrónica, proporciona una gran cantidad de beneficios. Por un lado, el historial se gestiona de acuerdo con una especificación compleja. Los usuarios sin JavaScript, ya sea por su propia elección o no, no perderán el acceso por completo. Para que los SPA permanezcan disponibles cuando JavaScript no lo está, la representación del lado del servidor de repente se convierte en algo que debe considerar.

La accesibilidad también se ve perjudicada si un enrutador del lado del cliente no permite que las personas sepan qué contenido de la página ha cambiado. Esto puede hacer que aquellos que dependen de la tecnología de asistencia se den cuenta de los cambios que se han producido en la página, lo que puede ser una tarea ardua.

Algunos enrutadores del lado del cliente son muy pequeños, pero cuando comienzas con React, un enrutador compatible y posiblemente incluso una biblioteca de administración de estado, estás aceptando que hay una cierta cantidad de código que nunca puedes optimizar, aproximadamente 135 KB en este caso. Considere cuidadosamente lo que está construyendo y si un enrutador del lado del cliente vale la pena las compensaciones que inevitablemente hará. Por lo general, es mejor sin uno.

Si estás preocupado por el rendimiento de navegación percibido, puedes apoyarte en rel = prefetch para buscar documentos de forma especulativa en el mismo origen. Esto tiene un efecto dramático en la mejora del rendimiento de carga percibido de las páginas, ya que el documento está disponible inmediatamente en el caché. Debido a que las capturas previas se realizan con una prioridad baja, también es menos probable que tengan que lidiar con recursos críticos para el ancho de banda.

Ahora bien, el principal inconveniente de la captación previa de enlaces es que debes tener en cuenta que puede ser potencialmente un desperdicio. Quicklink, un pequeño script de búsqueda previa de enlaces de Google, mitiga esto un poco al verificar si el cliente actual está en una conexión lenta, o tiene habilitado el modo de ahorro de datos, y evita la búsqueda previa de enlaces en orígenes cruzados de forma predeterminada.

Los trabajadores del servicio también son muy beneficiosos para el rendimiento percibido por los usuarios que regresan, ya sea que se use el enrutamiento del lado del cliente o no, siempre que conozca los hilos. Cuando buscamos rutas con un trabajador del servicio, obtenemos muchos de los mismos beneficios que la búsqueda previa de enlaces, pero con un grado mucho mayor de control sobre las solicitudes y respuestas. Ya sea que piense en su sitio como una “aplicación” o no, agregar un trabajador de servicio es quizás uno de los usos más responsables de JavaScript que existen en la actualidad.

Javascript no es la solución a tus problemas de diseño.

Si estás instalando un paquete para resolver un problema de diseño, procede con precaución y pregunta “¿qué estoy tratando de lograr?” CSS está diseñado para hacer este trabajo y no requiere abstracciones para usarse de manera efectiva. La mayoría de los problemas de diseño que los paquetes de JavaScript intentan resolver, como la colocación de cajas, la alineación y el tamaño, la gestión del desbordamiento de texto e incluso los sistemas de diseño completos, se pueden resolver con CSS en la actualidad. Los motores de diseño modernos como Flexbox y Grid son lo suficientemente compatibles como para no necesitar iniciar un proyecto con ningún marco de diseño. CSS es el marco. Cuando tenemos consultas de características, mejorar progresivamente los diseños para adoptar nuevos motores de diseño de repente no es tan difícil.

El uso de soluciones JavaScript para problemas de diseño y presentaciones no es nuevo. Fue algo que se hizo en 2009 cuando cada sitio web tenía que verse en IE6 exactamente como lo hacía en los navegadores más capaces de esa época. Si todavía estamos desarrollando sitios web para que tengan el mismo aspecto en todos los navegadores en 2020, deberíamos reevaluar nuestros objetivos de desarrollo. Siempre habrá algún navegador que tengamos que admitir que no pueda hacer todo lo que pueden hacer esos navegadores modernos y perennes. La paridad visual total en todas las plataformas no es solo una búsqueda hecha en vano, es el principal enemigo de la mejora progresiva.

Nuestra intención no es desacreditar JavaScript

No te equivoques, JavaScript ha sido una fuente de disfrute durante más de una década. Como cualquier relación a largo plazo, aprendemos más sobre ella cuando pasamos más tiempo con ella. Es un lenguaje maduro y rico en funciones que solo se vuelve más capaz y elegante con cada año que pasa.

Sin embargo, la disyuntiva es la forma en que se ha desarrollado una tendencia a verlo como un primer recurso para crear contenido para la Web. Queda claro que la web está embriagada de JavaScript. Lo buscamos para casi todo, incluso cuando la ocasión no lo requiere. Y como creo que todos amamos la web y queremos hacerlo bien, la intención es buscar una manera de cómo hacerla más resiliente e inclusiva para todos.