

Why jQuery shouldn't be in the (Django) admin - dannyr
http://lazypython.blogspot.com/2009/11/why-jquery-shouldnt-be-in-admin.html

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

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

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

~~~
Daniel_Newby
"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.

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

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

~~~
mbrubeck
About 25% of all sites crawled by builtwith.com use jQuery:

<http://trends.builtwith.com/javascript/JQuery>

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

------
tkahn6
I don't know if it's acceptable to comment on things like this at HN, but this
article is written terribly.

~~~
weaksauce
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.)

