> I have successfully used tw.dojo, tw.yui, tw.extjs, tw.jquery, and > tw.mootools with TG2. Nevermind the fact that I authored most of the > above. ;-) I think Jorge hit it on the head, different tools for > different needs. I do find myself leaning more and more in the Dojo > direction. > > Keep in mind also that tw.extjs is locked at extjs release 2.0.x > because of licensing issues. It is licensed under LGPL. dojo, yui, > jquery, and mootools all have permissive licenses. That may or may > not be a consideration, but don't expect to see an updated tw.extjs > from me, I will not GPL my software.
I'd say it's a big mistake if tg doesn't choose an official JS library. The reasons are manifold: 1. Tg is a web application framework (last time I checked) and no serious web application can exist today without client side code. This statement has been formulated in a very provocative way on purpose, what is probably more accurate is that the vast majority of web applications these days contain client side code. And the ratio of the number of web apps that do use client side code to the number of web apps that do not use client side code keeps growing. I'd even say the vast majority of tg users already use client side code and their number will grow. As a result, client side code is a subset of web app code and a web app framework should help users write client side code. A JS library is something that does this, i.e. it is an integral part of a web app framework. I don't see any difference between a templating solution, ORM solution or a JS library from a web app framework point of view. I could have seen a difference 5 years ago but not anymore. In another 5 years time it will seem really silly that a web app framework has no out of the box support for client side code. 2. From a PR point of view nice demos, examples, screencasts are very important. Their effectiveness can be hugely improved by using a fancy JS library and its associated UI components. I'd guess such demos/examples/screencasts will be created to boost tg's popularity, they will attract newbies, they will download tg to find that what they have seen on the demos/examples/screencasts is not available with their download. They will be first confused and frustrated (they were sold on something they didn't get), then they will ask questions on the mailing list, then they will get answers like "there is no blessed JS library, use whatever you want", then they will reply "ok, I don't know which one to use, I'd like the one in the demo" or "ok, I don't know which one to use, can you recommend something?", then they will be given advice of the form "download JS library extension X", which they will do and keep wondering why they didn't get it in the first place. 3. Having no blessed JS library will create more work for the dev team on the mailing list because they will have to answer questions (which will surely come, such questions are already coming!) to this effect. 4. People like to have sane defaults because this eliminates work for them, i.e. the research/evaluation/trial cycle is needed for picking something out of many available options. The dev team is a trusted source the users trust anyway. 5. An official or blessed JS library doesn't limit users in any way, it only adds possibilities. Advanced users can use their favorite JS library, they don't have to stick to the default. Newbies will be happier, advanced users will not care anyway. 6. The tg core code will not be polluted or complicated by an official choice. No code needs to go into the core, in fact, an official JS library choice is more of a communication effort than code writing. Nothing in the core needs to reflect the fact that an official blessed JS library exists. The only thing needed is that when a user downloads tg the official JS library is downloaded too just as sqlalchemy or a templating solution is downloaded, and if the user chooses to download the docs, the included examples will be downloaded too, which will use this JS library. And I think JS examples will be created anyway, the only thing needed is that a common JS library is used for all examples (the official one). There simply needs to be a unified voice, featuring on the tg website and in mailing list postings, that the official JS library is XY. 7. One argument against a default JS library: there is no single best one, different libraries fit different needs. This is true, but not only for JS libraries but for template systems and ORMs too. For example Mako or pyTenjin are very fast so well suited for heavy traffic sites, kid and genshi are slow but have other advantages. The default choice is genshi, a reasonable middle ground. Similarly, sqlalchemy and sqlobject are both good options for their particular target audiences but since a choice has to be made, a reasonable middle ground is sqlalchemy. In a same way, a reasonable middle ground exists among JS libraries one just have to choose it wisely. I'd be interested to hear the arguments against the inclusion of a JS library, I can't see any reasonable such argument, but would be happy to hear your opinions! My main concern is that not choosing a default JS library will negatively impact the success of tg while making a choice will boost its popularity and does not require lot of work since it's mainly a communication effort. Cheers, Daniel -- Psss, psss, put it down! - http://www.cafepress.com/putitdown --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "TurboGears Trunk" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/turbogears-trunk?hl=en -~----------~----~----~----~------~----~------~--~---
