Aunque el concepto en sí es algo que veía de vez en cuando, me sorprendió porque la página web es entretenida y está muy bien armada para poder experimentar sus funciones de un vistazo.
Fue una experiencia divertida que me despertó de golpe cuando ya me estaba dando sueño.
Para empezar, si la única razón para considerar una SPA era la "suavidad", yo simplemente habría renunciado a esa suavidad y la habría hecho como una MPA, así que la verdad no me genera mucha empatía...
Siendo sincero, tampoco es que hubiera mucho que hacer, pero sí había gente que ponía varias sesiones al mismo tiempo a la fuerza para sacarle el máximo provecho...
De los casos que presentaste, lo único que no se puede reemplazar con cosas como View Transitions son las herramientas de colaboración en tiempo real, pero la gran mayoría de los sitios web no son herramientas de colaboración en tiempo real. Sitios de marketing, dashboards y apps de comercio: todo eso se puede construir excluyendo frameworks SPA y manteniendo condiciones como renderizado del lado del servidor, páginas reales, animaciones basadas en CSS, precarga intencional y adopción mínima de JS. También existe Hotwire, de la comunidad de Rails, que apunta a eso, y además hay casos de producción como Basecamp y Hey. ¿Gestión de estado? A menos que sea algo como una herramienta de colaboración en tiempo real, normalmente basta con métodos del lado del servidor como parámetros de URL o sesiones del servidor, o con localStorage. También hay casos en los que claramente introducen una SPA solo por las transiciones de página (como el sitio oficial de AGF; incluso con Astro sería suficiente, pero hay casos claros donde metieron React), y no se puede negar que una de las ventajas representativas de las SPA de las que más se habla son precisamente las transiciones de página.
Sin duda hay casos en los que se adopta un framework SPA solo por una interacción fluida. Muchos de los sitios con SPA no necesitan interacciones complejas.
No todo es un endofuntor. Las cosas con varios parámetros de tipo, como Result<T, E>, no son 𝒞 → 𝒞 sino Result : 𝒞 × 𝒞 → 𝒞, así que esto es un bifuntor.
¡Es una observación muy acertada!
Parece que hubo un malentendido en el proceso de aplicar a Rust contenido escrito para otros lenguajes.
Como el sistema de tipos de Rust forma una sola categoría, la distinción entre endofuntor y funtor general parece no tener sentido.
Es una pena que el blog no tenga función de comentarios; tendré que preguntar si es posible solicitar una corrección.
Solo con ver el sitio de demostración ya resulta sumamente impresionante. De verdad ofrece una gran variedad de funciones con un código realmente corto.
Creo que esta persona se refiere al costo de suscripción del IDE. FLCC no se ofrece en la versión gratuita.
Pero tampoco es que la gente pague solo por eso.
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.
Aunque el concepto en sí es algo que veía de vez en cuando, me sorprendió porque la página web es entretenida y está muy bien armada para poder experimentar sus funciones de un vistazo.
Fue una experiencia divertida que me despertó de golpe cuando ya me estaba dando sueño.
Para empezar, si la única razón para considerar una SPA era la "suavidad", yo simplemente habría renunciado a esa suavidad y la habría hecho como una MPA, así que la verdad no me genera mucha empatía...
Siendo sincero, tampoco es que hubiera mucho que hacer, pero sí había gente que ponía varias sesiones al mismo tiempo a la fuerza para sacarle el máximo provecho...
De los casos que presentaste, lo único que no se puede reemplazar con cosas como View Transitions son las herramientas de colaboración en tiempo real, pero la gran mayoría de los sitios web no son herramientas de colaboración en tiempo real. Sitios de marketing, dashboards y apps de comercio: todo eso se puede construir excluyendo frameworks SPA y manteniendo condiciones como renderizado del lado del servidor, páginas reales, animaciones basadas en CSS, precarga intencional y adopción mínima de JS. También existe Hotwire, de la comunidad de Rails, que apunta a eso, y además hay casos de producción como Basecamp y Hey. ¿Gestión de estado? A menos que sea algo como una herramienta de colaboración en tiempo real, normalmente basta con métodos del lado del servidor como parámetros de URL o sesiones del servidor, o con
localStorage. También hay casos en los que claramente introducen una SPA solo por las transiciones de página (como el sitio oficial de AGF; incluso con Astro sería suficiente, pero hay casos claros donde metieron React), y no se puede negar que una de las ventajas representativas de las SPA de las que más se habla son precisamente las transiciones de página.Sin duda hay casos en los que se adopta un framework SPA solo por una interacción fluida. Muchos de los sitios con SPA no necesitan interacciones complejas.
No todo es un endofuntor. Las cosas con varios parámetros de tipo, como
Result<T, E>, no son 𝒞 → 𝒞 sinoResult : 𝒞 × 𝒞 → 𝒞, así que esto es un bifuntor.¡Es una observación muy acertada!
Parece que hubo un malentendido en el proceso de aplicar a Rust contenido escrito para otros lenguajes.
Como el sistema de tipos de Rust forma una sola categoría, la distinción entre endofuntor y funtor general parece no tener sentido.
Es una pena que el blog no tenga función de comentarios; tendré que preguntar si es posible solicitar una corrección.
¡Es un buen artículo! Solo que la explicación relacionada con el endofunctor tiene un error, así que estaría bien corregirla https://x.com/simnalamburt/status/1950074970647761168?s=46
king - man + woman = queenTiene todas esas funciones que uno piensa que ojalá tuviera. Este solo hace de NAS completo.
Solo con ver el sitio de demostración ya resulta sumamente impresionante. De verdad ofrece una gran variedad de funciones con un código realmente corto.
Namu Wiki...
La verdad no entiendo bien cómo pueden usarse juntos la verificación de edad y la protección de la privacidad..
¿En el momento en que te verificas no estás dejando al menos una vez tu firma ahí, o algo equivalente?
Si de verdad quieren proteger la privacidad, debería poder usarse de forma anónima
Excelente. Me encanta este tipo de enfoque.
Qué bueno ver una metodología de optimización no basada en ML.
Creo que esta persona se refiere al costo de suscripción del IDE. FLCC no se ofrece en la versión gratuita.
Pero tampoco es que la gente pague solo por eso.
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.