Hi,

> I am really curious about continuation-based web frameworks. Can you
> give us some examples in how this kind of web development can be
> different/better than what is done with a more "standard" framework
> such as Rails ?

Wee does not need continuations to work, which is a good thing because
sometimes they provoke some memory leaks in Ruby, mainly when things
get complex. I really don't know much about continuations myself. I
know that Wee at first used continuations, but since then it has
become only an option, which I'm not wanting to use at the moment. :-)
I suppose that it can make somethings more automatic, which is a good
thing, but Michael has probably created some nice workarounds for Wee
to work without continuations. Great creativity of him and great job.

GUI is generally divided in components/widgets, right? The problem is
that in the web, GUI components happen to exist in the browser
(client), but most of the business logic and state comes from the
server. In a normal web-page, you may have more than a FORM tag. So
when one is submitted, you may lose what has been entered in another
FORM. You may need to handle the BACK browser button. And you may need
to handle the Session, that is the maintenance of the state between
browser requests. Now, imagine arbitrary GUI components that happen to
be in the same web-page. Imagine each component with its own state and
responding to events. That's a lot to imagine, but have no fear,
because Wee is here.

Wee supports the GUI componentization for a web-app. You no longer
need to worry about everything by yourself (mainly about keeping
everything in sync), because Wee can handle a lot by itself. Not only
that, but the HTML generation is nice ruby code, with closures,
blocks, etc. The components will work together in the same page or in
different pages. Unload your work to them, and they will handle it.
You no longer need to worry about URLs, for instance. Just
"call(Component.new)" and it's like going to the next page. Just
"answer" and the previous component takes care.

Most of the layout work should be handled by CSS and JavaScript,
anyway. So the only HTML that's going to be generated by Wee is the
minimum necessary.

A lot of this happens by "magic". Sometimes you need to direct Wee to
do the right thing, because resources are limited so it's better to
share the responsibility of the resource handling with the developer.
For example, when handling the BACK button, I think (maybe because of
the lack of continuation issue.)

Wee has less layers than Rails, so it should be faster when working on
WEBrick. Wee is smaller than Rails, also. And lastly, I needed a
web-framework for some persistence library that I've created, and it
seems that Wee is a perfect match for it, so I couldn't be happier.
:-) In the future I might release it, but it's not an O/R mapper so
Og, which is an O/R mapper, already fills this role.

This is my unofficial description of what I've gathered of Wee at the
moment. It may be even better than this. It may become even better. It
has a bright future, that's for sure.

Rails is great also.

Cheers,
Joao