SPA, transiciones de elementos compartidos y tecnología de revalorización trucos CSS

Nolan Lawson desató una discusión cuando dijo describe una desviación notable de las aplicaciones de una sola página (SpaC):

Nuevos marcos modernos como astro, Qwiky Elder.js anunciar los suyos AMP [multi-page application] con "0kB JavaScript por defecto". Las publicaciones de blog hacen la lista de círculos todos los retos s Spas: historial, gestión de enfoque, recuperación de desplazamiento, Cmd / Ctrl-clic, pérdida de memoria, etc. Fotos alegres se toman contra el SPA.

Sin embargo, creo que lo que se discute menos es cómo ha cambiado el contexto en los últimos años para dar AMPes más que superioridad contra Spa.

Parece que mucha gente se aferró mucho a esta primera parte porque Nolan publicó un acciones posteriores para aclarar esto Spas están lejos de estar condenados:

[T]El propósito de mi publicación no era enterrar Spay bailan en sus tumbas. Creo que sí Spason geniales, he trabajado en muchos de ellos y creo que tienen un futuro brillante por delante. Mi idea principal era: si la única razón para usar Spa es porque "hace que la navegación sea más rápida", entonces tal vez sea hora de reevaluarlo.

Y hay buenas razones para decirlo. De hecho, el primer artículo menciona específicamente el trabajo que se está realizando Transiciones de elementos compartidos. Si avanzan, tendremos una API para animar/transicionar/dimensionar/posicionar elementos en la entrada de la página y existirá. Jake Archibald demuestra cómo funciona en Google I/O 2022 y el video es una joya.

Si se pregunta cómo una página puede cambiar a otra, el navegador toma capturas de pantalla de las páginas entrantes y salientes y luego cambia entre ellas. Por lo tanto, no es tanto que una página se convierta en otra, sino que el navegador contiene dos imágenes para que pueda animar una mientras la otra se anima. Jake dice que lo que sucede detrás de escena es una estructura DOM creada por pseudo-elementos que contienen las imágenes en la página:

<transition-container>
  <image-wrapper>
    <outgoing-image />
    <incoming-image />
  </>
</>

Podemos "capturar la pantalla" de un elemento específico si queremos aislarlo y aplicarle una animación diferente al resto de la página:

.site-header {
  page-transition-tag: site-header;
  contain: paint;
}

Y obtenemos pseudo-elementos que podemos conectar y personalizar @keyframe animaciones:

<!-- ::page-transition=container(root)  -->
<transition-container>
  <!-- ::page-transition-image-wrapper(root)  -->
  <image-wrapper>
    <!-- ::page-transition-outgoing-image(root) -->
    <outgoing-image />
    <!-- ::page-transition-incoming-image(root) -->
    <incoming-image />
  </>
</>

Hombre, ¡eso es muy inteligente!

Esto también es una prueba clara de cuánto HTML, CSS y JavaScript continúan evolucionando y mejorando. Tanto es así que Jeremy Keith sugiere que ya es hora de que lo haga. para reevaluar nuestra evaluación previa de algunas tecnologías:

Si no conocía los cambios de los últimos años, sería fácil pensar que las aplicaciones de una página ofrecen algunos beneficios únicos que ya no son válidos. […] Pero los desarrolladores siguen desconfiando y prefieren confiar en bibliotecas de terceros antes que en su propio navegador. Se decidieron por estas bibliotecas en el pasado. Evaluaron el estado del soporte del navegador en el pasado. Quiero que vuelvan a evaluar estas decisiones.

Ingredientes para SPA especialmente:

En particular, en los últimos años, la red ha sentido los pasos agigantados: trabajadores de servicio, API de JavaScript naturales y un impulso increíble en lo que puede hacer con CSS. Lo más importante de todo es que la interoperabilidad de los navegadores es cada vez mejor. El soporte universal para los nuevos estándares web está llegando más rápido que nunca.

HTML, CSS y JavaScript: este sigue siendo el mejor cóctel de la ciudad, aunque tarde un minuto en ponerse al día.