>         I would recommend a reasonably modern single-page app for
>         <docs.schemers.org <http://docs.schemers.org>> since that
>         address would be the obvious starting
>         point for newbies and many programmers expect something quite
>         modern
>         nowadays. It gives a good first impression if we have something
>         modern
>         there, in any case. Another reason is that the API will have a wide
>         variety of information. It will be hard to present all of it in an
>         interactive form unless we use a single-page app (there's just
>         so much
>         of it).
>
>     It would be nice to specify exactly what the app will do, though.
>     Will it be primarily a search UI with a text box and a few
>     controls?  (That's what I implemented for SRFIs at srfi.schemers.org
>     <https://srfi.schemers.org>.)  Or will it be something more elaborate?
>
> Exactly.
That's a fair question. I think it would be best if I did a mock-up or
prototype to illustrate it. It's hard to convey with words alone... I'd
like to have a mash-up of <docs.racket-lang.org>,
<pkgs.racket-lang.org>, <quickdocs.org>, <quicklisp.org>. But that
doesn't really communicate, because with Scheme we have to present
multiple implementations. It would also be nice to present cookbook and
tutorial material (e.g. if someone looks at an API reference for a
procedure, there could be a link "hey, did you know there's a tutorial
on this topic?"). So basically all package info and documentation the
API knows about, with all aspects deeply hyperlinked.

This could be the most ambitious site for any language to date, but I
think we should still aim for it :) If we miss the goal, we'll still
have an excellent site. If we aim lower, we'll have less enthusiasm and
will produce a site that is not even on par with the average language
site of today.

What are your preferred ways of working on this? I can produce the
mock-ups but it will take some time (at least a week or two) to get
anything done. If you are enthusiastic to start already, we can think of
another approach. And if you think the above plan is too ambitious or
dumb, that's fine too and we can do it another way :) The nice thing is
that with all the data in the API, experimenting on the UI is a lot cheaper.

> I created a repository with XHR GET support, if someone wants to play
> with it:
>
> https://github.com/scheme-live/ff.scm/commit/2cdb99105bf905d1eede18a3422aa8efd6959c62
>
> After git clone, I run: python3 -m http.server and then what is
> interesting happens in the
> web developer console but you need to input something in the input text
> box to trigger the
> XHR GET foo.js.
>
> I had some bad luck so you might want to run it in private browsing mode.
>
> The interesting code is main.js and main.scm.
>
> Another thing that is not described in the commit message is the use of
> custom reactjs
> components, right now I only tried basic stuff like div, input etc... I
> never tried third party
> widgets.
>
> You might need to run npm install. not sure about that. I think I
> commited the "helpers"...

Amazing. You work really fast!

I regret that there's so much good stuff that I don't have time to look
at this in proper detail. I'll try to make time later this week.
Currently stuck with getting the GraphQL/API started and trying to get
to the OS/archive stuff as fast as possible.

Any lurkers happen to be reading this thread and excited to advance
Scheme on the web? I feel we're all beginning to run out of person-hours
for real :)