Why jQuery shouldn't be in the (Django) admin

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...

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.

This is just silly.

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.

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 don't know if it's acceptable to comment on things like this at HN, but this article is written terribly.