Reduce demasiado la verdadera finalidad de un SPA
La View Transitions API es realmente genial, pero eso por sí solo no significa que los SPA dejen de ser necesarios.
Mira todos los sitios web con el mismo criterio
Sitio de marketing ≠ dashboard ≠ app de comercio ≠ herramienta de colaboración en tiempo real
Todos tienen requisitos estructurales distintos.
En la práctica, SPA + SSR + MPA conviven
Los frameworks híbridos como Next.js muestran bien esto.
Los recursos estáticos usan SSG, los dashboards después del inicio de sesión usan CSR/SPA, y para responder a los motores de búsqueda se usa SSR; se necesita una combinación flexible.
Creo que un SPA, más que solo una mejora en la experiencia de usuario, es el resultado de una mejora estructural.
En las páginas donde un SPA no es necesario, MPA + modern CSS puede ser una buena opción, pero los SPA siguen siendo esenciales en términos de estructura, estado, escalabilidad y mantenimiento. Creo que el modern CSS puede "complementar" a los SPA, pero no "reemplazarlos".
Honestamente, se ve como cuando alguien dice sobre Rust o Haskell, sin siquiera haberlos tocado: "eso no hace falta, hoy en día todo se puede hacer con C++".
Si bien es cierto que los frameworks SPA actuales y la tendencia del frontend basada en ellos necesitan seguir cuidándose de la no estandarización, y que también tienden a provocar sobreingeniería y consumo innecesario de recursos...
También siento que se está viendo el concepto de SPA de una forma demasiado estrecha, pero más aún, me hace dudar si realmente se entiende qué impacto tienen los frameworks SPA en el desarrollo en general.
Decir que con solo la API de View Transitions y algo de CSS ya está todo resuelto significa, dicho de otra manera, que todas las demás funciones que no tienen relación con eso, y los paradigmas necesarios para lograrlas, carecen por completo de sentido; me parece una postura demasiado arrogante.
Eso es un tema aparte de la sobreingeniería que implica crear con React un sitio que apenas reemplaza un folleto.
Estoy de acuerdo en que la mayoría de los proyectos pequeños no necesitan forzosamente un framework SPA, pero en servicios que exigen interacciones complejas y una experiencia de usuario continua, además del mantenimiento y la mejora continua que eso conlleva, no creo que sea así, a pesar de los avances de CSS.
Tengo entendido que, al intentar usarlo en Kotlin, puede haber un problema de rendimiento porque los tipos primitivos se envuelven en wrapper, por lo que se almacenan en el heap y no en el stack. Claro, en la mayoría de los casos de uso la mantenibilidad tiene prioridad. Además, se pueden minimizar los problemas de rendimiento usando value class.
Aunque los LLM no están exentos de desventajas, me cuesta estar de acuerdo con que todos los servicios de IA no sean rentables. Creo que en los próximos 5 años casi todos los servicios de plataforma actuales serán reemplazados por agentes de IA.
> ¿Quiere que también convierta este resumen en un documento aparte con formato de informe resumido en PDF (resumen general-introducción-desarrollo-conclusión)?
Como es alguien que normalmente publica mucho, parece que esto lo puso a propósito jajaja
Fue un texto interesante. Parece mejor primero pensar con la propia cabeza y luego usar un LLM.
La ventaja de Ada en general va más por el lado de que "es mejor que C". En C, una gran limitación es que se confía en el desarrollador y se permiten muchas cosas, como las conversiones implícitas de tipos. Pero parece que a la mayoría de los desarrolladores les sigue gustando más C, quizá porque ya están acostumbrados...
Puede que sea una característica particular de la base de código en la que trabajo, pero declaramos y usamos casi todo como tipos separados. Prácticamente solo usamos tipos básicos para índices de arreglos.
Lo decepcionante de este artículo
Reduce demasiado la verdadera finalidad de un SPA
La View Transitions API es realmente genial, pero eso por sí solo no significa que los SPA dejen de ser necesarios.
Mira todos los sitios web con el mismo criterio
Sitio de marketing ≠ dashboard ≠ app de comercio ≠ herramienta de colaboración en tiempo real
Todos tienen requisitos estructurales distintos.
En la práctica, SPA + SSR + MPA conviven
Los frameworks híbridos como Next.js muestran bien esto.
Los recursos estáticos usan SSG, los dashboards después del inicio de sesión usan CSR/SPA, y para responder a los motores de búsqueda se usa SSR; se necesita una combinación flexible.
Creo que un SPA, más que solo una mejora en la experiencia de usuario, es el resultado de una mejora estructural.
En las páginas donde un SPA no es necesario, MPA + modern CSS puede ser una buena opción, pero los SPA siguen siendo esenciales en términos de estructura, estado, escalabilidad y mantenimiento. Creo que el modern CSS puede "complementar" a los SPA, pero no "reemplazarlos".
Honestamente, se ve como cuando alguien dice sobre Rust o Haskell, sin siquiera haberlos tocado: "eso no hace falta, hoy en día todo se puede hacer con C++".
Si bien es cierto que los frameworks SPA actuales y la tendencia del frontend basada en ellos necesitan seguir cuidándose de la no estandarización, y que también tienden a provocar sobreingeniería y consumo innecesario de recursos...
También siento que se está viendo el concepto de SPA de una forma demasiado estrecha, pero más aún, me hace dudar si realmente se entiende qué impacto tienen los frameworks SPA en el desarrollo en general.
Decir que con solo la API de View Transitions y algo de CSS ya está todo resuelto significa, dicho de otra manera, que todas las demás funciones que no tienen relación con eso, y los paradigmas necesarios para lograrlas, carecen por completo de sentido; me parece una postura demasiado arrogante.
Eso es un tema aparte de la sobreingeniería que implica crear con React un sitio que apenas reemplaza un folleto.
Estoy de acuerdo en que la mayoría de los proyectos pequeños no necesitan forzosamente un framework SPA, pero en servicios que exigen interacciones complejas y una experiencia de usuario continua, además del mantenimiento y la mejora continua que eso conlleva, no creo que sea así, a pesar de los avances de CSS.
Está bueno porque hay muchas ideas interesantes surgidas de trabajar con búsqueda vectorial.
Tengo entendido que, al intentar usarlo en Kotlin, puede haber un problema de rendimiento porque los tipos primitivos se envuelven en
wrapper, por lo que se almacenan en el heap y no en el stack. Claro, en la mayoría de los casos de uso la mantenibilidad tiene prioridad. Además, se pueden minimizar los problemas de rendimiento usandovalue class.Como referencia, el ticket de soporte para Rust: https://github.com/android/ndk/issues/1742
¡Ojalá aparezca algo así también en C++!
Mmm, no estoy tan seguro. ¿No se usan los frameworks SPA más por las interacciones complejas con el usuario que por las transiciones fluidas?
Como se ejecuta localmente, parece que no hará falta pagar.
Gastar entre $20 y $200 al mes solo para eso es medio...
Mientras tanto, Pass:
Mmm... ^^;;; Me equivoqué... La próxima vez lo revisaré un poco más antes de publicarlo...
Aunque los LLM no están exentos de desventajas, me cuesta estar de acuerdo con que todos los servicios de IA no sean rentables. Creo que en los próximos 5 años casi todos los servicios de plataforma actuales serán reemplazados por agentes de IA.
> ¿Quiere que también convierta este resumen en un documento aparte con formato de informe resumido en PDF (resumen general-introducción-desarrollo-conclusión)?
Como es alguien que normalmente publica mucho, parece que esto lo puso a propósito jajaja
Fue un texto interesante. Parece mejor primero pensar con la propia cabeza y luego usar un LLM.
Parece que sí era cierto que la precisión y la sensación de autoría eran bajas.
Hasta el resumen ya es LLM..
Entendido, gracias.
La ventaja de Ada en general va más por el lado de que "es mejor que C". En C, una gran limitación es que se confía en el desarrollador y se permiten muchas cosas, como las conversiones implícitas de tipos. Pero parece que a la mayoría de los desarrolladores les sigue gustando más C, quizá porque ya están acostumbrados...
Puede que sea una característica particular de la base de código en la que trabajo, pero declaramos y usamos casi todo como tipos separados. Prácticamente solo usamos tipos básicos para índices de arreglos.
Pregunto por curiosidad. ¿También tiene ventajas diferentes a las de otros lenguajes de tipos populares? (
Kotlin,Rust,TypeScript, ...)Coincido.