> > The problem is: how would Tapestry do that? Not using any framework? > This would mean the committers would need to spend an awful lot of > time rewriting something that Javascript frameworks already do. Not > only this, but also to cope with the insonsistencies between browsers. > Defining an API that could be implemented in Prototype, jQuery or > another framework? More viable, but still a lot of work.
So far, the most complex parts I've seen that need replacing are the onDOMLoaded stuff, the selectors and the AJAX stuff. Everything besides the selectors have been done long before the web-frameworks first implemented them. The selectors (and DOM-traversal) would be the most work to rewrite in plain Javascript, unless Tapestry only uses element ids for lookups, I haven't checked this yet. > Tapestry is not forcing you to use any Javascript framework, just to > use jQuery.noConflict() and jQuery() instead of $() when you want ot > use jQuery. Well, like I said before. It sure feels that way. A lot of Javascript is included into the page (taking up client resources) and you don't want to force an unnessesary download onto your users. In my case I'm only using a fraction of what Prototype offers, but the full set of libraries is included. I learned Prototype just to be able to create Tapestry components that blended in, but eventually I moved back to jQuery, simply because of the enormous amount of great plugins available and to be able to reuse all of the code I wrote earlier. It still doesn't feel right to me to include so many Prototype libraries into the pages when so little of it is being used, especially since Tapestry tries to optimizes everything for performance by default (GZIP compression, javascript at bottom, etc). regards, Onno
