https://docs.racket-lang.org/sxml-intro/
SXML became the de facto standard in the Scheme community after Oleg and others developed some powerful libraries for it, starting with Oleg's SSAX parser. SXML is also better-suited to efficient manipulation of large HTML/XML when using immutable lists.
Also, if you're looking at code examples in TFA, and thinking that, even when composing HTML using lists rather than strings, it's still susceptible to injection programming errors, then one SXML-ish improvement is:
To your point though - sxml is fantastic.
But Scheme code can often be made faster, especially if you know the performance characteristics of the particular implementation.
Besides generally using good performance practices, know that Racket has some profilers that can be immensely helpful. (I once rigged up Racket's statistical profiler at the time to capture the data for each instance of certain kinds of very complicated Web requests in a production system, and used the reports to optimize the heck out of it.)
Is there a good guide to this kind of stuff as someone new to Scheme? Like a community intro, showing what the core packages are etc.?
How it worked in the past was that people would ask or Web search as-needed, and then others would answer.
Unfortunately, with the demise of Usenet, there was fragmenting in where you had to go to ask, as a lot of people gravitated towards implementation-specific forums. For Racket (nee PLT Scheme), there was a wealth of good advise in the email lists, but at some point after hosting was moved to Google Groups, Google searches themselves seemed to stop finding many of the articles that were in Google's own archive, even when you explicitly directed the search.
I suppose the thing to do is to just ask on demand, in one of the forum for whatever implementation you're using. (The Racket community, for one, was exceedingly good at this, when I was more involved. And I suspect some of the other popular Scheme implementations are, as well.)
Are you stating with RFC 6455's implementation and just changing the API or trying to approximate the implementations?
Janet and Gerbil Scheme are also worth a look:
Guile is absolutely amazing these days: it has a JIT for speed, superb POSIX support, plus you can dynamic-link in any functionality you need from a C library.
Or what kind of things do you do with it?
If you were propagating e.g. game state, you'd still want to stick that in a db, so the continuation would just be a session id?
Game state has to be propagated from the server to the client so the player knows what is happening where-as continuations as used in this article are more about avoiding this propagation (the hidden field in the example is replaced by dispatch-table tag which acts as a session id / location in the dispatch-table for finding the continuation function)
Persisting a continuation seems like it's similarly as challenging as persisting an arbitrary closure. Like usual there are things you can't really persist, for example in your call stack you might have some unwind handlers for closing files -- how do you persist file handles?
If you google ‘serializable continuations’ you’ll find a reasonable amount of prior art (e.g. http://wiki.call-cc.org/eggref/5/s11n). I think there has never been a good solution to versioning then against changes to the code.
