6 ms·

What I really want in a web framework is for it to stay out of my way. In that regard I have been happy with Flask. All of the functionality lives in externa

by yaur 12y ago

What I really want in a web framework is for it to stay out of my way. In that regard I have been happy with Flask. All of the functionality lives in external modules (many of which are reused in back end tools) with the relatively simple task of HTTP interactions living in a Flask powered facade.

nikentic 12y ago
I feel just the same. It feels much more modular than Django's module system.
andybak 12y ago
What I really want in a web framework is for a web framework to solve the common problems so I can write less code unless I'm doing something unusual. In that regard I have been happy with Django. All of the functionality does what you'd expect and nearly everything is overridable in a consistent way when you need to get closer to the 'metal'.
- possibilistic 12y ago
  This is just my personal experience, but once you try to do certain things with Django, you start to butt heads with it. Django relies far too much on convention, and it shoehorns you into their tooling patterns. I think the most exciting and flexible way to do things these days is with a collection of microservices. You can do feature work independently, test small isolable units of functionality, and achieve scale.That said, we could use cross-cutting libraries to make microservice implementation easier...
  - wahnfrieden 12y ago
    Have concrete examples where Django gets in the way? Re: microservices, I think it's much healthier to frame that debate as a matter of tradeoffs rather than one approach being universally better suited than the other.
    - oq64diyt 12y ago
      > Have concrete examples where Django gets in the way? Add support for multiple-column primary keys https://code.djangoproject.com/ticket/373 https://code.djangoproject.com/ticket/373 Opened 9 years ago NULL fields and Unique keys https://code.djangoproject.com/ticket/4136 https://code.djangoproject.com/ticket/4136 Opened 7 years ago
      - nkuttler 12y ago
        So you're saying things nobody cared enough about to get them implemented in 7+ years? You'll find bugs old like this in any open source project.
  - gtaylor 12y ago
    We've been pretty happy with it at Pathwright. 1.7 was a great release. The conventions aren't too restrictive, and it has been incredibly easy to get contractors plugged in and productive in minimal time. We follow many best practices, so our codebase is going to be "familiar" (to some extent) to anyone with some experience. We love Django for the productivity level our team achieves with it. The ecosystem is great, too. django-rest-framework in particular makes us oh-so-happy. Not to knock flask/Pyramid/everything else. Pick what your team can be most productive wit. I just think there are less reasons than ever to get too caught up in choice of framework. There are so many great options now.
    - ryan_sb 12y ago
      > Pick what your team can be most productive with Absolutely. If you already know one and like it, go forth and hack. If you're not sure, or don't like the one you have, there are tons of great options. Not just Flask/Django/Pyramid either. Tornado, Bottle, CherryPy, Falcon, and more all have dedicated users (some more than others).
  - edwinnathaniel 12y ago
    Ever since the beginning of the rise of microservice "architecture" we all know that a complete web-framework like Rails/Django does not fit the toolbox so I would suggest not to discuss the excess baggage/shortcoming of software X that is 90% designed to do Y to be applied to a different problem domain. Developers tend to get excited building microservices because let's be honest, most of us aren't Ops that have to watch those services 24/7. During the development of Microservices, everything looks rosy, as things evolved, if the organization does not have the skill-sets and the discipline to maintain these microservices, things fall down pretty quickly. Take logging as an example, I'm betting that many microservices implementation would find it a wee bit challenging to trace a user transaction end-to-end.
- jessedhillon 12y ago
  Eh, they all solve the same problems. Django has the additional requirement that you think exactly like the designers of the monolithic framework or you will spend a lot of time swimming upstream. Ever tried to integrate Django or Celery into a project whose configuration comes from .ini files or some other method? You end up writing your own configuration layer to get something that Django approves of. Don't even get me started on the ORM -- why does it even exist when we have SQLAlchemy? In the end, convention over configuration (just put your files in the magic locations, for example) is just another term for developer arrogance: of course my way is natural and everyone will want to think like me! With something like Pyramid I never find myself following a debugger down into the guts to understand why it is or isn't doing something -- I have to do this all the time with Django because some piece of magic isn't working as advertised. Ultimately, something like Django is concerned with "how can I make it work?" What professional engineers should be concerned with are questions like "what happens when it doesn't work?" and "will someone else be able to understand this?" With Django, what happens when it doesn't work is you find yourself about 13 levels deep in the stack looking at some wrapper class in this giant framework. If you do have to get into a Pyramid component, most of them are actually just individual projects, a single developer can understand the whole thing. The entire work of engineering is to make it work, without also making it comprehensible to others and easily serviceable -- and do it fast. Picking Django because it makes it easy to start a new project is just satisfying one of those, unless you really understand deeply the bowels of the framework or expect to hire someone who does.
  - drl42 12y ago
    I think that Django actually has very little "magic", given the functionality that it provides. With respect to the ORM - For standard CRUD stuff, I think the ORM just works. With respect to "Will someone else understand the code" - Having trained few engineers to use Django, the main issue always has been correct decomposition of the entire webapp into different submodules or Django "apps" - If the project has been properly modularized, then it is easy to find problems or add functionality. In short, imho writing good serviceable code does not depend upon the framework - it depends upon the team :)
  - gtaylor 12y ago
- deleted 12y ago
  [deleted]
- Walkman 12y ago
  Django is not known about it's 'overridability'. The only part which is easy to switch/leave is the template engine. Otherwise it makes not much sense to use Django if you want to 'override' any other component.
  - wahnfrieden 12y ago
    What parts would you like to override that are difficult to do so?
    - gtaylor 12y ago
      Some people want to replace the ORM, but I find myself dropping into SQL in places where I need more advanced features. Django is sometimes chided for its simplistic ORM, but I've actually started thinking that if you are going to use an ORM at all, it probably should only be used for the more simple cases. Fortunately, the vast majority of queries in our codebase at Pathwright are pretty simple. You need not be afraid to use SQL when you need to do something more advanced. You don't need to feel dirty about it. Postgres in particular can do many more things than any ORM is going to be able to cover 100%. Sometimes you can flat out do something much more efficiently than the ORM can with a simple SQL statement. If you follow this line of thinking, I'm not sure there's a great reason to bother wedging SQLAlchemy into Django, if I'm just going to end up dropping down into SQL for the more advanced queries.
      - wahnfrieden 12y ago
        The ORM lets you write raw SQL with .extra: https://docs.djangoproject.com/en/dev/ref/models/querysets/#extra https://docs.djangoproject.com/en/dev/ref/models/querysets/#... and still get ORM objects back in return, or with .raw: https://docs.djangoproject.com/en/dev/topics/db/sql/ https://docs.djangoproject.com/en/dev/topics/db/sql/ or just by manipulating cursors directly. Nothing in Django makes it harder to use raw SQL...
      - raverbashing 12y ago
        I agree, sure, you lose portability (or you can have a generic slower ORM case if it's that important) but dropping down to the SQL in corner cases is perfectly valid (and helpful)
jessedhillon 12y ago
I choose Pyramid for the same reasons. Additionally, through paster I've been able to create custom empty project templates to easily get started on projects.
- ryan_sb 12y ago
  Yeah, paster is awesome, esp since there's so many great skeletons on PyPi already.
truncate 12y ago
Staying out of way is relative to developer to developer. I'm not experienced web developer. For me it was very quick to get started with Django and get things done. Documentation and community support is great, and so for Django related libraries. However I found its templating system getting in my way as compared to Jinja. Flask again damn easy to start with. However I had to spend time looking for auth frameworks, making it work, and found documentation for flask related libraries not very complete. Some modules seemed to be inactive.
- desaideas 12y ago
  I had a similar experience with setting up Django for the first time. The community is actually quite vibrant and I found an expert on AirPair that guided me through my use case.

by yaur 12y ago

nikentic 12y ago

I feel just the same. It feels much more modular than Django's module system.

andybak 12y ago

What I really want in a web framework is for a web framework to solve the common problems so I can write less code unless I'm doing something unusual. In that regard I have been happy with Django. All of the functionality does what you'd expect and nearly everything is overridable in a consistent way when you need to get closer to the 'metal'.

possibilistic 12y ago
This is just my personal experience, but once you try to do certain things with Django, you start to butt heads with it. Django relies far too much on convention, and it shoehorns you into their tooling patterns. I think the most exciting and flexible way to do things these days is with a collection of microservices. You can do feature work independently, test small isolable units of functionality, and achieve scale.That said, we could use cross-cutting libraries to make microservice implementation easier...
- wahnfrieden 12y ago
  Have concrete examples where Django gets in the way? Re: microservices, I think it's much healthier to frame that debate as a matter of tradeoffs rather than one approach being universally better suited than the other.
  - oq64diyt 12y ago
    > Have concrete examples where Django gets in the way? Add support for multiple-column primary keys https://code.djangoproject.com/ticket/373 https://code.djangoproject.com/ticket/373 Opened 9 years ago NULL fields and Unique keys https://code.djangoproject.com/ticket/4136 https://code.djangoproject.com/ticket/4136 Opened 7 years ago
    - nkuttler 12y ago
      So you're saying things nobody cared enough about to get them implemented in 7+ years? You'll find bugs old like this in any open source project.
- gtaylor 12y ago
  We've been pretty happy with it at Pathwright. 1.7 was a great release. The conventions aren't too restrictive, and it has been incredibly easy to get contractors plugged in and productive in minimal time. We follow many best practices, so our codebase is going to be "familiar" (to some extent) to anyone with some experience. We love Django for the productivity level our team achieves with it. The ecosystem is great, too. django-rest-framework in particular makes us oh-so-happy. Not to knock flask/Pyramid/everything else. Pick what your team can be most productive wit. I just think there are less reasons than ever to get too caught up in choice of framework. There are so many great options now.
  - ryan_sb 12y ago
    > Pick what your team can be most productive with Absolutely. If you already know one and like it, go forth and hack. If you're not sure, or don't like the one you have, there are tons of great options. Not just Flask/Django/Pyramid either. Tornado, Bottle, CherryPy, Falcon, and more all have dedicated users (some more than others).
- edwinnathaniel 12y ago
  Ever since the beginning of the rise of microservice "architecture" we all know that a complete web-framework like Rails/Django does not fit the toolbox so I would suggest not to discuss the excess baggage/shortcoming of software X that is 90% designed to do Y to be applied to a different problem domain. Developers tend to get excited building microservices because let's be honest, most of us aren't Ops that have to watch those services 24/7. During the development of Microservices, everything looks rosy, as things evolved, if the organization does not have the skill-sets and the discipline to maintain these microservices, things fall down pretty quickly. Take logging as an example, I'm betting that many microservices implementation would find it a wee bit challenging to trace a user transaction end-to-end.
jessedhillon 12y ago
Eh, they all solve the same problems. Django has the additional requirement that you think exactly like the designers of the monolithic framework or you will spend a lot of time swimming upstream. Ever tried to integrate Django or Celery into a project whose configuration comes from .ini files or some other method? You end up writing your own configuration layer to get something that Django approves of. Don't even get me started on the ORM -- why does it even exist when we have SQLAlchemy? In the end, convention over configuration (just put your files in the magic locations, for example) is just another term for developer arrogance: of course my way is natural and everyone will want to think like me! With something like Pyramid I never find myself following a debugger down into the guts to understand why it is or isn't doing something -- I have to do this all the time with Django because some piece of magic isn't working as advertised. Ultimately, something like Django is concerned with "how can I make it work?" What professional engineers should be concerned with are questions like "what happens when it doesn't work?" and "will someone else be able to understand this?" With Django, what happens when it doesn't work is you find yourself about 13 levels deep in the stack looking at some wrapper class in this giant framework. If you do have to get into a Pyramid component, most of them are actually just individual projects, a single developer can understand the whole thing. The entire work of engineering is to make it work, without also making it comprehensible to others and easily serviceable -- and do it fast. Picking Django because it makes it easy to start a new project is just satisfying one of those, unless you really understand deeply the bowels of the framework or expect to hire someone who does.
- drl42 12y ago
  I think that Django actually has very little "magic", given the functionality that it provides. With respect to the ORM - For standard CRUD stuff, I think the ORM just works. With respect to "Will someone else understand the code" - Having trained few engineers to use Django, the main issue always has been correct decomposition of the entire webapp into different submodules or Django "apps" - If the project has been properly modularized, then it is easy to find problems or add functionality. In short, imho writing good serviceable code does not depend upon the framework - it depends upon the team :)
- gtaylor 12y ago
deleted 12y ago
[deleted]
Walkman 12y ago
Django is not known about it's 'overridability'. The only part which is easy to switch/leave is the template engine. Otherwise it makes not much sense to use Django if you want to 'override' any other component.
- wahnfrieden 12y ago
  What parts would you like to override that are difficult to do so?
  - gtaylor 12y ago
    Some people want to replace the ORM, but I find myself dropping into SQL in places where I need more advanced features. Django is sometimes chided for its simplistic ORM, but I've actually started thinking that if you are going to use an ORM at all, it probably should only be used for the more simple cases. Fortunately, the vast majority of queries in our codebase at Pathwright are pretty simple. You need not be afraid to use SQL when you need to do something more advanced. You don't need to feel dirty about it. Postgres in particular can do many more things than any ORM is going to be able to cover 100%. Sometimes you can flat out do something much more efficiently than the ORM can with a simple SQL statement. If you follow this line of thinking, I'm not sure there's a great reason to bother wedging SQLAlchemy into Django, if I'm just going to end up dropping down into SQL for the more advanced queries.
    - wahnfrieden 12y ago
      The ORM lets you write raw SQL with .extra: https://docs.djangoproject.com/en/dev/ref/models/querysets/#extra https://docs.djangoproject.com/en/dev/ref/models/querysets/#... and still get ORM objects back in return, or with .raw: https://docs.djangoproject.com/en/dev/topics/db/sql/ https://docs.djangoproject.com/en/dev/topics/db/sql/ or just by manipulating cursors directly. Nothing in Django makes it harder to use raw SQL...
    - raverbashing 12y ago
      I agree, sure, you lose portability (or you can have a generic slower ORM case if it's that important) but dropping down to the SQL in corner cases is perfectly valid (and helpful)

jessedhillon 12y ago

I choose Pyramid for the same reasons. Additionally, through paster I've been able to create custom empty project templates to easily get started on projects.

ryan_sb 12y ago
Yeah, paster is awesome, esp since there's so many great skeletons on PyPi already.

truncate 12y ago

Staying out of way is relative to developer to developer. I'm not experienced web developer. For me it was very quick to get started with Django and get things done. Documentation and community support is great, and so for Django related libraries. However I found its templating system getting in my way as compared to Jinja. Flask again damn easy to start with. However I had to spend time looking for auth frameworks, making it work, and found documentation for flask related libraries not very complete. Some modules seemed to be inactive.

desaideas 12y ago
I had a similar experience with setting up Django for the first time. The community is actually quite vibrant and I found an expert on AirPair that guided me through my use case.