Futuro de los Frameworks Frontend Charla Informal

Así que ahora voy a llamar en el orden que tenemos aquí a nuestros oradores, y ellos irán uno por uno, pero les pediré mientras los presento que les den un gran, gran aplauso a cada uno de ellos, y comenzando con el primero en este lado, que algunos de ustedes ya vieron en el escenario hoy, muy probablemente. Así que aplaudamos a Ryan Carniato, el creador de Sava.js. De acuerdo. Sigan aplaudiendo, porque ahora vamos a invitar al líder de producto de Angular, Minko Getsev. Continuando con nuestro próximo panelista, el co-creador de Astro, Fred K. Schott. Vamos, sigamos adelante, porque nuestro próximo panelista, ella es una de las principales mantenedoras, ¿verdad? Y vamos a invitar a Akanksha Doshi. ¡Vamos, aplausos, todos! ¡Energía! Necesitamos mantener esta discusión viva. Y por último, pero no menos importante, esta persona que quizás conozcan del panel anterior hoy, pero también es el co-creador de Next.js. ¡Así que demos la bienvenida a Tim Neutkens!

De acuerdo, y ahora voy a tomar mi lugar en esta silla. Comencemos esta discusión. Vamos a comenzar con un tema que Ryan ya tiene en su camiseta, supongo, que son las señales. Como nos hemos dado cuenta, la mayoría de los frameworks se han estado enfocando en las señales últimamente. ¿Cómo creen que las señales crecerán y seguirán impactando en el ecosistema? ¿Quién quiere ir primero? ¿Podemos empezar con Ryan? ¡Porque él tiene señales! RYAN NEUKOMPTON Sí, de acuerdo, seguro. Es gracioso, piensas que podría predecir estas cosas, pero honestamente no esperaba llegar a donde estamos hoy, donde la mayoría de los principales frameworks y algunos menos importantes están utilizando señales. Espero que esta tendencia continúe. Lo interesante de las señales es que no se trata de agregar señales y de repente obtener estos beneficios. Se trata de lo que puedes eliminar. Y estamos viendo eso en gran parte del ecosistema, con la adopción de muchas frameworks, algunas de las cuales están aquí con nosotros en este panel, y simplemente viendo más beneficios que podemos obtener al tener el flujo de datos conocido por la aplicación, básicamente. Esto se aplica de muchas formas. Resuelve la hidratación del renderizado en el servidor, cosas como la capacidad de reanudación. Honestamente, nos dará una visión increíble de las herramientas. ¿No sería genial si pudieras abrir tu VS Code y básicamente cuando vayas a actualizar algún estado, te diga cada parte de tu aplicación que puede actualizarse.

Lo sabemos simplemente por la forma en que las señales se conectan. Es muy emocionante y aún más emocionante ahora porque, sabes, lo que podría haber comenzado con pequeños grupos de nicho ahora está viendo, no sé, miles de desarrolladores que pueden usar señales, lo cual es muy emocionante desde mi perspectiva. ¿Prueba de micrófono? Puedes hablar en mi mejilla. Ahí tienes. Vamos a intentarlo. Muy bien. Tengo dos micrófonos.

Basado en todo lo que dijo Ryan, definitivamente van a ayudar mucho con las herramientas, y en Angular estamos muy interesados en usar señales para la hidratación parcial porque somos conscientes del flujo de datos. Estuvimos hablando con Evan Yu antes de Jazz Nation hace dos días, y es realmente emocionante cómo las señales también pueden permitir la reutilización de código en diferentes frameworks. Imagina construir lógica de negocio o algún tipo de hooks en un framework y poder reutilizarlos en todos los frameworks en caso de que las señales se conviertan en parte del estándar de JavaScript en el que están trabajando ahora mismo. No tengo nada más que agregar. Funciona.

De acuerdo. Creo que, sí, es cierto que ahora las señales, aparte de React, probablemente todos los demás frameworks y bibliotecas populares están utilizando el concepto de señales, no directamente, pero aún así están utilizando el concepto de señales. El concepto de señales ha estado presente desde hace mucho tiempo. Creo que KnockoutJS fue probablemente el primero en introducir el concepto de señales hace unos diez años, en 2010, según lo que leí en la propuesta. Así que el concepto ha estado presente durante mucho tiempo.

Ahora estamos tratando de estandarizarlo para que haya diferentes bibliotecas, pero en el fondo utilicen el mismo concepto. Y ahí es donde creo que los frameworks lo están adoptando lentamente. Probablemente para React, si no están utilizando las señales directamente debido a la forma en que funciona con el DOM virtual, pero tal vez se combinen con una biblioteca de gestión de estado como Recoil, que también utiliza en cierta medida el concepto de señales. Así que sí, tal vez lleguemos a un punto en el que todas las bibliotecas y frameworks puedan aprovechar la mejora de rendimiento que ofrecen las señales. Al mismo tiempo, la forma en que se escribe el código al utilizar señales es algo a lo que no estamos acostumbrados. Eso también es una preocupación al mismo tiempo. Hemos estado escribiendo código durante años. Y probablemente estemos un poco reacios a cambiar la forma en que pasamos las props. Tenemos que usar esas llaves para escribir el código. Así que probablemente ahí es donde también surgirá la curva de aprendizaje. Eso es como un compromiso, diría yo. Pero sí, creo que el futuro de las señales es realmente prometedor.

Y con suerte, todos los frameworks y bibliotecas podrán aprovechar los beneficios de rendimiento. ¿Alguien más quiere agregar algo?

De acuerdo. ¿Cuál es la siguiente pregunta? Voy a hablar sobre algo que algunos de ustedes pueden haber escuchado. Angular se está fusionando con Wiz, y la pregunta que tengo sobre este escenario es, ¿todos ustedes creen que podríamos ver en el futuro que algunos frameworks vayan en la misma dirección de alguna manera? ¿Te refieres a la fusión entre múltiples frameworks, o la fusión entre bibliotecas de frontend? En este caso, me refiero a la fusión entre múltiples frameworks. Probablemente no.

En este momento, son sólidos y React. Es bueno ver que hay otro aspecto en esto, que es que todos los frameworks que están saliendo ahora están aprendiendo del pasado. Por ejemplo, Astro tiene algunas mejoras con respecto a Next.js. También vemos esto con Remix y Next.js, donde Remix tenía acciones y cosas así, y trabajamos con el equipo de React para agregar algún tipo de primitiva de acciones a React en sí, ¿verdad? Y ahora, el equipo de Remix también está adoptando las acciones del servidor en Remix mismo, y pueden compartir estas entre los frameworks, ¿verdad? Aún están trabajando en ello. Pero eso es algo que probablemente sea más probable que suceda, que los frameworks se basen en las mismas bibliotecas de representación, como Next.js, Remix, Astro, con React Island, podrán compartir más componentes, porque antes la parte de los datos nunca formaba parte del modelo. Ahora también forma parte del modelo. Por lo tanto, puedes hacer la obtención de datos que funcione en todos los frameworks basados en React, ¿verdad? Menos entre React y Angular, Solid, ese tipo de cosas.

De acuerdo. ¿Fue Rich Harris quien dijo que las personas eligen los frameworks en función de su vibra? Creo que esa fue la cita. No sé si eso es algo bueno o malo. Estoy casi completamente de acuerdo con él. Mientras haya diferentes vibras, habrá diferentes frameworks. Incluso si, ya sabes, parte de ello es un aspecto técnico, y creo que estamos viendo el surgimiento, al menos en este momento, de al menos un par de enfoques arquitectónicos de alto nivel. Así que podrías argumentar que algunos de estos podrían fusionarse, ¿sabes? Pero quiero decir, la gente discute sobre la sintaxis. Algunas personas nunca usarán JSX, algunas personas nunca renunciarán a sus componentes de un solo archivo. No les importa que al final, si agarras, por ejemplo, Vue Vapor, Salt 5, Solid JS, la salida podría ser casi idéntica, pero todos tienen una sintaxis diferente. Desde mi perspectiva, es bastante posible que estemos convergiendo, pero es probable que las personas eviten que eso suceda completamente. Sí, estoy de acuerdo con todo lo que dijeron Tim y Ryan. Probablemente nos unifiquemos en algunas primitivas compartidas con el tiempo y prácticas compartidas. Veo cómo podemos, por ejemplo, comenzar a usar todas las transiciones de Vue para las animaciones de rutas. Eso va a ser genial. Muchos frameworks están compartiendo señales. Nos estamos unificando en ideas similares sobre la carga de código detallada. Y es muy difícil unificar la sintaxis. Hay muchos sentimientos fuertes al respecto.

Diré que me encanta ese comentario sobre la vibra, porque siento que es en realidad una reacción al hecho de que ninguno de nosotros tomará una postura sobre en qué somos buenos. Cuando visitas el sitio web de Svelte, es como el... ¿Qué es? Es como el navegador web cibernético. Es como, eso no es por lo que usas Svelte. Lo usas porque es realmente bueno en la visualización de datos. Tiene una sintaxis familiar de HTML. Es genial para aprender. Es realmente poderoso. React es realmente bueno para esto. Es un JSX estándar. Es una apuesta segura si estás construyendo tu empresa. Solid es muy eficiente y está liderando el camino. Así que creo que a veces, cuando hablamos de vibra o de fusionar estas cosas, creo que es bueno que cada uno tenga un enfoque y una vibra, algo en lo que se destaque, como el enfoque en el contenido de Astro. Y creo que si todos nos redujéramos al denominador común más bajo de una sola herramienta para gobernarlos a todos, perderíamos... No todos los casos de uso son iguales. No todas las tecnologías deberían ser iguales. Creo que es bueno que diferentes frameworks o bibliotecas hagan las cosas mejor o peor, de manera diferente y tengan enfoques diferentes.

Además, estoy de acuerdo con lo que todos han dicho. En lugar de centrarnos en fusionar los frameworks, creo que deberíamos centrarnos en estandarizar los principios utilizados detrás de esos frameworks, porque entonces podría ser posible en el futuro que en la misma aplicación, una parte pueda estar en Next.js, otra parte en Astro, y otra parte en algún otro framework. Así obtienes lo mejor de los tres, según el uso. Pero fusionar y crear una sola cosa también conlleva... No sé cómo afectaría el mantenimiento, porque ambos equipos estarían involucrados en, por ejemplo, implementar una función y luego decidir cómo y qué hacer, y cosas así. Así que creo que, sí, que haya diferentes frameworks, pero intentemos estandarizar los principios detrás de la construcción de esos frameworks en lugar de fusionarlos.

Entonces, retomando lo que acabas de decir, ¿crees que algo así está sucediendo ahora mismo con la propuesta TC39 para señales? ¿Algo que se está construyendo sobre eso, podríamos ver una implementación estándar de señales que todos los frameworks que ya las utilizan converjan en esa propuesta? Es posible, y probablemente cada uno tendrá una forma diferente de implementarlo que se ajuste a su sintaxis específica y formato de alteración de componentes.

De acuerdo. Entonces, una pregunta que también me gustaría hacerte ahora mismo es, olvidemos por un momento todo lo que has estado trabajando, las cosas en las que estás construyendo a diario, e imaginemos que alguien del público se acerca a ti y dice: `Necesito ayuda para elegir un framework de alguna manera`. Esta es la pregunta que te harían. ¿Cuáles serían los consejos o las preguntas de seguimiento que les harías para ayudarles a decidir cuál es la mejor opción para ellos en este mundo de todos estos frameworks? Creo que esta es la pregunta que todo nuevo desarrollador que se adentra en el frontend tiene, ¿cuál debería elegir? Hay tantas bibliotecas, tantos frameworks. ¿Por qué debería elegir React o por qué debería elegir Angular? Creo que todos los frameworks y bibliotecas son realmente buenos. Hay cosas buenas y compromisos en cada una de ellas. Dado que tenemos tantas opciones, la gente termina invirtiendo tiempo, lo cual es comprensible porque quieren elegir lo mejor. Eso es lo que queremos hacer. Pero creo que cuando se trata de uso, cada biblioteca está haciendo un buen trabajo. No diría que Angular es malo o que React es malo o que Solid es malo. Lo que hacemos es elegir una biblioteca y mantenernos fieles a ella durante años. Eso es lo que hacemos. Una vez que empezamos, por ejemplo, si elijo React, he estado trabajando con React durante un tiempo, por lo que sería difícil para mí cambiar a Angular de inmediato, porque la cantidad de tiempo que he invertido en aprender React, la forma en que funcionan las cosas en React, eso me ayuda a construir mejores aplicaciones con el tiempo. Así que creo que mi respuesta sería que no creo que haya una única respuesta clara para esto. No puedo decir simplemente `elige este framework`. Sería más bien `elige un framework, revisa la comunidad, revisa la documentación, la curva de aprendizaje, mantente fiel a él y úsalo`. Eso es lo que sugeriría. Al final, depende de sus resultados, ¿verdad? Si la pregunta es `¿qué framework debo aprender para conseguir un trabajo?`, puedo dar una respuesta bastante corta a esa pregunta. PHP. De lo contrario, simplemente diría, si tienes la libertad, sigue tu intuición.

Esa es mi versión resumida de eso. Ve a la docs y familiarízate. Es curioso, veo los frameworks casi como personas, lo cual es un poco extraño. Hay design éticos. No vas a entender todos los detalles de inmediato. Las personas son complicadas, hay partes ocultas, cosas en las que creen, cosas que muestran en la superficie, cosas que ocultan. Es interesante. Si tienes la libertad, toma una decisión intuitiva con la poca información que tienes y observa cómo te sientes al respecto.

Aparte de eso, a menudo no es tu elección. De hecho, muy a menudo apenas es tu elección. En ese caso, sé sensato. Elige lo que te consiga el trabajo, lo que te ayude a lograr lo que necesitas hacer con lo que ya sabes, donde ya te encuentras. Realmente no puedes equivocarte mucho. Creo que vale la pena explorar tantas tecnologías como sea posible para aprender diferentes ideas, diferentes paradigmas. Al final del día, si tienes un trabajo que debes hacer, es bueno elegir algo que sabes que te va a apoyar y que podrás dormir tranquilo.

Recuerdo que intenté aprender web development por primera vez con Rails. Ejecuté el pequeño comando de inicio y obtuve 20 carpetas y 50 archivos. Me sentí abrumado. Se suponía que esto era el framework que realmente te ayuda y terminé abandonándolo y usando Python con Django. La única razón fue porque cuando comencé, solo había cinco archivos. Esa fue la cosa que en ese momento para mí fue como, oh genial, puedo entender cinco cosas, genial. Usé ese framework durante dos años, solo por eso. Ni siquiera lo pensé. No sé si uno de ellos fue más útil al final, pero uno de ellos pudo no interponerse en mi camino. Tal vez eso fue algo personal mío. Tal vez otras personas no se sientan abrumadas de esa manera. Sea lo que sea para ti, creo que lo importante es que puedas comenzar a construir y ver algo surgir de ello, si eso es lo que mantiene tu atención, al menos para mí, eso fue lo más importante. Probablemente lo estés pensando demasiado, supongo que esa es mi respuesta breve. Haz algo y trabaja con algo que te haga sentir que puedes mantener la atención y la concentración y que te diviertas con ello. Estoy totalmente de acuerdo con lo que todos dijeron, especialmente con lo que dijo Ryan, elige lo que te consiga el trabajo.

Muchas veces, parece que no tienes la opción de elegir. Alguien más tomó la decisión hace cinco años y estás atrapado con esa cosa en particular porque tienes que lanzar otras cosas, así que tienes que lanzar características reales, eso tipo de cosas.

Una de las cosas en las que puedes pensar al elegir entre bibliotecas o frameworks son las otras partes, es decir, ¿voy a construir todos los componentes yo mismo? ¿Voy a construir cada botón, construir mi propio sistema de diseño, construir todas estas cosas? En ese punto, puedes decir que cualquier framework es suficientemente bueno. Tal vez quieras lanzar algo muy rápido y asegurarte de que estos... Ya tienes un conjunto de componentes que puedes usar, como un sistema de diseño que alguien más ha construido. En ese punto, puedes comparar, ¿cuáles son los sistemas de diseño? ¿Cuáles son las limitaciones que tienen para React o Angular, por ejemplo? Luego, elegir frameworks es otra cosa completamente diferente porque incluso si eliges React, es posible que tengas que elegir entre Nexus Remix, Astro, algunos de los nuevos frameworks, eso tipo de cosas.

Al final, mucho de esto depende. ¿Dónde queremos estar en cinco años? Si hablamos de cinco años, tal vez eso sea demasiado tiempo para ti, o tal vez sea demasiado corto. Algunas empresas piensan en el futuro de diez años, todavía necesitamos ejecutar la misma pila. Otros piensan que el próximo mes vamos a reescribir todo porque eso es lo que me gusta hacer. Tal vez usemos Angular, por ejemplo. De acuerdo, increíble. Algo que algunas personas se han preguntado y algo que he escuchado mucho en línea es que parece que el desarrollo web está en un bucle. Estamos retomando conceptos que teníamos hace años y estamos trayendo de vuelta cosas del pasado, ahora con una mejor tecnología. ¿Qué es algo que te gustaría traer de vuelta o crees que debería volver? ¿El destello de la tecnología llamativa? Diría que Astro es una exploración muy interesante de esa pregunta. Toda la arquitectura de MPA, esa idea de páginas web renderizadas en el servidor versus la renderización de aplicaciones con JavaScript, eso es la web de hace 20, 30 años, solo servidores ejecutándose. Obviamente, es una idea que todos los frameworks están explorando ahora. Definitivamente, nos adentramos directamente en eso y separamos el front-end del back-end de esa manera y luego jugamos con Solid y React. Creo que hay una integración de Angular y Astro en algún lugar. Me encanta esa idea de que cuando tomamos algo que es una gran idea para comenzar y la llevamos a su conclusión natural, de repente, esas cosas al principio parecían buenas ideas. Comienzas a ver cómo se escala.

Comienzan a desmoronarse. Luego la tecnología avanza. Ahora, algunas ideas antiguas tienen mucho más sentido. Estas ideas fluyen, como las transiciones de vista, que mostré en el escenario. Esa es una tecnología genial que cambia por completo, al menos para mí, la fórmula de lo que debería suceder cuando hago clic en un enlace. ¿Quién es responsable de eso? ¿Es el navegador, el framework, el desarrollador? Una característica como esa puede cambiar por completo esa fórmula de maneras que llevan otra década para entender qué significa al final del día.

Creo que eso es parte natural de que las cosas siempre están cambiando. Ahora tengo una pregunta seria. También en el... Eso se compara con la etiqueta parpadeante. En el pasado, cuando hacía desarrollo web hace 15 años, solíamos usar mucho la plataforma web. Después de eso, los requisitos de las aplicaciones web evolucionaron tan rápidamente que la plataforma web no pudo mantenerse al día. Intentaba adivinar hacia dónde ir y creaba algunas abstracciones que realmente no usamos. Los Web components podrían ser geniales. Muy pocas personas los están usando, por ejemplo. Últimamente he visto un cambio en el que la plataforma web está evolucionando en función de los requisitos compartidos de diferentes frameworks, y están agregando abstracciones que realmente son útiles, bastante útiles. Estamos incorporando cada vez más la plataforma web con el tiempo. Tenemos que adaptarnos con JavaScript. Estamos utilizando más características estándar de JavaScript en todos los frameworks. Puedes ver eso en Remix. Puedes verlo en Astro, en Angular, en Next y en otros frameworks.

¡Vaya! ¡La infraestructura se está derrumbando! De acuerdo. Probablemente sea por el fuego. Sí. Así que tenemos tres minutos para terminar esta charla junto al fuego. Y antes de que el escenario se incendie, debido a todo ese fuego que hay, ¿podrías... Intentemos terminar esto con algo emocionante. ¿Qué les emociona del futuro de los frameworks front-end? ¿En qué están trabajando ahora mismo? Creo que lo primero sería alguna forma de estandarización tanto como sea posible. Eso también ayudará... Eso también facilitará a los desarrolladores de aplicaciones elegir una biblioteca o framework, porque al final creo que se reducirá a cómo escribas el code.

Porque debajo del capó, probablemente tendremos muchas cosas estandarizadas. Entonces, la forma en que... Si estás escribiendo JSX o lo estás escribiendo a la manera de Angular o a la manera de solid JS, así que qué sintaxis te gusta más, cuál crees que tiene la curva de aprendizaje más baja, elige eso. Eso facilitará el proceso.

En segundo lugar, creo que... Cuando se trata de elegir un framework y quiero construir un proyecto, no se detiene ahí. Tengo que pensar en qué framework de CSS debo usar. ¿Debería usar Tailwind? ¿Debería usar otros componentes de estilo? ¿Debería usar CSS modules? ¿Qué debería elegir como bundler? ¿Debería elegir Webpack? ¿O debería elegir ES build? Hay muchas cosas como estas. ¿Los componentes serán accesibles? Así que creo que en algún momento, probablemente si podemos tener alguna estandarización donde los frameworks admitan algún tipo de bibliotecas estándar, con las que estén de acuerdo, eso podría no hacer el proceso fácil para nosotros, los desarrolladores existentes, pero definitivamente para los nuevos desarrolladores, porque no tendrán que perder tiempo eligiendo cosas. Entonces, al menos habrá alguna configuración predeterminada que tenemos ahora, algún soporte predeterminado. Y luego, si quieres actualizar la configuración, adelante, y tendrás opciones para elegir otras bibliotecas, pero al menos reducirá, creo, los ciclos mentales de los nuevos desarrolladores que se adentran en el frontend y eligen el framework. Veo eso como el futuro. ¿Quieres seguir? Me gustaría... Si cada uno de ustedes pudiera... Di una charla completa sobre lo que me emociona del futuro, así que me callaré un poco pero creo que cada proyecto aquí tiene cosas increíbles en marcha. Creo que, gracias a todos ustedes, se están impulsando cosas que hacen que Excal draw exista. Cosas así son geniales, así que sí, tengo muchas cosas que me emocionan. Quiero decir, estoy emocionado de ver si el tema de mi charla de esta mañana realmente se puede resolver. Quiero saber si hay una aplicación, como una capacidad para presentar un solo paradigma que pueda funcionar para sitios y aplicaciones, unificar la web. No sé si esto es posible, pero quiero averiguarlo. Estoy emocionado de enviar menos JavaScript al navegador, o al menos cargarlo incrementalmente para que la web sea más rápida y usable. Estoy realmente emocionado por todas las exploraciones que están ocurriendo actualmente. Especialmente... Lo que es realmente interesante es que hay mucha superposición, por lo que la gente podría pensar, como, oh, todo lo que React está haciendo es muy diferente de lo que Sola está haciendo, o todo lo que Esther está haciendo es muy diferente de lo que Next.js está haciendo. Gran parte de esto se superpone entre sí de muchas maneras. Terminamos hablando ayer, y hablamos durante, como, dos horas solo sobre todas estas cosas que en realidad son muchas de las mismas cosas que estamos tratando de resolver, y las resolvemos de esta manera, las resuelves de esa manera, y muchas de ellas son pruebas, muchas otras cosas son como esto es cómo queremos que sea la X, ese tipo de cosas. Estoy emocionado de ver, para React en sí mismo, estoy emocionado de ver la DX para los botones cervicales mejorar en el próximo año o dos años también, porque eso es algo en lo que estamos trabajando bastante. De acuerdo. Y con eso, estamos justo a tiempo para terminar la diapositiva del fuego. ¿Puedo aplaudir a nuestros oradores? Gracias. Gracias. Gracias.