Based on my own experiences building isomorphic JavaScript apps with Django, I haven't had any issues where I felt Django was getting in my way. I've tackled the problem in two different ways, both of which worked without any great difficulty:
1. The primary web-app is actually a node process. Everything you'd consider a view is handled by React and React-Router, data requirements are handled by making an HTTP request to Django REST Framework. This isn't especially efficient, since the base response times aren't great when you're depending on HTTP for data (this can obviously be improved by getting the data via other channels). 2. Use node purely as a rendering engine. I actually created an alternative to TemplateResponseMixin that communicated with a node process via zerorpc (chosen for the sake of simplicity) rather than rendering a template from disk. This abstraction could be made neater by packaging it up as a custom template engine that takes care of converting the data into a format that zerorpc accepts (ie no querysets or rich objects). This approach was significantly faster with base response times of about 8ms for a simple page with no data dependencies, but I felt I was implementing my routing logic twice (once in Django, once in node). The second approach is easier to get running at acceptable performance levels quickly, but is quite clunky to implement. Going forward I'm probably going to favour the first approach, which essentially means turning my Django projects into nothing more than a data layer, which is fine for me because I've found that once you're using React (or similar) heavily, you're not using much else from Django anyway. Andy On 2 June 2015 at 07:43, Emil Stenström <[email protected]> wrote: > On Tuesday, 2 June 2015 05:19:43 UTC+2, Bobby Mozumder wrote: >> >> At this point it’s probably easiest for Django to provide templates only >> for Javascript front-end, and for Django to only serve API endpoints. >> >> We really don’t need Django to serve HTML pages anymore, except for the >> initial page-load. >> > > In 2012, Twitter posted in their engineering blog about their conclusions > of trying to move all rendering to the client. It was just too slow. The > answer, and what is considered "best practice" now, is to render everything > on the server the first load, and render all subsequent page loads to the > client. This also means you get a nice fallback for clients that don't > support javascript. > > -- > 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 [email protected]. > To post to this group, send email to [email protected]. > Visit this group at http://groups.google.com/group/django-developers. > To view this discussion on the web visit > https://groups.google.com/d/msgid/django-developers/783577b2-79f4-4445-81de-3208a16037a4%40googlegroups.com > <https://groups.google.com/d/msgid/django-developers/783577b2-79f4-4445-81de-3208a16037a4%40googlegroups.com?utm_medium=email&utm_source=footer> > . > > For more options, visit https://groups.google.com/d/optout. > -- 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 [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CAOA51CX1Or0XDbtpEpN%2BZmwE3ExDG5c5nihfwR0vnWG4_CkLQw%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
