4 ms·

It is very easy to say "Django has large design problems" and go on about how it "imposes ilegitimate requirements". Truth is that Django is a framework and by

by rburhum 14y ago

It is very easy to say "Django has large design problems" and go on about how it "imposes ilegitimate requirements". Truth is that Django is a framework and by definition, frameworks give you a way/structure to do things. If you don't want a framework, then there are several other options. The strength of Django comes from the huge quantity of packages you can swap in/out. You mentioned you don't like the Django Template engine and that Jinja s better. Easy to swap. Don't like the authentication? Swap it out for something else or use a custom one. Don't like the ORM? Dont't use it... sadly you'll be missing out on south which has saved me from sql schema and data migration headaches. Caching? Redis, Memcache, or write your own. It plugs easily. Async processing? Celery is only a few lines of code away. Indexing with Sphinx search or Lucene is trivial. Want to add automatic CSS/JS minification + bundling + sprite generation + cache busting? There are django apps for that. Need analytics? You only need two methods for middleware. I could go on forever... The point is that this is exactly what I expect from a framework. If the framework doesn't do it, the somebody has to - and that means it is me.

cookiecaper 14y ago
It's about the rigidity of the structure given. A framework is supposed to give me the tools and structure I need to do what I brought the framework in to do. On a web framework, that is to pipe I/O over the web, give me access to web-layer stuff like the request object, and provide a few other simple structural niceties like MVC (which itself is quite flexible in Pyramid (optionally, of course)). I don't want it constraining me to the point where the world breaks if I decide the default ORM or template is not making the cut. As for all the things you've mentioned, it's perfectly plausible to have those things occur in Sinatra/Flask/Pyramid/whatever. The structures they provide are sufficient to hook up the kind of things you've mentioned. It's only that smaller communities have fewer pre-packaged solutions. In most cases, if you're building a new, serious platform, you'll want to use something that you can believe in technically, even if initially you'll have to contribute some of those modules yourself. You must be willing to invest in things you believe in, or they will die.
- rburhum 14y ago
  I am sorry, but I am still failing to see your point. Let me address the specifics issues you brought up: Accessing the request object? In Django, there is a RequestContext that can be accessed all over the place (e.g. middleware, views, templates or wherever else you wish to pass it through). It has many helper methods that parse several thing only one method call away. The template engine? I have used Jinja in some projects with Django. It literally takes less than five lines of code to swap out. Look it up. The Django ORM? Don't make the calls. I have done a handful of projects where doing everything through the ORM would have been a really bad decision since the web app was mostly about being a front end for an analytics system with processing that took from hours to days to complete. Instead, I wrote raw PostgreSQL/PostGIS SQL queries all over the place that ran asynchronous and hooked up Hadoop Clusters for other items... everything being controlled through django-celery. It was really easy to do. The state currently uses it to do "serious" pollution, health and city growth analysis, hence why I fail to see your point. You mentioned Sinatra/Flask/Pyramid and such. Thore are good frameworks, but you also acknowledge that there are "smaller communities in few cases" and my point is that is exactly where django shines: the ecosystem. I like to build "new serious platforms", too. To do that, I use whatever is appropriate from Django and the community and I have yet to stumble upon something that keeps me stuck because of the decision I made. Granted, it is a hammer and sometimes you need a drill. Let me give you an example: One of the apps I needed to write is a realtime geolocation service. For that, I use websockets and node.js because of its non-blocking and persisted connection nature. Does that mean that I need to ditch Django altogether? Hell no, I let the front reverse proxy direct the websocket traffic to node.js and the rest to django. My node.js code is so tiny because it is just a Pub/Sub client proxy. Most of the work is done in async Celery/RabbitMQ workers (that use the Django ORM by the way). Doing this with Django is easy (well, to be fair, the credit should go to the vast amount of python libraries). I "believe [in Django] technically"... why? Because in the four years I have been using it I have yet to get stuck because of my decision to pick it. I don't use it for everything, but I do for 99% of web related work. Once again to the risk of repeating myself, I pick and choose the Django parts I need in a per-project basis. Funny enough, I still laugh everytime somebody complains about some performance thing and I pretty much see their face jaw drop to the ground when I install varnish in front, change two lines of code to tweak the expiration headers, and deploy the static content with a good CDN. 5x performance is not surprising. Yes, there are several Django apps that make this trivial to do. Sorry I still don't see the specifics of the points you are trying to make.

by rburhum 14y ago

cookiecaper 14y ago

It's about the rigidity of the structure given. A framework is supposed to give me the tools and structure I need to do what I brought the framework in to do. On a web framework, that is to pipe I/O over the web, give me access to web-layer stuff like the request object, and provide a few other simple structural niceties like MVC (which itself is quite flexible in Pyramid (optionally, of course)). I don't want it constraining me to the point where the world breaks if I decide the default ORM or template is not making the cut. As for all the things you've mentioned, it's perfectly plausible to have those things occur in Sinatra/Flask/Pyramid/whatever. The structures they provide are sufficient to hook up the kind of things you've mentioned. It's only that smaller communities have fewer pre-packaged solutions. In most cases, if you're building a new, serious platform, you'll want to use something that you can believe in technically, even if initially you'll have to contribute some of those modules yourself. You must be willing to invest in things you believe in, or they will die.

rburhum 14y ago
I am sorry, but I am still failing to see your point. Let me address the specifics issues you brought up: Accessing the request object? In Django, there is a RequestContext that can be accessed all over the place (e.g. middleware, views, templates or wherever else you wish to pass it through). It has many helper methods that parse several thing only one method call away. The template engine? I have used Jinja in some projects with Django. It literally takes less than five lines of code to swap out. Look it up. The Django ORM? Don't make the calls. I have done a handful of projects where doing everything through the ORM would have been a really bad decision since the web app was mostly about being a front end for an analytics system with processing that took from hours to days to complete. Instead, I wrote raw PostgreSQL/PostGIS SQL queries all over the place that ran asynchronous and hooked up Hadoop Clusters for other items... everything being controlled through django-celery. It was really easy to do. The state currently uses it to do "serious" pollution, health and city growth analysis, hence why I fail to see your point. You mentioned Sinatra/Flask/Pyramid and such. Thore are good frameworks, but you also acknowledge that there are "smaller communities in few cases" and my point is that is exactly where django shines: the ecosystem. I like to build "new serious platforms", too. To do that, I use whatever is appropriate from Django and the community and I have yet to stumble upon something that keeps me stuck because of the decision I made. Granted, it is a hammer and sometimes you need a drill. Let me give you an example: One of the apps I needed to write is a realtime geolocation service. For that, I use websockets and node.js because of its non-blocking and persisted connection nature. Does that mean that I need to ditch Django altogether? Hell no, I let the front reverse proxy direct the websocket traffic to node.js and the rest to django. My node.js code is so tiny because it is just a Pub/Sub client proxy. Most of the work is done in async Celery/RabbitMQ workers (that use the Django ORM by the way). Doing this with Django is easy (well, to be fair, the credit should go to the vast amount of python libraries). I "believe [in Django] technically"... why? Because in the four years I have been using it I have yet to get stuck because of my decision to pick it. I don't use it for everything, but I do for 99% of web related work. Once again to the risk of repeating myself, I pick and choose the Django parts I need in a per-project basis. Funny enough, I still laugh everytime somebody complains about some performance thing and I pretty much see their face jaw drop to the ground when I install varnish in front, change two lines of code to tweak the expiration headers, and deploy the static content with a good CDN. 5x performance is not surprising. Yes, there are several Django apps that make this trivial to do. Sorry I still don't see the specifics of the points you are trying to make.