Hi,
I'm no experienced developer nor a Django contributor, but I "suffered"
from this theme too. What I tried in the past is to create a Django
"application", or more a framework (https://pypi.org/project/gdaps/), to
support "plugins" which consist of a backend (the django part), and an
included frontend (which shoud contain a "plugin" of a Js-framework like
Vue.js or Angular, etc) that "blends" in into the web client dynamically.
I have experimented with using templates serving Vue code, or separating
the part that is served to the browser from the Django backend in a
different directory, bypassing Django templates, and did not succeed much.
This all is not directly related to the theme here, but where it is
connected, is that, for writing a modern application nowadays, you IMHO
have to be responsive in the frontend, and I think that async calls are
not smart enough to solve that.
If you ever tried the "easiness" of Meteor, you always envy that when
using Django with templates.
So: If I had a wish to Santa Claus :-), I would really support Django
having "Channels" (or however it may be named) included more deeply into
the system: I think that the Templates approach is not the worst,
because it is very flexible. It just doesn't have a solution to the
communication problem between server and client. Again, if I could wish
something, It would be Integration of frontend frameworks into the
template language and having calls to e.g. DRF included INTO the
template language, like the "batteries included" approach of Meteor with
their "connected" variables that update automatically when another
client changes them.
This all is possible with Django DRF, channels and a modern Js
framework, but VERY much boilerplate code and hand-written updates,
no-way modern.
I know it's much I demand here - I just want to add my 2cents - Django
is GREAT software.
It's just that the frontend side (templates, auto-communication and data
bindings) did not gain that much love as the backend.
Maybe you'll say "Hey, Django IS only a backend". Yes and no. If so, you
can remove the templates completely. It's not a backend, it just
focussed on the backend more than on the frontend.
If there would be a way to integrate channels more deeply into Django,
together with frontend 2-way data bindings, push notifications etc., I
would really appreciate it and could imagine supporting that using money
too.
Cheers,
Christian
Am 22.01.19 um 15:18 schrieb John Obelenus:
Chiming in. As a long-time django user (nearly a decade), websockets
is an area that the project on the whole is very, very, far behind the
leading edge of the web industry. It's great, often desirable, to not
be *on* the leading edge, but in my opinion, the project is too far
behind it.
There are numerous projects where I would, now, not consider using
django (or at least, using it only for the admin to save time/effort).
That is the first issue that I see for the django project as a whole.
Secondly, and probably something Andrew expects to be helped (if not
outright solved), is the general speed of serving requests. Async can
absolutely help here (How much it helps is up for debate). As a
developer who is using a lot more NodeJS now the inherent speed in
that platform's request lifecycle can often be a game-changer in terms
of performance and resources needed.
On Monday, January 21, 2019 at 2:57:18 PM UTC-5, Andrew Godwin wrote:
On Mon, Jan 21, 2019 at 4:34 AM Michael Martinez
<writemicha...@gmail.com <javascript:>> wrote:
Hi Andrew
To me, Websockets is the defining use case for using Django
Channels. From a user POV, saying that Channels is focused on
the wrong problem (websockets) is like saying Django is too
focused on HTTP.
When I have selected Channels (vs other tools), my rationale
was not:
"/I need a general purpose async platform and it would be
great if it worked with Websockets, ZeromQ and played nice
with Django.../" (therefore Django Channels vs Tornado vs ...)
rather my rationale is more like:
"/I need to build real time features with Websockets using
Django../" (therefore Django Channels).
Oh, I totally get that, and Channels does well at providing
WebSockets - the problem is that it's still an area with a lot
less interest and also one I personally have no use for at the
moment. Those things combined mean that WebSockets is not
something I'm really interested in supporting for free right now;
I'd have to be paid to work on it (as I was with the Mozilla grant
for a lot of Channels' development).
Andrew
--
You received this message because you are subscribed to the Google
Groups "Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send
an email to django-developers+unsubscr...@googlegroups.com
<mailto:django-developers+unsubscr...@googlegroups.com>.
To post to this group, send email to
django-developers@googlegroups.com
<mailto:django-developers@googlegroups.com>.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-developers/b357add7-cd44-4c12-b29b-0d28150417a2%40googlegroups.com
<https://groups.google.com/d/msgid/django-developers/b357add7-cd44-4c12-b29b-0d28150417a2%40googlegroups.com?utm_medium=email&utm_source=footer>.
For more options, visit https://groups.google.com/d/optout.
--
Dr. Christian González
https://www.nerdocs.at
+43 650 7644477
--
You received this message because you are subscribed to the Google Groups "Django
developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-developers/540a7c52-4680-e7cd-a867-14a5a465e212%40nerdocs.at.
For more options, visit https://groups.google.com/d/optout.
