4 ms·

While we are at the topic of Python web frameworks, I seriously like Flask's design better than django's. True that django came out before SQLAlchemy or Jinja2

by irahul 15y ago

While we are at the topic of Python web frameworks, I seriously like Flask's design better than django's. True that django came out before SQLAlchemy or Jinja2 became popular/existed, but I would have loved it had they re-factored. Django is great, with good re-usable components, but I like Jinja2 more than Django's templating. The argument for SQLAlchemy is more on the lines of I would prefer a standard ORM compared to everyone baking their own. SQLAlchemy used to be verbose, but the declarative extension now takes care of it. Other things I like about flask are explicit app object, and context locals.

BerislavLopac 15y ago
First, it's quite simple to replace Django's templating engine with Jinja. And second, Django's ORM isn't quite the equivalent of SQLAlchemy; the latter is supposed to be a true universal ORM, while the former is more limited, but focusing on the most important parts for a Web app.
- irahul 15y ago
  > First, it's quite simple to replace Django's templating engine with Jinja. Yes, it is. But most of the applications are tightly coupled with Django's ORM(auth, for eg, which I use very frequently), and in the end, I end up maintaining two types of templates which I don't like. > And second, Django's ORM isn't quite the equivalent of SQLAlchemy; No, it isn't. But SQLAlchemy does what django's orm does, and then some. I would prefer a compartmentalized model, where a web framework doesn't implement templating or ORM, provided a robust solution exists. The templating engine and ORM should be independent libs, and the web framework should glue them together, possibly adding a declarative layer above them(render_to_response, declarative ORM etc).
rlander 15y ago
Totally agree with you on this. I think Flask is Django done right and I've been beating that drum for quite some time (see, for example, my comments on the settings file [1]). The core devs claim that SQLAlchemy and Jinja weren't around at the time Django was developed, and that's fine. But in 2012, Jinja2 and SQLAlchemy are clearly better alternatives to Django's defaults. So why not incorporate them? Django doesn't even have first class support for Jinja2 templates, let alone the python HAML variants. What's ironic is that a few years ago Django was known for being loosely coupled when compared to Rails, which was considered monolithic ("my way or the highway"). Nowadays Rails is the flexible framework, allowing for different ORMs and templating systems, while Django is now the monolithic framework. Don't get me wrong, I love stability. But when a great percentage of developers are using hacks to get around the default configuration system and to support excellent external libraries like Jinja2 and SQLALchemy, something is very wrong. [1] http://news.ycombinator.com/item?id=3556929 http://news.ycombinator.com/item?id=3556929
Chris_Newton 15y ago
We've been using Flask recently, and I do like the simple, no-nonsense approach. Our project is modest in its library needs, and it's nice to have a useful toolkit without imposing a heavyweight structure on our code. There are significant limitations with some of these frameworks today, though. For example, lack of byte range/partial content support is bad news if you're serving large files (think multimedia). We're still investigating options here, but WSGI doesn't seem ideally suited to working that way, and as far as we can tell quite a few of the "microframeworks" lack any kind of support for returning partial content automatically. The concern seems to be that WSGI would need the application to generate a complete response even if it was going to serve only part of it as a 206, because there's no standardised part of the routing set-up that says "I need these byte ranges from whatever full response you would have given me". A common philosophy seems to be that such files should be served statically by your front-end web server anyway, but that is not sufficient in all cases. For example, you might need to process the request through your framework to generate the response on demand, implement access controls, or integrate with a custom logging/analytics framework. [Edits: Trying to clarify key points.]
- irahul 15y ago
  A common philosophy seems to be that such files should be served statically by your front-end web server anyway, but that is not sufficient in all cases. For example, you might need to process the request through your framework to generate the response on demand, implement access controls, or integrate with a custom logging/analytics framework. Depending on your use case, you can either use X-sendfile header - validate request, then return a X-sendfile response for your front-end server; or use gevent to stream the response.
  - Chris_Newton 15y ago
    Thanks for the suggestions. In case it helps anyone else: It's something about the way that Flask handles a direct send_file that seems to be causing problems in our tests. However, we've found reports of sendfile not working properly on certain platforms and we're still investigating, so I'm not convinced at this stage that the problem is with Flask itself.
hessenwolf 15y ago
We're working with flask at the moment, and I have found it excellent. I really don't want to be bothered by anything to do with the web framework because I am already busy with the other stuff, and I've been able to ignore it all with flask because it is simple and lightweight it works. We used pylons for the last project, and there are areas I still don't make improvements on because it is too much effort to get into it.

by irahul 15y ago

BerislavLopac 15y ago

First, it's quite simple to replace Django's templating engine with Jinja. And second, Django's ORM isn't quite the equivalent of SQLAlchemy; the latter is supposed to be a true universal ORM, while the former is more limited, but focusing on the most important parts for a Web app.

irahul 15y ago
> First, it's quite simple to replace Django's templating engine with Jinja. Yes, it is. But most of the applications are tightly coupled with Django's ORM(auth, for eg, which I use very frequently), and in the end, I end up maintaining two types of templates which I don't like. > And second, Django's ORM isn't quite the equivalent of SQLAlchemy; No, it isn't. But SQLAlchemy does what django's orm does, and then some. I would prefer a compartmentalized model, where a web framework doesn't implement templating or ORM, provided a robust solution exists. The templating engine and ORM should be independent libs, and the web framework should glue them together, possibly adding a declarative layer above them(render_to_response, declarative ORM etc).

rlander 15y ago

Totally agree with you on this. I think Flask is Django done right and I've been beating that drum for quite some time (see, for example, my comments on the settings file [1]). The core devs claim that SQLAlchemy and Jinja weren't around at the time Django was developed, and that's fine. But in 2012, Jinja2 and SQLAlchemy are clearly better alternatives to Django's defaults. So why not incorporate them? Django doesn't even have first class support for Jinja2 templates, let alone the python HAML variants. What's ironic is that a few years ago Django was known for being loosely coupled when compared to Rails, which was considered monolithic ("my way or the highway"). Nowadays Rails is the flexible framework, allowing for different ORMs and templating systems, while Django is now the monolithic framework. Don't get me wrong, I love stability. But when a great percentage of developers are using hacks to get around the default configuration system and to support excellent external libraries like Jinja2 and SQLALchemy, something is very wrong. [1] http://news.ycombinator.com/item?id=3556929 http://news.ycombinator.com/item?id=3556929

Chris_Newton 15y ago

We've been using Flask recently, and I do like the simple, no-nonsense approach. Our project is modest in its library needs, and it's nice to have a useful toolkit without imposing a heavyweight structure on our code. There are significant limitations with some of these frameworks today, though. For example, lack of byte range/partial content support is bad news if you're serving large files (think multimedia). We're still investigating options here, but WSGI doesn't seem ideally suited to working that way, and as far as we can tell quite a few of the "microframeworks" lack any kind of support for returning partial content automatically. The concern seems to be that WSGI would need the application to generate a complete response even if it was going to serve only part of it as a 206, because there's no standardised part of the routing set-up that says "I need these byte ranges from whatever full response you would have given me". A common philosophy seems to be that such files should be served statically by your front-end web server anyway, but that is not sufficient in all cases. For example, you might need to process the request through your framework to generate the response on demand, implement access controls, or integrate with a custom logging/analytics framework. [Edits: Trying to clarify key points.]

irahul 15y ago
A common philosophy seems to be that such files should be served statically by your front-end web server anyway, but that is not sufficient in all cases. For example, you might need to process the request through your framework to generate the response on demand, implement access controls, or integrate with a custom logging/analytics framework. Depending on your use case, you can either use X-sendfile header - validate request, then return a X-sendfile response for your front-end server; or use gevent to stream the response.
- Chris_Newton 15y ago
  Thanks for the suggestions. In case it helps anyone else: It's something about the way that Flask handles a direct send_file that seems to be causing problems in our tests. However, we've found reports of sendfile not working properly on certain platforms and we're still investigating, so I'm not convinced at this stage that the problem is with Flask itself.

hessenwolf 15y ago

We're working with flask at the moment, and I have found it excellent. I really don't want to be bothered by anything to do with the web framework because I am already busy with the other stuff, and I've been able to ignore it all with flask because it is simple and lightweight it works. We used pylons for the last project, and there are areas I still don't make improvements on because it is too much effort to get into it.