Rails is certainly not the be-all and end-all of web design. Lately it seems to be the 'cool' thing to bash Rails, but I'm not sure that that's warranted either. It seems to be a backlash against all the hype that Rails has generated along the way.
Time will tell whether or not Rails will become a piece of timeless software or if it will simply fall to the wayside.
Until then, go forth and write great software!
Ezra Z has made Merb, a lighter and arguably cleaner version of core Rails (minus AR, etc), if you're bugged by Rails core code.
One of the big advantages of statelessness is that it scales wonderfully. REST aligns itself with HTTP very nicely. Continuations are a clever compromise between highly stateful applications and stateless HTTP.
Ajax and Flex turn your browser into a smart client of sorts, and I think that a RESTful service design can stand independent of any particular client. It allows for many different clients to interact with your service besides just your particular Ajax web page. In that sense continuations would be perfectly suitable in those situations where you need to keep track of state. RESTful services need to stand independent of a particular client front end.
Anyway, I think that those principles are complementary and should work well together. Ajax (or some other rich client technology) on the front end and REST on the back.
Hmm. I think I may try my hand at writing a small web framework in Lua... that's been kicking around in my head lately.
Could you shed a little light on why you feel that way?
If you are building an Ajax/Flex rich client, particularly one that can work offline, you'd want the state on the client-side. Then you could view the server in a very RESTful way while handling program flow in your client app. Under these circumstances, there's less of a win with continuations.
Among the advantages in imposing a RESTful architecture on your server, the most interesting to me is the way that your server becomes a bunch of resources on which you can do a very limited set of things (the HTTP verbs). It imposes an easily understood interface, which is nice if you (or others) write other apps to access your server.
This premise is wrong, so I almost TLDR'd the post immediately. I decided to skim further, though:
"And to stress the first point again, Rails never concerns itself with the big-picture problem of 'writing webapps.' It only thinks as big as 'outputting HTML strings' and 'querying the DB for a list of things.'"
This is provably false. The average reader of the intro chapter of most Rails books could tell you that, for example, Rails enforces high-level application design patterns like Model-View-Controller, thus exposing his statement as factually untrue. The guy seems to have languages like PHP (or, charitably, Ruby) confused with the Rails framework. Nice try by the OP, but ultimately an unconvincing troll.