So what is the intersection of the sets "people that want to work on Django's Javascript" and "Javascript programmers that are unable to learn jQuery but could pick up an in-house Javascript framework"?
My guess is that it's the empty set. If you can pick up arbitrary custom Javascript, you can probably pick up jQuery pretty quickly, too. Even I know jQuery...
The author also assumes that more developers know the raw DOM API than know jQuery. I think that very few developers know enough to write efficient, portable client-side code using DOM calls directly. In my experience working with tons of different web developers, it's a lot faster for any developer (veteran or brand new) to learn and use a good framework like jQuery than to try to write cross-browser code without it.
If you want to write raw javascript against the metal and want it to be in any kind of usable state, the person writing it would have to be very familiar with cross-platform issues and quirks in various browsers and be able to route around them. In other words, they would have to, by defintion, be good enough to implement their own javascript framework.
Saying that using a framework which already handles this and is popular, standardized and free (as in speech) will increase the barrier for contribution is just plain misguided.
So, keeping in mind that what I say here is my own personal opinion, my own and no-one else's, and that I speak for myself and not any other person or entity...
I'm kinda on the fence about contrib.admin bundling/using jQuery, but not for any of the reasons in this article. For me it comes down entirely to compatibility.
At my day job I work with the oldest Django codebase in the world, and also one of the largest. We do pretty much everything it's possible to do with Django, including some fairly heavy custom admin stuff. Quite a bit of that involves JavaScript.
At the moment, we have code actively using the current bundled admin JS, two different public JS frameworks and one private internal JS framework. This is the result of years of dev work making use of whatever tools we happened to be using at the moment, and all of it still works today; we even have areas where multiple JS frameworks are in use side-by-side on the same page along with reuse of the standard admin JS.
I simply don't know what happens to all that code if suddenly the admin is jQuery. I don't know off the top of my head all the possible intersections of libraries and frameworks and how much code would need to be rewritten as a result. And I really don't want to think about whether people who use, say, MooTools for their own customizations would suddenly get the rug pulled out from under them (if Django's bundled jQuery and your bundled MooTools each want to bind '$', who wins?).
If the admin's going to move to using jQuery, these are the sorts of questions which need to be thought out, planned for and answered very, very thoroughly first.
"if Django's bundled jQuery and your bundled MooTools each want to bind '$', who wins?"
Yep. There needs to be a migration plan:
1. Announce that jQuery will temporarily use '$djq' (Django's jQuery) for jQuery starting in a few months. Don't let anything using '$' be committed during the migration period.
2. Immediately add JavaScript code to the bottom of every admin page that checks for the existence of '$djq'. If it is present, put a big flashing warning message on the page that says "Your Django admin page may break soon. Have your sysadmin look at this page [link goes here]."
3. The poor fools using '$djq' get a short chance to migrate their code. Probably nobody is using it anyway.
4. Start using '$djq'. You don't want to do this forever because it will confuse all the novices reading the jQuery tutorials and books.
5. Announce that the Django admin will switch to '$' for jQuery at the Django 1.1.0 release. (Or 1.2.0 if 1.1.0 is too soon.) '$djq' will be permanently left as an alias for '$', for compatibility with local admin code written during the migration period.
6. Put JavaScript code at the bottom of each admin page that checks if '$' is not jQuery and puts a giant blinking warning at the bottom of the admin page. Have a settings.py option to turn off the warning once the sysadmins learn what is going on. If somebody turns it off and doesn't develop a migration plan, that's their fault.
7. Shortly before 1.1.0, put in a new flashing warning that can't be turned off.
8. Substitute '$' for '$djq' for the pre-1.1.0 releases.
jQuery has simply won the Javascript framework marketplace in dramatic and dominating fashion. I don't remember the numbers, but some really high percentage of web sites now use it. Mootools, Dojo, and all other competitors are more on the fringe every month. People with all of the arcane knowledge needed to make complex DOM manipulation work perfectly across all browsers (including IE6) were rare to begin with, and now with jQuery at the level of maturity and support it has, and with performance issues improving, it seems almost silly for anyone aquire this knowledge and attempt to use pure JavaScript alone (especially since it's a highly flawed language to begin with.)
1) why would the inclusion of jquery preclude developers from contributing with their own raw javascript? seems like adding jquery would only add value, without removing it.
2) kind of seems ironic that someone thinks that django, a development framework, should be against using a development framework because of the nature of frameworks.
I think calling it an article is a bit over the top in terms of giving too much credibility. It really is just a blog post of one guys opinion.(Not that that is bad, it just is.)
My guess is that it's the empty set. If you can pick up arbitrary custom Javascript, you can probably pick up jQuery pretty quickly, too. Even I know jQuery...