Johan, We have been "shopping" for components recently and also worried about JavaScript/DOM bloat. The wicket-datetime jar uses YUI (Yahoo I think) and we decided not to use it as we were not sure we wanted to commit to YUI.
We have customers in Africa using our servers in the UK. Since their bandwidth may be very poor reducing the amount they have to download is important. It may be fine once cached but it is hard to get past that initial impression that because the browser is downloading two or three libraries on first use it seems slow. Sales team are keen on this for demos! Almost a bigger worry for me was trying to debug obscure issues when more than one library has started messing with the DOM... I'm a bit fussy about jar bloat (used Alfresco recently!) but JS library bloat is obviously more of a performance issue. At least we don't have to worry about logging APIs ;) Johan Compagner wrote: > > Purely visual javascript libs don't have anything to do with wicket. > Thats just dhtml/javascript programming. > Especially as you said that you also want to bind those events on the > clientside > What should wicket do then with those libs? (besides maybe serving them) > > johan > > > On 9/5/07, bmarvell <[EMAIL PROTECTED]> wrote: >> >> >> This is true but as you're actively checking JavaScript framework bits in >> I >> thought I'd ask if you have any plans to pick one framework and stick >> with >> it. >> >> I've already spotted some YUI bits and now animation.js is going in it >> just >> feels a little scattered... >> >> Especially when the animations and other common widgets are all available >> through one framework be it YUI, jQuery or Prototype... >> >> I can see the need for wickets custom Ajax stuff so maybe there should be >> a >> real push to use another framework for all the widget/visual >> representation. >> >> Then my users wont need to download wicket-ajax + YUI + animation.js when >> I >> wanna have a fading calendar that does ajax calls ;) >> >> Ben. >> >> >> >> Matej Knopp-2 wrote: >> > >> > Well, you can use whatever Ajax/javascript framework you want. >> > Wicket-ajax should work with all major js frameworks. It's not really >> > meant to be used outside wicket, as we don't guarantee api stability >> > of wicket-ajax (but that doesn't mean you can't use it though). >> > >> > We try to keep the footprint as low as possible, so that it gives you >> > minimum overhead if you want to use a custom framework too. >> > >> > -Matej >> > >> > On 9/5/07, bmarvell <[EMAIL PROTECTED]> wrote: >> >> >> >> Agreed hence why I said I was coining the _business_ term. >> >> >> >> >> >> Johan Compagner wrote: >> >> > >> >> > stupid thing is that all those slides and fades and fancy ui things >> are >> >> > not >> >> > really ajax.. >> >> > thats just JavaScript/DHTML >> >> > >> >> > johan >> >> > >> >> > >> >> > On 9/5/07, bmarvell <[EMAIL PROTECTED]> wrote: >> >> >> >> >> >> >> >> >> Sorry if this has been asked several times but it I didn't easily >> find >> >> it >> >> >> from a search. >> >> >> >> >> >> Fair enough about the actual "Ajax" functionality if specific code >> is >> >> >> required fair enough. >> >> >> >> >> >> I was using the term Ajax in a very business sense ie: full stack >> >> >> functionality; slides, fades etc. >> >> >> >> >> >> So for those specific issues are we to say: >> >> >> >> >> >> >> >> >> >> >> >> http://martijndashorst.com/blog/2007/04/16/javascript-animation-libraries-compared/ >> >> >> >> >> >> Is the future?? >> >> >> >> >> >> >> >> >> Matej Knopp-2 wrote: >> >> >> > >> >> >> > Hi, >> >> >> > >> >> >> > this question has been asked here numerous times. The thing is, >> >> there >> >> >> > is in fact no real alternative of wicket-ajax for us. >> >> >> > >> >> >> > Wicket is not built about Ajax widgets.Wicket is about >> server-side >> >> >> > components that can be partially updated using Ajax. That's a >> >> >> > fundamental difference. >> >> >> > >> >> >> > As for the features, wicket-ajax has numerous advanced features >> such >> >> as >> >> >> > - asynchronous pipeline that allows loading dependencies in >> >> >> > asynchronous way, yet respecting the order (unlike e.g. dojo >> where >> >> the >> >> >> > depending javascript are loaded using synchronous http requests >> >> which >> >> >> > block entire browser = usability disaster) >> >> >> > - ajax channels that allow you to stack or drop pending requests >> >> >> > - multipart ajax response for replacing multiple components in >> one >> >> >> > response, ajax header contribution processing (so that component >> can >> >> >> > render header response as it would normally do, wicket >> transparently >> >> >> > processes it and loads all dependencies (javascript references, >> >> >> > stylesheets, etc) in an asynchronous way while respecting the >> order) >> >> >> > - wicket-ajax.js is about 7kb compressed (with stripped down >> >> >> > comments). As this is a general purpose ajax framework, the size >> >> >> > matters. For sites where you using ajax only on certain places, >> >> having >> >> >> > a 200kb javascript dependency would be quite a burden >> >> >> > - there's more to it, the code is quite well documented, if you >> are >> >> >> > interested you can dig into it, also you should search achives, >> this >> >> >> > has been discussed here already. >> >> >> > >> >> >> > -Matej >> >> >> > >> >> >> > >> >> >> > On 9/5/07, bmarvell <[EMAIL PROTECTED]> wrote: >> >> >> >> >> >> >> >> Hello all, >> >> >> >> >> >> >> >> This is my first post so please be gentle ;) >> >> >> >> >> >> >> >> I'm a user interface developer (no Java) working on what will >> >> >> inevitably >> >> >> >> be >> >> >> >> a fairly heavy Ajax wicket project. After looking at a number of >> >> Ajax >> >> >> >> examples and pre built widgets I have to say I'm a little >> puzzled! >> >> Why >> >> >> >> does >> >> >> >> wickets core JS framework not use one of the main JS frameworks >> >> that >> >> >> are >> >> >> >> available such as jQuery, Dojo or Prototype? I believe you have >> a >> >> hand >> >> >> >> rolled version of mootools (although I may be wrong). Do the >> Wicket >> >> >> core >> >> >> >> team plan on supporting and enriching this hand rolled framework >> >> >> alone? >> >> >> >> Surely it would make more sense to choose one of the main JS >> >> >> frameworks >> >> >> >> that >> >> >> >> have dedicated teams of devs supporting it? >> >> >> >> >> >> >> >> Also I've found that Ajax widgets in wicket seem quite "here and >> >> >> there" >> >> >> >> in >> >> >> >> their implementation. Some demos use prototype, some use YUI (a >> >> >> >> datepicker >> >> >> >> for example). Doesnt this go against what JS frameworks are >> trying >> >> to >> >> >> >> provide? Choosing a decent framework such as jQuery or Prototype >> >> will >> >> >> >> give >> >> >> >> the developer a solid toolkit on which they can build, so extra >> >> >> >> components >> >> >> >> such as datepickers or custom widgets can be applied as >> "Plugins". >> >> >> >> Sticking >> >> >> >> to one framework reduces hits to the server, bandwidth, load and >> >> >> >> processing >> >> >> >> times all of which imho are good things. >> >> >> >> >> >> >> >> My worry at the moment is that the demos in wicket are very >> "lets >> >> get >> >> >> it >> >> >> >> working on the frontend" and not "lets think about a framework >> and >> >> its >> >> >> >> rich >> >> >> >> functionality". >> >> >> >> >> >> >> >> SO to summarize :) are there any thoughts about using a single, >> >> >> supported >> >> >> >> framework in wicket and moving forward from there? >> >> >> >> >> >> >> >> Cheers, >> >> >> >> >> >> >> >> Ben >> >> >> >> -- >> >> >> >> View this message in context: >> >> >> >> >> >> http://www.nabble.com/JavaScript-Frameworks-tf4383060.html#a12494810 >> >> >> >> Sent from the Wicket - User mailing list archive at Nabble.com. >> >> >> >> >> >> >> >> >> >> >> >> >> >> --------------------------------------------------------------------- >> >> >> >> 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] >> >> >> > >> >> >> > >> >> >> > >> >> >> >> >> >> -- >> >> >> View this message in context: >> >> >> >> http://www.nabble.com/JavaScript-Frameworks-tf4383060.html#a12495715 >> >> >> Sent from the Wicket - User mailing list archive at Nabble.com. >> >> >> >> >> >> >> >> >> >> --------------------------------------------------------------------- >> >> >> To unsubscribe, e-mail: [EMAIL PROTECTED] >> >> >> For additional commands, e-mail: [EMAIL PROTECTED] >> >> >> >> >> >> >> >> > >> >> > >> >> >> >> -- >> >> View this message in context: >> >> http://www.nabble.com/JavaScript-Frameworks-tf4383060.html#a12496187 >> >> Sent from the Wicket - User mailing list archive at Nabble.com. >> >> >> >> >> >> --------------------------------------------------------------------- >> >> 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] >> > >> > >> > >> >> -- >> View this message in context: >> http://www.nabble.com/JavaScript-Frameworks-tf4383060.html#a12496872 >> Sent from the Wicket - User mailing list archive at Nabble.com. >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [EMAIL PROTECTED] >> For additional commands, e-mail: [EMAIL PROTECTED] >> >> > > -- View this message in context: http://www.nabble.com/JavaScript-Frameworks-tf4383060.html#a12497476 Sent from the Wicket - User mailing list archive at Nabble.com. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
