Given that I sponsored Tapestry into the ASF and I work for JBoss, do you really have to ask? ;-)
Marc is talking about more "Richer Client" and I think I'll be talking to him about XUL which is awesome BTW. Microsoft is even planning to fork XUL with their own dialect. While I don't speak for Marc, I think I got what he was saying: The idea at JBoss is to "reduce the number of remote calls for performance" this is "duh" to anyone worth their salt, yet the browser->Appserver combo actually maximizes the number of remote calls. So basically the standard web app. I go to a page, I enter some data, I hit submit... Wait.... Slow..... Zzzzz.... Compare to the old days. VB might be loading stuff in the background had M$ gotten the threading model right (apartment threading..bah). The user wasn't necessarily exposed to the request/response (command pattern) model of the web. In short HTML/HTTP is a drag. Tapestry is AWESOME for HTML/HTTP. It removes a great deal of the suck, but it is still a kludge around the HTML/HTTP model. We need to move the non-critical session back where it belongs, on the client. History of Computing (abridged): Lets do everything on big mainframes (thin client) Oh no, lets do everything on the client (fat client) Oh no, lets do everything on web servers (thin client - HTML was VT100 for the 90s) predictive: Oh crap, that sucks too...maybe we should put some of that back on the client (fatter than thin client) but still do the business logic on the server. All that said, we DID make progress. Fat client was an improvement over the mainframe (no offense Greg) and far cheaper (go CP/M->OS/2->Windows!). The web did allow richer thin clients than originally (HTML looks much nicer than ANSI art and VT100) and had better tech surrounding it. That being said, it has many of the disadvantages of mainframe computing (spikes, centralization of processing, etc). Now we need a better compromise between what we had with VB/Powerbuilder/etc and what we have with the web. Is your session really something that belongs on the server? Is it business logic? Is it OUR data or YOUR data.. Its time to rethink web-computing. I don't think Tapestry has to die under this model, but evolve to use more than HTML. JSF has a minor advantage in this area, but at what cost? With EJB3 simplifying and removing XML configuration/meta data do I really want to maximize it on the front end? In the age of Eclipse and the post-boom do I really want to go back to 3-5k per seat tools above massive abstractions that leak? Its time to standardize on simplistic programming models, not build large cathedrals on complex ones. The foundation of JSF is shaky, EJB 1-2.x proved that. The idea might be nice but the implementation...well go look at that and tell me if you really want to meta-code that way. -Andy > From: "David Moran" <[EMAIL PROTECTED]> > Reply-To: "Research Triangle Java User's Group mailing > list."<[EMAIL PROTECTED]> > Date: Wed, 19 May 2004 08:39:44 -0400 > To: "Research Triangle Java User's Group mailing list." <[EMAIL PROTECTED]> > Subject: [Juglist] JBoss and Web Client > > What was the web client that Marc Fleury said the other night that JBoss was > looking to work with and does anyone know if they considered Tapestry? > > > _______________________________________________ > Juglist mailing list > [EMAIL PROTECTED] > http://trijug.org/mailman/listinfo/juglist_trijug.org _______________________________________________ Juglist mailing list [EMAIL PROTECTED] http://trijug.org/mailman/listinfo/juglist_trijug.org
