Mario,

Yes, I can see the distinction between 'in' qp and 'on top of' qp
elements of gz.

The more I understand gz the more comfortable I feel about deciding to
spend time getting to know it. The combination with evoque would be a
great addition.

I think the 'how much will be done in the client vs server' question
will aways exist. For me personally the answer is where do I get the
most productivity for my time. Thus without serverside UI frameworks
(like gizmo(qp) ;-) ) web2 is a productivity no no - client debugging js
etc is just too painful. But for others it might be more about winning
new eyeballs / customers with slick interfaces that have to be delivered
within a browser so a whole lot a js pain is worthwhile. I think the
trick is to have a toolbox that caters for both server driven and client
driven user interfaces. gz shows a way to do that with tight integration
between client executed code and server code all generated from the
serverside code framework. The spec vs Mochikit implementation in gz is
a very good demonstration of this.

I like qp because it is bread-and-butter i.e. nothing frilly. I am
liking gz because it builds on that and provides tools and
implementations that I'd have to address at some point anyway. You are
right though, a qp and evoque combination does solve a lot just by
themselves.

Tristan