4 ms·

Personally, I think mega frameworks are an anti-pattern. Once you're working on an even moderately serious project with multiple people, it makes sense to have

Personally, I think mega frameworks are an anti-pattern. Once you're working on an even moderately serious project with multiple people, it makes sense to have the various layers/tiers decoupled. Django is great because it does very well the one part it's supposed to be doing, without overreach. Not that it wouldn't be cool to have a Meteor-like in Python for rapid prototyping.

sametmax 10y ago
Django doesn't have "the one part". It's doing A LOT: - HTTP response life cycle - templating - routing - database access layer, including migrations - admin generation - authentication - session management - project life cycle - project layout - serialization - caching at several layers - settings management - web app sdk (with reusable views and pluggable apps) - data validation and form handling - event handling (mainly using signals) - security management (csrf token, xss escape, sql escape, signed cookie, ALLOWED_HOST...) - testing framework - dev toolkit (autoreloading runserver, auto server static file, etc) - command line management - i18n and l18n (including text translation and timezone handling) - RSS feed generation Django is HUGE. It is great because despite being huge, it's very, very, very well integrated. This is why pyramid didn't catch on as much: it's as big, but not as well integrated. This is why flask get away with it: it's not as well integrated, but it's not big. If you want to handle complex technologies like the one brought by crossbar, you can't expect most people to do it by hand. Not only it's not productive, especially at the begining of the project, but most devs simply don't have the skills to do so, nor should they have to. Imagine if most people had to do the CSRF code in Django. Or the create the admin by hand. Or reroll their authentication method every time. Do you think they would do it right ? Two months ago I worked with some administration, and they had a flask site. Because flask doesn't come with auth, instead of looking for a flask blueprint with it, they rolled their own. I was based on md5 hashed passwords without a salt. I kid you not.
- jkarneges 10y ago
  > was based on md5 hashed passwords without a salt. I kid you not. Yikes. :) Well yes, I suppose it comes down to where you draw the line about what should be coupled or not, but perhaps more importantly is the ability to opt-out of certain components or be able to substitute them. For me personally, I mostly care about separating the common service tiers (e.g. frontend/clients, server/api, database/queue/etc). Django's ORM works with multiple databases and is entirely optional either way. Also it has little opinion of how the frontend should work. This is great because we've used at least four different databases and three different frontend JS frameworks with Django. I'm confident any of the service tiers could be replaced (including the Django tier) without disrupting the others.
  - sametmax 10y ago
    > to opt-out of certain components or be able to substitute them. I agree. One of the problem I see currently is that you have either: - a good integration and a huge coupling - loose coupling but poor integration A good framework must provide movable parts to customize your stack, but a high level API to integrate the default provided part together to that if you don't swap them, they feel like a whole. I used vues, react, jquery and angular with Django, and I love the fact it doesn't requires me to use a particular front end tech. But I wished at least a contrib app would provide some help for the front end: routing, auth and all are just not DRY ATM.
- vosper 10y ago
  > This is why flask get away with it: it's not as well integrated, but it's not big. Flask does get away with it, though it's so unintergrated that as soon as you need anything beyond super super basic you're better off with something else.

sametmax 10y ago

Django doesn't have "the one part". It's doing A LOT: - HTTP response life cycle - templating - routing - database access layer, including migrations - admin generation - authentication - session management - project life cycle - project layout - serialization - caching at several layers - settings management - web app sdk (with reusable views and pluggable apps) - data validation and form handling - event handling (mainly using signals) - security management (csrf token, xss escape, sql escape, signed cookie, ALLOWED_HOST...) - testing framework - dev toolkit (autoreloading runserver, auto server static file, etc) - command line management - i18n and l18n (including text translation and timezone handling) - RSS feed generation Django is HUGE. It is great because despite being huge, it's very, very, very well integrated. This is why pyramid didn't catch on as much: it's as big, but not as well integrated. This is why flask get away with it: it's not as well integrated, but it's not big. If you want to handle complex technologies like the one brought by crossbar, you can't expect most people to do it by hand. Not only it's not productive, especially at the begining of the project, but most devs simply don't have the skills to do so, nor should they have to. Imagine if most people had to do the CSRF code in Django. Or the create the admin by hand. Or reroll their authentication method every time. Do you think they would do it right ? Two months ago I worked with some administration, and they had a flask site. Because flask doesn't come with auth, instead of looking for a flask blueprint with it, they rolled their own. I was based on md5 hashed passwords without a salt. I kid you not.

jkarneges 10y ago
> was based on md5 hashed passwords without a salt. I kid you not. Yikes. :) Well yes, I suppose it comes down to where you draw the line about what should be coupled or not, but perhaps more importantly is the ability to opt-out of certain components or be able to substitute them. For me personally, I mostly care about separating the common service tiers (e.g. frontend/clients, server/api, database/queue/etc). Django's ORM works with multiple databases and is entirely optional either way. Also it has little opinion of how the frontend should work. This is great because we've used at least four different databases and three different frontend JS frameworks with Django. I'm confident any of the service tiers could be replaced (including the Django tier) without disrupting the others.
- sametmax 10y ago
  > to opt-out of certain components or be able to substitute them. I agree. One of the problem I see currently is that you have either: - a good integration and a huge coupling - loose coupling but poor integration A good framework must provide movable parts to customize your stack, but a high level API to integrate the default provided part together to that if you don't swap them, they feel like a whole. I used vues, react, jquery and angular with Django, and I love the fact it doesn't requires me to use a particular front end tech. But I wished at least a contrib app would provide some help for the front end: routing, auth and all are just not DRY ATM.
vosper 10y ago
> This is why flask get away with it: it's not as well integrated, but it's not big. Flask does get away with it, though it's so unintergrated that as soon as you need anything beyond super super basic you're better off with something else.