David Thompson <dthomps...@worcester.edu> skribis: > Ludovic Courtès <l...@gnu.org> writes: > >> John Darrington <j...@darrington.wattle.id.au> skribis: >> >>> In particular, I have noticed that http://gnu.org/s/guix/package-list.html >>> is now >>> over 1.5 MB in size and is startign to take an unacceptably long time to >>> load (at >>> least for me). >> >> I think it’s rendering that takes time, not transfer per se (unless you >> have a very slow connection.) >> >> I would like it to use David’s guix-web JS code to add the search box >> and multiple-page split. I suspect this would address the rendering >> time and usability issues. But of course, that would need help from >> someone knowledgeable... :-) > > We could make a specialized application that did this, since guix-web > will soon enough be concerned with authentication and other things that > aren't needed here. To do things the way guix-web does, it would > require a Guile server component for the JSON API.
I was thinking of something simpler: statically generate package-list.html (as we currently do, with list-packages.scm), but instead of spitting out the HTML table directly, produce the JSON data that guix-web’s browser-side code expects. >> It would be ideal if this were done in a “progressive enhancement” >> fashion, such that it can still be viewed in emacs-w3m. > > Yes, agreed. This would be the hardest part, because guix-web is > designed as a "single-page application", using JavaScript for all > rendering. I would be inclined to write this package list browser in > the same fashion, because it results in much more elegant code than the > jQuery soup we would otherwise be in. > > What should the non-JS fallback viewer look like? Should we just > display the full list as we do now? I think so. Ludo’.
