41–50 of 89 posts
If you are doing anything more than a simple CRUD, and heck, even if that's all, you should at least peek at how many queries are happening in views and how page render timing is broken down.
https://github.com/django-debug-toolbar/django-debug-toolbar
Maybe I'm delusional, but even as someone who has worked pretty extensively (4 months of full stack Django development) with Django, posts like these things make me want to stay away from Django. I read this post, and I see bandaids. I see bloat, and I see warts. I don't want to build on a codebase that needs 5 extensions out of the box to be sane. Granted, I know this is not the real story with Django. It is a rathe…
Implementations that stand out, like south, may get incorporated. Especially when they're valuable to the core of Django; all may not agree, but migrations (and class based views) should have been in there from the start.
Others depend on your needs. Don't force me into using TinyMCE as a rich text editor, I'll regretfully make that decision myself. I want to choose the best available package for my CDN host. I'm switching thumbnail processing engines because mine hasn't been updated in over two years.
Importing all of my models into the shell is best left as an explicit modification for those that want it. If it was a good idea, why wouldn't Django do it by default?
Reasons to use Django over other, lighter frameworks:
* The ORM
* Forms – The ORM
* contrib.admin
* Authentication
* Extendable command line interface
Maybe I'm delusional, but even as someone who has worked pretty extensively (4 months of full stack Django development) with Django, posts like these things make me want to stay away from Django. I read this post, and I see bandaids. I see bloat, and I see warts. I don't want to build on a codebase that needs 5 extensions out of the box to be sane. Granted, I know this is not the real story with Django. It is a rathe…
I want to build on a platform where far more than 5 extensions are needed to be sane -- I want the vast majority of my "core" functionality to be provided by an extension.
Far too often "Batteries included" means "Batteries soldered in with a thick layer of epoxy on top".
Maybe I'm delusional, but even as someone who has worked pretty extensively (4 months of full stack Django development) with Django, posts like these things make me want to stay away from Django. I read this post, and I see bandaids. I see bloat, and I see warts. I don't want to build on a codebase that needs 5 extensions out of the box to be sane. Granted, I know this is not the real story with Django. It is a rathe…
I don't want to build on a codebase that needs 5 extensions out of the box to be sane. I want to build on a platform where far more than 5 extensions are needed to be sane -- I want the vast majority of my "core" functionality to be provided by an extension. Far too often "Batteries included" means "Batteries soldered in with a thick layer of epoxy on top".
What, no django-annoying? That's the first thing I ever use: https://github.com/skorokithakis/django-annoying That, and shortuuid: https://pypi.python.org/pypi/shortuuid/ Disclosure: I maintain one and wrote the other, but they and South are the three things I use for every project.
It'd be nice if you were clear about what versions of django and python are supported.
From django-annoying's feature list:
* render_to - seems to be roughly equivalent to django.shortcuts.render
* signals decorator - now in core[1] (since 1.3)
* ajax_response - seems useful, though might make sense to check request.is_ajax[2]
* autostrip - hmm, seems oddly edge case-y, I definitely wouldn't apply it to all my forms
* get_object_or_None - nifty
* AutoOneToOneField - assumes the related model is valid with only the FK filled in, which seems fairly unlikely in many OneToOne cases. I'm not sure if this was proposed to core, but I'd think it would need some sort of default= fillin feature to be more generally useful.
* JSONField - soo many competing and variously featureful implementations. This has been discussed a few times; it seems fairly easy to implement and hard to gain consensus. I wish we could get it in core, but the juice doesn't seem worth the squeeze.
* get_config - I don't think I understand the purpose of this, unless you're just trying to be more intention-revealing than getattr(settings, ...)
* HttpResponseReload - nifty
* StaticServer - I don't think I understand why you wouldn't want to config urls.py instead.
[2] https://docs.djangoproject.com/en/dev/ref/request-response/#...
Maybe I'm delusional, but even as someone who has worked pretty extensively (4 months of full stack Django development) with Django, posts like these things make me want to stay away from Django. I read this post, and I see bandaids. I see bloat, and I see warts. I don't want to build on a codebase that needs 5 extensions out of the box to be sane. Granted, I know this is not the real story with Django. It is a rathe…
If it helps any, as someone who's been building Django sites for years, I will say that while all of those are at least handy, absolutely none of them is needed. On the list, the only one I use with any regularity is South, which I do consider must-have. That said, it seems that the Django core team agrees, as it's being (or maybe is even finished) pulled into Django core.
After that, I personally add allauth, storages, and s3-folder-storages as well, but that's a personal preference thing and there are very good reasons to use alternatives to each of those components.
Earlier quoted context omitted.
Here's the advice I was given: if you're going to go with an opinionated framework, go with Rails. If you really want to use Python over Ruby, go with Flask. His thought is that Ruby is more dogmatic than Python by design, so Rails' dogmatic nature lends itself to Ruby more. Python's flexibility lends itself to a more flexible, lightweight framework like Flask.
Python is more dogmatic than Ruby. http://www.python.org/dev/peps/pep-0020/ Choosing a minimalistic web framework like Flask or Sinatra makes sense if you're experienced enough to know what choices Django and Rails make for you and you're comfortable making those decisions on your own. Otherwise, pick Django or Rails and start building things.