Thanks,

a) Since Jaxer is primarily a server-side technology, it actually can solve many problems for developers that want to target browsers with *no* JavaScript support at all — how is that for degradation? For example, if you detect there’s no client-side JS you could do whatever is needed in server-side JS and send the results to the client. Of course you then have no client-side event handling, and really no callbacks, as you might expect. If JavaScript is available on the client, the client-side part of the Jaxer framework is very small, and is really only used/needed for callbacks.

b) This one deserves at least an FAQ entry but really more of a detailed study and use-cases. We’re working on that now. The scaling story is a lot better than having to mirror all of the browser-user interactions on the server, as in your Opera Mini analogy. Jaxer simply processes the page before it’s served to the browser, then leaves the browser to do its thing without mirroring anything, and only needs to worry about function callbacks. There is no need for, and no resources invested in, maintaining a synchronization between the client and server DOMs, user events, etc.

Hope that helps,
Uri

Also–speaking of great teams, (and to clarify) GI was created by a team — not me as the “original author”. There have been many contributors, but the core most have really been Luke Birdeau and Michael Peachey who were there on day one in 2001 when we sat down at the whiteboard and in the more recent years Jesse Costello Good who added lots of great stuff to Luke’s insightful foundations and helped refine and optimize the concepts further (and did the bulk of the work to get GI running in Safari too). The source says it all @ http://gi.tibco.com.