Mira, ojo, esto me sorprendió un montón del Metaframeworks Pain Points,
que es lo de la gente de que se queja de los Metaframeworks.
Y fíjate que el número uno, el número uno, son problemas con Nexys.
Sí, hombre.
Impresionante.
Yo creo que es que, por ejemplo, algo que me pasó a mí,
y te lo cuento así con mucha honestidad,
un gran volumen de preguntas que nosotros tenemos en nuestros cursos de Nex,
mucho estuvo relacionado a el caché.
Mucho estuvo relacionado a que,
hey, pero ya hice el deploy de mi aplicación,
pero actualicé la aplicación y hago el refresh de la aplicación
y sigue mostrando data vieja.
Y por más que le estoy poniendo de que no maneje el caché,
que sea todo dinámico, siempre me está manejando el caché.
Y todo estaba acorde a la documentación.
Y bueno, qué diablos estará pasando por acá.
Y tuvimos muchas preguntas relacionadas a eso.
Y por aquí está pasando un helicóptero.
Sí, ¿no? ¿Estabas escuchando algo?
Bueno, igual te están buscando la gente de Nexys a ver qué dices.
Sí, sí, sí.
Está difícil porque tengo un proxy en Canadá para que crean que estoy en Canadá,
pero realmente no estoy ahí.
Pero sí, hay muchas preguntas relacionadas al caché de Nex.
Y ahorita cuando pase esto del cambio de la versión 15,
toda la gente que tiene aplicaciones en versión 14 que las tiene funcionando bien,
van a tener que revisarlo si hacen la actualización,
porque posiblemente la aplicación va a trabajar al revés de como ellos lo pusieron.
Es decir, ahora lo que teníamos todo en caché,
usando el caché por defecto de Nex,
ahora van a tener que específicamente decirle cómo quieren que trabaje ese caché,
porque por defecto ya no lo van a hacer.
Claro, a ver, lo bueno es que el cambio no va a romper nada,
sino que lo que puede ocurrir es que trabaje de más, ¿no?
Y que te salga más caro el servidor, por suerte.
Lo digo porque si el cambio fuese al revés, sí que podría ser bastante polémico.
A mí lo que me...
Pero hablando de cosas buenas de Nexys,
la verdad es que si tú sabes el triacys, Nexys es lo más lógico para utilizar.
Sí, total.
No necesitas...
O sea, Nexys es una bestia.
Tiene demasiadas cosas.
Tiene tanta cosa Nexys que posiblemente tú no vayas a usar ni la mitad.
Y honestamente, después de estar usando los Server Components,
ya me terminaron gustando.
O sea, ya pasada esa curva y ese como odio inicial,
como que ahora todo tiene que ser Server Component,
y que ahora vamos a usar una nueva estructura de directorios,
y que ahora todo tiene que ser así,
o sea, se volvió bien opinionado, ¿cómo es?
Opinioné.
Sí.
Tiene una forma de hacer las cosas,
pero en parte eso es bueno porque nos permite a nosotros,
cuando tenemos un problema,
que la comunidad sepa automáticamente,
hey, el problema es por esta estructura de directorios,
o sea, es más fácil encontrar ayuda en ese caso.
Pero me gusta saber de que todo es literalmente optimizado por el lado del servidor,
a menos de lo que tú quieras.
Pero este comentario positivo es por el helicóptero.
Si estás mal, pestañea, Fernando.
Sí, sí, vamos a...
No, todo está bien, todo está bien.
Todo está bien, vale, vale.
No, pero es verdad que el problema que yo le veo a React Server Components
es que aunque yo tengo un montón de experiencia y años trabajando,
y aunque desde el principio he utilizado React Server Components,
todavía, de vez en cuando, me sorprende algún error o algún bug,
o tengo que...
Ay, conchale, es que no puedo utilizar esto dentro de esto
porque es un React Server Component,
y entonces tengo que extraer...
Hay que separarlo y ponerlo.
Exacto.
Eso es como mi problema de que por más tiempo que sepa,
siempre me pilla en alguna cosa.
Es eso o hacerlo de Quick,
que le pones símbolo de dólar por todo lado...
Por todos los sitios.
...para optimizarlo con función, para hacer esas funciones.
Sí.
Y sí, ese es un punto que uno se acostumbra.
Se acostumbra.
Sí, te acostumbra.
Bueno, esto la verdad es que va a ser un componente al lado del cliente,
no vamos a separarlo.
Para mí, uno de los...
Lo que más me incomoda de la versión nueva de Next
es que uno puede tener Server Actions en cualquier lado.
O sea, uno puede...
O sea, uno crea el Server Action o en el componente
que está del lado del cliente,
y ahí está el Server Action,
por alguna misteriosa razón,
uno le puede poner el Use Server a la función,
y después eso puede ser un poco difícil de determinar
qué se ejecuta al lado del servidor, qué no,
o, ay, yo quería que esta función fuera del lado del servidor,
que en teoría voy a regresar a Astro,
me gusta cómo lo tiene Astro,
porque a fuerza te obliga a que tus Server Actions
estén en esta carpeta,
si no, no son Server Actions.
Y eso me gusta,
porque es más fácil de encontrarlos todos,
sé que están ahí.
En cambio en Next están por cualquier lado,
pero a la vez eso es bueno para muchas personas,
porque les da la libertad de poner las cosas
y estructurarlo como diablos querrás, ¿no?
Claro.
Pero es un arma de doble filo,
porque imagínate que tú tienes un raw query,
estás haciendo un raw query para...
Digo, un raw query donde tú dices select asterisco
from my tabla, no sé qué,
y estás haciendo un raw query y se te olvidó ponerle
que era un server component.
Y el error va a llegar del lado del cliente
diciendo que no se puede ejecutar tal cosa
porque va a haber el query,
el cliente en el error,
o lo podría recibir.
Pero eso es porque se me olvidó ponerle
use server a mi función.
Digámosle.
Es un caso como...
Es posible, ¿no?
No digo que vaya a pasar,
pero es una posibilidad.
Mira, dice por aquí...
No entiendo si cada vez tenemos más conectividad,
¿por qué cargar al servidor y no al cliente?
A ver, esto creo que tiene bastante sentido,
aunque es verdad que durante una temporada
en el mundo del desarrollo web
como que quisimos hacerlo todo en el cliente
como para que los servidores fuesen más livianos,
pero lo cierto es que no hay nada más rápido,
nada más rápido que hacer en el servidor
y nada más rápido que estático.
O sea, estático es lo superior
porque directamente te devuelve una cadena de texto,
tú la renderizas y tal.
Pero piensa que...
Si querés, puedo dejarnos hablar esto
al responder estas preguntas de la comunidad
en este rato que queda.
Sí, sí, sí.
Yo estoy de acuerdo contigo
porque eso pasó...
Creo que cuando hubo el apogeo de React y Angular
y que estaban estos titanes peleando,
su característica más fuerte eran los SPAP
también porque...
Sí.
Originalmente, yo les diría que...
Los servidores...
No hay ningún equipo más fuerte
que el servidor que nosotros tenemos.
Y luego vinieron empresas como
Vercell, Amazon Web Services, Nellify,
toda esta gente que empezaron a crear Edge Functions
o una forma de desplegar en funciones nuestros sitios
y era más barato.
Es más barato que tener un servidor corriendo 24-7.
Entonces, solo son funciones que se invocan
cuando alguien lo solicita.
Pero luego también tenemos muchos dispositivos móviles.
Es más, la web se accede más por dispositivos móviles
que por computadoras.
Entonces, no todos los teléfonos,
no todos tienen el último teléfono,
no todos tienen la mejor conexión de internet del mundo.
Y...
Claro.
Y además que es más...
Que no siempre tienes la mejor conexión.
O sea, no es que tú tengas una buena conexión.
Es que a lo mejor estás en la calle
y en ese momento no tienes buena conexión.
Pasaste por un túnel.
O estás en el metro o estás...
Claro, exacto.
Pero es contra...
Bueno, es un balance.
Pero...
Claro.
Pero cuando todo es generado de lado del servidor,
el servidor le manda...
Inclusive, dependiendo de lo que utilices,
puede que mande todo el CSS,
todo el script en un único archivo.
En lugar de hacer un montón de peticiones,
ok, necesito el archivo de JavaScript A, B, C, D, E.
Le manda todo.
O sea, toda la página ya viene con sus scripts respectivos
para que se haga una sola petición.
Claro.
Y eso es mucho más rápido.
Inclusive, el estilo que tener que...
Voy a cargar el CSS por esa referencia.
Voy a cargar este script por...
Cuando ustedes le ponen ese source, dos puntos...
Perdón, source igual...
Y ponen un path, eventualmente el navegador web,
cuando recibe esa petición,
va a volver a hacer otra petición, get,
para traer ese script, cargarlo, ejecutarlo.
Entonces, una página web puede tener
un montón de peticiones internas.
Y eso es algo que hace que lenta la web.
Pero bueno.
Manu dice, ¿qué crees que se pudiera hacer
para que el músculo de Astro pueda llegar a ser tan fuerte
como para ser una tecnología que sea más
para hacer programas completos como tipo Next?
Yo espero que eso no ocurra nunca.
Porque creo que la cagarían.
O sea, creo que lo que tiene que hacer Astro
es enfocarse en sus fortalezas actuales,
que justamente es el no hacer programas completos.
Porque si no, lo que se convertiría ya en Astro,
entonces tendrías que añadir un estado
a la parte del cliente.
Y ya cuando añades un estado a la parte del cliente,
ya te estás convirtiendo...
Se te está poniendo cara de framework.
Y eso al final tiene un montón de posibilidades
que yo espero que no tenga que afrontar Astro.
¿Tú cómo lo ves, Fernando?
Yo lo que esperaría es que Astro simplemente
estabilice todas las funciones que tiene ahorita.
O sea, que se calmen un poco,
que terminen los server islands,
que terminen los server actions,
que todo esté funcionando bien así como está.
Y que implementen lo que tienen ahorita,
que dejen de meter tanta cosa
que hace que la gente no quiera...
O sea, que manejen esa simplicidad que tienen ahorita.
Porque en el momento en que empezamos a meterle
partial pre-rendering,
de que más servers hay props,
o no sé qué montón...
O sea, ¿quién sabe cuántas cosas
que tienen otros frameworks?
Eso hace que aprenderlo sea complicado.
Y aprender Astro,
comparado con las demás tecnologías,
es el más fácil de todos.
Es muy fácil.
Básicamente saber HTML, CSS y JavaScript
y ya sabes...
Y ya está.
La mayor parte de Astro.
¡Gracias!
¡Gracias!