Well the ArcWTF challenge was sort of a joke, but I think this code isn't better.
The big problem is you (and Arc and others like it) imply too much historical knowledge in the name of terseness. What happens is when someone has to fix the thing they have to dredge up all the knowledge of where things are rather than finding them right there.
For example: If I have to come and fix the template that has the input form in your code where do I go? Do I edit some code deep inside your framework? Is there a page somewhere? Is it in HTML? Oh it's not? So I have to hire a guy who is a designer and a Lisp or Java or Smalltalk guru? Ok there is a template, so where is it? Is that configured somewhere so I have to one more level of indirection to find the thing that configures the thing that shows the page?
If you back off the tersness a bit, you can then have a piece of code that's still small, but also complete by itself. Anyone coming to my code sample and told, "Fix the damn submit button so it's cornflower blue." Can do it no problem because it says right there what file is being used in what way.
Additionally, I don't buy it with these "yours is 40 lines haha" challenges. Who the hell cares? It's more about the usability and ease of maintenance.
There is no template. That is the code. All of it.
I do not think it is hard to follow at all. Definitely easier than your Lua code. It translates right into the description of what it's doing:
On the page '/said' display the following:
A form containing:
an input box named message
a submit button that goes to the following page when clicked:
a link with text "click me", that goes to following page when clicked:
a text saying "You said #{message}"
The problem you have with it is likely that it seems too simple. You're looking for additional code that isn't there. This way of coding with continuations as in Arc and in my snippet has many problems, including scalability, memory usage and bookmarking urls, but simplicity or understandability isn't one of them.
If it doesn't scale(for some definition of scaling - features, server load, etc.) and you have to rewrite it, it's still essentially hard to follow, because you will have to reconcept the entire system, and presumably stay data-compatible.
Zed simply advocates that you ignore toy systems if they don't give you an in towards writing a real app later.
I disagree. Something can be easy to understand even if it doesn't scale well. Bubblesort is easy to understand, even though it doesn't scale well. If Zed's claim was that it doesn't scale he should (and would) have written that, instead of writing that it's hard to read.
The big problem is you (and Arc and others like it) imply too much historical knowledge in the name of terseness. What happens is when someone has to fix the thing they have to dredge up all the knowledge of where things are rather than finding them right there.
For example: If I have to come and fix the template that has the input form in your code where do I go? Do I edit some code deep inside your framework? Is there a page somewhere? Is it in HTML? Oh it's not? So I have to hire a guy who is a designer and a Lisp or Java or Smalltalk guru? Ok there is a template, so where is it? Is that configured somewhere so I have to one more level of indirection to find the thing that configures the thing that shows the page?
If you back off the tersness a bit, you can then have a piece of code that's still small, but also complete by itself. Anyone coming to my code sample and told, "Fix the damn submit button so it's cornflower blue." Can do it no problem because it says right there what file is being used in what way.
Additionally, I don't buy it with these "yours is 40 lines haha" challenges. Who the hell cares? It's more about the usability and ease of maintenance.