This summer as a part of the Google Summer of Code program Zain Memon worked on improving the UI for Django's admin, specifically he integrated jQuery for various interface improvements. I am opposed to including jQuery in Django's admin, as far as I know I'm the only one. I should note that on a personal level I love jQuery, however I don't think that means it should be included in Django proper. I'm going to try to explain why I think it's a bad idea and possibly even convince you.
The primary reason I'm opposed is because it lowers the pool of people who can contribute to developing Django's admin. I can hear the shouts from the audience, "jQuery makes Javascript easy, how can it LOWER the pool". By using jQuery we prevent people who know Javascript, but not jQuery from contributing to Django's admin. If we use more "raw" Javascript then anyone who knows jQuery should be able to contribute, as well as anyone who knows Mootools, or Dojo, or just vanilla Javascript. I'm sure there are some people who will say, "but it's possible to use jQuery without knowing Javascript", I submit to you that this is a bad thing and certainly shouldn't be encouraged. We need to look no further than Jacob Kaplan-Moss's talks on Django where he speaks of his concern at job postings that look for Django experience with no mention of Python.
The other reason I'm opposed is because selecting jQuery for the admin gives the impression that Django has a blessed Javascript toolkit. I'm normally one to say, "if people make incorrect inferences that's their own damned problem," however in this case I think they would be 100% correct, Django would have blessed a Javascript toolkit. Once again I can hear the calls, "But, it's in contrib, not Django core", and again I disagree, Django's contrib isn't like other projects' contrib directories that are just a dumping ground for random user contributed scripts and other half working features. Django's contrib is every bit as official as parts of Django that live elsewhere in the source tree. Jacob Kaplan-Moss has described what django.contrib is, no part of that description involves it being less official, quite the opposite in fact.
For these reasons I believe Django's admin should avoid selecting a Javascript toolkit, and instead maintain it's own handrolled code. Though this brings an increase burden on developers I believe it is more important to these philosophies than to take small development wins. People saying this stymies the admin's development should note that Django's admin's UI has changed only minimally over the past years, and only a small fraction of that can be attributed to difficulties in Javascript development.
Subscribe to:
Post Comments (Atom)
So you would rather the Django Admin have custom rolled Javascript that is not vetted nor understood or documented by anyone? This is just a dumb position. The Admin is a contrib, not Django proper. I actually can see many benefits to embracing jQuery in the Admin over the convoluted spaghetti Javascript that is there now.
ReplyDeleteThis just seems a bit silly coming from a framework itself. The whole point is to have people smarter/better than me working on all those finer points, dealing with IE issues/Opera workarounds, and letting me make something that works great.
ReplyDeleteI don't know any web dev that only deals with a single JS library. I know some that don't care for jQuery for all apps, preferring Dojo for larger applications, but I don't know that jQuery is any sort of hurdle for people wanting to contribute.
Yeah, gotta disagree with you here. It has nothing to do with "knowing Javascript" or not. An experienced Dojo/MooTools/YUI coder will be able to work more effectively and easily with clean jQuery code than with Django's homegrown hand-rolled vanilla DOM code. There is just no good reason in 2009 to write JS straight to the DOM APIs; it's basically saying "I like cross-browser bugs and I would like more of them, please."
ReplyDeleteThis is sort of Deuce's point, but that's like saying people who 'know Python' might be put off using Django.
ReplyDeleteI know this is low priority and is considered a tar pit, but blessing jQuery would be a good thing, imho.
You're making a few assumptions here that aren't necessarily valid.
ReplyDelete1) "By using jQuery we prevent people who know Javascript, but not jQuery from contributing to Django's admin."
Just because jQuery is available doesn't stop developers from contributing plain old Javascript code.
2) "If we use more "raw" Javascript then anyone who knows jQuery should be able to contribute, as well as anyone who knows Mootools, or Dojo, or just vanilla Javascript"
It's not just a matter of raw proficiency, though. It's a matter of time and effort. Needlessly making contribution more mundane will only cause a loss of contributors. The reason Django is so popular is because it's *fun* -- I dare you to find me one person who finds plain old Javascript fun.
There is a marked increase in time and effort required for contributing plain old Javascript code, and that time and effort provides no additional benefit. I would argue that by forcing the lowest common denominator, you're actually *reducing* the number of contributors you get.
3) "selecting jQuery for the admin gives the impression that Django has a blessed Javascript toolkit"
This is one of those points where we could go back and forth forever, but in brief, my view is this: if we do not expose jQuery outside the admin, if we do not document how to use jQuery outside the admin, and if we don't even take the smallest steps to make it easier to use jQuery outside the admin, then jQuery is blessed only for the admin. I don't think anyone has an issue with that.
4) "...if people make incorrect inferences that's their own damned problem..."
I refer you to the straw poll I took during our panel at DjangoCon, where only one person in the room made this incorrect inference (hint: his name rhymes with schmalex). ;)
MVC (or MTV in Django's lingo) except in the admin panel. Let's mix html in with our controller.
ReplyDeleteJavascript, but not a vetted library, lets roll our own and Repeat Ourself.
DRY method be damned! Reinvent the wheel.
If the Django admin were being built from scratch today, would you advocate for building it without the help of a JS lib? You'd be laughed out of the room, and rightly so.
ReplyDeletejQuery should be in the Admin. You're plain wrong if you think it should be there without cross platform javascript libraries. It perhaps should be written with a SMALLER cross platoform JS library, but not way in hell should raw JS be the order of the day, raw JS is a nightmare.
ReplyDeleteI don't think this was pointed out yet but jQuery is Javascript, javascript is not jQuery. Your statement that by including jQuery we disclude people who know javascript but not jQuery, makes jQuery = Javascript, in terms of stack level, which they don't. I think that JS developers would love not having to re-invent the wheel.
ReplyDeleteOne last point, if you write JS to progressively enhance, versus gracefully degrade, you could always rip out the jQuery lib, and use your own, without sacrificing usability.
This purist attitude in the open-source world needs to stop. We need to quit bustin' our own balls for no reason.
ReplyDeleteIf you aren't happy with jQuery being in Django proper, fork it. I'd love to see what kind of sacrifice in productivity it takes.
yer wrong.
ReplyDeleteNormally I agree with just about everything you say, I'm practically a fanboy. However, this time I think you're wrong. JQuery isn't blessed, it's legitimately just won the race, those who don't use it are usually only doing so because of legacy momentum, at-least in my experience. Maybe we shouldn't use JavaScript because it makes JavaScript look blessed, or HTML because it makes HTML look blessed. Django can power a text only website, right? Regardless, it makes the experience much better, JQuery it up!
ReplyDeletei found it buggy and 2 orders of magnitude too big
ReplyDeleteTalk about running away from a wolf, and running into a bear. (Trying to avoid using jQuery, and forcing developers to write hand-rolled javascript...)
ReplyDeleteIf we decided to not use jQuery, the django community probably ends up with create its own library, because we don't want an AJAX request to be written differently just because the two have been created by two different contributors.
ReplyDeleteSo we just get another JS lib, probably near of one that already exists, without any of its advantage, but we some draw back, the need to maintain it wasn't the less. Actually, this would reduce the number of contributors as they need to learn the django JS lib.
I add that if someone is not happy with jQuery, it is probably easier to replace than the ORM. But there's people that prefer SQLAchemy over django-ORM, and they are OK with loosing some functionnalities like the whole admin.
The only case I see where there's advantage to not use jQuery would be if we decide to create a JS generator, like GWT or Cappuccino, but based on Python, like Pyjama.
I have to disagree. Forcing anyone to work with the DOM API directly is basicly asking them not to contribute. JavaScript is a very good language, but the DOM is just a pain. I don't think anyone considers working with the standard DOM API now a days, and I don't think Django should reinvent the wheel here.
ReplyDeleteAs for using jQuery, as long is it doesn't prevent people from using other libraries in their admin customizations, I don't think there's any problem with this library over that one.
"By using jQuery we prevent people who know Javascript, but not jQuery from contributing to Django's admin."
ReplyDeleteI would argue that more people are good at using jQuery than just plain old JavaScript. There might be more JavaScript coders but they all wont know how to take into account the huge number of problems that jQuery covers for you.
sounds like reinventing the wheel with custom javascript
ReplyDeleteShort: Did not convince me.
ReplyDeleteHonestly, I won't be able to contribute to anything if it uses raw javascript, but if it's in jQuery, then I can be useful.
ReplyDeletehttp://www.google.com/trends?q=jquery+javascript,+yui+javascript,+prototype+javascript,+dojo+javascript&ctab=0&geo=all&date=all&sort=0
ReplyDeletejQuery is the javascript framework...
I agree with the other commenters. If people are able to contribute using raw JavaScript, they're certainly able to contribute using JQuery. I'm a JQuery guy and I worked recently on a project where Scriptaculous was used. I fired up the documentation, took a look at how things were done in the Scriptaculous world and started contributing. Raw Javascript is always the worst option.
ReplyDeleteAnd I really don't care wrt "blessed". A Javascript library is needed these days. If people decide to use JQuery, great. If MooTools or something else is considered a better fit, so be it.
Javascript frameworks solve most of the problems that we shouldn't need to solve; yet in raw Javascript we are exposed to the nuances of different browsers and DOMs which makes raw Javascript so ugly to use.
ReplyDeletePersonally I don't care which framework we use, but we should use a framework. Personally I prefer JQuery, I think it shares the pragmatism expressed by the value, "for perfectionists with deadlines".
I agree with Carl that having jQuery in the admin in no way blesses it for Django at a whole as it would never appear anywhere outside /admin/. And everyone is free not to use contrib.admin at all.
ReplyDeleteSo if jQuery inclusion could improve the admin interface and/or the devs productivity (which I'd bet on) it definitely gets a "+1" from me.
For a big enough project, like the Django admin, you need a JavaScript library of some kind if you're going to use JavaScript for more than a few simple functions.
ReplyDeleteWhen you consider doing raw JavaScript on a website or application, chances are you will face a number of browser-related or productivity issues, and will cherry-pick valuable scripts from JavaScript experts to build your JS with. Something to help DOM traversing. Something to help with registering events, cross-browser-style. Something to provide a standardized domready event. Something to help with DOM manipulation. Something to facilitate XHR calls.
People with good knowledge of JavaScript will be able to do that. But when you have several contributors, you need to make sure that basic set of scripts holds together, is documented, and will be used by every contributor (rather than each contributor using the helper scripts they're used to). So, your options are: iron out, document and maintain your custom-made library; or use an existing library that is already documented and maintained. The first option sounds like a waste of Django contributors' time; what's more, it could yield sub-par results.
I'm not saying jQuery is the right answer. I think it's a good one, but YUI or Mootools might be better for Django's admin, or maybe a smaller JS library if what that library provides fits the needs.
Anyway, going for raw JavaScript would be an organizational mistake. It's fine when you're the only contributor or the contributors are a small team of people working closely together. It would be wrong here.
The current javascript in the admin is pretty bad. Let's not add more of that. Jquery seems like a reasonable choice for me and, it seems, most others too.
ReplyDelete-1 on the idea of handrolling YAJSAL (yet another JavaScript abstraction library). The numerous points made by the above posters should make this more than clear.
ReplyDeleteYes, I would submit to you that picking a library actually increases the number of people willing (even excited) about contributing to the admin. I'd hazard a guess that there are more people who know javascript and are willing to learn jquery than there are those willing to write cross-browser compliant code in straight javascript. Being a good python programmer does not involve shunning all libraries, and I would argue that the same holds true for javascript programmers. :)
ReplyDeleteI totally disagree. Admin JS is in stale just because of plain JS usage. Nobody is interested to contribute just because it is written in plain JS. This is a fact, I have seen people trying to contribute but stopped just because there's no framework there. I don't care if it uses jQuery or Mootools or Dojo or whatever framework. But there must be a framework for JS.
ReplyDeleteI have mixed feelings on this myself. I think it's a bit bad for Django, however inadvertantly, to "bless" a javascript framework.
ReplyDeleteBut in this particular case, it being just the admin, and not forced or even defaulted in use of the rest of the framework, and the obvious benefits this could provide, I'm for it.
I've got to add my name to the ones who disagree with this post. I respect your opinion and your programming skills, Alex, but in this case I think the advantages of using a Javascript toolkit outweigh the advantages of being toolkit agnostic. I think that jQuery is the most widely used toolkit at this point, but if there's a good reason to select a different toolkit I'd be for it. The point is not that blessing a particular toolkit, the point is taking advantages of the efficiency, security, and usability enhancements that a well designed, well tested toolkit provides.
ReplyDeleteI also disagree with this. jQuery or any other js framework is ok. Just follow the DRY principle and don't re-invent the wheel.
ReplyDeleteYou are very short sighted.
ReplyDeleteThanks. We are just building a business site with django.
ReplyDeleteThanks for your post and django.
So, on the one hand you've got someone who's actually written code to improve the admin (using jQuery) and I might add using mockups that have been sitting around for *years*. He's actively trying to contribute the code and users want it committed so they can use it. On the other hand, there's a mythical pool of people who might someday write some code to improve the admin if Django holds-off on using someone else's library? Of all the parties here, this mythical pool of people is your primary focus?
ReplyDeleteIgnoring that there are 50% more hits for jquery when googling than for django (to say nothing of familiarity with django's javascript), one might actually look at this as an opportunity. People use javascript frameworks and django itself using one in the admin could provide a good body of code for people to read, learn from, and use -- without django explicitly endorsing one or providing barriers to using others.
Agreed with all of the above. Writing cross-browser-compliant JS is actually a really difficult task, and as others have said, if we want to get good cross-browser behavior without using someone else's framework, we end up having to build our own de facto framework, instead, that will be less good than one actually written by people whose core competency is Javascript (there aren't many people better-suited to that task than John Resig...).
ReplyDeleteAlso, I'm extremely skeptical of this: "People saying this stymies the admin's development should note that Django's admin's UI has changed only minimally over the past years, and only a small fraction of that can be attributed to difficulties in Javascript development."
Isn't it possible that it has barely changed precisely because much of the useful functionality people might have wanted to add would have required stronger JS tools than were present in the stack? You also offer no evidence to support your claim that "only a small fraction" of the lack of changes (?) was because of JS, since we have no way of knowing what contributions might have been made had the toolset been there.
You did not convince me. :D
ReplyDeleteI am on Alex's side in saying that no JS library should be included. 90% of the people disagreeing are just caught up in a holy war they believe jQ has won. I'd like to point out that although jQ is popular, it is not technically superior to others. Considering a good chink of Python programmers came from PHP, it's amazing how fast they can connect 'popular' to 'best'.
ReplyDeleteI believe there should only be minimal JS in the admin to foster people to be able expand the admin to their liking. For example, I prefer more inheritance based libraries like Moo. If jQ were integrated, i would not only have to use two different libraries in the admin, but I would also have to tip toe around namespace issues. The admin is not a silver bullet, it should provide the base ability that it already provides and not try to satisfy every niche. In fact I'd go so far as to say there's already too much JS in the admin. We are a python framework.
@joshuajonah I think you misunderstand the nature of the disagreement. I think most people commenting are more anti-writing-your-own-raw-JS than they are pro-jQuery, and that any relatively mature JS toolkit would, in their eyes, be better than none at all. jQuery probably has some advantage in exposing us to potential contributors, but I think MooTools would be a solid option, as well.
ReplyDeleteYour argument regarding including jQuery "shutting out" Javascript developers is extremely unconvincing to me and I expect to most others. It is absolutely not unreasonable to expect people developing Javascript for Django to know a library, either jQuery, some custom Django Javascript library or both. People have to learn a ton of libraries to work on the Python end of Django. It's normal. jQuery is a very compact library. It takes at most a few hours to learn.
ReplyDeleteYour position then hinges on whether using jQuery in the admin amounts to "blessing" a library. I argue that you are correct, it does. I think it's about time, though, and I think jQuery is the right choice, simply because it abstractifies the most arduous and repetitive parts of cross-browser programming, makes searching the DOM simple, is conceptually compact, and most of all plays nice with the rest of Javascript. It takes minimal namespace and does not modify any builtin oject - so developers choosing not to use it can rely on Javascript behaving as they expect.
However, I think there is also merit to the argument that Django should not bless a Javascript library, so I admit you may be right.
But mainstream news sites (e.g., http://www.ctv.ca/news) these days are moving more an more to highly interactive Javascript and AJAX heavy models these days - we risk being left behind by our core market by ignoring advanced frontend behavior integration. Django is itself a collection of libraries to ease back end web site development, and it is hypcritical to say that developers should use only raw Javascript on the front end and expect no overt support from Django. You might as well condemn Django and Python itself and go tell evenyone to code CGI applications in C.
@Andrew Pendleton
ReplyDeleteI was more condemning the fact that we use any JS. I don't feel JS is really required in the admin at all. It will never get complicated if optional add-ons like tabs and datepickers are left up to the user. Hell, the Django datepicker is horrible in the first place.
I would prefer a limited amount of vanilla JS to incorporation a library into the admin, even a light one.
Also I believe anybody who is going to take a crack at developing additions to be merged into Django should have some understanding of javascript, well beyond how to use jQuery. Javascript in my mind is a prerequisite to learning something like jQuery at any level beyond adding l33t jabbascripz to your Wordpress blog. Using vanilla javascript also works as a retard filter.
Saying people shouldn't have to know vanilla javascript to work on Django is like saying people shouldn't have to know vanilla Python to work on Django. I'd hope our development community is a notch above that.
@Stephen DeGrace
ReplyDeleteFollowing that logic, Django should also build a webserver, database, caching system, javascript framework, and browser. Django's core focus is to be really good at one thing. Django can't be everything to everybody. There needs to be a line drawn somewhere.
"I think jQuery is the right choice, simply because it abstractifies the most arduous and repetitive parts of cross-browser programming, makes searching the DOM simple, is conceptually compact, and most of all plays nice with the rest of Javascript."
The problem with this is that I can name 5 other JS libraries that meet that exact specification as well.
The bottom line is that nothing in the admin requires javascript, therefore including a 50kb file for the sake of a datepicker and a couple of other discretionary uses is retarded. This should be left up to the user and the task at hand.
I was going to stay out of this, but twice now I have read in the comments that no JS is needed in the admin.
ReplyDeleteYou obviously have never done any serious sites. The ability to have a livesearch interface for multi-selction of users is a crucial missing piece for the admin. Ever try to find a person in a dropdown of 10K users? Ever try to load an admin page with an FK for that?
mind-boggling....
tl;dr, but I agree, we should use scriptaculous instead of jQuery (I assume that's what you were arguing for).
ReplyDelete"People saying this stymies the admin's development should note that Django's admin's UI has changed only minimally over the past years, and only a small fraction of that can be attributed to difficulties in Javascript development."
ReplyDeleteThe admin is desperately crying out for a face lift and if anybody was to do anything about that then without jQuery a lot of resources will be lost.
One other note for the whingers about jQuery's size: Django currently has something like 90KB of JavaScript plus inline code and all of that can be simplified (sometimes dramatically) by using a javascript library like jQuery - anything with DOM manipulation, AJAX, event handling, etc. requires much less code after the initial investment of loading a perfectly cacheable file.
ReplyDeleteThis process also avoids many bugs: for example, I ran into #6183 awhile back - the author of SelectFilter2.js had to write a ton of tedious, error-prone DOM manipulation code and, not being perfect, got it slightly wrong. Using a framework would have made that code much easier to write and debug *and* would likely have not had the problem in the first place since the good frameworks transparently handle non-obvious issues like element ordering when changing the DOM.
Personally, I like jQuery's style for pure DOM work but with a large project like the Django admin I'd go with either YUI or Dojo since the widgets are immediately and broadly usable (with massive room for expansion/customization) and both frameworks have excellent 508 compliance which is essential for people using Django at large companies, government organizations and generally good karma.
I'm sure someone's about to say: "Wait, you just mentioned 3 libraries!!!" - I'd note that all of them have more core developers, more users, wider testing and - critically - actual documentation and tutorials. For any example, it's much easier for someone who needs to extend Django's admin interface or wishes to contribute changes back to learn how to customize a jQuery, YUI or Dojo widget than the Django admin code and those libraries have clear maintenance policies so you can be confident that public APIs won't break in the next release.
it´s almost there (at least for the grappelli-users):
ReplyDeletehttp://code.google.com/p/django-grappelli/source/browse/#svn/branches/haineault/media/jquery/grappelli/src
@joshuajonah:
ReplyDeleteWell, of the things you've listed, the only one missing or problematic in any way is the javascript framework. Everything else is well covered by other projects, with Django providing good, well-considered integration.
Your options with the admin are to limit it to very simple and unimpressive behavior, or to reinvent the wheel, if you don't want to bless a Javascript library. I would argue that for any behavior-rich content provided as part of Django, that jQuery is ideal, because it doesn't alter built-in objects and can be made to play very nice indeed with the namespace - which means that individuals can use other libraries with more far-reaching effects for their personal customisations if they choose and still avoid conflicts.
One way or another, Django needs to forge ahead and take the increasing user expectation of rich web page behaviors seriously. Javascript framework agnosticism is a worthy principle but should not be a religious conviction.
I thought I would add another anonymous ad hominem attack. You fool! j/k I am a big fan of jQuery but I see your point. I suppose that I would vote for a richer admin that included jQuery. But, I'm torn b/c I respect your opinion on this probably more than I do my own XD.
ReplyDeletePutting jQuery into admin is a good idea.
ReplyDeleteWow, just ... wow. Let's stymy the development of Django so that we don't appear to favor one framework over another?
ReplyDeleteThis comment has been removed by a blog administrator.
ReplyDelete