36 ms·

Spoelski has a great rant about frameworks and the concept of abstractions ad nauseam: http://discuss.joelonsoftware.com/default.asp?joel.3.219431 http://discus

by kmfrk 14y ago

Spoelski has a great rant about frameworks and the concept of abstractions ad nauseam: http://discuss.joelonsoftware.com/default.asp?joel.3.219431 http://discuss.joelonsoftware.com/default.asp?joel.3.219431. In a way, frameworks are inherently stupid, but who's to decide where between assembly language and x layer abstraction people should work in? 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. Django was created for practical purposes by people who used it in publishing. I think that's a great foundation for a framework - for some people - and piling on it is just a stupid bandwagon. --- EDIT: I found a better way to put this: the author doesn't have a problem with Django; he has a problem with the concept of frameworks.

famousactress 14y ago
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.
- jawr 14y ago
  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.
mattdeboard 14y ago
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.
- acdha 14y ago
  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.
  - mattdeboard 14y ago
    Yeah agreed, I just started writing js apps with backbone and dropping them into wherever in the amdin
    - acdha 14y ago
      I'm about +10 on that approach: customize the admin until you hit a difficult point, then stop trying to hammer screws.
      - mattdeboard 14y ago
        But the only tool I HAVE is a hammer!
- kmfrk 14y ago
  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.
  - Confusion 14y ago
    'replete' with a few Reddit-style comics, of which exactly one could be argued is a Rage comic (though it actually isn't).
  - zeemonkee2 14y ago
    It's a long-standing tradition for DjangoCon to have a "Why Django Sucks" presentation. And a healthy one IMHO.
detst 14y ago
> 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.
- xxpor 14y ago
  Jeff Bezos recognized this 10 years ago: https://plus.google.com/112678702228711889851/posts/eVeouesvaVX 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!
  - taligent 14y ago
    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.
- pfraze 14y ago
  Check out LinkJS. That's the project goal. https://github.com/pfraze/linkjs https://github.com/pfraze/linkjs
MatthewPhillips 14y ago
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.
- UK-AL 14y ago
  Well that's strange because Django didn't use much OO either when I used it in the past, only for the ORM.
  - anthonyb 14y ago
    Also this is Python, so you can poke the internals however you like :)
    - sashahart 14y ago
      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.
  - bad_user 14y ago
    You must have been using a different framework called "Django" than I did.
  - jonknee 14y ago
    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
igorgue 14y ago
Joel didn't write that article.
zeemonkee2 14y ago
> 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.

by kmfrk 14y ago

famousactress 14y ago

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.

jawr 14y ago
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.

mattdeboard 14y ago

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.

acdha 14y ago
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.
- mattdeboard 14y ago
  Yeah agreed, I just started writing js apps with backbone and dropping them into wherever in the amdin
  - acdha 14y ago
    I'm about +10 on that approach: customize the admin until you hit a difficult point, then stop trying to hammer screws.
    - mattdeboard 14y ago
      But the only tool I HAVE is a hammer!
kmfrk 14y ago
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.
- Confusion 14y ago
  'replete' with a few Reddit-style comics, of which exactly one could be argued is a Rage comic (though it actually isn't).
- zeemonkee2 14y ago
  It's a long-standing tradition for DjangoCon to have a "Why Django Sucks" presentation. And a healthy one IMHO.

detst 14y ago

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

xxpor 14y ago
Jeff Bezos recognized this 10 years ago: https://plus.google.com/112678702228711889851/posts/eVeouesvaVX 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!
- taligent 14y ago
  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.
pfraze 14y ago
Check out LinkJS. That's the project goal. https://github.com/pfraze/linkjs https://github.com/pfraze/linkjs

MatthewPhillips 14y ago

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.

UK-AL 14y ago
Well that's strange because Django didn't use much OO either when I used it in the past, only for the ORM.
- anthonyb 14y ago
  Also this is Python, so you can poke the internals however you like :)
  - sashahart 14y ago
    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.
- bad_user 14y ago
  You must have been using a different framework called "Django" than I did.
- jonknee 14y ago
  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

igorgue 14y ago

Joel didn't write that article.

zeemonkee2 14y ago

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