4 ms·

I've always been a huge fan of Django and how productive it feels to build web apps with. In a past life my employer was 100% Microsoft ASP.NET and I wanted to

by arrty88 12y ago

I've always been a huge fan of Django and how productive it feels to build web apps with. In a past life my employer was 100% Microsoft ASP.NET and I wanted to migrate them to Django to save on licensing. I think the Django core is strong enough to stand up to Microsoft.

orf 12y ago
I used to love Django, but after using it for a couple of years I've got a bit sick of it. The template language is horrible, as is the ORM. It's only redeeming features is the forms framework (only just) and the admin panel. That being said, it's super-awesome for getting a quick demo up or starting a project with unclear requirements. Edit: Why the downvotes? The templates are slow[1] and restrictive (no function calls with parameters in templates. wat). and the ORM is utter rubbish compared to SQLAlchemy. Django shines because it is convenient (and there is a large ecosystem) - relationships are easy to configure and everything just works together. Which is nice I guess, but it does force you to use all of Django's inferior stuff. 1. http://tomforb.es/just-how-slow-are-django-templates http://tomforb.es/just-how-slow-are-django-templates
- ekmartin 12y ago
  What do you use instead?
  - orf 12y ago
    I'm re-writing the application in Pyramid, and so far I like it. It's a bit harder to get started and get used to though.
    - secstate 12y ago
      LOL. Which is one of the huge benefits of Django, IMHO. You can slam the speed of template rendering and the ORM all you want, but in the Django tutorial the first thing you do is use the framework to model data and display it to a user. The Pyramid tutorial has you sending responses to the browser, which is so low-level I would hope the framework is more flexible than Django. EDIT: While I'm responding, I'll also note that if you're running into speed issues with your templating language, you've waited too long to setup a decent caching layer. (Hello, Varnish)
      - mahmoudimus 12y ago
        I agree with the general sentiment of this comment. I strongly believe that Pyramid is a "graduation" framework. Once one is past the honeymoon period of Django, for non-cookie cutter projects, Pyramid's very well suited for that "advanced" project where you find yourself fighting Django.
        crdoconnor 12y ago
        In what instances did you find yourself fighting django? I've done several huge projects in it and never had this issue. Most of the default building blocks are very sensible and if you need to decouple them (in extreme use cases), it's not that hard.
      - TylerE 12y ago
        The problem with that attitude is that when you hit the framework wall you hit it really hard.
- jsmeaton 12y ago
  What do you not like about the ORM? It's one of my favourite pieces of django.
  - mariocesar 12y ago
    Is actually one of the best components of Django. QuerySet objects and Custom Managers are really great for big projects
  - jawnb 12y ago
    The ORM is bad because it is a poor abstraction of SQL. This manifests itself in several ways, the largest being little control over the SQL queries generated. Here's a gist I made the other day demonstrating this. https://gist.github.com/jawnb/cd7a899cac5300c01709 https://gist.github.com/jawnb/cd7a899cac5300c01709 The poor abstraction really causes problems when you need to do anything beyond the simplest of use cases. To achieve even modest performance gains, you're better off hand writing your SQL. Additionally, doing even the most trivial of trivial aggregate queries will also mean that you're hand writing SQL. SQLAlchemy is light years beyond the django ORM in this regard. Don't take just my word for it though, here's a talk Alex Gaynor gave saying the same things. https://www.youtube.com/watch?v=GxL9MnWlCwo https://www.youtube.com/watch?v=GxL9MnWlCwo
    - jsmeaton 12y ago
      I think the most important difference between Alchemy and Django is the separation between the SQL abstraction layer and the ORM. There is no separation with django, making it very difficult to really get in there and make changes. But I don't think this makes the django ORM bad. It is very easy for beginners to get up and running. It is very easy to understand the models and the query language. As an FYI - 1.8 should make it possible to use .annotate() for constructs that aren't aggregates - like functions and extra select columns. You'll also be able to write more complex aggregates. It should give you greater control over your SQL, removing the need for .extra() in most cases (but not .raw()). It's what I've been working on recently: https://github.com/django/django/pull/2496 https://github.com/django/django/pull/2496
    - 12y ago
- bfwi 12y ago
  I don't think that many people care about server-side templating anymore. Some excellent JS frameworks has done away with that.
  - marcosscriven 12y ago
    I'm really curious why you say that? Certainly it seems to me there's enough downsides to client side rendering still that I can't see how it's that clear cut.
    - tragic 12y ago
      Well, restricting the server to basically providing a REST API for client code is basically the dominant way of doing certain sorts of applications, particularly those that may have web and native implementations and so forth. Some of us, however, make websites. We generally render our HTML server side. And Django templates are as good a way as any other (leaving aside speed concerns).
  - stdbrouw 12y ago
    Writing a template in one go, all in one file, is still vastly easier to wrap your head around than writing all sorts of different components in JavaScript and then gluing them together. There's great JS templating frameworks, but I don't see why anyone would use them unless you really have to, e.g. for data binding / dynamic changes to the DOM.
  - untothebreach 12y ago
    I think that is a bit of confirmation bias. Client-side rendering has definitely garnered a lot of attention lately, but that doesn't mean that everyone has simultaneously stopped doing server-side rendering
    - andybak 12y ago
      Yep. There are times when server-side is the right thing to do (mainly content-based sites - especially if SEO and accessibility are major concerns) and times when client side is (SPAs and the more 'app-like' end of the spectrum). PJAX is a great compromise between the two approaches: https://github.com/jacobian/django-pjax https://github.com/jacobian/django-pjax https://readthedocs.org/projects/django-easy-pjax/ https://readthedocs.org/projects/django-easy-pjax/
- tragic 12y ago
  I'm not sure why you'd hate the template language. Its deliberate dumbness can be tiresome, but on the other hand, if you're running into that, it's a code smell. I was sceptical about the whole "designed for designers" aspect of it - but I've had to introduce a couple of people, one of whom isn't a developer, to Jekyll at work, with the Liquid templates which are very similar syntactically, and it's been picked up very quickly. I keep hearing it's slow, but I haven't had to run at a scale that it's a pain point, so I wouldn't know.
  - crdoconnor 12y ago
    Its deliberate dumbness was a good idea that does not get enough credit. You should not be doing complex logic in the template layer. I still think it could be made more user friendly for designers, though. We need some sort of app that will autofill django templates' context variables with test data so that designers can see how it all looks and edit them under different circumstances without having to deal with the messiness or state of the system underneath.
- deleted 12y ago
  [deleted]
- riquito 12y ago
  The link you posted tell us that Jinja2 templates are way faster than Django's. Well, you _can_ use Jinja2 in Django, and you get the function calls in templates too, so what's the problem?
  - crdoconnor 12y ago
    Using jinja2 is technically possible, but it would be difficult to use other django apps at the same time as they all assume the standard django templates.
- meowface 12y ago
  I fully agree. Pyramid, Flask, and Bottle are all better alternatives.
  - dudus 12y ago
    They are hard to compare, a completely different mindset. They are minimalist frameworks while django tries to be a more complete framework. Each one excel at their goals in my opinion.
- TylerE 12y ago
  Agreed. Pyramid + SQLAlchemy + Alembic (migrations) + Deform (...forms) + your choice of (jinja2/mako/etc) == happiness
  - mahmoudimus 12y ago
    Not sure why you're downvoted. I am a very big Flask/Werkzeug user and I'm starting to really appreciate the power of Pyramid.
    - crdoconnor 12y ago
      I've looked into it and I have found very few (and generally quite minor) things which made it preferable to django. It's good, and certainly better than most frameworks out there, but better? I don't think so.
- misiti3780 12y ago
  django templates have gotten a lot faster in the last few years + plus is you think they are just slow, why not push everything to the client using a front-end MVC - everything is going that way anyways.
- andybak 12y ago
  Some of the new ORM features in 1.7 are great - and there are some even more cool things planned for 1.8 (a big generalisation of F expressions that will also include more flexible aggregation and annotation functionality). I like the ORM - the design philosophy is about making the simple things easy and the hard things possible and it think it succeeds at that.
- rectangletangle 12y ago
  I originally didn't like how you couldn't do real function/method calls in Django templates. It felt a bit like I had my hands bound, very restricting. However as I've used Django more and more, I've come to find keeping all but the most basic presentation logic out of templates makes it easier to write thorough view tests. When you weave a bunch of logic into a template, it becomes difficult to write proper tests. I've found using this "thin" template approach has helped me write simpler and faster code in general. Making this separation, also seems to make it easier to write more generic views and templates. Which helps with maintainability. If you absolutely need to make calls in templates, Django makes it trivial to write custom templatetags, which can be used to do this. They're also easy to test independently, seeing as Django implements this feature with a regular decorator. So templatetags can be called like any other Python function. After using Django quite a bit, I've really come to appreciate how it separates view logic from template logic. It really is the better approach IMO.

by arrty88 12y ago

orf 12y ago

I used to love Django, but after using it for a couple of years I've got a bit sick of it. The template language is horrible, as is the ORM. It's only redeeming features is the forms framework (only just) and the admin panel. That being said, it's super-awesome for getting a quick demo up or starting a project with unclear requirements. Edit: Why the downvotes? The templates are slow[1] and restrictive (no function calls with parameters in templates. wat). and the ORM is utter rubbish compared to SQLAlchemy. Django shines because it is convenient (and there is a large ecosystem) - relationships are easy to configure and everything just works together. Which is nice I guess, but it does force you to use all of Django's inferior stuff. 1. http://tomforb.es/just-how-slow-are-django-templates http://tomforb.es/just-how-slow-are-django-templates

ekmartin 12y ago
What do you use instead?
- orf 12y ago
  I'm re-writing the application in Pyramid, and so far I like it. It's a bit harder to get started and get used to though.
  - secstate 12y ago
    LOL. Which is one of the huge benefits of Django, IMHO. You can slam the speed of template rendering and the ORM all you want, but in the Django tutorial the first thing you do is use the framework to model data and display it to a user. The Pyramid tutorial has you sending responses to the browser, which is so low-level I would hope the framework is more flexible than Django. EDIT: While I'm responding, I'll also note that if you're running into speed issues with your templating language, you've waited too long to setup a decent caching layer. (Hello, Varnish)
    - mahmoudimus 12y ago
      I agree with the general sentiment of this comment. I strongly believe that Pyramid is a "graduation" framework. Once one is past the honeymoon period of Django, for non-cookie cutter projects, Pyramid's very well suited for that "advanced" project where you find yourself fighting Django.
      - crdoconnor 12y ago
        In what instances did you find yourself fighting django? I've done several huge projects in it and never had this issue. Most of the default building blocks are very sensible and if you need to decouple them (in extreme use cases), it's not that hard.
    - TylerE 12y ago
      The problem with that attitude is that when you hit the framework wall you hit it really hard.
jsmeaton 12y ago
What do you not like about the ORM? It's one of my favourite pieces of django.
- mariocesar 12y ago
  Is actually one of the best components of Django. QuerySet objects and Custom Managers are really great for big projects
- jawnb 12y ago
  The ORM is bad because it is a poor abstraction of SQL. This manifests itself in several ways, the largest being little control over the SQL queries generated. Here's a gist I made the other day demonstrating this. https://gist.github.com/jawnb/cd7a899cac5300c01709 https://gist.github.com/jawnb/cd7a899cac5300c01709 The poor abstraction really causes problems when you need to do anything beyond the simplest of use cases. To achieve even modest performance gains, you're better off hand writing your SQL. Additionally, doing even the most trivial of trivial aggregate queries will also mean that you're hand writing SQL. SQLAlchemy is light years beyond the django ORM in this regard. Don't take just my word for it though, here's a talk Alex Gaynor gave saying the same things. https://www.youtube.com/watch?v=GxL9MnWlCwo https://www.youtube.com/watch?v=GxL9MnWlCwo
  - jsmeaton 12y ago
    I think the most important difference between Alchemy and Django is the separation between the SQL abstraction layer and the ORM. There is no separation with django, making it very difficult to really get in there and make changes. But I don't think this makes the django ORM bad. It is very easy for beginners to get up and running. It is very easy to understand the models and the query language. As an FYI - 1.8 should make it possible to use .annotate() for constructs that aren't aggregates - like functions and extra select columns. You'll also be able to write more complex aggregates. It should give you greater control over your SQL, removing the need for .extra() in most cases (but not .raw()). It's what I've been working on recently: https://github.com/django/django/pull/2496 https://github.com/django/django/pull/2496
  - 12y ago
bfwi 12y ago
I don't think that many people care about server-side templating anymore. Some excellent JS frameworks has done away with that.
- marcosscriven 12y ago
  I'm really curious why you say that? Certainly it seems to me there's enough downsides to client side rendering still that I can't see how it's that clear cut.
  - tragic 12y ago
    Well, restricting the server to basically providing a REST API for client code is basically the dominant way of doing certain sorts of applications, particularly those that may have web and native implementations and so forth. Some of us, however, make websites. We generally render our HTML server side. And Django templates are as good a way as any other (leaving aside speed concerns).
- stdbrouw 12y ago
  Writing a template in one go, all in one file, is still vastly easier to wrap your head around than writing all sorts of different components in JavaScript and then gluing them together. There's great JS templating frameworks, but I don't see why anyone would use them unless you really have to, e.g. for data binding / dynamic changes to the DOM.
- untothebreach 12y ago
  I think that is a bit of confirmation bias. Client-side rendering has definitely garnered a lot of attention lately, but that doesn't mean that everyone has simultaneously stopped doing server-side rendering
  - andybak 12y ago
    Yep. There are times when server-side is the right thing to do (mainly content-based sites - especially if SEO and accessibility are major concerns) and times when client side is (SPAs and the more 'app-like' end of the spectrum). PJAX is a great compromise between the two approaches: https://github.com/jacobian/django-pjax https://github.com/jacobian/django-pjax https://readthedocs.org/projects/django-easy-pjax/ https://readthedocs.org/projects/django-easy-pjax/
tragic 12y ago
I'm not sure why you'd hate the template language. Its deliberate dumbness can be tiresome, but on the other hand, if you're running into that, it's a code smell. I was sceptical about the whole "designed for designers" aspect of it - but I've had to introduce a couple of people, one of whom isn't a developer, to Jekyll at work, with the Liquid templates which are very similar syntactically, and it's been picked up very quickly. I keep hearing it's slow, but I haven't had to run at a scale that it's a pain point, so I wouldn't know.
- crdoconnor 12y ago
  Its deliberate dumbness was a good idea that does not get enough credit. You should not be doing complex logic in the template layer. I still think it could be made more user friendly for designers, though. We need some sort of app that will autofill django templates' context variables with test data so that designers can see how it all looks and edit them under different circumstances without having to deal with the messiness or state of the system underneath.
deleted 12y ago
[deleted]
riquito 12y ago
The link you posted tell us that Jinja2 templates are way faster than Django's. Well, you _can_ use Jinja2 in Django, and you get the function calls in templates too, so what's the problem?
- crdoconnor 12y ago
  Using jinja2 is technically possible, but it would be difficult to use other django apps at the same time as they all assume the standard django templates.
meowface 12y ago
I fully agree. Pyramid, Flask, and Bottle are all better alternatives.
- dudus 12y ago
  They are hard to compare, a completely different mindset. They are minimalist frameworks while django tries to be a more complete framework. Each one excel at their goals in my opinion.
TylerE 12y ago
Agreed. Pyramid + SQLAlchemy + Alembic (migrations) + Deform (...forms) + your choice of (jinja2/mako/etc) == happiness
- mahmoudimus 12y ago
  Not sure why you're downvoted. I am a very big Flask/Werkzeug user and I'm starting to really appreciate the power of Pyramid.
  - crdoconnor 12y ago
    I've looked into it and I have found very few (and generally quite minor) things which made it preferable to django. It's good, and certainly better than most frameworks out there, but better? I don't think so.
misiti3780 12y ago
django templates have gotten a lot faster in the last few years + plus is you think they are just slow, why not push everything to the client using a front-end MVC - everything is going that way anyways.
andybak 12y ago
Some of the new ORM features in 1.7 are great - and there are some even more cool things planned for 1.8 (a big generalisation of F expressions that will also include more flexible aggregation and annotation functionality). I like the ORM - the design philosophy is about making the simple things easy and the hard things possible and it think it succeeds at that.
rectangletangle 12y ago
I originally didn't like how you couldn't do real function/method calls in Django templates. It felt a bit like I had my hands bound, very restricting. However as I've used Django more and more, I've come to find keeping all but the most basic presentation logic out of templates makes it easier to write thorough view tests. When you weave a bunch of logic into a template, it becomes difficult to write proper tests. I've found using this "thin" template approach has helped me write simpler and faster code in general. Making this separation, also seems to make it easier to write more generic views and templates. Which helps with maintainability. If you absolutely need to make calls in templates, Django makes it trivial to write custom templatetags, which can be used to do this. They're also easy to test independently, seeing as Django implements this feature with a regular decorator. So templatetags can be called like any other Python function. After using Django quite a bit, I've really come to appreciate how it separates view logic from template logic. It really is the better approach IMO.