Sure, using a document wide event catcher is probably sure to be faster than the per-element gwt default.
The point I was making was: Why split it into the Static / Read-only / Read-Write / Full featured for different clients? (as per the overview section). Surely a hybrid model that _always_ does fast server side rendering, and then a light(er) GWT frontend that can catch the events in the rendered content (eg. through rendered 'onclick' events in the statically rendered content) would be the solution in all cases? What's the advantage of offering multiple different ways of rendering, except to make it easy to support low-end devices (eg. phones), and ignore certain browsers (eg. IE7) and why do that when the Data API already allows people to cater for this, as shown by the read-only mobile apps we already have using the Data API? ~ Doug. On Oct 22, 3:43 pm, David Hearnden <[email protected]> wrote: > On Oct 20, 1:03 pm, dougx <[email protected]> wrote: > > > > > > > I like the idea of a backend that can dynamically scale functionality > > from server side rendering to client side rendering based on the > > computing device, but I wonder if its the correct approach. > > > Given that it's much easier to write back-end systems that deliver > > static HTML that work on all browsers than to write rich frontend > > systems that are dynamic and interactive, surely choosing this path > > dooms the gwt front end to a dubious future where open source > > contributors work on the easier server side rendering code, make it > > look great, and the js frontend lags in functionality and is > > eventually dropped. > > > Then, on top of that look at the front ends people have already made > > using the data api; basically server side rendered apps. > > > I know there's a goal to make WIAB a generic product that runs on > > everything and so on, and things like the WebSocket support make IE > > support a real hassle, but................ why not just make the data > > api top notch and leave people to write other front ends for it using > > that, and focus of delivering a wave.google.com like experience in > > WIAB? > > The Undercurrent design is not intended to diminish the richness of > behaviour in a web client. It's more about expressing that same rich > behaviour in a style that can leverage the superior processing > capabilities of servers, in order to deliver a more responsive UI. > > One of the goals was that writing a feature in Undercurrent's style > would be no harder than writing it in a typical GWT style; that is, > the design is there to enable things (server-side rendering and staged > delivery of code), rather than restricting capabilities. For core > editing features, the Undercurrent wave panel's rich interactive > behaviour is equivalent (but faster) than the Google Wave panel, and > more features are coming. Stay tuned. > > -David -- You received this message because you are subscribed to the Google Groups "Wave Protocol" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/wave-protocol?hl=en.
