logo

midulive


Transcribed podcasts: 605
Time transcribed: 13d 3h 7m 36s

This graph shows how many times the word ______ has been mentioned throughout the history of the program.

Next.js fue uno de los frameworks de JavaScript más queridos el año pasado y, de alguna manera, en la última semana es el más odiado.
Acaba de alcanzar la vida útil típica de un framework de JavaScript.
Dice, la razón es que Next.js ahora tiene una calidad inaceptable.
Las nuevas funciones son geniales, pero la calidad es insoportable.
Ya ha pasado un año entero desde su lanzamiento y solo ha mejorado marginalmente, por lo que hemos perdido la esperanza de que puedan solucionarlo.
¡Dios! ¡Dios! ¡Dios!
Mira, este es tan interesante que dice,
Vercell está intentando convertir Next.js en Ruby on Rails.
El único problema es que la mayoría de las funciones de Rails han sido probadas en batalla por 37 signas.
GitHub, Shopify y el resto antes de ser extraídas integradas en Rails.
Por otro lado, Vercell simplemente agrega funciones que les ayudan a vender computación en la nube por cualquier medio necesario.
Hostia, la verdad es que esto me parece una chorrada de comentario porque creo que no es verdad.
Creo que Next.js está bastante probado y que incluso los React Server Components están en producción en muchos sitios.
Puedo entender que haya gente que piense que crean features para vender servicios, eso lo puedo entender.
Pero decir que no está probado en batalla, eso me parece un poco vía por los pelos, porque creo que Next.js justamente...
De hecho, tiene muchos casos de estudio, no sé, y a ver, no son cualquier empresa.
O sea, te pones en los casos de estudio, a ver, y es que alucinas.
Tienes Netflix, tienes la propia GitHub, o sea, no sé, me parece que eso está un poco pillado por los pelos.
Hay muchos casos de estudios de...
Utilizando AppRouter han mejorado, no sé qué, no sé cuánto.
Las empresas que se murieron a Next.js hace años o meses no están revaluando repentinamente si deberían pasar a la nueva moda.
También es muy probable que todavía estén en el rutador de las páginas y no experimenten errores de los primeros usuarios.
Eso también es verdad.
O sea, es que la gente, claro, también el ansia.
Nosotros que queremos lo último de lo último, queremos estar ahí, bueno, lo podemos entender.
Next.js Defender.
A ver, Pruiz, yo entiendo que a lo mejor penséis, no, es que está defendiendo...
Yo, bueno, los que me conozcan, que han estado aquí y he traído a Guillermo, a mi amigo y querido Gonzi.
He traído a gente de Eversell que admiro y aprecio y me encanta.
Y hay cosas que me gustan y hay cosas que no me gustan y yo creo que las digo.
Adiós Next.
Hola Next 4x Faster.
Pero claro, me han dado esta camiseta y ¿qué esperas que diga?
Pues Nexty es a muerte.
Y la migración que van a hacer a PHP, pues 4x.
No, pero me encanta Next.js.
Sí que me encanta, pero he sido crítico con Next.js.
Tengo mis propias opiniones y yo creo que el feedback, o sea, creo que hay que ser crítico porque estas cosas ayudan.
No hay que ser, ay no, todo es perfecto.
No, cuando salió el app router yo di algunos palillos de, oye, creo que se han apresurado, creo que hay cosas que no se entienden, no sé qué.
Pero también tiene cosas positivas.
O sea, que tire la primera piedra en desarrollo de software quien ha hecho algo perfecto a la primera.
Porque es que entonces, pues, yo qué sé, le damos un premio o algo.
Y creo que Next.js a lo largo de su evolución, pues ha tenido muchos aciertos y también ha tenido algunos errores.
Y creo, y le preguntamos, o sea, nadie, nadie me puede decir que no le dijimos incluso a Gishermo cuando vino aquí a la MiduConf y se lo preguntamos.
Y le dijimos lo del feedback y se lo había tenido en cuenta.
Y nos contestó, y nos contestó bien, porque es que estas cosas, amigos, no hay que ocultarlas.
Las cosas, mientras sean con respeto, o sea, mientras sean con respeto, yo creo que el feedback siempre es agradecido.
Mucho, mucho hate del que veo.
Viene de dos puntos.
Hate, no digo crítica constructiva, porque crítica constructiva creo que hay y es válida.
Por ejemplo, los React Server Components.
Es raro, ¿no?
Que los React Server Components estén en beta todavía, pero entonces Next.js sí que los usa y tal.
Que entiendo por qué lo hacen, porque para los frameworks sí que está estable.
Pero es verdad que mucha gente esto puede no entenderlo, y eso lo puedo entender.
Pero el hate que veo viene de dos partes, por lo que veo por aquí.
Uno, gente que no usa Next.js, que dices, tío, pues qué más te da, ¿sabes?
O sea, hay gente que se mete por aquí y dice, bueno, yo es que Naxx me encanta.
Pues claro, si es que Naxx es buenísimo también.
Y si sabes, Vue, no tiene sentido que utilices Next.js, o sea, suelta del brazo a Next.js y hasta gente.
Déjala, déjala lo que tú quieras.
Está súper bien que utilices Naxx o que utilices Svelte, sabes, del palo.
Mira, Naxx, Naxx question, ¿no?
Y luego sí que veo a otra cosa, que justamente lo tengo por aquí en el chat, que va más por aquí alineado.
React Server Components está lejos de estar listo para producción, más lejos de lo que pensaba de estar listo para producción.
Es hora de volver a trabajar en las API de Remix actuales.
Sin embargo, estoy realmente entusiasmado con React Server Components.
Nos habrían dado una visión más clara para crear rutas de migración desde React Router SPA a Remix RSC y podemos comenzar ahora.
No se requieren reescrituras.
Todavía vamos a hacer los React Server Components.
Solo esperaba que nuestra próxima iteración de la API se basara en él.
Dejaremos que otros sean los canarios que mueren en la mina y haremos otra iteración rápida en Remix sin él.
Aunque esta iteración está muy inspirada y anticipa React Server Components.
Es que claro, estas collejillas, tío, estas collejillas.
Mira, Lee le contesta, dice, tú lo dijiste tú mismo, mejor tú mismo.
Si listo para producción significa que los clientes lo están usando en producción, entonces hay alrededor de 8000.
Dentro del millón de sitios, del top un millón de sitios de internet, hay 8000 webs que utilizan React Server Components según HTTP Archive.
Y dice, si es así, dice, pues ponlo en estable, ponlo en versión estable, ¿no?
Y dice, bueno, es que está estable para frameworks como Remix o Next.
De hecho, React lo anunció, que estaba estable justamente para esto.
¿Puedo entender esa crítica?
O sea, ¿la puedo entender?
La crítica que hace Ryan de que no esté en estable y tal.
Sí que es raro, es raro de que React hace un año que no se actualiza, los React Server Components solo los puedes utilizar a través de un framework como Next.js.
Pero está como en alfa para todo el mundo, pero no para los frameworks.
Pues la verdad es que eso lo puedo llegar a entender.
Pero por otro lado, veo esa comparación muchas veces como rozando el que se quieren pelear.
Remix y Next.js, que dices, joder, no sé, estable en el desarrollo, inestable mentalmente.
¿Sabéis qué pasa?
Que tanto React como Next.js, esto no os guste, te puede gustar o no React, Next.js.
Pero una cosa que yo creo que es innegable es que a día de hoy es seguramente el framework o biblioteca, framework por Next.js, biblioteca, por el caso de React, más utilizados en el stack actual.
Que dependiendo de la ciudad, del país y tal, cuántas ofertas y tal, pero yo creo que React de alguna forma es el más utilizado como stack.
Y cuanto más usuarios, más clientes, más gente te está viendo, más problemas vas a encontrar, más hate y más te va a doler.
Más te va a doler el hecho de que algo no funcione bien, más responsabilidad vas a tener a la hora de cómo evolucionas, a quién dejas atrás, cómo cambias algo.
Y hay una responsabilidad muy compleja que es una de las razones por las que React yo creo que le cuesta mucho evolucionar.
Hace un año, amigos, que no sale una versión de React.
Porque yo creo que van con pies de plomo.
O sea, sí que claro os lo digo.
Mira, 3 de mayo de 2023 hablaban de la React Canaries.
Mira, desde el 29 de marzo que no sale una Mayor.
Que, a ver, no pasa nada.
O sea, al final no tienen que salir Mayor todos los días.
Pero que sí que se nota esos pies de plomo que digo de no hacer muchos cambios que sean muy subversivos, que agiten mucho el nido.
¿Qué significa Canary?
Canary significa canario, es un pajarito.
¿No conocéis lo que es un canario?
Es un pajarillo muy chulo.
Este es un canario muy chulo, muy chulo.
Nada, pero ¿qué significa Canary Releases?
Entonces, una Canary Release es básicamente una versión como preparada para salir a producción, pero todavía no lista, ¿no?
No es como una Release Candidate, sino que sería más como una prueba, una versión de prueba.
Por ejemplo, Chrome tiene su versión Canary.
Chrome Canary, que es de color amarillo, como el canario.
Es una versión un poco especial.
Porque es inestable, es hacia donde quieren ir.
A lo mejor llegan actualizaciones que nunca llegan a estable.
O sea, que van a hacerlo como si fuese de prueba.
Entonces, no es que sea una beta, porque la beta sí que son cosas como que seguro que van a llegar a producción, a no ser que haya un error muy bestia.
Entonces, la versión Canary sería como una versión para probar cosas.
Como más inestables, que no sabes si van a funcionar, vas a probar a ver cómo funcionan, si la gente tiene una buena, no sé, una buena percepción, si la forma de utilizarlo le convence a la gente.
No es preproducción, porque preproducción sería como la cosa previa a la producción y son cosas que seguro que llegan a producción.
Entonces, sería una versión más de experimentos, donde van a poner una propiedad de CSS para ver si a la gente le gusta, si esa sintaxis tiene sentido.
Son para hacer pruebas.
Es una versión más experimental, con novedades que esperas que vengan, pero también con muchos experimentos.
Y eso sería un poco lo de React Canaries también, que son features que van a utilizar solo meta de forma interna para ellos.
Y a lo mejor también frameworks que sí que lo puedan utilizar, pero que ya os digo, ¿ves? ¿Por qué no tal?
Pues bueno, aquí tendrían un poco la explicación.
El tema es que Brandon, que últimamente ha sido bastante en contra de NextGS, más que nada porque lo ha utilizado mucho en producción,
dice, ¿qué es esto? ¿Qué es esto que preguntas en la pantalla incorporada de NextGS?
Tómate un descanso que aparece aproximadamente cada 20 minutos durante el desarrollo.
La velocidad de desarrollo del enrotador de aplicaciones es ciertamente más rápida que la del enrotador de páginas antiguas,
pero aún así obtienes cosas tontas como esta.
Este es el último de NodeGS, o sea, Node20 con NextGS.
Y nada, es un error de... ¡pum! Ha reventado la memoria y ya está, ¿sabes?
Mi opinión profesional es que deberías crear nuevas aplicaciones con Remix en lugar de NextGS.
Parece que NextGS se ha vuelto demasiado complejo de administrar.
Lo que resulta aún más desafiante es que no genera ingresos directamente.
¿Cómo que ingresos?
Pues raro, porque yo creo que sí que le genera revenue, o sea, a través de los servicios.
Parece...
Lo que resulta aún más desafiante es que no genera ingresos directamente,
por lo que es difícil justificar la inversión que realmente necesita.
Vale, vale.
O sea, es que dice que NextGS no está generando dinero directamente a Vercell.
Yo creo que está muy equivocado, ¿eh?
Creo que NextGS es el caballo de Troya perfecto que tiene Vercell para que lo use todo el mundo.
Sería como decir que Wordpress...
O sea, no sé, me parece que está tan errado.
Vamos a ver.
Vamos a ver.
Imagina Wordpress.
Wordpress es un proyecto totalmente de código abierto, por si no lo sabíais.
Wordpress es un proyecto de código abierto 100%.
O sea, es como decir que Wordpress no se trabaja en Wordpress porque requiere mucha inversión y no genera revenue directamente.
Pero a ver, por favor, no tiene sentido esto.
Claro que genera revenue, o sea, es de código abierto, pero tiene al final un ecosistema detrás que obviamente genera revenue.
Decir esto, que NextGS ha vuelto demasiado complejo a administrar y que lo desafiante es que como no genera ingresos directamente,
es difícil justificar la inversión que realmente necesita, esto es como cualquier otra cosa que sea de código abierto y que tenga un ecosistema.
Esto es después de haber reconstruido todo nuestro panel con NextGS a AppRouter.
Las características de Next son bastante buenas, pero la ejecución y la calidad son demasiado bajas para soportadas.
PostData ha sido excelente trabajar con las personas del equipo de NextGS.
Esto no es hate para ellos.
Y no intento culpar a nadie.
Lo único que sé es cómo usarlo cada día a día.
Ojo, y aquí Brandon dice, el leadership de Remix parece más en sintonía con lo que la mayoría considera listo para producción.
Dice, tampoco estoy contento con el hecho de que Next todavía usa Canary React y Remix aún no puede usar React, Server y Components.
A ver, esto es mentira.
Joder, pero es que esto qué es.
Esto no tiene sentido.
Remix puede utilizar React, Server y Components cuando quiera.
A ver, esto, esto, ¿cómo que aún no puede?
Esto, esto es mentira.
De que dice, no estoy contento de que Next esté utilizando la versión Canary y que Remix todavía no puede utilizar los React, Server y Components.
Esto no tiene sentido.
Remix podría utilizar los React, Server y Components cuando quiera.
Los puede utilizar ya, si quiere.
No hay un bloqueo, no es que Meta o Oversell.
Porque de hecho hay otros frameworks que utilizan los React, Server y Components sin ningún tipo de problema.
Dice, ciertamente existe un incentivo financiero para que el React, Server y Components sea difícil de usar por cualquier framework además de NextGS.
La verdad es que Brandon me sorprende, me da la sensación que hay aquí como algún tipo de, no sé, intención rara.
Porque no parece, no parece, no sé, es raro, es raro.
No me parece, no me parece que tenga mucho sentido lo que dice, sinceramente.
Y ojo Ryan porque aquí incluso acusa a la gente de Vercell y dice, como anécdota, son mucho menos colaborativos en Vercell que en Meta.
Antes solían comunicarse y mantenerme informado durante años y luego se detuvo.
Y desafortunadamente el equipo de Meta rara vez tiene respuestas.
Yo sinceramente a mí Remix no me encanta.
No por nada, sino porque no me termina de encajar.
A mí sí que me parece un poco más lento que NextGS.
O sea que me sorprende lo que la gente dice y tal.
Pero me parece un framework buenísimo, o sea, me parece increíble y todas las cosas que ha traído sobre la mesa me parecen tremendas.
Sí, suena más a problemas personales tanta historia.
Sí, ¿verdad?
Yo creo que es un poco pena que lleguemos a estos niveles de falta de colaboración.
No sé.
Y me sorprende el comentario de Brandon porque está equivocado y no sé si es.
O sea, esto obviamente no está equivocado.
Obviamente que le revienten no es equivocado.
Pero hay algunos comentarios que me da la sensación incluso, no sé si con mala intención.
Lo digo sin conocer, pero no sé.
Es que esta frase es muy incorrecta y teniendo en cuenta que Brandon debería saber de lo que habla.
Es un poco raro.
¿Quién sería Brandon?
Brandon al final es un CEO de Flight Control HQ.
No sé si trabaja en algunos...
Ah, Blitz.
No sé qué es Blitz.
Es Full Stack.
No sé.
No sé si es aquí donde está trabajando y es lo que está desarrollando.
Y se supone que esto es lo que ha pasado a NextDS.
No lo sé.
Y que parece ser que es lo que le peta cada 2x3.
Pero bueno, al final, rarete.
Ahora sí que tiene sentido que digas lo de rarete.
O más que rarete, ¿sabes lo que yo diría?
Yo lo que diría...
Yo diría eso.
Más que nada.