[thwarted]

A point of comparison should be to git.kernel.org, which loads and renders instantly (at least compared to all these other sites), contains a massive amount of actual content per page, is highly cacheable on the server, and uses exactly zero javascript while remaining usable (for its use case at least, which is all links and little form interaction (only the search box)).

[pragmatic]

Imagine a spectrum from document to application (from left to right).

This is the almost fully left as a pure document with low interactivity.

Applications are much harder to cache and start up fast.

[morelisp]

How far we've come that near-real-time multidimensional dynamic views onto multi-GB data stores is considered 'a pure document' by someone. Why, just because it uses links and URLs and instead of buttons and fetch?

[pvillano]

Yes, in the current context of the need for client side rendering.

[morelisp]

No, you've assumed the question. "Applications are much harder to cache and start up fast" because you're defining "applications" to intentionally exclude architectures which are cachable and fast to start.

If I shipped a git repo viewer as an executable, nobody would be asking why it's not rather a txt/doc/PDF. It's unquestionably an application, not a document.

[klysm]

The ui is not that functional compared to other git front ends.

[esperent]

On mobile, I just checked out git.kernel.org.

It takes about 4s to load and does 2 or 3 jarring text reflows, I guess as fonts load or something.

It's also unreadable. Incredibly tiny text that would exhaust my eyes to parse within a few minutes.

And besides that... It's just text. Displaying text is easy. I'm sure this would be close to instant whatever framework you used, as long as it was coded well.