Reactividad: De ida y vuelta

Buenos días a todos. Me alegra estar aquí de nuevo. Voy a hablar sobre cómo todo lo viejo se vuelve nuevo otra vez. Ya saben que mi pasión es la reactividad. Así que les contaré un poco más sobre eso, pero primero contaré una historia completamente diferente. De hecho, de una época completamente diferente.

Hace 200 años, surgió el campo de la ingeniería civil. Y estaba cambiando todo el tiempo. Inventaron máquinas de vapor, barcos, trenes, estaciones y ferrocarriles. Y hubo un hombre que se hizo especialmente famoso. Porque probablemente fue el mejor ingeniero civil de todos los tiempos. Y su nombre es Eisenbart Kingdom Brunel. Y ¿qué lo hizo tan grande? Les daré tres razones. En primer lugar, construyó muchas cosas. Construyó el primer túnel bajo el río Támesis. Construyó el gran puente cerca de Bristol. Construyó los barcos de vapor más grandes de la época. Y también, se vestía adecuadamente. Lamentablemente, no seguimos esa tradición, si me miro a mí mismo, a todos ustedes. Pero creo que podemos aprender algo de eso. En tercer lugar, tenía la cita más profunda y elocuente sobre programación. Ahora, es posible que se pregunten, ¿cuál es esa cita? Les diré en un momento, así que estén atentos.

Mientras tanto, mientras leía sobre ingeniería civil, muchas cosas cambiaron en el mundo del front-end. En primer lugar, aparentemente, la inteligencia artificial está a punto de quitarnos nuestros trabajos. En segundo lugar, sucedió esto. De repente, teníamos componentes React, y estaban leyendo de la base de datos en el sistema de archivos frontal. Aparentemente, volvieron al servidor. Entonces, ¿estamos volviendo a escribir en PHP? De todos modos, si combino esas dos cosas, no estoy seguro si eso es algo bueno o malo. No estoy seguro de si odiar a la inteligencia artificial o tener lástima de ella. En otras palabras, ¿estamos dando vueltas en círculos? Y creo que ese no es el caso.

Creo que lo que está sucediendo aquí es muy interesante. Quiero decir, es muy fácil bromear al respecto, pero esto es algo serio. Entonces, si observo la ingeniería front-end, cómo conozco su evolución, comenzamos con todas esas cosas sin servidor, páginas renderizadas en el servidor, luego agregamos algo de interactividad encima con JavaScript, jQuery, y luego se nos fue de las manos y construimos un framework del lado del cliente adecuado. Y ahora estamos volviendo a hacer más en el servidor. Entonces, te hace preguntarte, ¿la tecnología simplemente está dando vueltas? Y este ciclo parece estar cerrado, casi.

Pero aquí está lo interesante. A menudo comenzamos con un problema y dos cosas tienen que suceder simultáneamente. Por un lado, tenemos esta gran revolución donde abordamos un problema de manera completamente diferente y, al mismo tiempo, evolucionamos las tecnologías existentes en pequeños pasos. Curiosamente, al final, a menudo vuelven a converger.

Dan Abramov dio una gran charla hace un par de semanas donde básicamente planteaba que si React hubiera comenzado en el servidor con componentes del servidor y solo hubiera agregado interactividad del lado del cliente más adelante, aún habríamos llegado al mismo lugar. Y este ciclo, creo, existe en muchos lugares.

Piensa en cómo pensamos en los estados a lo largo de los años. En primer lugar, comenzamos con la mutabilidad, que es cómo funciona JavaScript de forma predeterminada, pero luego se volvió complicado. Es fácil escribir código espagueti con él. Y para los frameworks, es muy difícil renderizar eficientemente la interfaz de usuario. Así que pasamos a este paradigma de inmutabilidad y adoptamos un enfoque radicalmente diferente para administrar los estados.

Pero luego resultó que a veces también podemos exagerar. Este fue un ejemplo interesante hace un par de meses, donde 10-stack table, que es una biblioteca muy buena y conocida, en casos muy específicos, se volvió mil veces más rápido. ¿Por qué? Porque cambiaron algunas cosas inmutables de nuevo a inmutabilidad y administración interna. Y descubrimos nuevamente que, como, la inmutabilidad es realmente eficiente cuando se trata de cambiar objetos, etc. De todos modos, eso nos llevó a concluir, está bien, hagamos algo de inmutabilidad. Tal vez en lugares locales esté bien. Emur está adoptando ese enfoque. Tiene, como, inmutabilidad local temporal y hace que las cosas sean mucho más eficientes.

En paralelo, también hubo evoluciones en marcha. También descubrimos que, como, con la introducción de los proxies alrededor de 2015, 2016, podemos tener inmutabilidad observable. Bueno, todavía tenemos inmutabilidad, pero en realidad los frameworks pueden saber qué está sucediendo con esos objetos. Y ahora tenemos algo nuevo y popular, que son las señales. Está muy inspirado en ambos paradigmas. Y frameworks como Soled y Quick lo están popularizando. Es interesante ver hacia dónde va esto. Existen tanto sabores inmutables como inmutables. Y una de las cosas interesantes en las que a veces pienso es, si comenzamos a componer nuestras señales y tenemos árboles de señales, ¿estamos básicamente de vuelta en el modelo de programación mutable? Pero ahora de manera diferente. Entonces tal vez aquí se está cerrando un círculo. Aquí hay otro de esos círculos, la reactividad.

Así que hace 10 años, ya se mencionó brevemente en la introducción, teníamos esos frameworks reactivos como Backbone, Angular, Knockout. Y en algún momento nos dimos cuenta, hey, son muy impredecibles, poco confiables. Tomemos un enfoque muy diferente. Y ese enfoque muy diferente fue el de React, introduciendo esta idea de tener árboles mutables y renderizar conceptualmente de arriba hacia abajo y de tipo árbol y debería estar bien. Y también es un cambio muy radical y una gran mejora. Pero al mismo tiempo, la reactividad en sí también se desarrolló aún más. Así que obtuvimos frameworks que en realidad eran predecibles y ejemplos de esto son Vue y MobX, Felta, Quick y Solid nuevamente. Así que también hubo esta evolución ocurriendo al mismo tiempo. Y la pregunta interesante es, ¿hacia dónde llegaremos a continuación? Y hay algunas cosas que me intrigan, lo que creo que podría suceder.

Entonces, ¿cómo se ve la próxima generación de reactividad? En primer lugar, dentro de React, hay algo realmente interesante sucediendo con React Forget. Aún se adhiere al mismo modelo, pero te brinda como desarrollador la experiencia de la reactividad básicamente, donde tienes un código bastante sencillo y no tienes que pensar en cómo optimizar, cómo construir dependencias, ese tipo de cosas.

El otro desarrollo muy interesante que está ocurriendo es básicamente que la frontera entre el servidor y el cliente se está difuminando. Lo vemos con los componentes del servidor de React. Lo vemos también en algo como Quik, donde podemos tener cierres en el servidor, serializarlos, y ejecutarlos en el cliente. Y lo que creo que sería realmente genial, y estoy esperando que el framework FUSH estandarice esto o lo haga popular, es donde la reactividad atraviesa la frontera de la red, y podemos suscribirnos a cambios directamente en el servidor y viceversa.

De todos modos, esto podría ser otro círculo que se cierra. Y nos hace preguntarnos, ¿todo se vuelve nuevo otra vez? ¿Y es algo malo o bueno? Y creo que hay tres lecciones interesantes que podemos aprender de esto. Primero, creo sinceramente que no estamos dando vueltas en círculos. Creo que estamos avanzando en espiral. Creo que estamos avanzando hacia algo más grande, donde aprendemos de todo lo que hicimos en el pasado, pero también aprovechamos todo lo que hicimos en el pasado. En segundo lugar, significa que nosotros, como ingenieros, debemos ser capaces de actuar a la luz de la incertidumbre. No sabemos exactamente hacia dónde nos dirigimos en espiral. Pero mientras tanto, tenemos que hacer nuestro trabajo y servir a nuestros usuarios. Así que no te preocupes si no estás completamente seguro de cuál de los frameworks es exactamente el mejor. Y en tercer lugar, uno muy importante, es que el dogma mata la innovación, en el momento en que te aferras a una solución, básicamente detienes la espiral. Si estás en un punto en el que todo debe ser inmutable, o todo debe ser mutable, ahí es donde se detiene el progreso. Y eso me lleva de vuelta a Brunel. Así que recuerda, Brunel construía puentes. Así que tiene esta cita. Y creo que estaba hablando de programación, pero aún no existía en ese momento. Porque él construía puentes y así es una cosa muy responsable de hacer. No tiene control de versiones. Y si no los construyes correctamente, la gente podría morir. Así es como funcionan los puentes. Así que esta cita debe haber sido sobre programación. Y básicamente dijo, estoy en contra de establecer reglas o condiciones que se deben observar en la construcción de puentes, para que el progreso de la mejora mañana no se vea obstaculizado o limitado al registrar o registrar como ley los prejuicios o errores de hoy. Así que creo que esa es una visión muy radical de la ingeniería. Y eso es lo que quiero dejarles. Todo lo antiguo será nuevo otra vez. Y también en esa perspectiva, un anuncio muy pequeño, MobX volverá a tener decoradores ahora que están estandarizados. Y con eso los dejo. Gracias.