swup
Streaming the response #635
kurtextrem
started this conversation in
Feature ideas
Replies: 1 comment
-
|
This sounds super-interesting. While I haven't yet worked with XHR streams, the performance improvement sounds like a good thing. From a cursory reading of the requirements and the caveats in the sjax package, this deviates quite a bit from swup's core assumptions:
To me, it sounds like this would be a great plugin for lower-level libraries like htmx or alpine. I'm happy to be convinced by a PR if you want to give this a try, though! |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
-
Hi, as far as I understand swup waits until the XHR is done before swapping out the DOM and then does the transition.
However, instead of waiting for the full response, the XHR response could be streamed into a DOM node, e.g. like here: https://github.com/jongacnik/streamjax. A few years have passed, we no longer have to use the iframe hack. All of those approached lead to an improved performance over XHR + innerHTML (see Jake's article).
Swup-next
I hear you say: it makes transitions harder... except that Chromium now supports SPA transitions: https://developer.chrome.com/docs/web-platform/view-transitions/. This is very new tech, but in 2016 Web Streams were also very new tech, fast forward to 2023, they're as old as 3+ years now - so what if we start swup-next, that uses modern streaming with view transitions to achieve a native, reload-free, experience?
Server
Servers need to implement a check if the request is an XHR request (by e.g. setting a special header in the request, such as
swup-xhr: 1).When that header is set, servers should omit
<head>and stuff that should not be streamed into the container (e.g. do not send the header etc. again, only the content that should replace the previous content)<head>stuffAs we omit everything that is not part of the updated body (as we're streaming the response right in), we need a way to update the favicon and title, so we probably should also come up with a response header (
swup-favicon:,swup-title)?<script>/<link>I'm not sure if streaming those in work with the Web Streams. I'd assume yes -- but with the iframe hack it was slightly more work to get them right (see Jake's original article where he proposed the hack). This needs to be taken into account / tested.
What does everything think of this? Is this deviating too much from swup, e.g. would a fork make sense? Or a new project under the Swup umbrella?
Beta Was this translation helpful? Give feedback.
All reactions