> thread when I first came to Django. In hindsight, it was pure > inability to write the javascript myself, and reluctance to properly > learn javascript. In the end I've seen that writing javascript > manually results in much cleaner html output, using less code and it > sometimes just performs better. On top of that, switching to another > javascript has no effect whatsoever on your python/django code.
The pure inability to write JavaScript argument is no trivial matter. JavaScript for all of it's toy-like qualities can be maddeningly complex and frustrating. This is an open source project and many of the people who develop django apps share their work. It's a beautiful thing. I've learned more poking around people's code then I have from <insert method here>... That's why, IMO, it's good to have a standardized javascript library (if not necessarily official). People want to write and share apps. And sharing them with a community that knows what to do with them only makes them more powerful. If people shared their AJAX integrated code I'm sure it would save me _lots_ of time. Both in figuring out how to do things and drop-in code. So here's what it would probably mean to me: * Official Documentation - This is the first place I look for how to do things. * Open source apps that I read to learn how to do things/Cookbook pages for all sorts of wacky stuff * Drop in apps that extend functionality and make my site more useful * Not having to chose a damn library myself (I use mochikit, but I feel like it's dying on the vine) * A chance to co-opt a JavaScript community/not lose a JavaScript community to some other project * A good marketing opportunity - just being able to put a check mark next to AJAX integration, however meaningless is useful. Those who ignore marketing do so at their own detriment. * More cool apps written in django. Hey, the apps sell the framework. * Share knowledge! I guess my point boils down to tools create possibilities. Possibilities are impossible to fully articulate ahead of time. I think I've thrown out some decent ones, but there are doubtless many more. The point is that people learn, use, and adapt things in ways that aren't always canonized. By embracing a tool, say a hammer, you're not just going to hammer nails. You're going to carry around a hammer and if something comes up that I can use my hammer for, you're going to use it. The django developers have the ability to control the debate by picking a library. The fact that they don't want to may be perfectly valid. (I haven't read any of the pro and con other than this thread.) But that doesn't mean the community can't rally around a particular project. The fact of the matter is that de facto standards often bubble up to become official standards. This is the risk that the django devs run by not picking the library; one will be picked for them. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Django users" 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/django-users?hl=en -~----------~----~----~----~------~----~------~--~---
