10 ms·

Wonderful! I just want to extend a heartfelt "thank you" to all the guys and gals contributing to Django. Django is still a cornerstone of our startup and we'r

by bryanh 14y ago

Wonderful! I just want to extend a heartfelt "thank you" to all the guys and gals contributing to Django. Django is still a cornerstone of our startup and we're way past the point where folks have traditionally said "Django starts to constraint you". We've found that to be untrue. We love the templating, the ORM and all the built-in tools (not to mention 100s of libraries that get you an 80% finished feature in 5% of the time). I hope to meet a lot of you at Pycon, I'd be happy to buy you a beer. I'll be wearing the bright orange Zapier shirt, you can't miss me. :-)

cookiecaper 14y ago
I wonder if perhaps your people just don't have much exposure, because the templating in Django is awful compared to Mako/Jinja2, the ORM in Django is awful compared SQLAlchemy, and most of the useful features of Django are easily available in Pyramid or Flask, yet these systems are unobtrusive and simple. Django has a monstrous "middleware" piece and a bunch of other cruft that is really just bothersome dead weight. It's not that there's no use for it, it's just that similar things are accomplished in much more concise, fast ways in other frameworks. Not to hate on Django, jacobian, or the LJ-World, I appreciate the effort put into the system. But I don't think it really has much to offer in present-day for people developing new, serious platforms. I feel the same way about most other "full-fledged" MVC frameworks, because they all seem to far exceed what ought to be the logical bounds of their influence. In many cases you feel like you're writing Django, Cake, or Rails and not writing the actual language based on, because these frameworks mandate so much and require special integration to do much of anything. In something like Pyramid, you write Python, and Pyramid provides the pieces that make it easy to bundle together and publish as a website. I've had positive experiences with Sinatra, too. "Microframeworks" and close cousins like Pyramid are really much more appropriate dev platforms, imo: modular, unpretentious, exist simply to help you get your program onto the web in a fast, concise, and simple way, without attempting to inject a rewrite of the standard lib or force you to conform to their unique flavor of MVC, their crappy ORM, etc.
- tonyblundell 14y ago
  The full-fledged-ness, mandates and influence that you complain about are actually plus-points for some.
- run4yourlives 14y ago
  Every time I find myself in another platform, working away, there is always a point where I stop and say to myself - I wouldn't be doing this if I was using Django. That's why I use Django.
- acdha 14y ago
  > I wonder if perhaps your people just don't have much exposure Having used and rejected each of the things you mentioned for various reasons, I think you're making the common mistake of assuming that other people have the same challenges and preferences you do. It's particularly pointless to do this in a project release announcement thread – if it really doesn't work for you, just skip over it rather than flaming.
- metaphorm 14y ago
  the only thing I agree with in your entire post is criticism of the django template language. its a pretty bad system that encourages sloppy work arounds. jinja would be nice. fortunately the template system is one of the easier things in django to swap out. i think you're wrong about the ORM. django's ORM is actually really good, its just that the api is optimized for different use cases than SQLAlchemy. django ORM does a better job of simplifying the most common queries. its worse at complex queries. thats a reasonable trade off and i think you go way too far when you say its "awful".
- mattdennewitz 14y ago
  i think you are more opinionated than django
  - cookiecaper 14y ago
    Really not a fan of this terminology, popularized by DHH/37S. The term "opinionated design" is basically an excuse to make a rigid, unadaptable behemoth, because it's easier to just say "if you don't like it, you don't have to use it" than to address some of the problems. There is a balance, of course, and you can't spend all your time abstracting out to support the most transformative, irregular use case, but something like mixing ORMs or templating languages is actually a great example. Look at Pyramid v. Django/the others. A web framework should simply be about piping your program's I/O to the web. Templating and ORM shouldn't even be in scope. Having reasonable defaults is fine, but claiming it's OK to tightly couple your general-use web framework with user-facing unrelated libraries as hard dependencies (i.e., forcing users to use a certain ORM/templater) because it's "opinionated design" is silly. It's simply bad design.
zalew 14y ago
> we're way past the point where folks have traditionally said "Django starts to constraint you". We've found that to be untrue. We love the templating, the ORM Well, that means you are not past that point. First you learn to love your tools, then you learn to hate them, and it's ok. It's not really that hard to reach the point where the orm pisses you off (examples: https://speakerdeck.com/alex/why-i-hate-the-django-orm https://speakerdeck.com/alex/why-i-hate-the-django-orm by core dev, there is a talk somewhere on pyvideo.org), especially if you have actually written some complex sql queries in your life.
- Daishiman 14y ago
  Honestly, it's more of a 98/2 case for most business systems. Writing complex SQL for that 2% hasn't bothered me particularly thus far. And for simple (and not so simple) joins, the syntax is lighter than SQLAlchemy. I'm not saying the critique is bad, it's just that in practice it's not something you'll be noticing day to day, and if you are, switching to pure SQL or SQLAlchemy is not a bad alternative (and Django makes that very easy to do).
  - zalew 14y ago
    Sure, I'm currently doing a project with SqlAlchemy in Django (I went pure SqlA in there, but there is Aldjemy if anyone wants to just occasionally extend their query capabilities on top of Django's objects). There is no doubt Django orm is easy for most web crud cases, but also you have to admit that many queries that are trivial to write in pure sql take some weird gymnastics to implement using the orm (Q, F, extra, mapping raw_sql - yuk) - that's what I meant by 'pisses you off'.
    - dirtyaura 14y ago
      Yes, and there is a cognitive overhead to think SQL queries both in Django ORM syntax and SQL and when should I switch between ORM syntax and raw_sql, when should I implement custom manager etc. Our codebase is an enterprise app and it has maybe a ratio of 50/50 between complex queries and straightforward single table selects or simple joins. I much prefer SQLAlchemy Core: I can think a complex query in SQL, try it in sql shell and implement it in SQLAlchemy Core so that the resulting code resembles the actual query. This resemblance also helps a lot of when you do performance optimizations.

by bryanh 14y ago

cookiecaper 14y ago

I wonder if perhaps your people just don't have much exposure, because the templating in Django is awful compared to Mako/Jinja2, the ORM in Django is awful compared SQLAlchemy, and most of the useful features of Django are easily available in Pyramid or Flask, yet these systems are unobtrusive and simple. Django has a monstrous "middleware" piece and a bunch of other cruft that is really just bothersome dead weight. It's not that there's no use for it, it's just that similar things are accomplished in much more concise, fast ways in other frameworks. Not to hate on Django, jacobian, or the LJ-World, I appreciate the effort put into the system. But I don't think it really has much to offer in present-day for people developing new, serious platforms. I feel the same way about most other "full-fledged" MVC frameworks, because they all seem to far exceed what ought to be the logical bounds of their influence. In many cases you feel like you're writing Django, Cake, or Rails and not writing the actual language based on, because these frameworks mandate so much and require special integration to do much of anything. In something like Pyramid, you write Python, and Pyramid provides the pieces that make it easy to bundle together and publish as a website. I've had positive experiences with Sinatra, too. "Microframeworks" and close cousins like Pyramid are really much more appropriate dev platforms, imo: modular, unpretentious, exist simply to help you get your program onto the web in a fast, concise, and simple way, without attempting to inject a rewrite of the standard lib or force you to conform to their unique flavor of MVC, their crappy ORM, etc.

tonyblundell 14y ago
The full-fledged-ness, mandates and influence that you complain about are actually plus-points for some.
run4yourlives 14y ago
Every time I find myself in another platform, working away, there is always a point where I stop and say to myself - I wouldn't be doing this if I was using Django. That's why I use Django.
acdha 14y ago
> I wonder if perhaps your people just don't have much exposure Having used and rejected each of the things you mentioned for various reasons, I think you're making the common mistake of assuming that other people have the same challenges and preferences you do. It's particularly pointless to do this in a project release announcement thread – if it really doesn't work for you, just skip over it rather than flaming.
metaphorm 14y ago
the only thing I agree with in your entire post is criticism of the django template language. its a pretty bad system that encourages sloppy work arounds. jinja would be nice. fortunately the template system is one of the easier things in django to swap out. i think you're wrong about the ORM. django's ORM is actually really good, its just that the api is optimized for different use cases than SQLAlchemy. django ORM does a better job of simplifying the most common queries. its worse at complex queries. thats a reasonable trade off and i think you go way too far when you say its "awful".
mattdennewitz 14y ago
i think you are more opinionated than django
- cookiecaper 14y ago
  Really not a fan of this terminology, popularized by DHH/37S. The term "opinionated design" is basically an excuse to make a rigid, unadaptable behemoth, because it's easier to just say "if you don't like it, you don't have to use it" than to address some of the problems. There is a balance, of course, and you can't spend all your time abstracting out to support the most transformative, irregular use case, but something like mixing ORMs or templating languages is actually a great example. Look at Pyramid v. Django/the others. A web framework should simply be about piping your program's I/O to the web. Templating and ORM shouldn't even be in scope. Having reasonable defaults is fine, but claiming it's OK to tightly couple your general-use web framework with user-facing unrelated libraries as hard dependencies (i.e., forcing users to use a certain ORM/templater) because it's "opinionated design" is silly. It's simply bad design.

zalew 14y ago

> we're way past the point where folks have traditionally said "Django starts to constraint you". We've found that to be untrue. We love the templating, the ORM Well, that means you are not past that point. First you learn to love your tools, then you learn to hate them, and it's ok. It's not really that hard to reach the point where the orm pisses you off (examples: https://speakerdeck.com/alex/why-i-hate-the-django-orm https://speakerdeck.com/alex/why-i-hate-the-django-orm by core dev, there is a talk somewhere on pyvideo.org), especially if you have actually written some complex sql queries in your life.

Daishiman 14y ago
Honestly, it's more of a 98/2 case for most business systems. Writing complex SQL for that 2% hasn't bothered me particularly thus far. And for simple (and not so simple) joins, the syntax is lighter than SQLAlchemy. I'm not saying the critique is bad, it's just that in practice it's not something you'll be noticing day to day, and if you are, switching to pure SQL or SQLAlchemy is not a bad alternative (and Django makes that very easy to do).
- zalew 14y ago
  Sure, I'm currently doing a project with SqlAlchemy in Django (I went pure SqlA in there, but there is Aldjemy if anyone wants to just occasionally extend their query capabilities on top of Django's objects). There is no doubt Django orm is easy for most web crud cases, but also you have to admit that many queries that are trivial to write in pure sql take some weird gymnastics to implement using the orm (Q, F, extra, mapping raw_sql - yuk) - that's what I meant by 'pisses you off'.
  - dirtyaura 14y ago
    Yes, and there is a cognitive overhead to think SQL queries both in Django ORM syntax and SQL and when should I switch between ORM syntax and raw_sql, when should I implement custom manager etc. Our codebase is an enterprise app and it has maybe a ratio of 50/50 between complex queries and straightforward single table selects or simple joins. I much prefer SQLAlchemy Core: I can think a complex query in SQL, try it in sql shell and implement it in SQLAlchemy Core so that the resulting code resembles the actual query. This resemblance also helps a lot of when you do performance optimizations.