Isn't it nice when you not only understand what an article is about from the headline, but also get all the necessary information from it alone? Short and to the point.
The ultimate would be if Adobe's CEO used an iPad to post a message on Facebook which was leaked out because his privacy settings were changed when he wasn't looking, and then Steve Jobs replied.
I'm not too excited because I always use the development version of Django. Django-trunk is always surprisingly stable and hasn't given me any crashes.
same here, although I am excited about 1.2 being released as it will mark the end of the bug tracking stage, and the start of the 1.3 feature discussions.
True I hope drag and drop ordering for inlines is finally added so I can stop rolling my own to work with the updates, though I guess I can understand if they're hesitant to include jQueryUI in addition to jQuery in admin interface.
I've been watching this pretty closely; the multi-db in 1.2 alone makes it worth the upgrade. It's about a 20 line backend router to get round-robin RODB usage, which is very welcome for sites under high read loads.
A lot of systems have been redone to take custom XBackend classes (like the CacheBackend before it, EmailBackend and others are now available), and in my experience this is a good level of access for customizing parts of Django.
Lots of applications aimed at Django are already 1.2 compatible. They've really spent a long time (a few months after freeze) making sure this release is going to be solid, so I have high hopes.
The original commenter might have their own thoughts, but after using both Symfony and Django here are mine:
- A well organized, much more cohesive plugin structure: http://www.symfony-project.org/plugins/
Plugins are versioned with compatibility matrices for each major Symfony release, and indexed in a centralized location.
- Much better extensibility of both framework and plugin classes. You can easily subclass any existing model class to customize to your needs. Django is severely lacking here (e.g. customizing auth.User to accept an email based login without breaking existing apps that rely on auth.User).
- Much better customizability of the admin interface.
- Very powerful model level validation. This isn't Symfony so much as Doctrine, which is the best PHP ORM I've ever worked with.
- symfony project:deploy production is pretty sweet.
Of course, in general, I still prefer Django to Symfony.
- PHP as a language is so unexpressive that Symfony has resorted to using YAML files and code generation to represent configuration data and model objects.
- The code generation gets a bit unwieldy at times (tons of classes and empty subclasses).
- Frankly, if your language is so verbose that you end up needing to store your data in a different format (e.g. YAML and PHP, XML and Java), you're using the wrong language.
- Jinja2 is also a much nicer templating language than straight PHP.
When it comes to authentication, wouldn't it be rather easy to subclass the ModelBackend class to simply use email instead of username if that's what you want? And if you want to extend user.Auth with more user data, they have a way of doing so as well, without subclassing: http://www.b-list.org/weblog/2006/jun/06/django-tips-extendi...
Could you be more specific as to what kind of things the Symfony/Doctrine model level validation can do?
1) Yes, it is possible to subclass the ModelBackend. That's not the only step involved in switching from username based logins to email based logins, however, since the default User definition has defined a required username CharField that takes some hackery to get around.
2) Symfony does the same thing with a one to one User <-> Profile relationship. I find this to be a silly hack in both frameworks that creates extra database JOINs for no reason. If I want to place a foreign key on the user table because multiple Users can belong to a single Account, I shouldn't have to go through an additional join table.
3) You can configure Doctrine to raise an exception if you try to save() a model object with invalid fields, and check if the fields are valid at any time with isValid(). It makes a lot more sense to me to do this at the model level since there are many scenarios where you still want validation and aren't actually using forms of any sort.
Re. customizing auth.User to accept email based login - There isn't a completely DRY solution for this, but it's got much better - here is a tiny app that will do it for you:
It seems to me there would be a major bug since the existing auth.User email field definition is not unique and allows blank values, and this app doesn't do anything to check against that, nor does it do anything to remove the existing username field definition.
models/ORM
Doctrine does better job.
- abstract model definition via yml file
- multiple connections/databases/environments easily managed
- Cool API (shortcuts, relations, custom tables etc.) + DQL for queries + support for multiple DB engines
admin interface / CRUD interface
- they are easy to generate but easier to customize under symfony.
- you can do 90% of the stuff via a config file generator.yml.
The rest is extending the generated code and customizing queries to the model
configuration
- you can do more via the config files in Symfony and control your project/applications vs Django.
forms system
- the abstract forms system comes with generated forms based on your model, widgets with validations, binding with your model, customizable renderers.
You can have a custom CRUD interface up and running and linked to your tables in less than a few minutes.
routing
- routing.yml and sfPatternRouting does a much better job without using complex regex patterns
- Also, all routes are abstract, understandable and well located.
testing
- Unit testing and functional testing is very well done. You can launch specific tests, launch failed tests only, call your model/forms easily because they are all objects, simulate a browser session etc.
You can do all that stuff with Django but will a lot more code.
framework vs API
- symfony abstracts anything useless as a plugin where Django tends to integrate some of it in their Framework (CSV, PDF generators etc.). That's a lack of vision.
Anyway, just a couple of points, I could go on and on ;-)
Because all the things you say are either wrong (multiple db engines, forms for CRUD) or a matter of taste (the use of YAML, regexes for routing, including batteries).
And, for the language thing, PHP is plain horrible.
Agreed. Seems to me his answer is mostly taste rather than actual use.
The thing about "complex regex" struck me as odd. Why are his routing regexes complex? If they're that hard to write, then I'd suggest he'd revisit the routing scheme.
I haven't used Symfony before because I rather not develop in PHP unless I really have to. Having said that, If i ever have to, I'd like to give Symfony a try.
is literally the most retarded syntax I've ever seen for invoking an object callback, and is indicative of PHP's roots as a non object oriented scripting language.
No doubt, the way PHP deals with functions is one of the worst parts about the language. create_function and the rest have been made a bit better, though, with the introduction of anonymous functions in PHP 5.3.
forms system - Disagree, Django forms and generic views let you do the exact same thing.
routing - Disagree. I've used several routing systems across web frameworks and it mostly comes down to a matter of taste. Django's system could probably be a little simpler (most of the time you don't need the full power of regexes to match simple numbers or string) but it gets the job done and stays out of my way.
testing - Disagree. Why did they write their own testing framework (lime) when SimpleTest and PHPUnit already existed?
framework vs API - Agreed. The added downside is that once a third party app makes it into Django core, it evolves much more slowly due to backwards compatibility issues.
Also, I seriously tried to use Doctrine for a PHP project and though it seems great at first, I ended up going back to raw SQL. I have used Django and it's ORM, and I had no desire to do raw SQL.
Symfony seems way over-engineered to me, and the horror of the PHP syntax really turns me off (though I'm quite familiar with PHP). If I'm going to use PHP, I'd rather just do what it is best at and get straight to the point.
I am pretty good at Django. But Django is really disappointing. I've switched back to PHP. These are the problems:
1. Django has a steep learning curve
2. Django speeds up the start of the project, but afterwards development gets slow. Real slow.
3. Impossible to find django programmers that are not horribly expensive
4. The django app model makes code a mess. It's a horrible model and does not create reusable code.
5. Django is instable. I have to restart my server ever minute when running Django
6. If you use something like Pinax, the amount of memory django consumes is massive
7. Your site may run fine with normal traffic, but increase to about 100 a minute and the site starts giving bad gateway errors. Be CONSISTENT in your errors, django
8. The django people are slow. It has been years and django has barely changed
9. The templating scheme cannot be outsourced. You need a programmer to understand it
10. The nifty tricks they have to render your pages with shortcuts are very difficult to understand. Really difficult to understand
Django is not a nice framework. I believed in django for two years, but I've moved on. It's a good theoretical framework, but it's a terrible practical framework.
1. Really? Compared to throwing a few pages out with PHP but on complex apps the time you save not reinventing the wheel would be the payback.
2. Hard to know what you were doing wrong without more info.
3. I've found excellent Django coders for less than $15 dollars/hour through freelancer sites.
4. The conventions around reusable code are growing up as the Django ecosystem grows up. There are good and bad examples but it's very possible to write reusable apps if you use the right architecture and separation of concerns.
5. Again. You are doing something wrong.
6. Django does use more memory than a simple mod_php setup and Pinax is a complex project but I'd like to see numbers once you compare apples to apples. ie. PHP+framework as a long running process matching Pinax for functionality. Would the memory requirements be that different?
7. Sounds like it's your server technology that's giving you those errors. You'd have to tell us what the underlying Python errors were for us to know whether Django was at fault or your setup.
8. You are not alone in thinking this but that is viewed as a feature for people trying to run stable sites. If you want to live on the bleeding edge then join the django-experimental branch that has opened recently on Github
9. Huh? Most people complain the Django template system is too simple and therefore limited.
10. I have no idea what you are trying to say here.
You do sound slightly trollish. Give us a bit more info to go on and we can have a constructive debate.
I know you are a smart guy, but I totally disagree with almost everything you said:
1. Django has a steep learning curve
-> Django has a learning curve for hard stuff, like context processors, complex queries, fixtures, etc., but if you just want to make a simple website fast, then Django is easy. Python is simple to understand, Django is extremely well-documented for beginners, and there is a lot of out-of-the-box functionality to work with,
2. Django speeds up the start of the project, but afterwards development gets slow. Real slow.
-> I haven't found this to be the case. I have found that if you make poor design decisions at the beginning of a project, it will crawl to a halt regardless of the language or framework involved.
3. Impossible to find django programmers that are not horribly expensive
-> Never tried, can't comment.
4. The django app model makes code a mess. It's a horrible model and does not create reusable code.
-> There's a difference between reusable code and reusable apps, and Django apps lead to the latter.
5. Django is instable. I have to restart my server ever minute when running Django
-> Not me... sounds like you don't use mem-caching.
6. If you use something like Pinax, the amount of memory django consumes is massive
-> Can you benchmark this against a RoR or Joomla... I think this is unsubstantiated.
7. Your site may run fine with normal traffic, but increase to about 100 a minute and the site starts giving bad gateway errors. Be CONSISTENT in your errors, django
-> mem-caching!
8. The django people are slow. It has been years and django has barely changed
-> This is crazy. Django is being actively developed... 1.0, 1.1, 1.2 were all about a year apart and this involved massive improvements including stuff that personally mattered to me like geo-django being rolled into trunk.
9. The templating scheme cannot be outsourced. You need a programmer to understand it
-> I have yet to find a good designer I could outsource any sort of HTML/CSS that didn't cost an arm and a leg.
10. The nifty tricks they have to render your pages with shortcuts are very difficult to understand. Really difficult to understand
-> I don't understand what you mean here.
Django is not a nice framework. I believed in django for two years, but I've moved on. It's a good theoretical framework, but it's a terrible practical framework.
10. The nifty tricks they have to render your pages with shortcuts are very difficult to understand. Really difficult to understand
-> I don't understand what you mean here.
I tend to concur with your lack of understanding. Does he mean render_to_response? direct_to_template? I mean, jeez, their functionality is pretty much obvious in the naming.
(Not OP, but I do work with Django every day for the past couple of months):
1. Django docs, while great compared to many other projects, are still quite lacking, especially in examples.
3. It's probably true, compared to the quantity of PHP coders out there. The average Django dev is probably better than the average PHP dev - again, quantity - but you don't always need the skills/costs of a really good dev. Sometimes you just need someone to install & customize Wordpress.
5. Not sure how memcache is related to that, but in any case - if your app can use significant caching, framework/language performance isn't an issue to begin with.
6. I don't really get the Pinax - RoR comparison.
7. See 5.
8. Honestly, coming to Django from RoR, and knowing that they both got going around the same time, I sometimes wonder what Django folks have been up to all that time ;) (To be fair, there are definitely things Rails could learn from Django)
9. Templating was just a poor design choice for Django, IMHO. Instead of using Python in the templates, as RoR/PHP do, you basically need to learn a new single-use language, which in time will inevitably get more like a real language anyway.
Regarding 1, the documentation is quite clear to me. Then again, this is an open source project and if you think that the documentation is lacking, then by all means try and improve it. If not for your benefit, then for the benefit of others like you. Speaking from experience, the core devs are very helpful on the list.
Regarding 5, I think he means that the OP was not using the caching layer which should drop the load significantly. I think he's hinting that the slowdown is from the database rather than Django itself.
Regarding 9, that's a matter of taste. I find their template tags quite good and I hate the tag soup with other systems. However, every templating system is going to be a compromise. Personally, I have no idea how to design one that would please both designers and programmers.
>Then again, this is an open source project and if you think that the documentation is lacking, then by all means try and improve it
Sure, but when it comes to a making a choice between technologies, most people would pick the one that already has good docs.
>I think he's hinting that the slowdown is from the database rather than Django itself
If that's the case, the OP wouldn't see much difference between Django & other solutions.
>Regarding 9, that's a matter of taste
Absolutely, as well as workflow. I'd say if you work in a place where designers write the HTML separately from developers, a templating language makes sense. If developers do it, using the native language is preferable.
>Your point 3 is just plain weird
How's that? (1) PHP is far more common than Django. (2) As result, Django devs cost more but have higher average skill. (3) Some web dev jobs are relatively low skill, so it's useful to have someone who can do them cheaply.
When I hear someone complain that Django doesn't have good docs it comes across to me like, say, I'm overhearing a teenager, who is seeing the Sears Tower in Chicago for the first time, and he says, "Not tall enough. Lame."
I have to laugh, really.
More perspective: I did graphics programming in an evil mix of BASIC and 6502 Assembly, way back long ago. Later I learned OpenGL -- a bit easier, but still a lot of learning curve, math, non-ideal docs, etc. Then I learned PyGame -- muuuuch easier. Then I was in a club meeting and heard a developer (who of course was pimping the latest foshizzle mine-not-yours graphics/game framework du jour) say something like, "PyGame? Too much boilerplate, too complex, too hard to learn." Left me speechless.
Perhaps in 50 years we'll reach a point where if anything that needs to be done isn't fully automated and handed to us on a silver platter, people will complain, "Needs a button I can push to make it happen. No button. Lame. I'm going back to bed."
I didn't complain about Django's docs. In fact I called them "great compared to many other projects". I did note they aren't perfect yet. (Basically I have the same opinion on Django as a whole)
Looks like this discussion is becoming another platform war, something I'd hope HN & Django would avoid. FWIW, I also taught myself Z80 assembly back in the day. So? If I had an alternative that was easier to learn, I'd definitely take it. Unlike the 80s, users now are a download away from switching to a different platform if they find it more friendly. I think Django's developers actually realize that better than most.
Many sites, including us run django and cope with several 100's of requests per minute, without issue, I've never had django become unstable or a single gateway issue. How did you try and host django?
It was a pretty low end server at webfaction. The point I'm making is that it should give me the same errors at low load that it gives at high load. But with django when you change your load, the errors change.
We have one of those as well, they arent suitable for any site where you are expecting 100's of queries per minute (unless you dont touch the db :)) the gateway error is probably a lack of django processes being made available to serve requests. This is probably nothing to do with the framework itself and is a hosting issue, try another provider, just my 2cents..
Specifically with Webfaction, that's exactly what's going on; it has to do with the particulars of their typical Django setup on the shared hosting. (I've had the same "Bad Gateway" errors from PHP sites at Webfaction... it's very much a server setup issue, not anything to do with the code it's running.
Exactly... It's common for epople to think that the framework covers every aspect of the technical architecture of the actual website/service itself - probably a natural assumption due to how the web evolved - Apache, static files, then some light scripting, then PHP. it doesn't - it's just an underlying framework.
If you're expecting web-scale traffic - you have to engineer for it from the ground up - servers, content-delivery networks, design decisions, caching strategies and technologies.... yadda yadda yadda.... no framework is a magic pill that does it all - and if it were, it would quickly be outdated and inflexible.
When something is malfunctioning, it's not very surprising when it malfunctions evenly and error reporting gets weird.
You should monitor server behaviour and throttle traffic back when it's close to its limits. I usually see things on monitored servers (check memory allocation over time - how much cache, how much process, how much kernel, iowait time, swap for sharp increases) in time to issue corrective measures.
Tuning maximum processes/threads on Apache seems one simple way to prevent that. Memcache and Varnish are also your friends with that - anything that prevents the workload from reaching Apache is.
That pretty much negates your intro. If it's too hard for you, then, maybe, you are not good at it.
> 2. Django speeds up the start of the project, but afterwards development gets slow. Real slow.
Django apps maintain elegance and consistency for far more development iterations than anything else I have used before. That's the opposite of what I experience.
> 3. Impossible to find django programmers that are not horribly expensive
It's also impossible to find bad Django programmers
> 4. The django app model makes code a mess. It's a horrible model and does not create reusable code.
What are you talking about? Even the built-in admin app is a pluggable application. Unless you are careless, everything is modular
> 5. Django is instable. I have to restart my server ever minute when running Django
I have been pounding (100 simultaneous connections, 800 requests/second) a server that will enter production next week for 18 hours straight now. It shows no sign of stress. Maybe you should fire your sysadmin.
> 6. If you use something like Pinax, the amount of memory django consumes is massive
Memory is relatively cheap. Memcache and MySQL consume most of the server memory on the above scenario.
> 7. Your site may run fine with normal traffic, but increase to about 100 a minute and the site starts giving bad gateway errors. Be CONSISTENT in your errors, django
Like I said above, I am running 800 requests per second out of a two-server front-end + 1 backend for 18 hours with no error and no slowdown. You should monitor your machine carefully to identify problems. Maybe you are running too many HTTP listeners, maybe you are using mod_python instead of mod_wsgi. I won't troubleshoot your server for you.
> 8. The django people are slow. It has been years and django has barely changed
We call it consistency
> 9. The templating scheme cannot be outsourced. You need a programmer to understand it
Apart from ZPT, I never saw a template a designer couldn't mangle. And some did mangle ZPT templates badly.
> 10. The nifty tricks they have to render your pages with shortcuts are very difficult to understand. Really difficult to understand
Again, I think the problem is not on the tool side.
1. "The Framework for Perfectionists with Deadlines", not "The Framework for Non-Programmers Who Don't Know How Pick Up A Framework"
2. What?
3. Good talent is generally not free. Turns out that right now, a lot of good talent happens to like Django. Perhaps this indicates something, hm?
4. As opposed to writing raw SQL for different RDBMS's?
5. What?
6. If you use something large like Photoshop, the amount of memory it consumes is large, too. Pinax is a large collection of apps. Turn off the parts you don't need!
7. What? Setting up sites to handle 1k reqs/second is trivial with a little bit of caching.
8. Perhaps you should read release notes then, hm?
9. Welcome to Django -- don't use the parts you don't like. People have successfully used Jinja with Django to good effect. But your claim of the template language being hard for designers to understand is bullshit. The most advanced logic they have to deal with is if/else, and even that got easy in 1.2 with the smart-if tag.
10. See point 1.
You might not like Django for a lot of valid reasons -- but all of these weren't.
Everything has a steep learning curve once the framework has been integrated into an actual product. You could say the same about having to learn a new PHP deployment, or a Java servlets based product.
