There is something new to consider when choosing a JavaScript library as Wicket's base: http://www.jondavis.net/blog/post/2008/09/jQuery-Has-Won-The-3-Year-Javascript-Framework-Battle-As-Far-As-Im-Concerned.aspx http://www.hanselman.com/blog/jQuerytoshipwithASPNETMVCandVisualStudio.aspx
Jörn On Wed, Aug 27, 2008 at 1:05 AM, Matej Knopp <[EMAIL PROTECTED]> wrote: > On Wed, Aug 27, 2008 at 12:50 AM, Jörn Zaefferer > <[EMAIL PROTECTED]> wrote: >> On Tue, Aug 26, 2008 at 10:19 PM, Matej Knopp <[EMAIL PROTECTED]> wrote: >>> Hi, >>> >>> On Tue, Aug 26, 2008 at 9:24 PM, jWeekend <[EMAIL PROTECTED]> wrote: >>>> >>>> Matej, >>>> >>>> What are the implications of the decision to "base Wicket Ajax Next >>>> Generation on YUI" in terms of choosing a Javascript library for future >>>> Wicket based web front ends? >>> actually, there really are none. The use of YUI will be more or less >>> internal to Wicket, so you can continue using jQuery, YUI2 or whatever >>> else you are using. Everything in Wicket (and YUI) is namespaced so >>> there are no conflicts. >> >> Of course there is the overhead of including two or more libraries in >> an application, which don't find desirable. > > Wicket uses only part of YUI, the compressed minified required YUI > javascript is about 20kb big. I would understand the concern if I used > dojo or some other behemoth with 200+ kb of compressed javascript. > >> >>>> + there's huge number and variety of jQuery plugins for those special >>>> occasions. >>> Unfortunately the quality of plugins varies. For actual wicket ajax >>> implementation i prefer to stick with the core thing, and that's where >>> YUI definitely beats jquery. I don't say that there are no plugins for >>> jQuery that covers YUI functionality. Question is how well are those >>> plugins supported and maintained. >> >> You are well on the point that the variety of plugins varies. I see it >> this way: jQuery core is small, very stable and the base for >> everything else JS-related. jQuery UI is the official project >> providing the same stability and quality for various high-level UI >> components (like dialogs) and also low-level components (like >> drag&drop, sortables). We'll see at least two major releases this year >> that add more components to the mix. Anything else that isn't covered >> by core or UI is almost always covered by some third-party plugin. >> While these plugin can be of bady quality (eg. no >> documentation/demos), they can still provide a good starting point, so >> that you don't have to start from scratch. Even if you do a full >> rewrite, the existing plugin can expose useful information like >> potential browser-bug-traps. > Problem is that the jQuery core doesn't cut it. And rewriting plugins > from scratch? Are you serious? This is exactly the reason why I > decided to use YUI. The stuff that I need is there, it is supported > and maintained. >> >>> Anyway, as I say, this doesn't make any implication to Wicket users or >>> 3rd party components. The reason why wicket ajax is based on another >>> framework is to get rid of most of the low level browser specific code >>> we have currently so that I wouldn't have to maintain it :) >> >> Whatever the framework, I think its a good idea to start with >> something well supported and tested. Thats why I use Wicket, though >> I'd like it even more with jQuery as the base framework :-) > > At this point, I really don't see any advantage that YUI would give me > over jQuery. > Also it is possible that InMethod grid will be part of Wicket 1.5 > extensions which is another point for using YUI. Rewriting the grid > with jquery would be a huge pain. > > -Matej > >> >> Jörn >> >> PS: Comet support is a nice to have, but I think there a way more >> important things for core than that, eg. annotation-based validation >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
