7 ms·

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 com

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
    > 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. nope. that's what a server gateway interface is for. giving you a set of reusable tools and conventions to help you work - that's what a framework is for. the scope of the framework can be wider or narrower and it depends what you like - it's just, like, your opinion, man. the so called microframeworks are cool, but they are not a remedy to every problem out there. > forcing users to use a certain ORM/templater forcing? not sticking with the defaults and building an exotic combo leaves you out of re-using a lot of the ecosystem apps, but certainly you are not "forced" to do anything.
  - gtaylor 14y ago
    I think it's important to note that not everyone wants or needs to choose every single component in a project. In fact, this can be a big waste of time and added complexity for some projects, particularly the more simple ones. Even for a larger project, your choice of template language is nowhere near as important as the quality and cohesiveness of your overall design (you know, the actual important stuff). With the move towards heavier API-driven client-side stuff, the choice of frameworks gets to be even more boring. Django is easy to hire for, it's easy to get help for, it's easy to Google around for. I can plug in an intern and have him productive very quickly due to the great documentation, and the "opinionated" nature of Django (there are widely known best practices for lots of things) is great in this case. He doesn't have to wade through all of my glueing of pieces together, figure out this lesser known, lesser documented, lesser supported framework (Pyramid). He just says "Oh, this is Django, I get it." I don't make the claim that Django is better than Pyramid, but I think it's probably foolish to do the reverse as well. They are just two different ways of doing things: minimalistic/bring your own lunch versus batteries included.
bryanh 14y ago
One might easily take offense at your comment: > perhaps your people just don't have much exposure > new, serious platforms Both could have been omitted and your points would still have been valid. Anyways, I'm not advocating Django as "the one true way", just stating that is hasn't hindered us in the least. :shrugs:
- cookiecaper 14y ago
  I don't intend offense. I'm just suggesting an explanation for why you may feel Django is not problematic. When all you have is a hammer, everything looks like a nail. I've met many-a-programmer fairly early in their careers who praise things like Cake, Rails, or Django, but in my experience at least, as they mature, they prefer less invasive solutions.
  - adamauckland 14y ago
    My 2 cents in response: I use C#, JavaScript and Python daily. I spent 6 months learning Ruby but decided it wasn't for me. I also use Objective C for iOS and enjoy optimising SQL in my database layer. However the three platforms I use in order are .Net MVC, Django and node.js. Before I chose Django I wrote my own Python-based web framework but decided I'd rather build applications than frameworks. Django has a massive community built around it that I couldn't find anywhere else (note - I _have_ been using Django since 2007). The main reason I use Django? because I, personally, know what I'm doing, where everything lives and can get it done quickly. It works for me and it clearly works for other people, so you can't knock it. What I _wouldn't_ do, is advertise for a 'Django' developer. You have to know Python and understand what your framework is doing under the hood. Django is great, I'm sure Pyramid is great as long as you understand what it's doing and have read the code, but most importantly, what we all are is Python programmers.
  - mtrimpe 14y ago
    In a few years you'll probably get to the point where you don't prefer less invasive solutions but will pick the right tool for the job. If you know you'll be iterating rapidly but will stay within the confines of 'standard CRUDdy app' then e.g. Django, RoR, Spring Roo e.a. will be probably be good to you. If you expect to go beyond those confines you'll be burnt. In general it's about finding what I like to call the 'grain of the tool' and pick the ones where you can go with the grain.
jtchang 14y ago
For people developing new platforms I think Django has a great deal to offer and should be a serious contender if you are looking into Python based web frameworks. A few specific things I like about Django: 1. A decent app ecosystem 2. Lots of documentation and a fairly mature codebase. 3. Django south for migrations.
- cookiecaper 14y ago
  I use Pyramid for Python-based web applications. None of the features you've mentioned are specific to Django. 1. What is "a decent app ecosystem"? We call these "libraries" elsewhere. 2. Pyramid same. (and, as someone whose attempted to build apps with both, I find Pyramid's much clearer) 3. This is ORM specific, not framework specific. SQLAlchemy has sqlalchemy-migrate or Alembic.
  - gtaylor 14y ago
    He never said they were specific to Django, he was mentioning a few specific things he liked about Django. It's great you like Pyramid, but honestly, a lot of this is just a matter of taste. I personally find the way Pyramid fits together and its documentation less appealing than Django. In my dabblings with Pyramid, I found the community less responsive and helpful. But that's all subjective and anecdotal, just like your take on Django (which is why this is a boring discussion). The truth is, good engineers can do great things with far less than Django or Pyramid. The choice of framework is a very boring discussion, since most modern, widely used options are going to be "good enough" in the right hands. Your idea and its execution are front and center. If you're sufficiently skilled, your framework shouldn't be a huge factor in your execution. Pick something that you like, and just get to work.
    - cookiecaper 14y ago
      Right, I never said it was impossible to build something useful in Django. I just believe it's a non-optimal choice, in almost any situation. I don't believe "it's just a matter of taste" to have a web framework that knows its place and makes it simple to adapt, or unpretentiously allows you to code with minimal rigidity. I don't find any contrary arguments presented thus far convincing. Saying that Pyramid's documentation and overall "fit" is "less appealing" is a matter of taste. Indicating that Django is much bigger is a matter of fact, and that it provides little if any additional benefit and increases rigidity and practical obligation to conventions is a matter of informed analysis. The argument to be made, then, is why that obligation and rigidity and bigness are valuable, which thus far, no one has really done. It's not necessarily Django's fault. Pyramid is a much later framework, and alternate implementations of pieces of the full stack like Jinja2, Mako and SQLAlchemy became mature after Django was initially conceived. it's nothing personal to Django or the people involved in it (I've even submitted patches, but to my knowledge, they were not merged). It's just a thing that has been superseded, and that happens in tech. Now it's just a matter of how long until everyone else can drop the religion and admit they're wasting time on compliance and rigidity that shouldn't be there. I'm not saying Django is the least productive framework in existence. I'm not saying it'll ruin your company or life if you use it. I know people who use it and we are able to get along. I work with it occasionally. I'm just saying, "it's unwise", for almost any large-scale new project.
philipn 14y ago
I develop a new, serious, widely-used platform and I love Django. I've definitely been around the block, have developed python-based web apps without frameworks, etc. I've never had an issue with Django being inflexible. The strong conventions and the fact I don't have to make a decision about every little thing makes me, and the ecosystem, more productive.
- cookiecaper 14y ago
  >I've never had an issue with Django being inflexible. The strong conventions and the fact I don't have to make a decision about every little thing makes me, and the ecosystem, more productive. I don't really understand this. Other frameworks don't require you to "make a decision about every little thing" either. It's not like they're just a blank file that says "<WRITE FRAMEWORK CODE HERE>". They come with defaults, things that are in place automatically. They come with suggestions and recommendations for optional stuff. They come with docs and tutorials. They just don't make illegitimate mandates, they don't revolve around a specific ORM or a specific template. If you start a clean Pyramid project with the "alchemy" scaffold (recommended) right now, you'll have Chameleon, SQLAlchemy, and URL routing automatically chosen for you. You don't have to make any more decisions. You just have to open up views.py and start coding.
  - ubershmekel 14y ago
    To you it may be "illegitimate mandates" but to a django dev it's a blissful ignorance. You might just have to agree to disagree. Let's say you want to add a column to your database. Because the django ORM is so popular and monolithic, it has amazing tools for the job that do it auto-magically when you modify models.py. And that's just one facet of many. For some folk, the flexibility of Pyramid is nothing but a bother.
    - cookiecaper 14y ago
      No, because you don't have to use the flexibility. Pyramid comes with defaults. You can blissfully just use what comes out of the box, or you can, relatively easily, use something else. There is no cost to the programmer who simply wants to ignorantly use the default tool set.
monkeypizza 14y ago
I use jinja2 with django, it's good. https://github.com/coffin/coffin/ https://github.com/coffin/coffin/
- cookiecaper 14y ago
  The problem is that someone has to create that project as anything more than a shim in the first place. There is no reason a generic web framework should require a full-fledged compatibility effort to switch out what should be "just another library". Note that there are several incompatibilities with "true" Jinja2 at the bottom of that readme, and that support for built-in "Django tags" is necessary. This is far less adaptable than Pyramid, which makes most internal functionality like that accessible via the request object, which can be accessed by your template language's typical variable evaluation syntax, and which can use Mako or the default Chameleon with just a one-line configuration change, or Jinja2 and others by installing a simple shim layer that is mostly boilerplate. Personally, I've tried to use mako with django and found it unwieldy to pass the correct information across the controller-template barrier. This was some time in the past, however, so perhaps either the adapter or documentation has improved and the problem no longer exists. The real issue, however, is that a generic web framework would make it difficult to replace unrelated user-facing libraries in the first place.
  - SoftwareMaven 14y ago
    Given the callback nature of the Django templating library with template tags, includes, and other goodies, it is not as simple as "call foo_template() and return string". As soon as a template tag is involved, internal data structure needs to be exposed, with makes * everything* much harder.
- zalew 14y ago
  there is also https://github.com/jbalogh/jingo https://github.com/jbalogh/jingo Jingo serves purely as a minimalistic bridge between Django and Jinja2. Coffin attempts to reduce the differences between Jinja2 templates and Django's native templates.
bebop 14y ago
Just as a note to everyone, you can use Mako/Jinja2, SQLAlchemy and really any other Python tool/library out there with Django. What Django does well is provide a pre-built and (IMHO) easy to use set of default tools. This does not mean that you must use these tools, they are just there by default if you need them. You could really just use Django as an HTTP routing tool.
- cookiecaper 14y ago
  I admit it's been a while, but when I tried django-sqlalchemy in the past, it was not in a pleasant state. Last I came around, it was certainly not just a simple drop-in thing. While I'm sure you're right that it's not a hard requirement in that you can figure out how to make it work, it's not an easy thing, and you'll be fighting the framework and the conventions all along the way as interdependent stuff stops working. Again, in my experience. If things have improved significantly, I'd like to know. When toys ship "batteries included", it's easy to pull them out and replace with a different brand, if you want. Django, and most other web frameworks, don't make that interoperability a serious concern, afaik. When you use a framework, you are essentially adopting its code into your project all at once, and you become responsible to make sure it works and adapts to your needs even if upstream dies out or makes a decision that renders new versions unusable for your use case. "Non-removable batteries" are therefore a major design flaw in your project, even if you haven't had occasion for it to be exposed yet. The batteries of monolithic, "opinionated" web frameworks like Rails and Django may be partially removable, and maybe they've improved recently, but newer frameworks like Flask and Pyramid don't have this issue at all, and it makes them much more flexible.
  - hknews 14y ago
    Just wondering if you have any tips (that you recall) for making django and sql alchemy work together. sql alchemy seems like the best ORM to work with and django has a nice ecosystem. If sql alchemy only does read operations on django models, will that make the integration simpler?
rburhum 14y ago
I built http://www.modewalk.com/ http://www.modewalk.com/ from scratch using Django. I do have "plenty of exposure", and the default template engine worked just fine. The default ORM is just fine. Most of the defaults are just fine.
- rashthedude 14y ago
  Hey, very interesting site indeed. I had a few questions about what other stacks/technologies you've made use of. Drop me a line or two on rashid.aden.omar@gmail if you could. Thanks
  - rburhum 14y ago
    thanks. Sure, I'd be happy to share my rationale for the components I picked. Sending you an e-mail.
- cookiecaper 14y ago
  Again, the issue isn't whether "the defaults are just fine". It's a larger design problem, where a framework makes illegitimate assumptions and imposes illegitimate requirements, making it difficult to swap out components that shouldn't be mission critical. This is excused as "opinionated design", which, as I explain in another comment, is another way to say "bad design with an attitude".
  - SoftwareMaven 14y ago
    Opinionated design is not "bad design with attitude". You may disagree with the opinons, but those opinions are thought through and made for the best interests of all the users. It is not uncommon for you to sit in the outside the "norms" the framework is shooting for, but that is not a problem for either you or the framework. A framework that tries to be all things to all people generally sucks for everybody.
    - cookiecaper 14y ago
      >A framework that tries to be all things to all people generally sucks for everybody. Right, I agree. I like a framework that tries to be a generic web framework for most people who want to write a typical web application in Python. That seems adequately specific to me. I don't consider that "opinionated design", it's simply identifying a market. "Opinionated design" is an excuse to make interopability and cross-compatibility difficult. There are, generally speaking, few good reasons to do this. Things that are totally out of scope obviously shouldn't be integrated, but if you feel the need to bundle a certain type of library with your framework, shouldn't it be sensible that someone might want to tweak that someday, or replace it with another library that does the same thing in a different way? Opinionated design is about copping out of that logic and putting a smooth sheen on it, it's saying "OK, we understand this is a reasonable, in-scope requirement, but we're opinionated and cool, like Steve Jobs, so we're just going to say you have to use this library or you're SOL. Remember, we are cool like Apple, and that's why we can tell you off in this fashion". Not "only projects that implement this prudent, adaptive, and objectively important-for-our-use-case protocol will work", but "only this library" or "only this way". Projects that don't suffer from scope creep or far-fetched, irrelevant integration aren't called "opinionated design", they're simply called "well-managed". It doesn't come from having an opinion and telling everyone else to shove it. It comes from having goals and the discipline, reason, and structure in place to stick to them.
Alex3917 14y ago
"the templating in Django is awful compared to Mako/Jinja2, the ORM in Django is awful compared SQLAlchemy" You can use Django with Jinja2 and SQLAlchemy.
- wahnfrieden 14y ago
  And you lose a lot of the benefits of Django, to be fair. We use Jinja2 on DrawQuest but it was a bit messy to add back features like the Django context processor.
  - SoftwareMaven 14y ago
    I'd love to hear more. We are considering Django with Jinja2, primarily because I think some of the Django template opinions are a bit wrong. I don't want to fight one direction in my efforts to keep from fighting another, though. I'd prefer the details I know. :)
- robertfw 14y ago
  Yes, but you start making life difficult with regards to the app ecosystem, which imo is the main reason for using django
mixmastamyk 14y ago
The templating is simple on purpose, to keep logic out of them. Seems like a reasonable design to me.
- bmelton 14y ago
  If separation of duties is a concern, Django's templates (IMO) get it more right than anything else. I remember, at one point, that I felt Django templates were limiting me, and started swapping them out piecemeal for Jinja, and my designers started to absolutely hate me. Not because they had to convert anything, I converted everything by hand, but just that the amount of syntax you can cram in there keeps everything less pure. Since then, I realized I was trying to do too much in the template and started putting things where they belonged, and now, whenever I work with Jinja or Mako, it feels a little too much like editing Wordpress themes or something in PHP. Long story short, I learned the hard way that if you're putting logic in the templates, you're probably doing something wrong, and I agree that it is not only a reasonable design, but a very good suggestion as well.
coldtea 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. Define awful in concrete terms. I've not been much constrained by Django in any way. Even if all of those are "better" in some spec-listing way, Django could still be better by offering better integration for it's tools. Like the iPhone, in actual use, beats phones that are better than it "spec-wise".
rbanffy 14y ago
While I agree with you Jinja and SQLAlchemy have nice features absent from their Django counterparts, I would not call them awful. There are problems Django solves and problems Pyramid solves and there I nothing wrong in using one or the other.

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
  > 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. nope. that's what a server gateway interface is for. giving you a set of reusable tools and conventions to help you work - that's what a framework is for. the scope of the framework can be wider or narrower and it depends what you like - it's just, like, your opinion, man. the so called microframeworks are cool, but they are not a remedy to every problem out there. > forcing users to use a certain ORM/templater forcing? not sticking with the defaults and building an exotic combo leaves you out of re-using a lot of the ecosystem apps, but certainly you are not "forced" to do anything.
- gtaylor 14y ago
  I think it's important to note that not everyone wants or needs to choose every single component in a project. In fact, this can be a big waste of time and added complexity for some projects, particularly the more simple ones. Even for a larger project, your choice of template language is nowhere near as important as the quality and cohesiveness of your overall design (you know, the actual important stuff). With the move towards heavier API-driven client-side stuff, the choice of frameworks gets to be even more boring. Django is easy to hire for, it's easy to get help for, it's easy to Google around for. I can plug in an intern and have him productive very quickly due to the great documentation, and the "opinionated" nature of Django (there are widely known best practices for lots of things) is great in this case. He doesn't have to wade through all of my glueing of pieces together, figure out this lesser known, lesser documented, lesser supported framework (Pyramid). He just says "Oh, this is Django, I get it." I don't make the claim that Django is better than Pyramid, but I think it's probably foolish to do the reverse as well. They are just two different ways of doing things: minimalistic/bring your own lunch versus batteries included.

bryanh 14y ago

One might easily take offense at your comment: > perhaps your people just don't have much exposure > new, serious platforms Both could have been omitted and your points would still have been valid. Anyways, I'm not advocating Django as "the one true way", just stating that is hasn't hindered us in the least. :shrugs:

cookiecaper 14y ago
I don't intend offense. I'm just suggesting an explanation for why you may feel Django is not problematic. When all you have is a hammer, everything looks like a nail. I've met many-a-programmer fairly early in their careers who praise things like Cake, Rails, or Django, but in my experience at least, as they mature, they prefer less invasive solutions.
- adamauckland 14y ago
  My 2 cents in response: I use C#, JavaScript and Python daily. I spent 6 months learning Ruby but decided it wasn't for me. I also use Objective C for iOS and enjoy optimising SQL in my database layer. However the three platforms I use in order are .Net MVC, Django and node.js. Before I chose Django I wrote my own Python-based web framework but decided I'd rather build applications than frameworks. Django has a massive community built around it that I couldn't find anywhere else (note - I _have_ been using Django since 2007). The main reason I use Django? because I, personally, know what I'm doing, where everything lives and can get it done quickly. It works for me and it clearly works for other people, so you can't knock it. What I _wouldn't_ do, is advertise for a 'Django' developer. You have to know Python and understand what your framework is doing under the hood. Django is great, I'm sure Pyramid is great as long as you understand what it's doing and have read the code, but most importantly, what we all are is Python programmers.
- mtrimpe 14y ago
  In a few years you'll probably get to the point where you don't prefer less invasive solutions but will pick the right tool for the job. If you know you'll be iterating rapidly but will stay within the confines of 'standard CRUDdy app' then e.g. Django, RoR, Spring Roo e.a. will be probably be good to you. If you expect to go beyond those confines you'll be burnt. In general it's about finding what I like to call the 'grain of the tool' and pick the ones where you can go with the grain.

jtchang 14y ago

For people developing new platforms I think Django has a great deal to offer and should be a serious contender if you are looking into Python based web frameworks. A few specific things I like about Django: 1. A decent app ecosystem 2. Lots of documentation and a fairly mature codebase. 3. Django south for migrations.

cookiecaper 14y ago
I use Pyramid for Python-based web applications. None of the features you've mentioned are specific to Django. 1. What is "a decent app ecosystem"? We call these "libraries" elsewhere. 2. Pyramid same. (and, as someone whose attempted to build apps with both, I find Pyramid's much clearer) 3. This is ORM specific, not framework specific. SQLAlchemy has sqlalchemy-migrate or Alembic.
- gtaylor 14y ago
  He never said they were specific to Django, he was mentioning a few specific things he liked about Django. It's great you like Pyramid, but honestly, a lot of this is just a matter of taste. I personally find the way Pyramid fits together and its documentation less appealing than Django. In my dabblings with Pyramid, I found the community less responsive and helpful. But that's all subjective and anecdotal, just like your take on Django (which is why this is a boring discussion). The truth is, good engineers can do great things with far less than Django or Pyramid. The choice of framework is a very boring discussion, since most modern, widely used options are going to be "good enough" in the right hands. Your idea and its execution are front and center. If you're sufficiently skilled, your framework shouldn't be a huge factor in your execution. Pick something that you like, and just get to work.
  - cookiecaper 14y ago
    Right, I never said it was impossible to build something useful in Django. I just believe it's a non-optimal choice, in almost any situation. I don't believe "it's just a matter of taste" to have a web framework that knows its place and makes it simple to adapt, or unpretentiously allows you to code with minimal rigidity. I don't find any contrary arguments presented thus far convincing. Saying that Pyramid's documentation and overall "fit" is "less appealing" is a matter of taste. Indicating that Django is much bigger is a matter of fact, and that it provides little if any additional benefit and increases rigidity and practical obligation to conventions is a matter of informed analysis. The argument to be made, then, is why that obligation and rigidity and bigness are valuable, which thus far, no one has really done. It's not necessarily Django's fault. Pyramid is a much later framework, and alternate implementations of pieces of the full stack like Jinja2, Mako and SQLAlchemy became mature after Django was initially conceived. it's nothing personal to Django or the people involved in it (I've even submitted patches, but to my knowledge, they were not merged). It's just a thing that has been superseded, and that happens in tech. Now it's just a matter of how long until everyone else can drop the religion and admit they're wasting time on compliance and rigidity that shouldn't be there. I'm not saying Django is the least productive framework in existence. I'm not saying it'll ruin your company or life if you use it. I know people who use it and we are able to get along. I work with it occasionally. I'm just saying, "it's unwise", for almost any large-scale new project.

philipn 14y ago

I develop a new, serious, widely-used platform and I love Django. I've definitely been around the block, have developed python-based web apps without frameworks, etc. I've never had an issue with Django being inflexible. The strong conventions and the fact I don't have to make a decision about every little thing makes me, and the ecosystem, more productive.

cookiecaper 14y ago
>I've never had an issue with Django being inflexible. The strong conventions and the fact I don't have to make a decision about every little thing makes me, and the ecosystem, more productive. I don't really understand this. Other frameworks don't require you to "make a decision about every little thing" either. It's not like they're just a blank file that says "<WRITE FRAMEWORK CODE HERE>". They come with defaults, things that are in place automatically. They come with suggestions and recommendations for optional stuff. They come with docs and tutorials. They just don't make illegitimate mandates, they don't revolve around a specific ORM or a specific template. If you start a clean Pyramid project with the "alchemy" scaffold (recommended) right now, you'll have Chameleon, SQLAlchemy, and URL routing automatically chosen for you. You don't have to make any more decisions. You just have to open up views.py and start coding.
- ubershmekel 14y ago
  To you it may be "illegitimate mandates" but to a django dev it's a blissful ignorance. You might just have to agree to disagree. Let's say you want to add a column to your database. Because the django ORM is so popular and monolithic, it has amazing tools for the job that do it auto-magically when you modify models.py. And that's just one facet of many. For some folk, the flexibility of Pyramid is nothing but a bother.
  - cookiecaper 14y ago
    No, because you don't have to use the flexibility. Pyramid comes with defaults. You can blissfully just use what comes out of the box, or you can, relatively easily, use something else. There is no cost to the programmer who simply wants to ignorantly use the default tool set.

monkeypizza 14y ago

I use jinja2 with django, it's good. https://github.com/coffin/coffin/ https://github.com/coffin/coffin/

cookiecaper 14y ago
The problem is that someone has to create that project as anything more than a shim in the first place. There is no reason a generic web framework should require a full-fledged compatibility effort to switch out what should be "just another library". Note that there are several incompatibilities with "true" Jinja2 at the bottom of that readme, and that support for built-in "Django tags" is necessary. This is far less adaptable than Pyramid, which makes most internal functionality like that accessible via the request object, which can be accessed by your template language's typical variable evaluation syntax, and which can use Mako or the default Chameleon with just a one-line configuration change, or Jinja2 and others by installing a simple shim layer that is mostly boilerplate. Personally, I've tried to use mako with django and found it unwieldy to pass the correct information across the controller-template barrier. This was some time in the past, however, so perhaps either the adapter or documentation has improved and the problem no longer exists. The real issue, however, is that a generic web framework would make it difficult to replace unrelated user-facing libraries in the first place.
- SoftwareMaven 14y ago
  Given the callback nature of the Django templating library with template tags, includes, and other goodies, it is not as simple as "call foo_template() and return string". As soon as a template tag is involved, internal data structure needs to be exposed, with makes * everything* much harder.
zalew 14y ago
there is also https://github.com/jbalogh/jingo https://github.com/jbalogh/jingo Jingo serves purely as a minimalistic bridge between Django and Jinja2. Coffin attempts to reduce the differences between Jinja2 templates and Django's native templates.

bebop 14y ago

Just as a note to everyone, you can use Mako/Jinja2, SQLAlchemy and really any other Python tool/library out there with Django. What Django does well is provide a pre-built and (IMHO) easy to use set of default tools. This does not mean that you must use these tools, they are just there by default if you need them. You could really just use Django as an HTTP routing tool.

cookiecaper 14y ago
I admit it's been a while, but when I tried django-sqlalchemy in the past, it was not in a pleasant state. Last I came around, it was certainly not just a simple drop-in thing. While I'm sure you're right that it's not a hard requirement in that you can figure out how to make it work, it's not an easy thing, and you'll be fighting the framework and the conventions all along the way as interdependent stuff stops working. Again, in my experience. If things have improved significantly, I'd like to know. When toys ship "batteries included", it's easy to pull them out and replace with a different brand, if you want. Django, and most other web frameworks, don't make that interoperability a serious concern, afaik. When you use a framework, you are essentially adopting its code into your project all at once, and you become responsible to make sure it works and adapts to your needs even if upstream dies out or makes a decision that renders new versions unusable for your use case. "Non-removable batteries" are therefore a major design flaw in your project, even if you haven't had occasion for it to be exposed yet. The batteries of monolithic, "opinionated" web frameworks like Rails and Django may be partially removable, and maybe they've improved recently, but newer frameworks like Flask and Pyramid don't have this issue at all, and it makes them much more flexible.
- hknews 14y ago
  Just wondering if you have any tips (that you recall) for making django and sql alchemy work together. sql alchemy seems like the best ORM to work with and django has a nice ecosystem. If sql alchemy only does read operations on django models, will that make the integration simpler?

rburhum 14y ago

I built http://www.modewalk.com/ http://www.modewalk.com/ from scratch using Django. I do have "plenty of exposure", and the default template engine worked just fine. The default ORM is just fine. Most of the defaults are just fine.

rashthedude 14y ago
Hey, very interesting site indeed. I had a few questions about what other stacks/technologies you've made use of. Drop me a line or two on rashid.aden.omar@gmail if you could. Thanks
- rburhum 14y ago
  thanks. Sure, I'd be happy to share my rationale for the components I picked. Sending you an e-mail.
cookiecaper 14y ago
Again, the issue isn't whether "the defaults are just fine". It's a larger design problem, where a framework makes illegitimate assumptions and imposes illegitimate requirements, making it difficult to swap out components that shouldn't be mission critical. This is excused as "opinionated design", which, as I explain in another comment, is another way to say "bad design with an attitude".
- SoftwareMaven 14y ago
  Opinionated design is not "bad design with attitude". You may disagree with the opinons, but those opinions are thought through and made for the best interests of all the users. It is not uncommon for you to sit in the outside the "norms" the framework is shooting for, but that is not a problem for either you or the framework. A framework that tries to be all things to all people generally sucks for everybody.
  - cookiecaper 14y ago
    >A framework that tries to be all things to all people generally sucks for everybody. Right, I agree. I like a framework that tries to be a generic web framework for most people who want to write a typical web application in Python. That seems adequately specific to me. I don't consider that "opinionated design", it's simply identifying a market. "Opinionated design" is an excuse to make interopability and cross-compatibility difficult. There are, generally speaking, few good reasons to do this. Things that are totally out of scope obviously shouldn't be integrated, but if you feel the need to bundle a certain type of library with your framework, shouldn't it be sensible that someone might want to tweak that someday, or replace it with another library that does the same thing in a different way? Opinionated design is about copping out of that logic and putting a smooth sheen on it, it's saying "OK, we understand this is a reasonable, in-scope requirement, but we're opinionated and cool, like Steve Jobs, so we're just going to say you have to use this library or you're SOL. Remember, we are cool like Apple, and that's why we can tell you off in this fashion". Not "only projects that implement this prudent, adaptive, and objectively important-for-our-use-case protocol will work", but "only this library" or "only this way". Projects that don't suffer from scope creep or far-fetched, irrelevant integration aren't called "opinionated design", they're simply called "well-managed". It doesn't come from having an opinion and telling everyone else to shove it. It comes from having goals and the discipline, reason, and structure in place to stick to them.

Alex3917 14y ago

"the templating in Django is awful compared to Mako/Jinja2, the ORM in Django is awful compared SQLAlchemy" You can use Django with Jinja2 and SQLAlchemy.

wahnfrieden 14y ago
And you lose a lot of the benefits of Django, to be fair. We use Jinja2 on DrawQuest but it was a bit messy to add back features like the Django context processor.
- SoftwareMaven 14y ago
  I'd love to hear more. We are considering Django with Jinja2, primarily because I think some of the Django template opinions are a bit wrong. I don't want to fight one direction in my efforts to keep from fighting another, though. I'd prefer the details I know. :)
robertfw 14y ago
Yes, but you start making life difficult with regards to the app ecosystem, which imo is the main reason for using django

mixmastamyk 14y ago

The templating is simple on purpose, to keep logic out of them. Seems like a reasonable design to me.

bmelton 14y ago
If separation of duties is a concern, Django's templates (IMO) get it more right than anything else. I remember, at one point, that I felt Django templates were limiting me, and started swapping them out piecemeal for Jinja, and my designers started to absolutely hate me. Not because they had to convert anything, I converted everything by hand, but just that the amount of syntax you can cram in there keeps everything less pure. Since then, I realized I was trying to do too much in the template and started putting things where they belonged, and now, whenever I work with Jinja or Mako, it feels a little too much like editing Wordpress themes or something in PHP. Long story short, I learned the hard way that if you're putting logic in the templates, you're probably doing something wrong, and I agree that it is not only a reasonable design, but a very good suggestion as well.

coldtea 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. Define awful in concrete terms. I've not been much constrained by Django in any way. Even if all of those are "better" in some spec-listing way, Django could still be better by offering better integration for it's tools. Like the iPhone, in actual use, beats phones that are better than it "spec-wise".

rbanffy 14y ago

While I agree with you Jinja and SQLAlchemy have nice features absent from their Django counterparts, I would not call them awful. There are problems Django solves and problems Pyramid solves and there I nothing wrong in using one or the other.