Nolan Lawson löste einige Diskussionen aus, als er eine spürbare Abkehr von Single-Page-Anwendungen (SPAs) beschrieb
Coole neue Frameworks wie Astro, Qwik und Elder.js bewerben ihre MPA [Multi-Page-Anwendung] mit „0kB JavaScript standardmäßig“. Blogbeiträge machen die Runde und listen all die Herausforderungen mit SPAs auf: Verlauf, Fokusverwaltung, Scroll-Wiederherstellung, Cmd/Strg-Klick, Speicherlecks usw. Freudige Sticheleien werden gegen SPAs gerichtet.
Ich denke, was weniger diskutiert wird, ist, wie sich der Kontext in den letzten Jahren verändert hat, um MPAs einen Vorteil gegenüber SPAs zu verschaffen.
Es scheint, dass eine Reihe von Leuten an diesem ersten Teil festgehalten hat, weil Nolan eine Fortsetzung veröffentlicht hat, um zu klären, dass SPAs noch lange nicht am Ende sind.
[D]er Punkt meines Beitrags war nicht, SPAs zu beerdigen und auf ihrem Grab zu tanzen. Ich denke, SPAs sind großartig, ich habe an vielen von ihnen gearbeitet und ich denke, sie haben eine glänzende Zukunft vor sich. Mein Hauptpunkt war: Wenn der einzige Grund, warum Sie eine SPA verwenden, darin besteht, dass „sie Navigationen schneller macht“, dann ist es vielleicht an der Zeit, das zu überdenken.
Und es gibt gute Gründe dafür. Tatsächlich verweist der erste Artikel ausdrücklich auf die Arbeit an Shared Element Transitions. Wenn sie vorankommt, haben wir eine API zum Animieren/Überblenden/Größenändern/Positionieren von Elementen beim Ein- und Ausblenden von Seiten. Jake Archibald demonstrierte, wie es bei Google I/O 2022 funktioniert, und das Video ist ein Juwel.
Wenn Sie sich fragen, wie eine Seite in eine andere übergehen kann, nimmt der Browser Screenshots der ausgehenden und der eingehenden Seite und wechselt dann dazwischen. Es ist also nicht so sehr, dass eine Seite zu einer anderen wird, als vielmehr, dass der Browser zwei Bilder festhält, um eines einzublenden, während das andere ausgebendet wird. Jake sagt, was hinter den Kulissen passiert, ist, dass eine DOM-Struktur aus Pseudoelementen erstellt wird, die die Seitenbilder enthalten.
<transition-container>
<image-wrapper>
<outgoing-image />
<incoming-image />
</>
</>Wir können ein bestimmtes Element „screenshotten“, wenn wir es isolieren und eine andere Animation als der Rest der Seite anwenden wollen.
.site-header {
page-transition-tag: site-header;
contain: paint;
}Und wir erhalten Pseudoelemente, in die wir eingreifen und benutzerdefinierte @keyframe-Animationen zuweisen können.
<!-- ::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 />
</>
</>Verdammt, das ist verdammt clever!
Es ist auch ein Beweis dafür, wie sehr sich HTML, CSS und JavaScript weiterentwickeln und verbessern. So sehr, dass Jeremy Keith vorschlägt, es sei höchste Zeit, dass wir unsere frühere Einschätzung einiger Technologien überdenken.
Wenn Sie sich der Änderungen der letzten Jahre nicht bewusst wären, könnten Sie leicht weiterhin denken, dass Single-Page-Apps einzigartige Vorteile bieten, die tatsächlich nicht mehr gelten. [...] Aber Entwickler bleiben misstrauisch und ziehen es vor, Drittanbieterbibliotheken gegenüber nativen Browserfunktionen zu vertrauen. Sie haben in der Vergangenheit eine Entscheidung über diese Bibliotheken getroffen. Sie haben den Zustand der Browserunterstützung in der Vergangenheit bewertet. Ich wünschte, sie würden diese Entscheidungen überdenken.
Die Zutaten speziell für SPAs
Insbesondere in den letzten Jahren hat sich das Web in Sprüngen und Grenzen entwickelt: Service Worker, native JavaScript-APIs und ein erstaunlicher Schub bei dem, was Sie mit CSS tun können. Am wichtigsten ist, dass die Interoperabilität zwischen den Browsern immer besser wird. Universelle Unterstützung für neue Webstandards kommt schneller denn je.
HTML, CSS und JavaScript: Es ist immer noch der beste Cocktail der Stadt. Auch wenn es eine Weile dauert, bis er aufholt.