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.

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.

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?

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.

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.

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.

What do you not like about the ORM? It's one of my favourite pieces of django.

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

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

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

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

This isn't really a big deal - you can just hand-write your sql directly using .raw() and just pull out the corresponding result set and use it as you were doing before.

I've had to do what you're suggesting, but not a huge amount. Maybe 10-15 times on large, high scale projects.

SQLAlchemy is better but the number of times I have to break out of its abstraction layer are not enough for me to feel like I really have a desperate need to use alchemy instead. It's a minor inconvenience, nothing more.

Is actually one of the best components of Django. QuerySet objects and Custom Managers are really great for big projects

It's got better. When I first started using it you couldn't bulk save objects, each save was an individual query. It also loves to make lots of queries, especially in templates. I guess my true dislike stems from using SQLAlchemy, and realizing how awesome it is compared to Django's ORM.

I do love the relationship stuff - making a m2m field is super easy and it just works. Also manager/queryset extensions are super easy.

I haven't actually used SQLAlchemy, but I know it has a lot of features that would be extremely useful for django. I really like how it separates out the Core and ORM components.

I prefer djangos syntax for composing queries and defining models though.

The common criticism I hear is that it can't do everything, unlike SqlAlchemy. Fair enough, but the Django ORM is no doubt simpler to use than SqlAlchemy.

SQLAlchemy is designed for people who know SQL already and want a safe and convenient way to use it from Python.

The Django ORM is designed for people that want their Python data objects to be persisted to a back-end data store.

Both of these things have their place. The problem with the Django ORM is sometimes you need to do something slightly more complicated than what it supports and your back to raw SQL. These scenarios are really common, 90% of Django project have raw SQL in them.

SQLAlchemy uses the data mapper pattern whereas django ORM uses active record - that's the main difference. Neither one is really 'better', there are advantages to both approaches:

http://russellscottwalker.blogspot.sg/2013/10/active-record-...

The main advantage to django ORM in my opinion is 'less code', although it does create an excessive coupling between your persistence / model layer. Whether that is something you can live with or not is up to your project's requirements.

I'm pretty happy to work with both. Just don't make me use RoR!

I've got to disagree with the 90% figure. The vast majority of projects I've seen (which are typically pretty straightforward from a data modeling perspective) rely only on the ORM.

Maybe 5% of the Django projects I've been involved in contain raw SQL.

What do you use instead?

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.

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)

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.

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.

The problem with that attitude is that when you hit the framework wall you hit it really hard.

Agreed.

Pyramid + SQLAlchemy + Alembic (migrations) + Deform (...forms) + your choice of (jinja2/mako/etc) == happiness

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.

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.

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.

I don't think that many people care about server-side templating anymore. Some excellent JS frameworks has done away with that.

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.

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

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://readthedocs.org/projects/django-easy-pjax/

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.

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

I fully agree.

Pyramid, Flask, and Bottle are all better alternatives.

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.