JavaScript No Es Lento – Solo Está Programado Incorrectamente

Hola a todos. Soy Srilakna. Soy un ingeniero de JavaScript. Y hoy voy a hablar sobre un tema muy interesante, JavaScript no es lento, solo está mal programado. Sé que el título es un poco dramático, pero pronto descubriremos por qué lo he dicho.

Así que he preparado una pequeña demostración para presentarme. Así que déjame ir a la parte de la demostración. Estoy muy emocionado por eso. Así que aquí está mi demostración. Al hacer clic en uno o no más, verás una breve introducción de mí mismo. Y esta prueba de capacidad de respuesta y contador es para el propósito de la demostración posterior.

Así que déjame hacer clic en el botón. Espera, ¿qué pasó? El contador se congeló por un momento, ¿verdad? OK, déjame hacerlo de nuevo. Uno o no más. El botón de prueba de capacidad de respuesta no es clicable por un momento. ¿Qué está pasando? No estaba preparado para eso. OK, déjame calmarme e intentar solucionar esto. Puedo hacerlo. Así que comenzaré revisando la pestaña de la consola si hay algún error o no. Así que déjame hacer eso primero. Consola y estoy actualizando. Uno o no más. Prueba de capacidad de respuesta. No, no hay error en la consola. Así que no tengo ninguna llamada de red. Así que también estoy omitiendo la pestaña de red. Esto está relacionado con el retraso. Así que creo que la pestaña de rendimiento puede ayudarnos. Así que déjame ir a la pestaña de rendimiento y. Nuevamente, comenzar a grabar.

Prueba de capacidad de respuesta. OK, detener. OK, podemos ver una montaña amarilla muy larga. Sé para qué es esto. En realidad, tengo una computación pesada sincrónica, pero en realidad usé fragmentación para que no bloquee el hilo principal. Pero esto no funciona, en realidad, de alguna manera. Estos son el método de fragmentación de cómputo. Y puedo ver esto es, creo, el clic del botón para probar la capacidad de respuesta. Déjame comprobar. Así que. Sí, llamada a función. Sí, este es el clic del botón de prueba de capacidad de respuesta. Y en realidad esperaba que este botón se registrara en algún lugar entre la fragmentación de cómputo, entre dos fragmentos de cómputo. Pero esto no sucedió realmente.

Todo el bloque de JavaScript, el JavaScript pesado se ejecutó completamente. Luego esto se registró y el intervalo establecido para el contador se está registrando. Y sé, creo que sé por qué está sucediendo esto. OK, así que antes de explicar esto a ustedes, déjenme resumir rápidamente lo que está sucediendo aquí. Así que la computación pesada bloquea todo el hilo principal, aunque he usado fragmentación para evitar que eso suceda. Y el segundo es un clic del usuario, que debería tener la máxima prioridad. Eso no se está registrando correctamente. Eso se registra después de que toda la ejecución pesada se haya completado. Y de esta visualización del rendimiento, podemos ver claramente una cosa que algo está mal con la programación de JavaScript y la priorización de tareas.

Así que. Antes de avanzar con esta depuración, debemos recordar dos cosas importantes sobre JavaScript que JavaScript es de un solo hilo, significa que JavaScript usa un hilo, un solo hilo para realizar tareas, lógica, UI de escritorio y JavaScript usa programación cooperativa. Significa que si JavaScript está ejecutando algo actualmente y voy a JavaScript diciendo como, por favor ejecuta mi tarea, JavaScript me dirá déjame terminar mi tarea primero, luego programaré o ejecutaré la tuya. Este es en realidad el concepto básico de la programación cooperativa. Y cuando estamos hablando de programación cooperativa, revisemos rápidamente cómo el modelo de prioridad que JavaScript usa detrás. Así que lo primero es no ceder. Esto está reservado para los códigos sincrónicos que se ejecutan completamente hasta su finalización y tiene la máxima prioridad.

Next is the next highest priority has micro tasks. Estos son callbacks de promise, mutation observers. Esto se ejecuta a continuación. Después de eso, la tercera prioridad más alta es request animation frame. Callbacks que se ejecutan justo antes de los próximos tres pines. Tiene la tercera prioridad más alta. Después de eso, tareas interframe, tareas normales como funciones de timer, fetch callbacks, este tipo de tarea cae bajo esta categoría. Esto se ejecuta con prioridad ordinaria. Y al final está request idle callback. Esto tiene la prioridad más baja, significa que cuando el hilo está en estado inactivo, solo entonces este tipo de tarea se ejecutará. Así que esta es la estructura jerárquica de prioridades web.

Y claramente podemos ver una cosa, aunque he usado fragmentación para evitar que esta tarea pesada se bloquee, el hilo principal como JavaScript es de un solo hilo y usa programación cooperativa. JavaScript es en realidad como completar toda la ejecución de la tarea pesada primero, y luego verificará la siguiente tarea con mayor prioridad. Nosotros, los desarrolladores, claramente no tenemos control para decirle a JavaScript que después de completar este fragmento, después de completar la ejecución de un fragmento en particular, por favor ejecuta este clic de usuario, y luego puedes continuar con el siguiente fragmento. No tenemos ese tipo de control. Y ese es el problema con JavaScript.

Y esto no es cuán rápido es JavaScript, sino cuán inflexible ha sido el modelo de programación de JavaScript. Entonces, ¿tenemos algo que pueda evitar que esto suceda? Y esa es la solución. Bueno, puedes hablar sobre set timeout, puedes pensar que set timeout puede ayudarnos a resolver este problema. Bueno, set timeout es solo una función de temporizador.

Así que no, set timeout no puede. Luego request idle callback. Hemos visto la jerarquía de prioridades. Se ejecuta cuando el hilo está en modo inactivo. Piensa en la situación. Si el usuario está interactuando constantemente con el navegador, entonces no hay modo inactivo para el hilo. Así que la tarea nunca se ejecutará. Así que completa imprevisibilidad. Así que estas dos opciones, no podemos depender de estas dos. Así que esto es realmente un problema de programación real y necesitamos una solución real para esto.

No soluciones alternativas como usar web workers cuando eso ni siquiera es necesario o mostrar una sincronización de todo. No, una solución real. Bueno, si me hubieras preguntado esto hace algunos años, diría que no. Pero hoy, sí, tenemos la respuesta. JavaScript ha lanzado una nueva familia de APIs de scheduler. Y hoy vamos a hablar sobre la más importante y más priorizada. Esa es post task.

Entonces, ¿qué es post task? Es una API de programación basada en promesas que te permite encolar tu trabajo con una prioridad específica. Y esta prioridad influye en cómo los navegadores, los bucles de eventos la programan. Así que esta es la sintaxis. Veremos esta sintaxis en unos momentos. Otra cosa importante es que actualmente está disponible en navegadores basados en Chromium. Aunque existe polyfill. Y Safari y Firefox, navegadores no basados en Chromium, también están siguiendo esto. Esta es una amplitud de API de scheduler.

Así que lo siguiente importante es cómo funciona internamente. Utiliza una cola de tareas global. Así que la primera pregunta, ¿qué es la cola de tareas? La cola de tareas es una cola donde las tareas significan la función de JavaScript que quieres que el navegador ejecute. Espera por datos. Y cuando usamos scheduler.postTask, estás insertando una tarea en una de estas colas.

Y cada cola de tareas tiene un nivel de prioridad específico según la sintaxis. Tenemos un vistazo de la prioridad. Así que hay tres tipos de prioridades. User blocking, user visible y background. User blocking tiene la prioridad más alta y está reservada para clics de usuario. Y este tipo de tareas importantes. Luego está user visible.

Esto tiene prioridad media y esta es la prioridad predeterminada para post task. Y al final están las tareas de background. Tiene la prioridad más baja, tarea no visual y tareas como mine donde se procesa computación pesada, que pueden tener la prioridad más baja, caen en esta categoría. Otra cosa importante es que cuando publicas una tarea, hereda la prioridad de la cola en la que la colocaste.

Y una tarea, como dije, en la cola de background se trata como de baja prioridad y cederá a trabajos más importantes. Así que claramente tenemos un entendimiento de cómo funciona esta API de post task. Y esta es la sintaxis de la API de post task. Solo una sintaxis rápida.

Y déjame implementarlos en mi código, suficiente de la parte teórica. Así que lo que haré, esta es mi función compute chunk. Y aquí tengo este bloque sincrónico largo de computación pesada. Y envolveré este compute chunk con la API de scheduler ya que es una función basada en promesas.

Así que uso un sink de ello. Y déjame habilitar el botón apropiado para esto también. Sí. Y déjame. Verificar de nuevo. Bueno, esto es lo que esperaba y está funcionando tal como esperaba. Sin retraso en la UI, sin pantalla congelada. Y déjame mostrarte cómo se está colocando esto en el hilo principal. Así que primero, déjame refrescarlo de nuevo. Y haciendo clic en esto.

Esta detención de la capacidad de respuesta. OK, así que ahora estamos viendo, en realidad, hay múltiples chunks. Y explicaré lo que está sucediendo aquí. Así que cada compute chunk está envuelto con esta prioridad de post task. Y veremos el botón de interacción. Haz clic en algún lugar aquí.

Sí. Aquí. Así que. Déjame verificar. Incluso la función de clic llamada. Sí, este es el evento. Entonces, lo que está sucediendo aquí es que hemos envuelto el compute chunk con este post task con prioridad de background, los está tratando como una tarea de menor prioridad. Así que cuando primero comenzó el compute chunking y luego cuando el usuario hace clic, entonces le da al clic del usuario su propio espacio.

Y después del procesamiento del clic del usuario, entonces nuevamente comienza las funciones de compute chunks o computando los chunks, chunks individuales. Y sí, hemos prevenido el congelamiento y retraso de la UI. Así que estamos al final de nuestra sesión y hemos hecho JavaScript rápido nuevamente. Mira, JavaScript no es inherentemente lento. Su programación por defecto es simplemente rígida.