Add some sort of lazy-loading

[Cyberes]

Currently, when viewing a room the backend has to connect to the Matrix server and fetch everything. This seems to take 1 to 2 seconds under normal conditions and I expect the process could take longer if the Matrix server is under load. This makes the website feel very sluggish to the user.

I suggest having the client load a static page and wait for the backend server to finish fetching the room. Once it's complete the client can load the room.

Potential solutions

View-Transitions API for multi-page apps

See #222 (comment)

Streaming server-side rendering

We're not using React but the streaming SSR ideas they have are interesting to inspire some solution for Hydrogen:

• https://www.patterns.dev/posts/streaming-ssr
• https://blog.logrocket.com/streaming-ssr-with-react-18/
• https://web.dev/rendering-on-the-web/#streaming-server-side-rendering-and-progressive-rehydration

[MadLittleMods]

The goal of the archive is to be able to visit a URL and instantly view Matrix content from any time in history (and let search engines do it too). We're a long ways away from https://archive.matrix.org/ feeling like that but it's something this project is striving for. This is where a lot of other Matrix clients start to fall apart nowadays because of slow startup times and just built for a different use case but we wanted the same feeling that the Gitter archives had (maybe you're familiar) where it just works.

This doesn't mean we have to stick to only server-side rendering but it seems like it keeps things really simple. We can be close and have a nice fast, fat pipe to the homeserver to get fast data fetching and cache responses which we can serve instantly to everyone visiting the archive.

Introducing something like lazy-loading or some dynamic piece like infinite scroll changes the entire paradigm of the Matrix Public Archive and then basically we just start moving into the territory of a normal Matrix client like Hydrogen itself.

Adding jump to date functionality to the conventional Matrix clients is on the list and it's something I've been pushing forward in Element ever since introducing MSC3030 with the /jumptodate slash command and jump to date headers which is only really stuck behind addressing element-hq/element-web#21263

I would be interested in doing some lazy-loading like this if Hydrogen supported something like React Server Components. That way we could still keep with the server-side rendering approach but serve something quicker in the mean-time. This conversation with Dan Abramov about React Server Components is really long but I found it really intriguing how we could utilize something like that here.

Improving the performance of the /messages API endpoint in Synapse (Matrix homeserver) is definitely on our radar and something we want to improve. You can track our progress by following the issues in https://github.com/matrix-org/synapse/milestone/11

[Cyberes]

Yeah, it's certainly a stretch goal for now. One issue with lazy-loading is that it defeats the goal of having something a search engine can read. Improving the performance of /messages and adding useful APIs to Synapse is probably the best way forward for now.

[MadLittleMods]

Just thought of an idea to solve this by of using View Transitions API to smoke and mirrors all of this while still maintaining our server-side rendered multi-page app (MPA).

This demo shows the power off really well with a multi-page app: https://www.maxiferreira.com/blog/astro-page-transitions/

full-demo.mp4

Even though the current View Transitions API only supports single-page apps (SPA), they used some clever workarounds which make it look feasible to use for some real MPA. Although, as the blog post mentions, there are some navigation race conditions and placeholder/skeleton complexity that needs to be thought about.

It definitely seems like a no-brainer to use when the API supports multi-page apps in any case. It looks like Chrome already has experimental support for multi-page apps via the chrome://flags/#view-transition-on-navigation flag, see https://developer.chrome.com/blog/spa-view-transitions-land/ (and a video demo)

And it makes a lot of sense to use something like this when we support threads since opening and closing a thread will probably be separate page navigations. It would just make all of that seem flawless!

---

Other links:

• https://developer.chrome.com/docs/web-platform/view-transitions/
• https://github.com/WICG/view-transitions
• https://twitter.com/charca/status/1637832314364497920
• https://twitter.com/charca/status/1594725772148752391
  • https://github.com/Charca/astro-view-transitions
  • https://twitter.com/charca/status/1592909120554033156
• https://twitter.com/crim_codes/status/1658182657899913239
• https://daverupert.com/2023/05/getting-started-view-transitions/
• https://tylergaw.com/blog/view-transitions-first-experiments-mpa/

[Cyberes]

Hey, that's perfect! Parsable by robots, (mostly) functional with noscript, and meets the lazy-loading criteria!