One hot topic that keeps coming up over and over again on the Django mailing lists and in IRC has to do with when Django will get “AJAX support”. There are two answers to that question; one can be stated with authority, and the other consists entirely of my own unofficial and non-binding opinion. Let’s start with the first:
Doing AJAX with Django has always been pretty easy, though maybe in a way that’s not obvious to users of other frameworks. All you have to do is use a slightly different template — to return XML- or JSON-formatted data instead of HTML — and you’re golden.
This has gotten quite a bit easier in the past week, thanks to the first draft of a new module: django.core.serialization. In essence, the serialization system is designed to make it easy to translate Django model instances into various other formats. Serializers for XML, JSON and simple Python are now included in Django, so you could now do this in a view:
from django.core import serializers def my_json_view(request): data = serializers.serialize("json", MyModel.objects.all()[:5]) return HttpResponse(data, mimetype="application/javascript")
And voilà: you have a view which returns the latest five objects from a model in JSON format. Perfect for AJAX requests. You could even have the same view respond to both “normal” and AJAX requests by adding a parameter to the URL and changing output types based on that.
The same idea can easily be applied to most of the common operations people want to use AJAX for; comment posting, for example, could be handled by firing an XMLHttpRequest to a view which would save the comment and return it serialized in the format of your choice.
Jacob and I have also tossed around ideas for a Django “web services” API which would let you make calls from JavaScript or any other language to create, retrieve, update or delete arbitrary objects; the new serialization framework would make it extremely easy to have this output in any format you like, and would provide a powerful way for you to do pretty much anything you like via AJAX.
And now it’s time for me to step up on my soapbox and issue a big fat disclaimer: the following represents nothing more than my own opinion, and has no necessary bearing on what will actually end up happening in Django. This is just what I think, and doesn’t attempt to speak for anyone or anything else, and what I have to say on this topic is inflammatory and is almost certainly going to make some people angry. Read on with that in mind, and at your own risk.
So. You may have noticed that the above example dealt only with the server side of things, and left out the business of actually constructing and firing off an XMLHttpRequest. That’s as it should be, because — and I know this is heresy — I think people should actually write JavaScript instead of relying on a framework to handle it for them.
Yes, I know that Rails and TurboGears and all the other guys have those nifty “helpers” where you tell the framework what effect you want and it drops in the correct JavaScript for you. But something like that would be a really bad idea for Django.
Besides thinking people should write JavaScript when they need JavaScript, there are a couple of reasons why I feel that way: offering built-in systems for automatically doing XMLHttpRequests and other effects would tie Django to a particular JavaScript toolkit, which I think would be an awful idea. Or else it would require us to maintain code in the framework for all of the popular JS toolkits, which would be an even worse idea. It would also mean getting opinionated and telling people how they should develop, which is an absolutely terrible idea.
But the big, overriding reason is still this: it’s high time that a lot of so-called “web developers” out there finally grow the hell up and learn how to write JavaScript.
Whenever people start talking about how they’d like Django to offer the kinds of “JavaScript helpers” you find in other frameworks, they inevitably fall back to a single line of reasoning: “why should I learn JavaScript and deal with all those DOM quirks and other incompatibilities when all I want is this simple effect?”
My tried-and-true response to that has always been to ask why, if we buy that reasoning, a web framework should expect them to learn CSS just to float a sidebar on the left side of the page, or learn HTML just to put in a list of links. HTML and CSS have just as many quirks and incompatibilities across browsers, and can take just as much time to master, as JavaScript; why, then, should we expect web developers to have to learn any of them? Shouldn’t the framework just automatically generate all the client-side code?
Of course, that’s a ludicrous thing to suggest. HTML and CSS are foundational technologies of the Web, and no-one is suggesting that web developers shouldn’t have to know them. In fact, a “web developer” who didn’t know HTML and CSS has no right to the title.
But here’s the thing: JavaScript is just as foundational as HTML and CSS. Now, granted, when I first got into this business JavaScript was something of a red-headed stepchild; 99% of all the JavaScript deployed on the public Web was devoted to making images change when you rolled your mouse over them, and the other 1% was written by scary people who called it “DHTML”.
But now… now it’s 2006, and we’re slowly realizing that those “DHTML” guys were really onto something. The rich interaction possibilities opened up by JavaScript are being recognized for what they are, and have even spawned a whole raft of new buzzwords and new toolkits. And even though it was always technically that way, we’re coming around to see (or, in some cases, being dragged kicking and screaming into seeing) that the Web really is based on three technologies: HTML for structure, CSS for style and JavaScript for behavior and interaction.
Which means that here and now, in 2006, if you call yourself a “web developer” you have absolutely no excuse for not knowing JavaScript. And if you don’t know JavaScript, you have absolutely no right to call yourself a “web developer”.
Yes, JavaScript takes time and effort to master. And yes, there are still lots of inconsistencies in how the major browsers deal with advanced JavaScript. But HTML and CSS take time and effort to master. And advanced HTML and CSS are still rendered inconsistently in the major browsers. And, just as in HTML and CSS, it’s possible to write JavaScript which works around the inconsistencies. And, just as in HTML and CSS, smart people have already written that code and made it available online, for free.
So, once again: you have absolutely no excuse for not knowing JavaScript.
Of course, once you’ve learned JavaScript you should feel free to use toolkits like Dojo, MochiKit and Prototype; they provide tons of useful code for dealing with common situations and for smoothing out the wrinkles in the various browser implementations. That’s pretty much what libraries are for, and you should take all the advantage of them you can.
But, and here’s the thing, when you use those libraries to write JavaScript you should actually use those libraries to write JavaScript. Using a “helper” from your framework to call the appropriate code for you is like using a motorized wheelchair because you’re too lazy to walk. And, just as people who actually are walking will get places faster than you will in your powerchair, people who actually write JavaScript are going to leave people who rely on “helpers” in the dust.
So, to get back to the actual topic at hand:
Any questions?
Comments for this entry are closed. If you'd like to share your thoughts on this entry with me, please contact me directly.
It would be awesome if you can point some good docs/books about javascript: The internet have a lot of crap about this
Very good article!!!
Do you recall how much it took to learn to walk? And now you want us to do that again? ;-P
No, thanks, i think I’ll wait until Python replaces Javascript in the browser.
No, seriously. It’s already on its way for XUL scripting in Mozilla:
Brendan Eich Discusses Python for XUL Scripting
and Brett Cannon is working on the main target:
Doc for new restricted execution design for Python
In the meantime, there’s nothing wrong with getting a little help from our friend Mochikit (thanks Bob!).
I’ve been waiting for someone more experienced with web development to stand up and say this!
I recently had to breakdown and learn javascript (and HTML and CSS), and found MochiKit made it incredibly easy. It gave me a more Pythonic way of doing things, and it already took into account the known browser inconsistencies.
In the end, learning enough javascript to get the job done wasn’t very hard at all.
While I agree with your position on AJAX in Django (I don’t believe Django should be championing a particular JS toolkit by providing built-in hooks to it’s AjAX and effects methods, I don’t know if I really agree with this:
It seems to me that as the web gets older, the disciplines within it get more and more specialized. Back when I first got into the web (early 90s), there was this concept of a “webmaster.” The “webmaster” was the person who took care of an organization’s website — from top to bottom. The did server administration, CGI scripting (usually with Perl), visual design, markup, and everything in between.
But that model is long since dead — and for good reason. Web development has gotten more complex, and it not requires some degree of specialization. You happen to be someone who can do the top-down thing pretty well, and that’s great. But that’s unusual, and I don’t think people should be expected to do that. The term “web developer” can potentially cover a lot of disciplines: server-side programming, client-side programming, flash, HTML/CSS, graphic design, usability/accessibility, interaction design, etc. To state that an expert in any one of these fields is not worthy of being called a “web developer” because they’re not an expert in all of them is pretty harsh, I think.
I don’t want to learn Javascript because I consider it to be outside the scope of my particular specialization on the web. Oh sure, I know bits and pieces of Javascript and I can wrangle one of the popular frameworks into doing what I want — but I don’t really know Javascript. But what I do know, I know really well, and I think being a great specialist is just as valuable as being a jack of all trades.
Sorry for the slight tangent. Nice post. :)
Douglas: by far the best reference anywhere of any sort is the Rhino book. It treats JavaScript the way JavaScript should be treated, which is to say as a programming language that happens to have an API for working with web pages.
Nicola: that way lies the Google Web Toolkit. And the results won’t be pretty. Nonetheless, it’s already being ported to Python.
Jeff: learning JavaScript won’t kill you, you know :)
And though there certainly are increasing degrees of specialization in our industry, I still think there’s a responsibility to know all three layers of the Web’s front end; even if you never use it and someone else is going to come along and add it later, knowing JavaScript will help you make better decisions at every step of the design and development process.
Non-compatible HTML or CSS won’t “break” your site like javascript might. That’s what I’m constantly worried about when writing javascript.
You don’t work much in Internet Explorer, do you?
;)
I agree with that. I think that everyone has a responsibility to understand, at least conceptually, all of the layers of a web document — but that’s a bit different than learning javascript. I want to understand how javascript works and how it interacts with the DOM so that I can properly communicate with DOM scripters. I want to understand how Python works, since that’s the sever-side language we use for my job. But I don’t feel like I need to learn both of them. I just need to understand how they fit together with the parts of the document I deal with more specifically.
That is absolutely fantastic news about django.core.serialization. Up until know I have been writing my own object to json serialization by hand. This will save a lot of work.
I also cannot wait to see what becomes of the Django “web services” api. I think that is something that will really be a killer feature for Django.
On a side note. Please keep up the great posts about the latest news from the newsgroup. I am sure many people, like myself, find them very userfull, since they don’t always read the newsgroup.
Thanks again.
I fully agree with a broader view of not tying django to a particular js toolkit. Also the new serializers are quite handy (just looked at them after this post!).
One particular instance where it would be great to get more “integrated” js into django is on the admin. It already does useful things like populating slug fields and opening a new window for many to many fields object-creation. Right now, having models order by an arbitrary field works well, but interface wise it sucks. An useful feature, would be drag and drop ordering of models on the list view. This one is though to hack on, because not only you must add more js to the admin(easy) but you must also hook up with the backend (to save the new order after dragging). That itself raises a full set of questions: would the order save be automatic after drag? or would there be a “save order” button on top after the user is done “reordering”. Also , the model would have to have an additional field (to store it’s order).
maybe something inside the admin inner class: class Admin: … draggable_order = ‘field_name’ # the name of an IntegerField responsible for keeping order information.
Are there any plans to accommodate such use case (or maybe am I the only one to find this very useful)?
Thanks, arthur
Arthur: I’d wonder at the logic for that use case; how often do you really need to rearrange the order in which the applications are listed on the index page?
Also, you can already change that in a couple of ways (by overriding the template — and Django will spit out the HTML it’s using for easy editing — or by changing the order of applications in
INSTALLED_APPSand/or the order of model definitions in the models file).@Douglas:
You can find very good introductions here:
http://www.crockford.com/javascript/survey.html
and here:
http://simon.incutio.com/slides/2006/etech/javascript/js-reintroduction-notes.htm
Don’t quote me on this, but I’m pretty sure Wilson Miner, who is the designer responsible for the Django admin interface, has plans to further Javascript-ify it. Of course, he just moved across the country and started a new job, so hard telling when he’ll get to it — but I do think it’s on his to-do list at some point.
James: Since this never comes up on the mailing list I suppose it’s pretty much a special case. But, at any rate I can see a few situations where arbitrary ordering is useful. a) a photo gallery app. maybe ordering by date / title is not as meaningful. b) in a bookmark list app (ala del.icio.us. ), I created “sets”, pages of bookmarks, and it was useful to allow an arbitrary order. c) a portfolio app. sometimes you would like to list your works not by client name neither on chronological order. These are three real life examples I’ve encountered so far. I guess that as you move away from cms like apps (blogs, newspapers) it makes more sense to allow users to order their own content (django already allows that, it’s just that drag and drop in the admin would make the interface more elegant). cheers arthur
I don’t fully understand the point of this article (apart looking as somewhat a rant for God knows whom).
It looks like: “hmmm let’s found a good reason to trash competitors which include built-in Javascript capabilities which Django does not and even say it would be a bad idea to do so because.. er.. Javascript is a given nowadays, isn’t it?”
Well SQL is as well and yet Django provides its own wheelchair… hmm sorry… ORM.
I really have the feeling that each time I read an article about Django it’s to learn that “Django is the best and even when Django is missing something, well it’s done on purpose and is actually better than the rest”. Tiring.
Yeah people should learn Javascript but as the rest of the crowd said here, do we have to comprehensively know a language before doing anything with it? Do you?
Here is a good excuse for not knowing Javascript:
If you use any Javascript at all, you can fall fowl of the WCAG accessibility standards if you are not careful to ensure it works in the absence of Javascript. Furthermore, many ‘AJAX-y’ usages of Javascript (such as dynamically updating parts of the page) almost certainly don’t comply with WCAG recommendations, so you are still in trouble even if the user has javascript enabled, but is partially sighted for instance. If you care about accessibility, either because you actually care or because you are being paid to care, or are forced by law to care (e.g. lots of public bodies in the UK), then you will probably avoid Javascript to a very large degree. There are plenty of articles about this, I won’t repeat them.
But I just wanted to point out that knowing Javascript is not at all mandatory for lots of web development. You can create perfectly usuable web sites without it.
Personally, I would say that having a solid grasp of HTTP is more important — lots of web developers don’t have a clue.
Sylvain: you just go ahead and think whatever you want; ORM is a very different thing from “you don’t need to knwo SQL”, even though too many people use it that way.
And again, my beef here is with people who say “I don’t want to learn JavaScript, I’d rather have some automated template tag do it for me”, which is entirely too common a position these days; even if you don’t become a JavaScript expert, you should know how the language works and, at the very least, how to use a good library or two in order to get the effects you want. Asking, as so many do, that someone else hide JavaScript from you completely in the form of a “helper” is lazy and childish.
Luke: no, that’s not an excuse. If you use any HTML and CSS at all, you can also fall afoul of accessibility guidelines very easily; does that mean people shouldn’t use HTML and CSS, or rather does it mean that they should spend more time learning their craft?
And I think knowledge of JavaScript is going to get more and more unavoidable as time goes by; the AJAX genie isn’t going to get put back in the bottle, so now’s the time to learn how to do things right.
Agreed. That being said, I don’t think I’ve seen any framework hiding completely Javascript from the developer either. Yeah some people are childish and they want everything and their money back, but then your article is not clear you were aiming at lazy people.
If I look at TurboGears, they don’t hide JS from the developer, do they? They might offer helper but at the end of the day you still need to understand Javascript itself.
I don’t understand how SQL/ORM is any different from Javascript/Frameworks-that-do-it-all since in both cases the goal is to hide as much as possible the underlying details and provide a smooth interface for the developer.
I think you are right overall but the way you put things are somewhat unclear to me.
If you’re causing JavaScript to be added to a page without actually writing JavaScript or a
scripttag, then your framework is hiding it from you and that ain’t cool.ORM is a bit different because, while people do use ORM systems to avoid writing SQL (and that’s just as bad as hiding from JavaScript), ORM itself is not about avoiding SQL; it’s about giving persistence to the objects of an OO programming language by translating between the classes and objects of your code and the tables and rows of a relational database. In other words, ORM is primarily a means of taking a code object and storing it, then retrieving it later as a code object with the same attributes.
Kudos, as ever, James. A great article, especially the serialization. I agree with what you’ve said, though I’m likely one of the web developers you’re talking about who only knows enough Javascript to get by.
To Jeff, what you’re describing sounds more like the role of a web designer to me, as opposed to a web developer. I am definitely am not trying to cut you down, and your site is a testament to your skills as a designer and a developer. But to do just HTML/CSS results in static pages and one of the tennets, in my mind, of a developer is interactivity.
Thanks again, all. Wonderful read, both the post and the comments.
@Jeff…
Actually, the design foundation for the new AJAXy admin widgets is mostly done. I don’t know where Jacob is on implementing them—I know there are some unsolved problems—but this new serialization framework looks like progress.
Once that first foundation stuff is in I’ve got lots of ideas for even more fancypants bits and widgets.
Wilson, don’t forget that the Dojo-fication of the admin is pretty much done, too (though it hasn’t been committed); from the front-end side it’ll be pretty easy for me to add new widgets as we need them.
Absolutely. I consider myself to be a web designer, and not really a web developer. Although I do occasionally play with web development (i.e. programming) on personal projects, my job is that of a designer.
So I presume, then, that you agree with me that it’s not really within the scope of my job to be a Javascript expert. It is, I believe, in the scope of my job to understand how Javascript works, and probably to be able to read it and tweak other people’s code to some degree. I just don’t think I need to be able to write complex scripts from scratch, and it sounds like you agree with me.
James doesn’t. He and I talked about it yesterday, and he definitely believes that it is my job to know Javascript inside and out. And that’s okay. We can agree to disagree. No big deal. :)
Jeff, we did talk about this yesterday :), but someone who doesn’t know Ja
And I do think you should know JavaScript. I’m not asking that everyone get up to the level of Dean Edwards or Douglas Crockford, but you should know your way around in the language. As you well know, it doesn’t take expert-level JavaScript knowledge to pick up Prototype or MochiKit or one of the popular libraries and build interesting effects with it; that’s the level of knowledge I think is appropriate as a baseline.
Serializer needs filter.
Currently the serializer returns: [{“pk”: “1”, “model”: “map.location”, “fields”: {“lat”: 44.94141, “lng”: -123.034286, “tag”: “Salem”}}, {“pk”: “2”, “model”: “map.location”, “fields”: {“lat”: 44.052219, “lng”: -123.086548, “tag”: “Eugene”}}]
I need it to return: [{“pk”: “1”, “fields”: {“lat”: 44.94141, “lng”: -123.034286}}, {“pk”: “2”, “fields”: {“lat”: 44.052219, “lng”: -123.086548}}]
Also, why include the model at all?
It seems to me that if it is included, it doesn’t need to be in each record returned. Is it possible to have different models in one serialization?
A filtration mechanism would be very helpful here.
I tried your example. I found that “mime_type” should be “mimetype”. I also agree with Chappie that some sort of filter would be great. However, I guess that could be done when retrieving the data.
Thanks for the example.
Thanks to MochiKit, I’ve started using JavaScript quite a bit in my web apps. However I have to take the opposing view here: JavaScript is nowhere near as core as CSS, which in turn is not as core as HTML. Besides the fact that many browsers can do neither JavaScript nor CSS, you can accomplish the same things with pure HTML that you can with HTML+CSS+JavaScript, but the reverse isn’t true. By “accomplish” I’m not referring to fading effects, pretty layout etc. I’m talking about the actual core functions of the application. In fact if your application can’t function without JavaScript, then I’d argue you have no right to call yourself a “web developer”. I expect millions of blind people will agree with me.
Cliff, no-one’s saying that people should run out and make stuff that doesn’t work without JavaScript, or stuff that isn’t accessible. I take accessibility extremely personally (I’m colorblind and my eyesight is otherwise rather horrible), so if someone does build something that’s got major accessibility problems I’ll happily beat them upside the head with my trusty cluestick.
But at the same time, the progressive enhancement of user experience provided by JavaScript is becoming an absolute 100% necessity for web applications. And as a result, knowing JavaScript is becoming an absolute 100% necessity for web developers.
James,
I think for a certain class of application you are correct. I think what I take umbrage with is the blanket statement you’ve cast out that in order to be a “web developer” you must know JavaScript. I think there are places where JavaScript is appropriate and places where it isn’t. JavaScript is an enhancement, not a core feature. I think there is plenty of room on the web for developers who prefer not to do client-side scripting, and I’d judge them on how well they do what they set out to do rather than on whether or not they’ve embraced the technology of the day.
I certainly consider it wise to use JavaScript where it will enhance the user experience, but at the same time I’d much rather see web developers focus on core concerns such as scalability, security, accessiblity, etc, and then consider where things like JavaScript might create an improved user experience.
Cliff,
You can’t enhance if you don’t know how the enhancement works. And even if you’re not developing the next GMail, there are tons of useful enhancements JavaScript can provide without getting in the way of anything else (live searches, immediate form validation, comment posting via XMLHttpRequest — I could go on all day). And professional web developers need to know how to do those things, which means they do need to know JavaScript.
James, Thanks for the info on serialization - I had no idea that was in there. Very useful.
Also, mime_type should be mimetype to get the example to work.
Tone
I think James’ point is well taken, in the same sense that if you’ve never programmed in C or in assembly, you’ll never really understand pointers and memory allocation in a fundamental way, etc. (Think “Java 90-day wonders”-style programmers.)
I whole heartedly agree. The only time I used the helpers in Rails was to quickly prototype stuff and I ALWAYS ended up going back and stripping it out. I’ve got OCD when it comes to behavior and structure separation, plus its just freakin easier to read!
In that case, maybe we don’t really disagree at all. I also think that’s a pretty appropriate level of Javascript knowledge for my job — and, as you know, I’m pretty capable of getting Prototype to do what I want. :)
Hmm… Like Jeff, I’m not really buying this argument. “Web Developer” is a broad title, one that get’s more ill-defined as the web matures. It’s hard to hang the necessity of any skill on this position—it’s quite dependent on the needs of the project at hand, as well as the skills of the rest of the team.
Of course, learning JavaScript will make anyone involved in the web more useful—but the real question is, who should learn it? In my opinion, it’s a skill that the programmer should bear—since, as you said, JavaScript should be considered a true programming language.
Claiming that a web developer (who I take, in your agruement, to be a “xhtml/css designer-developer”) must ‘learn’ JavaScript is a akin to a web developer demanding all programmers learn how to anchor classes and ids semantically, never allow programmatic output (even user inputed data) to break an XHTML document’s validity, and obey all XHTML tag conventions perfectly (i.e. list for lists, tables for tables, definition lists, etc). Oh yeah, and document their code cleanly, especially when it appears in a template that non-programmers must edit. In a perfect world, both programmers and developers/designers would know each other’s skills much better.
I respect your desire to keep JS libraries out of Django. However, I don’t think that choice necessitates a claim that ‘more people should learn js’… My 2 cents.
Matt, “developers should learn JavaScript” is one of the reasons for not integrating lots of JavaScript helpers into Django, not the other way around.
One of my co-workers this morning made the point in a fairly succinct way: if you’re a web shop, you absolutely have to have a JavaScript guy, just as you absolutely have to have an HTML+CSS guy. Maybe they’re the same guy.
And if you’re a one-man shop, they are the same guy. Time to learn it.
Also, “web programmers” who don’t know both HTML and good HTML practices have some learning to do, too. And if they’re the ones who get to learn JavaScript, then they sure as hell better know good HTML practices because they’re going to be fiddling with the DOM.
I’m just learning Django,it’s a good article:) I’m from China and I want to make friends with you!
Django should encourage the use of a JavaScript library the same way Django encourages the use of a certain templating system, O-R mapping layer, and url dispatching system.
AND… Django’s admin system should use this library.
AND… the library is Dojo :) (I thought this had been decided already.)
Well, those are my opinions, anyways. We need to move forward on a common platform, or we’ll forever be behind Ruby on Rails. Sorry guys.
I’d much, much rather get things right than do something just to “get ahead of Rails”. So that’s a useless argument with me.
I completely and wholeheartedly agree with this post. It makes me especially happy to hear this viewpoint from someone on the inside of a framework. I think a framework that writes JavaScript for you is one layer of abstraction too many.
To the web developers who claim it is not their job to know JavaScript: that’s fine as long as you never need to use JavaScript. If you stick to design, HTML, and CSS, everything’s cool.
But if you find yourself needing to use JavaScript, it is completely unacceptable to go looking for some “helper” to do it for you. Either pass the work on to someone who knows how to do it, or learn how to do it yourself.
Poop or get off the pot.
you should code in machine codes, and do not rely on any wheelchairs be they called python, ruby, or java. p.s. I know how to code JavaScript.
I think the most important statement that James is trying to make here is that it is a framework’s responsibility to make programmers learn JavaScript. Sure it is possible to add javascript helper functions to Django, and yes that would speed up initial development times and reduce bugs since Python is usually more terse than JS… even for expert JS programmers. But speed, utility, and bug quantity are sacrificed because there are people out there that do not know JavaScript and James feels like Django should police those people. Essentially, James is arguing that Django needs to be dumbed down, to reduce the features and utility of the framework, because the beginner programmers need a smackdown.
So I am sorry to the professionals amongst us, the ones who know JavaScript very well, but would simply rather spend their time in more fruitful ways and let the framework do a little extra work for them. To those professionals, my condolences, but Django will not provide for you, will not help you, because James is more interested in teaching a lesson to the people who never bothered to work as hard as you and learn JS.
Lucas, I’m amazed that you can stretch far enough to put all those words in James’s mouth from all the way up there on your high horse. ;-)
Let’s count the number of things Lucas claims which have no basis whatsoever in anything I’ve said:
Except, well, I didn’t say that. In fact, I said pretty much the opposite when I stated that “opinionated” isn’t a good thing for a framework to be.
Strike one.
I’m so terribly sorry that I wasn’t able to accomodate your worldview by saying anything even remotely close to that.
Strike two.
That’s one hell of a stretch, dude. You’re not just pulling things out of your ass, you’re reaching way up the GI tract and yanking it out your duodenum or something.
Strike three, and he’s out!
How is this different than the “SQL Helpers” that Django provides?
article.get_object(name__exact=’foo’)
translates to
SELECT * FROM articles WHERE name = “foo”
Isn’t this lazy and childish as well? Wouldn’t a more pure framework, one that doesn’t cater to children or the lazy, force you to get objects by SQL using a find_by_sql function?
I don’t understand why there isn’t a middle ground here, sort of like using Javascript helpers, but being able to drop into javascript when needed (Sound familiar?)
I also disagree with this statement:
I write Django and RoR code at my current job and never touch HTML, CSS or Javascript. I understand the basics of these languages, but am not an expert in them (I couldn’t write my own ajax, for example). Does this mean I am not a web developer? Teams (especially as large as the one I work on) need specialists, and I am one. I proudly call myself a web developer.
See here. ORM’s purpose, even though people may use it for that, is not to hide SQL from you, and people who do use it to avoid SQL are going to find that there are lots of useful things they can’t do.
Mostly because there already are helpers for JavaScript. They go by names like Dojo, Prototype, and so on. Why do some people find it unbearably hard to learn them?
Personally? I think that everyone on the team should have a baseline level of knowledge of the various technologies involved. Specialization is one thing; ignorance is something else entirely.
I agree with this 100%. When I set about integrating “AJAX” into my django apps, this is the approach I took. All you need to do is return the json objects using the framework. Everything else is done in your templates. You don’t need any helpers on the python/django side— the rest of the fancy stuff is all JavaScript. If you want to use a toolkit like dojo, then go ahead.. but otherwise you’ve hit the nail on the head for what counts as django’s support for AJAX.
Why can’t they make javascript tags that , in your words describing ORM, don’t hide javascript from you? I know that with these tags, there are many useful things I will not be able to do. However, they are a good start and help me turn over a barebones functional template (view, actually, in RoR) to a designer for polish.
Honestly, Javascript is a terrible, inconsistent language and I feel dirty after writing code in it. I get much more satisfaction dropping a RoR Ajax tag on a page than having our Javascript guy spend an hour writing the same function.
Joseph, if it takes your “JavaScript” guy an hour to write a trivial function, you need a new JavaScript guy.
It’s really not a bad language.
James, I think we may have to agree to disagree. Javascript is the only programming language I know of that the same function does different things in different environments. I laugh every time I hear our designer say he had to write a function twice, once for IE and once for Firefox.
I really am interested in your detailed opinion on the difference between “sql helpers” and javascript helpers. Why are these so different?
Just to clarify, I don’t consider these helpers a part of the ORM. I think the ORM strictly relates to taking a query’s results and making objects out of it, and also trivial details like saving and deleting.
Sounds like it’s time for your designer to pick up a toolkit that abstracts away the browser differences.
A moment ago you certainly seemed to be impying that ORM was a “SQL helper” intended to hide SQL from the developer. Django doesn’t offer any “SQL helpers”, so I’m not sure what exactly you’re asking about here.
What’s so hard about learning Javascript?
Why avoid learning it when obviously your skills as a web “developer” would improve?
Why avoid learning it if you would be able to produce better web sites by doing so?
Never mind whatever “standards” you might break, or if someone says that you are not a real web developer if you don’t know it. This is either just an excuse or bullying. Frankly, you should just learn it because it will benefit you. It’s not rocket science. That you refuse means you are just lazy or stupid.