Reactividad: De ida y vuelta

Rate this content
Bookmark

Todo lo viejo es nuevo otra vez. ¡Pero esta vez es diferente, promesa!

12 min
02 Jun, 2023

Video Summary and Transcription

La charla discute la naturaleza cíclica de la evolución tecnológica, con ejemplos de ingeniería civil y desarrollo de software. Explora el cambio de los marcos sin servidor a los marcos del lado del cliente y el reciente regreso al procesamiento del lado del servidor. Se examina la evolución de las tecnologías y los estados, destacando la progresión de la mutabilidad a la inmutabilidad y la introducción de la inmutabilidad observable. También se exploran el futuro y la próxima generación de reactividad, con un enfoque en la borrosa frontera entre el servidor y el cliente y la importancia de abrazar la incertidumbre y evitar el dogma.

Available in English

1. Everything Old is New Again

Short description:

Voy a hablar sobre cómo todo lo viejo se vuelve nuevo otra vez. Hace 200 años, surgió el campo de la ingeniería civil. Eisenbart Kingdom Brunel, el mejor ingeniero civil de todos los tiempos. Construyó muchas cosas, incluyendo el primer túnel bajo el río Támesis, el gran puente cerca de Bristol y los barcos de vapor más grandes de la época. La inteligencia artificial está a punto de quitarnos nuestros trabajos. Los componentes de React solían leer de la base de datos en el sistema de archivos frontal, pero aparentemente, han vuelto al servidor. ¿Estamos volviendo a escribir en PHP? ¿Estamos dando vueltas en círculos? Creo que ese no es el caso.

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.

2. The Loop of Technology Evolution

Short description:

Creo que lo que está sucediendo aquí es muy interesante. Comenzamos con cosas sin servidor y páginas renderizadas en el servidor. Luego agregamos interactividad con JavaScript y jQuery, pero se nos fue de las manos y construimos un framework del lado del cliente. Y ahora estamos volviendo a hacer más en el servidor. ¿La tecnología simplemente está dando vueltas?

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.

3. The Evolution of Technologies and States

Short description:

A menudo comenzamos con un problema y dos cosas tienen que suceder simultáneamente. Evolucionamos las tecnologías existentes en pequeños pasos. 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. Piensa en cómo pensamos en los estados a lo largo de los años. Comenzamos con la mutabilidad, pero luego se volvió complicado. La inmutabilidad es realmente eficiente cuando se trata de cambiar objetos. Con la introducción de los proxies, podemos tener inmutabilidad observable. Ahora tenemos señales, que están inspiradas en ambos paradigmas. Es interesante ver hacia dónde va esto. Aquí hay otro de esos círculos, la reactividad.

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.

4. The Future of Reactivity

Short description:

Hace 10 años, teníamos frameworks reactivos como Backbone, Angular y Knockout. Luego, React introdujo un enfoque diferente con árboles mutables y renderizado de arriba hacia abajo. La reactividad continuó evolucionando, dando lugar a frameworks predecibles como Vue, MobX, Felta, Quick y Solid. La pregunta ahora es, ¿qué sigue?

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.

5. The Next Generation of Reactivity

Short description:

Entonces, ¿cómo se ve la próxima generación de reactividad? La frontera entre el servidor y el cliente se está difuminando. La reactividad atraviesa la frontera de la red. Estamos avanzando hacia algo más grande, aprendiendo del pasado. Debemos actuar a la luz de la incertidumbre. El dogma mata la innovación. La cita de Brunel sobre no establecer reglas en la ingeniería. Todo lo antiguo será nuevo otra vez. MobX volverá a tener decoradores ahora que están estandarizados.

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.

Check out more articles and videos

We constantly think of articles and videos that might spark Git people interest / skill us up or help building a stellar career

React Advanced Conference 2021React Advanced Conference 2021
39 min
Don't Solve Problems, Eliminate Them
Top Content
Humans are natural problem solvers and we're good enough at it that we've survived over the centuries and become the dominant species of the planet. Because we're so good at it, we sometimes become problem seekers too–looking for problems we can solve. Those who most successfully accomplish their goals are the problem eliminators. Let's talk about the distinction between solving and eliminating problems with examples from inside and outside the coding world.
React Summit 2022React Summit 2022
27 min
Impact: Growing as an Engineer
Top Content
Becoming a web engineer is not easy, but there are tons of resources out there to help you on your journey. But where do you go from there? What do you do to keep growing, and to keep expanding the value you bring to your company? In this talk we’ll look at the different kinds of impact you can have as a web engineer. We’ll walk through what it means to take on bigger, more complex projects, and how to scale yourself, and grow the community around you. By driving our own development we can all grow our impact, and in this talk, we’ll discuss how to go about this.
React Advanced Conference 2023React Advanced Conference 2023
33 min
React Compiler - Understanding Idiomatic React (React Forget)
React provides a contract to developers- uphold certain rules, and React can efficiently and correctly update the UI. In this talk we'll explore these rules in depth, understanding the reasoning behind them and how they unlock new directions such as automatic memoization. 
React Summit 2023React Summit 2023
32 min
Speeding Up Your React App With Less JavaScript
Too much JavaScript is getting you down? New frameworks promising no JavaScript look interesting, but you have an existing React application to maintain. What if Qwik React is your answer for faster applications startup and better user experience? Qwik React allows you to easily turn your React application into a collection of islands, which can be SSRed and delayed hydrated, and in some instances, hydration skipped altogether. And all of this in an incremental way without a rewrite.
GraphQL Galaxy 2021GraphQL Galaxy 2021
32 min
From GraphQL Zero to GraphQL Hero with RedwoodJS
Top Content
We all love GraphQL, but it can be daunting to get a server up and running and keep your code organized, maintainable, and testable over the long term. No more! Come watch as I go from an empty directory to a fully fledged GraphQL API in minutes flat. Plus, see how easy it is to use and create directives to clean up your code even more. You're gonna love GraphQL even more once you make things Redwood Easy!
JSNation 2023JSNation 2023
28 min
SolidJS: Why All the Suspense?
Solid caught the eye of the frontend community by re-popularizing reactive programming with its compelling use of Signals to render without re-renders. We've seen them adopted in the past year in everything from Preact to Angular. Signals offer a powerful set of primitives that ensure that your UI is in sync with your state independent of components. A universal language for the frontend user interface.
But what about Async? How do we manage to orchestrate data loading and mutation, server rendering, and streaming? Ryan Carniato, creator of SolidJS, takes a look at a different primitive. One that is often misunderstood but is as powerful in its use. Join him as he shows what all the Suspense is about.

Workshops on related topic

React Advanced Conference 2021React Advanced Conference 2021
174 min
React, TypeScript, and TDD
Top Content
Featured WorkshopFree
ReactJS is wildly popular and thus wildly supported. TypeScript is increasingly popular, and thus increasingly supported.

The two together? Not as much. Given that they both change quickly, it's hard to find accurate learning materials.

React+TypeScript, with JetBrains IDEs? That three-part combination is the topic of this series. We'll show a little about a lot. Meaning, the key steps to getting productive, in the IDE, for React projects using TypeScript. Along the way we'll show test-driven development and emphasize tips-and-tricks in the IDE.
React Advanced Conference 2021React Advanced Conference 2021
145 min
Web3 Workshop - Building Your First Dapp
Top Content
Featured WorkshopFree
In this workshop, you'll learn how to build your first full stack dapp on the Ethereum blockchain, reading and writing data to the network, and connecting a front end application to the contract you've deployed. By the end of the workshop, you'll understand how to set up a full stack development environment, run a local node, and interact with any smart contract using React, HardHat, and Ethers.js.
React Summit 2022React Summit 2022
136 min
Remix Fundamentals
Top Content
Featured WorkshopFree
Building modern web applications is riddled with complexity And that's only if you bother to deal with the problems
Tired of wiring up onSubmit to backend APIs and making sure your client-side cache stays up-to-date? Wouldn't it be cool to be able to use the global nature of CSS to your benefit, rather than find tools or conventions to avoid or work around it? And how would you like nested layouts with intelligent and performance optimized data management that just works™?
Remix solves some of these problems, and completely eliminates the rest. You don't even have to think about server cache management or global CSS namespace clashes. It's not that Remix has APIs to avoid these problems, they simply don't exist when you're using Remix. Oh, and you don't need that huge complex graphql client when you're using Remix. They've got you covered. Ready to build faster apps faster?
At the end of this workshop, you'll know how to:- Create Remix Routes- Style Remix applications- Load data in Remix loaders- Mutate data with forms and actions
Vue.js London Live 2021Vue.js London Live 2021
169 min
Vue3: Modern Frontend App Development
Top Content
Featured WorkshopFree
The Vue3 has been released in mid-2020. Besides many improvements and optimizations, the main feature of Vue3 brings is the Composition API – a new way to write and reuse reactive code. Let's learn more about how to use Composition API efficiently.

Besides core Vue3 features we'll explain examples of how to use popular libraries with Vue3.

Table of contents:
- Introduction to Vue3
- Composition API
- Core libraries
- Vue3 ecosystem

Prerequisites:
IDE of choice (Inellij or VSC) installed
Nodejs + NPM
JSNation 2023JSNation 2023
174 min
Developing Dynamic Blogs with SvelteKit & Storyblok: A Hands-on Workshop
Featured WorkshopFree
This SvelteKit workshop explores the integration of 3rd party services, such as Storyblok, in a SvelteKit project. Participants will learn how to create a SvelteKit project, leverage Svelte components, and connect to external APIs. The workshop covers important concepts including SSR, CSR, static site generation, and deploying the application using adapters. By the end of the workshop, attendees will have a solid understanding of building SvelteKit applications with API integrations and be prepared for deployment.
React Summit 2023React Summit 2023
106 min
Back to the Roots With Remix
Featured Workshop
The modern web would be different without rich client-side applications supported by powerful frameworks: React, Angular, Vue, Lit, and many others. These frameworks rely on client-side JavaScript, which is their core. However, there are other approaches to rendering. One of them (quite old, by the way) is server-side rendering entirely without JavaScript. Let's find out if this is a good idea and how Remix can help us with it?
Prerequisites- Good understanding of JavaScript or TypeScript- It would help to have experience with React, Redux, Node.js and writing FrontEnd and BackEnd applications- Preinstall Node.js, npm- We prefer to use VSCode, but also cloud IDEs such as codesandbox (other IDEs are also ok)