> he has a problem with the concept of frameworks

I'd say it's more of a problem with frameworks as they exist today. I'd like to see a movement to REST API service frameworks with some level of cooperation to get compatibility for standard client libraries.

Everything then gets built around services: from static site generation to single-page apps, third-party developer APIs to admin interfaces. Then you'd have flexibility to replace any piece of the architecture, whether to get better to performance from a service or to use the latest JS single-page app framework.

Jeff Bezos recognized this 10 years ago:

https://plus.google.com/112678702228711889851/posts/eVeouesv...

His Big Mandate went something along these lines:

1) All teams will henceforth expose their data and functionality through service interfaces.

2) Teams must communicate with each other through these interfaces.

3) There will be no other form of interprocess communication allowed: no direct linking, no direct reads of another team's data store, no shared-memory model, no back-doors whatsoever. The only communication allowed is via service interface calls over the network.

4) It doesn't matter what technology they use. HTTP, Corba, Pubsub, custom protocols -- doesn't matter. Bezos doesn't care.

5) All service interfaces, without exception, must be designed from the ground up to be externalizable. That is to say, the team must plan and design to be able to expose the interface to developers in the outside world. No exceptions.

6) Anyone who doesn't do this will be fired.

7) Thank you; have a nice day!

I remember when people thought Bezos was mad for doing this.

Now it has meant that Amazon can transition internal infrastructure into external AWS infrastructure and charge for it.

It really is genius and wouldn't surprise me if this becomes the future of how enterprise companies develop software.

Check out LinkJS. That's the project goal.

https://github.com/pfraze/linkjs

The problem is not frameworks; the problem is object oriented programming. Simply put, OOP lends itself to kitchen-sink frameworks because it is the only way to really share code in OOP. We write these large hierarchy of objects and then, because we have to carefully maintain state, we mark most of it as private, or sealed. Then we give precise instructions on how to consume and use the code, and even more precise instructions on how to extend it.

Well that's strange because Django didn't use much OO either when I used it in the past, only for the ORM.

You must have been using a different framework called "Django" than I did.

Have you used Django much? Some classes you run into frequently (besides Model):

* Form * HttpResponse * All middleware * Template * Etc, it's all classes except if you write function based views

Also this is Python, so you can poke the internals however you like :)

You can, but that doesn't mean you should. It's brittle. If your app or library breaks because a minor update to a dependency changed those internals completely, you can't say you weren't warned.

Who's piling on Django? It has flaws and weaknesses just like anything. It is a huge codebase that tries to be everything for everyone, and it succeeds about being almost everything for almost everyone, which is great.

But it can be very difficult to do relatively simple things with Django sometimes, mostly in the admin pages. Admittedly, this is a pain point people bring on themselves by trying to do too much there, but it's a big red swollen example of how too much interleaving and complexity make it painful or impossible to reason about what's happening.

This got a lot better in 1.4: TemplateResponse and the list filter API meant some gnarly code removal on my biggest customized admin project.

That said, I also chose to implement many of my admin changes at a higher level: templates which use jQuery, etc. and interact with the REST API for e.g. complex object creation are much easier than the crazy form / widget hacks I used to try.

Yeah agreed, I just started writing js apps with backbone and dropping them into wherever in the amdin

I'm about +10 on that approach: customize the admin until you hit a difficult point, then stop trying to hammer screws.

But the only tool I HAVE is a hammer!

I have no problem with criticism of Django, but to write a presentation called "Why Django Sucks" is bombastic, misguided link bait - replete with rage comics and whatnot.

It's just not constructive for the discussion, interesting as it may be.

'replete' with a few Reddit-style comics, of which exactly one could be argued is a Rage comic (though it actually isn't).

It's a long-standing tradition for DjangoCon to have a "Why Django Sucks" presentation. And a healthy one IMHO.

Actually yeah. Great point. I think Django rules for publishing, or building sites where your general technical competition might be Wordpress.

It's frankly an awkward fit for loads of web applications. It seems to me (note: Django guy, not RoR guy) that the Rails stuff has adapted much better to applications that fall well outside of the blog/publishing sphere... but maybe that's a false impression.

I disagree, you can write anything in Django.

I'm currently writing a control panel for libvirt and it's a pleasure to use Django, so many features mean I can concentrate on the problem at hand and not on reinventing the wheel.

Joel didn't write that article.

> I think people who criticize Django have yet to make up their minds about what a framework is all about, and what, if anything, it's for. They just hold on to their utopian idea of what their framework should be.

No, they have a different idea of what a framework should do or not do. Doesn't mean they have some utopian idea just because it's not Django.