On Tuesday, 2 June 2015 12:58:22 UTC+2, Andrew Ingram wrote: > > 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: >
I think the reason that Django has not been in the way here is that you have pushed it out of the way, and just reimplemented features that Django should have in javascript instead. I'm not saying this is bad for your project, it's just a shame that it's not something that Django can handle. More concretely: 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). > Here you use routing and views from React instead of using Django. The problem with this is as you say latency since getting data is a HTTP request, but you also get slow initial load times since there's no content to show. Rendering on the server first to get a quick initial load, and then delegating to React would give us the best of both worlds. > 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). > This sounds excellent. It's almost like implementing a new template engine, but instead just running it through node. The downside is that it requires you to install, deploy and maintain a separate javascript environment. What js template language were you using? I think implementing that same language for Django would give you the best of two worlds. All server-side rendering would remain like for any server-side app, but you could also send your templates to the view for fast client side rendering. > 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. > Did you read the Twitter post on this (https://blog.twitter.com/2012/improving-performance-on-twittercom)? They went the same route, moving all template logic to the client, found it was too slow on initial load, and then favoured the dual approach I'm hoping for. -- 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/da6ffda5-b6b0-4d41-91f0-d6101a3ddd2d%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
