However, in the context of the web (the client/server boundary), I think we need to be careful about how messaging is used. The web is made up of resources with URLs. HTTP is typically used for data transfer, and for good reason.
I sometimes see webapps communicating entirely over WebSockets. I don't mean just the realtime push part, I mean everything, request/response traffic and all. I understand that HTTP is suboptimal in certain contexts, but let's not throw the baby out with the bathwater.
I can imagine a large Django app that uses mostly plain request/response but needs, say, a small customer service bot or occasional real time notifications. This new feature is perfect for that.
"Careful" == do not break urls, use pushState and make sure equivalent document is returned for GET.
If you're the sole developer of a Single Page App with no API, then this difference may not be important. But if you're working with a team, or across teams, then building a WebSocket-only app will bring pain. As another commenter mentioned, as long as equivalent actions are possible via HTTP then some of the issues are alleviated.
And even the newer stuff isn't so much Websockets as it is serving JSON to single-page apps.
I've wanted to like Django (because Python is my preferred language) but it still feels so crufty from its origins as a newspaper server.
Care to elaborate?
Source: https://en.wikipedia.org/wiki/Django_(web_framework)#History
Personally I think the templating system is less and less useful because I'm serving single page apps that I don't really benefit from serving from Django any more (or are Angular and the variable syntaxes conflict with each other)
Overall very good docs though :)
Drop in a custom user model and
a) Better be a brand new project at all
b) You need to muck with the user manager also
c) How do you fix up the admin module? I have yet to see a fully fixed up admin module for the custom user.
I am not a Django pro so happy to be proved wrong. But take a default app, and record all steps to make the user model work (including password reset, login, logout, admin page). If that doesn't feel crufty to you I am not sure what cruft is.
https://github.com/danjac/ownblock/blob/master/ownblock/ownb...
Links or references to documented slowness?
http://nando.oui.com.br/2014/04/04/why_i_sort_of_dislike_dja...
It's nice to dabble around Pyramid and/or Flask, but everytime I use, or someone I know uses them for not completely trivial microservices, they are always reinventing those 'cookie cutters' from scratch on their own (or choose a set of 'cookie cutters' made by someone else).
Django can work as a 'microframework', i.e. 'hello world' in one file and in ~10-15 LOC.
Not to mention Django's 'stability', i.e. stable releases at known time, with known ahead roadmap and forthcoming changes, great documentation, etc., whereas Flask has not been released for 2years and 9months (!!!), master is 900 commits ahead (2400 commits in total) of latest version, documentation is not the best (especially for current `master`)... Pyramid is made by true rockstar programmers, though it did not stand against hip image of flask and it suffers from the fact that I must reinvent all the 'cookie cutters'. IMHO this 'microframework' approach is good only for trivial microservices and/or completely non-trivial, crazy custom apps, where overriding Django would be just too much.
Actually a core tenet of Python is: "There should be one-- and preferably only one --obvious way to do it".
So Django couldn't be more Pythonic in this regard.
No, there are several. But all of them should strive to be Pythonic, including in the sense of offering "one, and preferably only one, obvious way to do something".
>Dumb comment.
Oh, the irony.
>I was talking about architectures not syntax.
And the Zen of Python is about architecture and APIs too, not just the syntax of the language. They are generic guidelines about how to write Pythonic programs.
(I work in a shop which has used both, and generally try to avoid claiming one or the other is objectively better; they're not quite at the apples-and-oranges level, but pretty close)
That's not to say there are projects where another framework/language would have been better but no solution is going to save you from poor project management.
Django is like any other framework/language. Bad programmers can make a hash of it with ill-conceived ideas.
There is no boilerplate or constraint how those 'flexible' solutions should be created, thus every developer writes however he wants and if those developers have not made constraints for themselves you will have a total mess, written in so many styles as there were developers. Jeez, I've even seen messed up Django apps, where you usually must follow some patterns.
Patterns, constraints, models, architecture are for a reason and if a framework/language/library makes you use some specific styles, it's much easier to maintain such projects when there is more than 1 person working on them.
Flask provides the basics to build Web apps. It's low on opinions and flexible. I mostly use flask for systems that are very specific about their functinality and use case.
It's a batteries included framework, but at the end of the day it's just Python. You can integrate with whatever library is best for the job.
I've worked on Django apps that use SQLAlchemy instead of the Django ORM, Django apps that use Mako instead of the Django template language, and I'm currently exploring using Marshmallow instead of Django forms for some cases.
Is there anything in particular that you feel you can use with Flask or Pyramid but you couldn't use with Django?
What I found is that if you can manage stay within the confines of Django, you will be rewarded and can avoid writing a ton of code. There really isn't to many situation where you can't just to things "The Django Way". If you find one, then maybe rethink your solution. I had a ton of code where I tried to fight the Django Rest Framework, when I stopped and just accepted that Django and the Rest Framework is opinionated I was able to reduce complexity and line count.
Of cause there are problems where Django is simply the wrong solution.