And Nokia http://www.s60.com/life/thisiss60/s60indetail/technologiesandfeatures/webruntime
http://www.s60.com/life/thisiss60/s60indetail/technologiesandfeatures/webruntime/webruntimedetail On Sun, Sep 28, 2008 at 7:01 PM, Jörn Zaefferer <[EMAIL PROTECTED]> wrote: > 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] >> >> > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
