5 ms·

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 framewor

by 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.
    - gtaylor 14y ago
      > I just believe it's a non-optimal choice, in almost any situation. And this is where your argument loses every bit of credibility, this is an awful, unsubstantiated blanket statement. I'll be the first to bemoan Django for its flaws (it has many, as do all frameworks), but this is absurdly misguided thinking. There are tons of success stories to the contrary, with new ones adding to the pile every day. > The argument to be made, then, is why that obligation and rigidity and bigness are valuable, which thus far, no one has really done. I think you're missing the point entirely. Your claims of rigidity aren't applicable for everyone. For a very large number of users, Django doesn't need to be super de-duper modular/interchangeable (it's good enough for many/most). In fact, some people don't want the complexity of SQLAlchemy. Some don't even know/care what jinja is (I personally haven't felt the desire to switch to it, as I feel it has problems of its own). Django is batteries included. Pyramid is not. These are two different approaches that each have tradeoffs. > 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. Again, not everyone wants these pieces you are talking about. While SQLAlchemy is a great piece of a software, it is a complex piece of software with a steeper learning curve than the simple Django ORM. There are plenty that don't need/want something as heavy duty as SQLAlchemy. In my case, if I need the absolute best performance or advanced features, I am writing SQL instead of dealing with any ORM that makes bad choices for me. More ORM is not attractive to me, I tend to dislike them for anything but the most simple cases (ie: the basic Django ORM operations). That is where your blanket statement falls to tatters. Differing requirements, different priorities. > I'm just saying, "it's unwise", for almost any large-scale new project. And not all advice is created equally :) I'd say that it is appropriate for some large-scale projects and teams, and inappropriate for others. It's flat out wrong to make a blanket statement like yours.
      - cookiecaper 14y ago
        No, I'm not sure why you're so dedicated to promoting Django's negative qualities as if they're virtues. The rigidity is not preferable, in any circumstance. It's simply less adaptive, and therefore less useful, architecture. If you want simple, you can use adaptive frameworks simply. They come with defaults just like Django does. The difference is that it's easy to swap or mix-and-match components, and it's an intended use case. On Django, if you don't go with vanilla, it's a hack. As I wrote elsewhere, "batteries included" doesn't (or shouldn't) mean "batteries hard-welded". It's fine to include stuff and have defaults; adaptive frameworks have these too, but they considered the fact that someone may want to do something irregular at some point and that it shouldn't be a world-breaking experience for that to happen. A framework that understands its place is all gain, in that it doesn't intrude and try to force something, and no loss, in that it also comes with defaults that you can just use if you aren't yet at a stage where you'd have a reason to replace them, and therefore, from an objective technical standpoint, it is a better choice. Perhaps social issues override this in some situations, but those can't be considered in our removed, objective, technical context. >I'll be the first to bemoan Django for its flaws (it has many, as do all frameworks), but this is absurdly misguided thinking. There are tons of success stories to the contrary, with new ones adding to the pile every day. It doesn't matter if there are success stories. I'll repeat myself, I guess, and say that I don't intend to say that Django is useless or terrible or that it does nothing and will ruin your life. The point is that most people who choose Django for technical (not social like "we all already know django") reasons are making an incorrect choice. For now "we all already know django" is acceptable, just like "well we all already know SVN" was, but at some point it won't cut it anymore, and you'll be expected to adapt. >Django is batteries included. Pyramid is not. I disagree. Pyramid comes with batteries. It has a full stack ready to go for you if you just want to open it up and code, just like Django does. The difference is that Pyramid allows you to tweak or swap freely as necessary, and Django makes it difficult. >It's flat out wrong to make a blanket statement like yours. No, it isn't. My blanket statement is generally but not all inclusive. Is it wrong to say "Using Windows 2000 as the primary hosting platform for new projects is almost always wrong"? Things change in tech. Rigid generic frameworks that try to dictate templaters and ORMs are old hat, they are plainly incorrect for all but the most esoteric use cases. There is no good reason to do this. Is Django going to disappear overnight? No, but I hope that people can get past their holy wars and take a serious objective analysis. Consider that you're actually against a useful feature set just because the less-powerful solution is often "good enough". That's not a reason to choose a thing, it's just a reason not to flee from a thing. I'm not saying every Django app needs to be rewritten, but I do think it's silly to settle on "good enough" for new stuff when "much better" is available at little or no downside.
cglace 14y ago
The only thing I hated about django was using south for migrations. It was a huge headache.
- vhost- 14y ago
  The company I work for just switched _to_ south from a custom migration system and it has been really awesome. It streamlined out development process a bit as well.
- bmelton 14y ago
  I never really loved them until I started working on a massive Django project with Oracle. South doesn't support Oracle, and now I have to manually tweak tables every time I update a schema. Since that happened, I fricking love South.
- jtchang 14y ago
  So what did you use instead? Let me just say having migrations is a "good thing". I know one place that just does SQL stuff by hand when they go to production. Seriously?!
  - cglace 14y ago
    I still used south for migrations I just found that I ended up editing the migration files for every migration.
    - rburhum 14y ago
      why? For the data migrations?

by jtchang 14y ago

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.
  - gtaylor 14y ago
    > I just believe it's a non-optimal choice, in almost any situation. And this is where your argument loses every bit of credibility, this is an awful, unsubstantiated blanket statement. I'll be the first to bemoan Django for its flaws (it has many, as do all frameworks), but this is absurdly misguided thinking. There are tons of success stories to the contrary, with new ones adding to the pile every day. > The argument to be made, then, is why that obligation and rigidity and bigness are valuable, which thus far, no one has really done. I think you're missing the point entirely. Your claims of rigidity aren't applicable for everyone. For a very large number of users, Django doesn't need to be super de-duper modular/interchangeable (it's good enough for many/most). In fact, some people don't want the complexity of SQLAlchemy. Some don't even know/care what jinja is (I personally haven't felt the desire to switch to it, as I feel it has problems of its own). Django is batteries included. Pyramid is not. These are two different approaches that each have tradeoffs. > 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. Again, not everyone wants these pieces you are talking about. While SQLAlchemy is a great piece of a software, it is a complex piece of software with a steeper learning curve than the simple Django ORM. There are plenty that don't need/want something as heavy duty as SQLAlchemy. In my case, if I need the absolute best performance or advanced features, I am writing SQL instead of dealing with any ORM that makes bad choices for me. More ORM is not attractive to me, I tend to dislike them for anything but the most simple cases (ie: the basic Django ORM operations). That is where your blanket statement falls to tatters. Differing requirements, different priorities. > I'm just saying, "it's unwise", for almost any large-scale new project. And not all advice is created equally :) I'd say that it is appropriate for some large-scale projects and teams, and inappropriate for others. It's flat out wrong to make a blanket statement like yours.
    - cookiecaper 14y ago
      No, I'm not sure why you're so dedicated to promoting Django's negative qualities as if they're virtues. The rigidity is not preferable, in any circumstance. It's simply less adaptive, and therefore less useful, architecture. If you want simple, you can use adaptive frameworks simply. They come with defaults just like Django does. The difference is that it's easy to swap or mix-and-match components, and it's an intended use case. On Django, if you don't go with vanilla, it's a hack. As I wrote elsewhere, "batteries included" doesn't (or shouldn't) mean "batteries hard-welded". It's fine to include stuff and have defaults; adaptive frameworks have these too, but they considered the fact that someone may want to do something irregular at some point and that it shouldn't be a world-breaking experience for that to happen. A framework that understands its place is all gain, in that it doesn't intrude and try to force something, and no loss, in that it also comes with defaults that you can just use if you aren't yet at a stage where you'd have a reason to replace them, and therefore, from an objective technical standpoint, it is a better choice. Perhaps social issues override this in some situations, but those can't be considered in our removed, objective, technical context. >I'll be the first to bemoan Django for its flaws (it has many, as do all frameworks), but this is absurdly misguided thinking. There are tons of success stories to the contrary, with new ones adding to the pile every day. It doesn't matter if there are success stories. I'll repeat myself, I guess, and say that I don't intend to say that Django is useless or terrible or that it does nothing and will ruin your life. The point is that most people who choose Django for technical (not social like "we all already know django") reasons are making an incorrect choice. For now "we all already know django" is acceptable, just like "well we all already know SVN" was, but at some point it won't cut it anymore, and you'll be expected to adapt. >Django is batteries included. Pyramid is not. I disagree. Pyramid comes with batteries. It has a full stack ready to go for you if you just want to open it up and code, just like Django does. The difference is that Pyramid allows you to tweak or swap freely as necessary, and Django makes it difficult. >It's flat out wrong to make a blanket statement like yours. No, it isn't. My blanket statement is generally but not all inclusive. Is it wrong to say "Using Windows 2000 as the primary hosting platform for new projects is almost always wrong"? Things change in tech. Rigid generic frameworks that try to dictate templaters and ORMs are old hat, they are plainly incorrect for all but the most esoteric use cases. There is no good reason to do this. Is Django going to disappear overnight? No, but I hope that people can get past their holy wars and take a serious objective analysis. Consider that you're actually against a useful feature set just because the less-powerful solution is often "good enough". That's not a reason to choose a thing, it's just a reason not to flee from a thing. I'm not saying every Django app needs to be rewritten, but I do think it's silly to settle on "good enough" for new stuff when "much better" is available at little or no downside.

cglace 14y ago

The only thing I hated about django was using south for migrations. It was a huge headache.

vhost- 14y ago
The company I work for just switched _to_ south from a custom migration system and it has been really awesome. It streamlined out development process a bit as well.
bmelton 14y ago
I never really loved them until I started working on a massive Django project with Oracle. South doesn't support Oracle, and now I have to manually tweak tables every time I update a schema. Since that happened, I fricking love South.
jtchang 14y ago
So what did you use instead? Let me just say having migrations is a "good thing". I know one place that just does SQL stuff by hand when they go to production. Seriously?!
- cglace 14y ago
  I still used south for migrations I just found that I ended up editing the migration files for every migration.
  - rburhum 14y ago
    why? For the data migrations?