3 ms·

I'm glad to see someone talking about using the lower-level web libraries in Racket. The high-level continuation-based ones are ridiculously unsuitable for actu

I'm glad to see someone talking about using the lower-level web libraries in Racket. The high-level continuation-based ones are ridiculously unsuitable for actual web programming (they store full state on the server at all times, and the URL gives you full access to the session, among other issues), but the lower-level ones actually look pretty clean and modern. And yet all the documentation keeps talking about the continuation stuff, bizarrely.

minikomi 11y ago
Indeed. I have fun making little web apps which serve a small single purpose and can be run from a single script[0] - templating using response/xexpr with paredit is.. well.. fun! Speed isn't a problem since I cache the result behind nginx - these aren't mission critical apps. [0] Tokyo Art Parties parsed out of Tokyo art beat events xml - https://github.com/minikomi/tokyoartparties-rkt/blob/master/artparties.rkt https://github.com/minikomi/tokyoartparties-rkt/blob/master/...
shriramkmurthi 11y ago
The continuation-based libraries are the simplest, easiest, quickest way to get a program off the ground. They make interactive Web programming just as easy as writing “scanf” or its equivalent, _and_ are safe in the face of various browser interactions. Therefore, they're a good default for prototyping. However, I agree that they also have issues, and the documentation should not over-emphasize them, but rather indicate what they are suitable for and what not and make clearer to readers a transition path out of there.
- mkozlows 11y ago
  I think that depends on where you're coming from. If you're a longtime web developer, stateless request/response are in your blood, and stateful, persistent programming is deeply weird.
jeapostrophe 11y ago
The issues you mention are all alleviated by the stateless continuations which do not store state on the server and allow various ways of closing off the session from simply having the URL. The documentation discusses the features of the Web framework, many of which have to do with its unique aspects. As you can see in this post, all normal Web programming is possible and easy, but there's very little special to say about it, because it's just a normal program.
- mkozlows 11y ago
  "It's just normal" is a thing that I think is good to communicate. Being able to use Racket to write web apps in ways that wouldn't be unfamiliar to Node devs makes the Lispy thing seem less weird and intimidating.

minikomi 11y ago

Indeed. I have fun making little web apps which serve a small single purpose and can be run from a single script[0] - templating using response/xexpr with paredit is.. well.. fun! Speed isn't a problem since I cache the result behind nginx - these aren't mission critical apps. [0] Tokyo Art Parties parsed out of Tokyo art beat events xml - https://github.com/minikomi/tokyoartparties-rkt/blob/master/artparties.rkt https://github.com/minikomi/tokyoartparties-rkt/blob/master/...

shriramkmurthi 11y ago

The continuation-based libraries are the simplest, easiest, quickest way to get a program off the ground. They make interactive Web programming just as easy as writing “scanf” or its equivalent, _and_ are safe in the face of various browser interactions. Therefore, they're a good default for prototyping. However, I agree that they also have issues, and the documentation should not over-emphasize them, but rather indicate what they are suitable for and what not and make clearer to readers a transition path out of there.

mkozlows 11y ago
I think that depends on where you're coming from. If you're a longtime web developer, stateless request/response are in your blood, and stateful, persistent programming is deeply weird.

jeapostrophe 11y ago

The issues you mention are all alleviated by the stateless continuations which do not store state on the server and allow various ways of closing off the session from simply having the URL. The documentation discusses the features of the Web framework, many of which have to do with its unique aspects. As you can see in this post, all normal Web programming is possible and easy, but there's very little special to say about it, because it's just a normal program.

mkozlows 11y ago
"It's just normal" is a thing that I think is good to communicate. Being able to use Racket to write web apps in ways that wouldn't be unfamiliar to Node devs makes the Lispy thing seem less weird and intimidating.