XUL thoughts: http://linuxintegrators.com/blog/acoliver/code/?permalink=0131.html
> From: [EMAIL PROTECTED] > Reply-To: "Research Triangle Java User's Group mailing > list."<[EMAIL PROTECTED]> > Date: Wed, 19 May 2004 10:10:55 -0400 > To: [EMAIL PROTECTED], [EMAIL PROTECTED] > Cc: [EMAIL PROTECTED] > Subject: Re: [Juglist] JBoss and Web Client > > 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 _______________________________________________ Juglist mailing list [EMAIL PROTECTED] http://trijug.org/mailman/listinfo/juglist_trijug.org
