3 ms·
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
by thwarted 4y ago
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)).
- klysm 4y agoThe ui is not that functional compared to other git front ends.
- pragmatic 4y agoImagine 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.
- sbdncuvh 4y ago
- morelisp 4y agoHow 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 4y agoYes, in the current context of the need for client side rendering.
- morelisp 4y agoNo, 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.
- esperent 4y agoOn 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.