Astro pone las cosas tan intuitivas que a veces pienso como nadie lo habia pensado antes, yo soy backend y no estoy muy empapado en nada de frontend más allá de lo poco que hago con angular, pero Astro me parece la mejor opción para el 70% de los casos de uso de clientes medianos/pequeños.
Yo no sé usar Astro e hice mi portfolio en Astro con una plantilla, ni un tutorial tuve que ver, iba revisando y aprendiendo leyendo. Me pareció super intuitivo y simple
Hola Midu! Podrías hacer un video de los componentes (base de datos, servidor web, balanceador de cargas, etc.) que se necesitan para montar una web o un backend para producción? Sucede que algunos tenemos una noción de lo que se debe usar, pero en mi caso no he tenido esa experiencia con proyectos grandes, y la información en internet es difusa y complicada de entender, y creo que sería mejor que alguien con tu experiencia nos diera esa clase de guía. Gracias Midu, eres el mejor!
En NextJS el equivalente sería: Suspense + RSC. Con RSC puedes leer el idioma en el server y mandar el componente en idioma correcto. O PPR para hacerlo totalmente estático.
Pero es que ahí está la gran gracia de todo! La experiencia de desarrollo es inigualable! Te centras más en lo que quieres lograr y no tanto en repetir mil veces lo mismo para tratar de lograrlo 😅
@@Bleibruk estoy de acuerdo. No creo que estemos haciendo lo mismo si no mejor. Si no hubiese gente que le dos vueltas a la rueda no tendríamos estas mejoras, así que bienvenida sea.
Uso Astro desde su versión 0, antes todo lo hacia en Next, sin darme cuenta deje de usar Next con los años para solo elegir Astro, si no lo estas usando aún, ya te tardaste.
Nuze... pero cuando empezó lo de ajax precisamente lo que se hacía era cargar un html estático y determinados divs con placeholder se reemplazaba con contenidos dinámicos que venían desde el servidor...
Lamento decir justo lo que mencionas, pero los static site generators existen desde "siempre" antes scripts de perl que generaban todo el html y la recarga de porciones era con ajax y te respondía un cgi perl o un php 😅
tiene muy buena pinta Astro, la verdad yo no se nada de front-end. Pensaba aprender React, pero Astro tambien pienso aprenderlo cuando midu haga su curso
@@n3storm También lo pensé, pero como dicen, la experiencia de desarrollo es distinta, y el ejemplo sería el ahorrarte crear ese endpoint, la plantilla HTML, etc.
@@ROBERT-hr4mk pero astro server islands no te ahorra el endpoint, tienes que programarlo tal y como se ve en el vídeo. la plantilla html tampoco te la ahorras en astro, alguien programó ese tallwind. quizás me falte algún generardor tallwind a estático? no sé mucho de tallwind.
.net eso lo tiene hace años, pero funciona un poco distinto, lo que pasa es que los frameworks modernos de js no lo tienen, esa es la novedad y esta cool.
Midu, muy bueno siempre tu contenido y tu forma de explicar. Me gustaría si algún día podemos profundizar en distintas opciones de despliegue para proyectos con Next y Astro. Yo uso Next, pero por ahora sólo se desplegar en Vercel y es super fácil, pero muy costoso para proyecto sencillos para clientes de Argentina. Pagar USD 20 mensuales solo de hosting es imposible.
Podrías desplegar tu servidor NodeJS en un contenedor de Docker y delegar la administración a servicios PaaS. Railway en su forma más básica te dá $5USD gratis al mes, y si se pasa el uso de RAM/CPU te va cobrando según el uso que le hayas dado. Por lo que ví, el plan de pago de entrada es de $5USD más los $5USD que dan cada mes.
@@FSH2 gracias por la sugerencia! En un proyecto más grande en el que trabajé usaban Docker, pero yo no participaba de esa parte, siempre un devops, así que no aprendí mucho, pero tal vez sea una buena solución, creo que con Docker es mucho más fácil tener opciones para desplegar. Lo estudiaré! Gracias de nuevo
@@rodolfolopezp gracias Rodolfo, alguno en particular? Como haces el despliegue? Si no molesta la prengunta. Es el área que tengo más floja y ahora que trabajo independiente necesito aprender si o si
Creo que entiendo porque lo comparan con PHP, y creo que el ejemplo no era el mejor XD Pero el del E-comerce si es más interesante. Explicación, en del botón de midu es muy fácil de hacer en PHP, ya que solo esta leyendo un header y cambiando el link y texto del botón. (Es lo que se sobre entiende se su ejemplo), por ende creo yo que en php seria muchísimo mas rápido ya que no tendrías que realizar una petición a una API. Pero en cambio el E-comerce cambia totalmente, ya que intentar hacer lo mismo con php generaría un bloqueo de la carga ya que PHP no posee asincronia perse, ya que tendrias que consultar a la base de datos etc, y para que haga lo mismo no estoy seguro si se podrian hacer con las Fibrers para evitar usar una API ya que eso agregaría latencia, pero aun así seguiría siendo mas complejo, o la otra, que es hacerlo de manera manual y aun seria mas complejo y todo a mano. Me parece una función muy útil he interesante para un montón de aplicaciones donde quieres que una parte que pueda tener mucha carga o incluso bloquear el cargado de la pagina, este "en segundo plano" cargándose y luego renderisandose, teniendo ya un fallback de forma muy intuitiva.
Justo quería saber si es posible hacer una Ecommerce con Astro ya que tuve hacer una proyecto sobre una en la Universidad y logre algo a medias, me gastaría ver un tuto ahora con eso de las Server Islands
Entiendo que es una excelente novedad el que llegue a Astro, pero tengo una consulta con este tema del server island. Como me imagino que funciona es que la pagina estatica carga y luego con un js hace una peticion para renderizar el componente de server island, para que este retorne el html correspondiente. Me parece que seria como cargar un server component dentro de una pagina estatica usando el supense. No se si me equivoco, si alguien me puede explicar lo agradezco.
sólo vengo a decir que me hace acordar el meme de OMNIMAN cuando le dice a su hijo "Mira lo que hacen para imitar una fracción de nuestro poder", y a OMNIMAN le agregaría el logo de PHP en el pecho.
@@fiderosado soy estudiante aún asi que mi palabra no tiene mucho peso, pero que no AJAX está super obsoleto? O ese era el que tenía problemas de seguridad
Las notificaciones en el celular funcionan de otra manera totalmente distintas. Podes hacerlas por workers, crear una rutina en intervalo o si es una app crear un servicio. Para la mayoría de los casos se usan sockets y webhook. Tu dispositivo debe estar escuchando constamente o intervalos y si lo querés hacer en modo 'artesano' desde scratch, debería crear una rutina para notificar al servidor que te envía las notificaciones, tu IP o puerto donde estás y si este cambia (ejemplo, cambias de atena 4/5G al desplazarte), actualizar esa info (para esto, los sockets ya te resuelven ese problema). Lo que presentó midu, es algo NUEVO y sólo para Astro. Las notificaciones y llevan más de 1 década y media de que se usan.
Y si hago un fetch desde el front para obtener la url y texto y cargarlo en el boton con js.. o quizas de este modo evito tener endpoint back.. seria solo front mmm interesante
si pero dejamos de usar eso en PHP por el problema de mantenimiento todo el código se vuelve "spaghetti" por eso usamos frameworks pero eso aumento la dificultad de hacer código y reduce su velocidad y si es un interesante propuesta pero quiero ver reutilización de código y separar la lógica para poder darle mantenimiento.
Una parte que no me ha quedado clara es ¿en el primer render, el boton de amazon esta, o se hace una request al server y carga el html del server aparte, y en el primer render no esta? (lo pregunto por ese pop inicial)
Así es. Carga todo en estático, menos ese botón, ya que después hace la petición al servidor y lo renderiza después. Lo que dice Midu para evitar el pop inicial es que tengas un botón similar como placeholder, para que cuando renderice el contenido dinámico desde el servidor no se vea tan pronunciado el pop.
No entiendo si son paginas estática despues el js pide la parte dinamica al server? Y que ventaja tiene sobre renderizar en el navegador si igual hay que hacer una petición extra? Aun asi tiene mas sentido que todo renderizado en el server
Me imagino que sería útil para dar la impresión que es sumamente rápido, ya que el renderizado ya no lo haría el cliente, sino el servidor. Incluso, no estoy seguro, pero podría ser que en ese componente tengas lógica muy importante, como que haga consultas a endpoints de otros servicios, entonces al hacer el renderizado desde el servidor, ya no estarías mostrando toda esa lógica, sino únicamente el resultado.
La ventaja principal es que el contenido estático es fácilmente cacheable, lo que significa que no solo cargara más rápido por ser estático, sino que además puedes usar una CDN para que el contenido se entregue aún más rápido a los usuarios según la zona geográfica donde vivan, de esta forma, solo el contenido dinámico (por ejemplo lo que está al alcance de usuarios específicos) es lo único que va a "traerse" al servidor. Típicamente, este contenido dinámico generado por el servidor es más complicado hacer caching porque los datos no siempre son los mismos ni siquiera para un mismo usuario, y tus opciones son rendimiento a costa de personalización o al contrario, cuando no debería ser así. Las estrategias de caching en el servidor pueden ser complejas o depender de la infraestructura, y el uso de CDN puede ser limitado (tendrías que ir siempre al servidor desde donde sea que el usuario te visite). Obviamente, para cada caso habría que ver la conveniencia de como realizarlo y esto depende del proyecto, no es un absoluto de que todo debe hacerse de esta forma, solo son alternativas que están ahí para aprovecharse.
No lo entendi jajajajajaja :( Osea que con astro no se puede acceder al backend para hacer llamadas api o algo asi? Yo programo con php y no necesito nada del cliente para servir estaticamente ese boton puesto que puedo detectar el pais desde el servidor e imprimir ese boton directamente en el html al cliente. Eso no se podia en astro?
No entiendo, la diferencia en mi cerebro sin el server:difer y con load:client es el mism, aparte de que el componente del boton seria cargado en el servidor, por la llamada que hace... pero en astro ya está poder tener componentes híbridos
Por la longevidad o la zona de confort empresarial se podría decir. Es lo mismo que pasa con Telegram vs WhatsApp, es mejor el primero pero la gente se acostumbro al segundo porque fue el primero que salió.
Porque al trabajar fuertemente con componentes, podes hacer lo que se llama compartimentalización. La compartimentalización no sólo ayuda a producir en paralelo (velocidad de desarollo), sino que también ayuda a aislar partes del sistema. Eso evita que los devs, puedan filtrar el producto o partes grandes del producto a terceros en el caso de que haya un leak. Cabe aclarar que esto en general, aplica a proyectos grandes donde tenes un desarollo grande como un paas o saas. Si vas a hacer una página donde hay un landing page y un par de routes para un carrito o un contact us, podrías hacerlo con html crudo y puro con alguna ayudita de bootstrap o tailwind. De necesitar listar dinámicamente pavadas, hasta con tener 2 o 3 javascript tipo un "shopingcart.js", y javascript vanilla puro, con un par de fetches se pude hacer más rápido que con react. El chiste de React, Angular, etc es que son para cuando tenes 3 o 4 equipos de 3 o 4 personas cada uno, y necesitar crear 10 módulos los cuales 7 se pueden hacer en paralelo sin depender de que otro equipo termine su parte. React, formenta mucho eso y por eso es super práctico.
Astro pone las cosas tan intuitivas que a veces pienso como nadie lo habia pensado antes, yo soy backend y no estoy muy empapado en nada de frontend más allá de lo poco que hago con angular, pero Astro me parece la mejor opción para el 70% de los casos de uso de clientes medianos/pequeños.
Yo no sé usar Astro e hice mi portfolio en Astro con una plantilla, ni un tutorial tuve que ver, iba revisando y aprendiendo leyendo. Me pareció super intuitivo y simple
Si alguien esta pensando en estudiar astro en este 2024, le digo de ante mano que es muy buena idea, yo lo hice y me encanto Astro
Ojalá Astro siga así y no trate de abarcar mucho en otras cosas como lo han hecho otros frameworks.
Hola Midu! Podrías hacer un video de los componentes (base de datos, servidor web, balanceador de cargas, etc.) que se necesitan para montar una web o un backend para producción? Sucede que algunos tenemos una noción de lo que se debe usar, pero en mi caso no he tenido esa experiencia con proyectos grandes, y la información en internet es difusa y complicada de entender, y creo que sería mejor que alguien con tu experiencia nos diera esa clase de guía. Gracias Midu, eres el mejor!
En NextJS el equivalente sería: Suspense + RSC.
Con RSC puedes leer el idioma en el server y mandar el componente en idioma correcto. O PPR para hacerlo totalmente estático.
cosas que ya haciamos antes pero que se renombran
A mí me gusta que la gente compare las noticias con otras porque también aprendo cosas relacionadas con la noticia que no sabía.
Excelente contenido Midu, de lo mejor, sin lugar a dudas en español y con aportes actualizados.
Usted es quien es un Astro! Gracias por todo Midu
Espero con ansias el curso de Astro!!
Astro de verdad que se actualiza rápido 🚄
tú y astro sois lo mejor de internet! (y next! ;))
Midu es excelente divulgador!!!
Lo que hace años era un Partial view cargado con Ajax 😂, la diferencia es la experiencia de desarrollo 😊
exacto.. Astro me parece increible , sin embargo para mi que no soy frontend prefiero htmx
Pero es que ahí está la gran gracia de todo! La experiencia de desarrollo es inigualable! Te centras más en lo que quieres lograr y no tanto en repetir mil veces lo mismo para tratar de lograrlo 😅
@@Bleibruk estoy de acuerdo. No creo que estemos haciendo lo mismo si no mejor. Si no hubiese gente que le dos vueltas a la rueda no tendríamos estas mejoras, así que bienvenida sea.
Exacto, es un partial view. Debo aplaudir?. 😂.
Gracias midu por ponernos al día 🇲🇽
Uso Astro desde su versión 0, antes todo lo hacia en Next, sin darme cuenta deje de usar Next con los años para solo elegir Astro, si no lo estas usando aún, ya te tardaste.
Jablador 🤣🤣🤣🤣🤣🤣🤣
el como el ajax que usa wordpress, woocommerce para actualizar el carrito de compras al momento de agregar un producto, etc. Muy interesante.
Nuze... pero cuando empezó lo de ajax precisamente lo que se hacía era cargar un html estático y determinados divs con placeholder se reemplazaba con contenidos dinámicos que venían desde el servidor...
Lamento decir justo lo que mencionas, pero los static site generators existen desde "siempre" antes scripts de perl que generaban todo el html y la recarga de porciones era con ajax y te respondía un cgi perl o un php 😅
tiene muy buena pinta Astro, la verdad yo no se nada de front-end. Pensaba aprender React, pero Astro tambien pienso aprenderlo cuando midu haga su curso
Buenas yo te aconsejaría estudiar los dos ya que astro se lleva muy bien de la mano de react , vue y svelte
yo creo que HTMX apuntando a un endpoint php/python,/node/rails/rust/go es más rápido y con una experiencia de usuario muy muy parecida :D
@@n3storm También lo pensé, pero como dicen, la experiencia de desarrollo es distinta, y el ejemplo sería el ahorrarte crear ese endpoint, la plantilla HTML, etc.
@@ROBERT-hr4mk pero astro server islands no te ahorra el endpoint, tienes que
programarlo tal y como se ve en el vídeo.
la plantilla html tampoco te la ahorras en astro, alguien programó ese tallwind.
quizás me falte algún generardor tallwind a estático? no sé mucho de tallwind.
@@n3storm pero con HTMX podes manejar rutas o lo planificas como una SPA?
@@guillermonarvay8247 como una spa, la ruta del htmx apunta al backend que prefieras. últimamente me divierto con flightphp que ha mejorado mucho
Me parece interesante la idea y no veo mal que otros generadores de sitios estáticos la copien. Aunque tengo la misma duda de jampierleal(9:30)
.net eso lo tiene hace años, pero funciona un poco distinto, lo que pasa es que los frameworks modernos de js no lo tienen, esa es la novedad y esta cool.
Jajajajajaja, como es que nunca faltan estos comentarios?
Midu, muy bueno siempre tu contenido y tu forma de explicar. Me gustaría si algún día podemos profundizar en distintas opciones de despliegue para proyectos con Next y Astro. Yo uso Next, pero por ahora sólo se desplegar en Vercel y es super fácil, pero muy costoso para proyecto sencillos para clientes de Argentina. Pagar USD 20 mensuales solo de hosting es imposible.
Podrías desplegar tu servidor NodeJS en un contenedor de Docker y delegar la administración a servicios PaaS. Railway en su forma más básica te dá $5USD gratis al mes, y si se pasa el uso de RAM/CPU te va cobrando según el uso que le hayas dado. Por lo que ví, el plan de pago de entrada es de $5USD más los $5USD que dan cada mes.
@@FSH2 gracias por la sugerencia! En un proyecto más grande en el que trabajé usaban Docker, pero yo no participaba de esa parte, siempre un devops, así que no aprendí mucho, pero tal vez sea una buena solución, creo que con Docker es mucho más fácil tener opciones para desplegar. Lo estudiaré! Gracias de nuevo
Yo despliego Nextjs desde Shared hosting. No he tenido problemas
@@rodolfolopezp gracias Rodolfo, alguno en particular? Como haces el despliegue? Si no molesta la prengunta. Es el área que tengo más floja y ahora que trabajo independiente necesito aprender si o si
Me pasa exactamente lo mismo. Donde desplegar una aplicación dinamica Next fuera de Vercel. Pudiste solucionar eso?
Gracias por lo videos midu, eres un grande
midu buen dia bro y que paso con la otra parte de react native ? esta excelente el curso
Que maravilla astro
estare esperando ese proyecto
Midu, aprox cuánto tiempo de desarrollo estimas para el desarrollo de una landing page de una empresa?
Creo que entiendo porque lo comparan con PHP, y creo que el ejemplo no era el mejor XD
Pero el del E-comerce si es más interesante.
Explicación, en del botón de midu es muy fácil de hacer en PHP, ya que solo esta leyendo un header y cambiando el link y texto del botón. (Es lo que se sobre entiende se su ejemplo), por ende creo yo que en php seria muchísimo mas rápido ya que no tendrías que realizar una petición a una API.
Pero en cambio el E-comerce cambia totalmente, ya que intentar hacer lo mismo con php generaría un bloqueo de la carga ya que PHP no posee asincronia perse, ya que tendrias que consultar a la base de datos etc, y para que haga lo mismo no estoy seguro si se podrian hacer con las Fibrers para evitar usar una API ya que eso agregaría latencia, pero aun así seguiría siendo mas complejo, o la otra, que es hacerlo de manera manual y aun seria mas complejo y todo a mano.
Me parece una función muy útil he interesante para un montón de aplicaciones donde quieres que una parte que pueda tener mucha carga o incluso bloquear el cargado de la pagina, este "en segundo plano" cargándose y luego renderisandose, teniendo ya un fallback de forma muy intuitiva.
Para mostrar en tu directo como se vería en otro país te recomiendo el extensión de SquareX
ya me volaba la cabeza con las Astro-Islands, ya con las server-islands... 🤯
Midu, está super interesante esto con astro, disculpa mi ignorancia, con next se puede hacer esto tambien? me interesa mucho
Justo quería saber si es posible hacer una Ecommerce con Astro ya que tuve hacer una proyecto sobre una en la Universidad y logre algo a medias, me gastaría ver un tuto ahora con eso de las Server Islands
Hola midulive, que VPN usas? saludos!
Se viene curso de astro!!!!!
Con un Fech hacia un api para ese botón no da la misma solución?
Duda, Y no es lo mismo que tener tu pagina estatica y renderizar un component dinámico desde el server, vamos Partial SSR de toda la vida?
Según entiendo: El Server Islands es poder hacer un contador y que el tiempo lo mande el server(backed) y se visualice en html??
Está cool. Solo que no se porque no le das más visibilidad a Nuxt 3, por ejemplo. Ya trae server components out of the box.
Eso se puede hacer solo si el componente esta hecho en Astro ? , o se puede usar tambien si el componente esta hecho en React o Vue ?
Hola midu pregunta, entonces seria mas rápido hacer híbrida la pagina con astro, que hacerla directamente en react??
Funcionaria en hosting compartido del estilo de hostinger o digital ocean?
Una pregunta, amazon no provee la documentacion del boton automatico para recoonocer el pais sin tener que estar haciendo cada boton para cada pais?
Entiendo que es una excelente novedad el que llegue a Astro, pero tengo una consulta con este tema del server island. Como me imagino que funciona es que la pagina estatica carga y luego con un js hace una peticion para renderizar el componente de server island, para que este retorne el html correspondiente. Me parece que seria como cargar un server component dentro de una pagina estatica usando el supense. No se si me equivoco, si alguien me puede explicar lo agradezco.
Como Next.js haciendo el botón 'use-client'? sigue siendo más rápido en Astro supongo
crearás una red social en Astro?
Entonces seria lo mismo que hacer un client component de react ?
Necesito hacer una app rapida de inventario de productos, astro sirve?
sólo vengo a decir que me hace acordar el meme de OMNIMAN cuando le dice a su hijo "Mira lo que hacen para imitar una fracción de nuestro poder", y a OMNIMAN le agregaría el logo de PHP en el pecho.
Jajaja eso mismo lo haces con AJAX y PHP, todos esos framework están dándole la vuelta para al final caer en lo mismo jajjaa😅
@@fiderosado soy estudiante aún asi que mi palabra no tiene mucho peso, pero que no AJAX está super obsoleto? O ese era el que tenía problemas de seguridad
@@fiderosado ajax no es seo friendly
Curso ecomerce para ejemplificar el coso que dijo con astro
pero se puede hacer eso con php.... es basicamente lo mismo o algo no estoy entendiendo.
gente no entiendo, asi no funcionan las notificaciones? Te llega en tiempo real, solo que en este caso te ve en que país estas
Las notificaciones en el celular funcionan de otra manera totalmente distintas. Podes hacerlas por workers, crear una rutina en intervalo o si es una app crear un servicio. Para la mayoría de los casos se usan sockets y webhook.
Tu dispositivo debe estar escuchando constamente o intervalos y si lo querés hacer en modo 'artesano' desde scratch, debería crear una rutina para notificar al servidor que te envía las notificaciones, tu IP o puerto donde estás y si este cambia (ejemplo, cambias de atena 4/5G al desplazarte), actualizar esa info (para esto, los sockets ya te resuelven ese problema).
Lo que presentó midu, es algo NUEVO y sólo para Astro. Las notificaciones y llevan más de 1 década y media de que se usan.
¿La señal "WOW" aparece de nuevo?
Y si hago un fetch desde el front para obtener la url y texto y cargarlo en el boton con js.. o quizas de este modo evito tener endpoint back.. seria solo front mmm interesante
alguien sabe que VPN usa midu?
si pero dejamos de usar eso en PHP por el problema de mantenimiento todo el código se vuelve "spaghetti" por eso usamos frameworks pero eso aumento la dificultad de hacer código y reduce su velocidad y si es un interesante propuesta pero quiero ver reutilización de código y separar la lógica para poder darle mantenimiento.
qué ventaja tiene esto a hacer un redirect en un link genérico? (Por ejemplo que sea bitly el que elije el link en base a tu localización)
Pero a dia de hoy, prefiero vercel y nextjs para todo. Aunque no esta mal aprender astro tambien.
Una parte que no me ha quedado clara es ¿en el primer render, el boton de amazon esta, o se hace una request al server y carga el html del server aparte, y en el primer render no esta? (lo pregunto por ese pop inicial)
Así es. Carga todo en estático, menos ese botón, ya que después hace la petición al servidor y lo renderiza después. Lo que dice Midu para evitar el pop inicial es que tengas un botón similar como placeholder, para que cuando renderice el contenido dinámico desde el servidor no se vea tan pronunciado el pop.
Y si en lugar de poner un botón que se parezca mucho, hago que el texto sea lo único que cambia xd
No entiendo si son paginas estática despues el js pide la parte dinamica al server? Y que ventaja tiene sobre renderizar en el navegador si igual hay que hacer una petición extra?
Aun asi tiene mas sentido que todo renderizado en el server
Me imagino que sería útil para dar la impresión que es sumamente rápido, ya que el renderizado ya no lo haría el cliente, sino el servidor. Incluso, no estoy seguro, pero podría ser que en ese componente tengas lógica muy importante, como que haga consultas a endpoints de otros servicios, entonces al hacer el renderizado desde el servidor, ya no estarías mostrando toda esa lógica, sino únicamente el resultado.
La ventaja principal es que el contenido estático es fácilmente cacheable, lo que significa que no solo cargara más rápido por ser estático, sino que además puedes usar una CDN para que el contenido se entregue aún más rápido a los usuarios según la zona geográfica donde vivan, de esta forma, solo el contenido dinámico (por ejemplo lo que está al alcance de usuarios específicos) es lo único que va a "traerse" al servidor. Típicamente, este contenido dinámico generado por el servidor es más complicado hacer caching porque los datos no siempre son los mismos ni siquiera para un mismo usuario, y tus opciones son rendimiento a costa de personalización o al contrario, cuando no debería ser así.
Las estrategias de caching en el servidor pueden ser complejas o depender de la infraestructura, y el uso de CDN puede ser limitado (tendrías que ir siempre al servidor desde donde sea que el usuario te visite).
Obviamente, para cada caso habría que ver la conveniencia de como realizarlo y esto depende del proyecto, no es un absoluto de que todo debe hacerse de esta forma, solo son alternativas que están ahí para aprovecharse.
O sea,es una página HTML con css estática, y se le añade Astro?
Es así?
Si.
Ya entendí
Pero, es mejor trabajar con Astro o Nextjs 14?
Dependiendo del proyecto pero la gran mayoría de los sitios será mejor opción Astro.
Proyecto pequeño/mediano, Astro.
No lo veo mal en cuanto a rendimiento, pero creo que puede ser poco legible a la hora de organizar el codigo.
Para cuándo curso de astro con auth y estás novedades?
No lo entendi jajajajajaja :( Osea que con astro no se puede acceder al backend para hacer llamadas api o algo asi?
Yo programo con php y no necesito nada del cliente para servir estaticamente ese boton puesto que puedo detectar el pais desde el servidor e imprimir ese boton directamente en el html al cliente. Eso no se podia en astro?
Midu sabe donde vivo, ahora tengo miedo de que se aparesca en mi casas y me obligue a aprender php.
que tal es astro con qwik?
toca migrar de nextjs a astro, no hay de otra v:
No entiendo, la diferencia en mi cerebro sin el server:difer y con load:client es el mism, aparte de que el componente del boton seria cargado en el servidor, por la llamada que hace... pero en astro ya está poder tener componentes híbridos
Por qué la gran mayoría de empresas usan React si hay mejores opciones como VUE o Astro?
Por la longevidad o la zona de confort empresarial se podría decir. Es lo mismo que pasa con Telegram vs WhatsApp, es mejor el primero pero la gente se acostumbro al segundo porque fue el primero que salió.
Porque al trabajar fuertemente con componentes, podes hacer lo que se llama compartimentalización. La compartimentalización no sólo ayuda a producir en paralelo (velocidad de desarollo), sino que también ayuda a aislar partes del sistema. Eso evita que los devs, puedan filtrar el producto o partes grandes del producto a terceros en el caso de que haya un leak.
Cabe aclarar que esto en general, aplica a proyectos grandes donde tenes un desarollo grande como un paas o saas. Si vas a hacer una página donde hay un landing page y un par de routes para un carrito o un contact us, podrías hacerlo con html crudo y puro con alguna ayudita de bootstrap o tailwind. De necesitar listar dinámicamente pavadas, hasta con tener 2 o 3 javascript tipo un "shopingcart.js", y javascript vanilla puro, con un par de fetches se pude hacer más rápido que con react.
El chiste de React, Angular, etc es que son para cuando tenes 3 o 4 equipos de 3 o 4 personas cada uno, y necesitar crear 10 módulos los cuales 7 se pueden hacer en paralelo sin depender de que otro equipo termine su parte. React, formenta mucho eso y por eso es super práctico.
la verdad que Astro esta tremendo! pero me la baja lo que todavia no hay muchos puestos laborales
la posta es que Next esta acaparando todo el mercado front jaja
bebe un trago cada vez que diga php
+1 lanzallamas
pero esto no son los micro-frontends? q manía con renombrar las cosas para apropiarselas
Midu pero es que [lenguaje] ya lo hacia ...
PHP: y lo nuevo? 🗿
creo que es mucho drama... lo mismo rapido en la sencilles pero en la complejidad sera un problema
si , que arda twitter
GRoso ese trucazo !!!
no dice el pais chile
5:05 Asi habla Afor xD
Me parece HTMX as a service
Pero que buen bidio
Yo puse lo de PHP 🤣😂 pero en broma
Me pareció similar a htmx
Vean NueJS
La gente que "programa" en JS son los primos de los que tienen iphone. Magico como los frameworks de Javascript "inventan" cosas de PHP en los 2000 😂
@@eki203 ?
No necesitas server islands para leer una cabecera y hacer un switcj
Suena a HTMX pero menos mierda