Rails and Java EE demonstrate that dependencies on specific implementations are not required to build a framework that offers features.
In Rails, you can rip out ActiveRecord and replace it by an entirely different ORM like DataMapper. There is no real default authentication support, but you can easily plug it in. The list goes on and on: they've done a decent job (I would say 'great', but there are still some improvements needed to make it 'great') at decoupling the various components of Rails and making it easy for users to mix and match.
You need a dependency to offer a certain feature, but not necessarily the default dependency. They have internal API's that decouple the lot. That is exactly what this presentation argues Django doesn't have, but should have.
Now I don't know anything about Django, so I can't judge whether the argument has a factual basis. If you tell me it is wrong, because you can easily replace the persistence or authentication layer of Django, then I have no choice but to believe you. However, the argument is logically consistent and the viability of the alternative it proposes is backed up by plenty of real world examples.
Django is a single python package but is really fairly modular. You can readily use anything in lieu of it's ORM (e.g SQLAlchemy), anything for template rendering (e.g jinja), you're absolutely not forced to use the provided auth component (it's not even enabled by default) nor the admin (but the admin of course only works with django models).
Don't take my word for it, all of this is actually written in multiple places in the docs, tutorials and/or Django site, I can't remember. Here's an excerpt that exemplifies Django's philosophy (from [0]):
> Each view is responsible for doing one of two things: Returning an HttpResponse object containing the content for the requested page, or raising an exception such as Http404. The rest is up to you.
> Your view can read records from a database, or not. It can use a template system such as Django's -- or a third-party Python template system -- or not. It can generate a PDF file, output XML, create a ZIP file on the fly, anything you want, using whatever Python libraries you want.
> All Django wants is that HttpResponse. Or an exception.
> Because it's convenient, let's use Django's own database API, which we covered in Tutorial 1.
Indeed, Django components are incredibly convenient to use, and readily included, and officially supported. But they're completely optional.
"but the admin of course only work with django models"
I think you missed the point. In Rails, ActiveSupport does a whole lot of automatic magic with ActiveRecord. But it is not limited to ActiveRecord, as most of that functionality is factored out into ActiveModel - implement those interfaces and your link helpers and whatnot will happily support nonAR models. I use this quite often to represent things that doesn't reside in a database.
Well, most of the time. There are a few things out there that are not migrated to ActiveModel yet that really should be (the model side of datehelpers in forms comes to mind).
The point I was making was with regard to the article, which goes down on Django because it would supposedly not be barebones enough. I was expliciting that although one does an apparently monolithic (easy_install|pip install) django, one can readily use only the project+url+view part and have something as barebones as Flask in which you could use other components. Additionally you could readily use only Django templates or the Django ORM, and use e.g Flask for the view part (or no view part at all if you're not doing web stuff)
As for the comparison with Rails, faking models is the same in Django, as both leverage duck-typing features of their underlying language. In Django, a model is just a class, and many things are just queried via introspection. Many parts just query model_instance.pk. Additionally populating Model.meta and you even get yourself some deeper model introspection features. To me the true important part of ActiveRecord, ActiveModel and ActiveSupport is rather that you have a set of modules that you can readily include/extend into your fake models to inject complete model behavior, and that is something Django lacks.
You name the example of link helpers, and interestingly this is an example of the difference of philosophy between Rails and Django (see [0]). Django parts are coupled more loosely than Rails parts, a possible rationale being that creating coupling between two distant parts such as URLs and models could enforce constraints on each, thus reducing their potential to independently shine and coercing possible alternatives of each to the provided model. Another example: with Django you explicitly create a request object (whether directly constructed or encapsulated into a helper method) to be returned by the view function while Rails does magic for you in the controller.
Interestingly you bring the problem of forms and this is again an area where Rails and Django differ. Rails wants both form and data to be handled by a single model, whereas Django separates form models and data models. The rationale here is that they are two different problems and that they ought to be solved by two different components (yet they share a great deal of similarity, and code).
FWIW I worked extensively with both (although my current job is in a Ruby shop, I worked with Django at my previous job and since I'm more of a Python guy I keep myself up to date on that front too), and am in no way saying that one is better than the other. Choose what works for you.
> dependencies on specific implementations are not required to build a framework that offers features
I think this is incorrect. You can't offer features without implementations; The feature will never be completely agnostic of its implementation. When you get a really strong shift in the possible implementations (for example: websockets or even long polling, vs rpc) then the feature (for example: dynamic UI), if re-implemented, starts exposing very different semantics and secondary features.
To sum it up: if you implement a thousand ORMs based on SQL db's then they're all going to look the same, implement one thing based on a NoSQL database and you suddenly see how the "feature" of "storing data" suddenly becomes something different from what could be anticipated by the people who designed the original "feature" back in the SQL era.
Let's not lie to ourselves and pretend that features are some wondrous thing poised in thin air above their implementations.
In Rails, you can rip out ActiveRecord and replace it by an entirely different ORM like DataMapper. There is no real default authentication support, but you can easily plug it in. The list goes on and on: they've done a decent job (I would say 'great', but there are still some improvements needed to make it 'great') at decoupling the various components of Rails and making it easy for users to mix and match.
You need a dependency to offer a certain feature, but not necessarily the default dependency. They have internal API's that decouple the lot. That is exactly what this presentation argues Django doesn't have, but should have.
Now I don't know anything about Django, so I can't judge whether the argument has a factual basis. If you tell me it is wrong, because you can easily replace the persistence or authentication layer of Django, then I have no choice but to believe you. However, the argument is logically consistent and the viability of the alternative it proposes is backed up by plenty of real world examples.