> On Jan 4, 2017, at 5:40 PM, Adam Johnson <[email protected]> wrote: > > How do people serve development Javascript & CSS files? These days > Javascript & CSS involves a large build process. Are we forced to manually > restart the development server every time Javascript changes? > > Django just serves them from the filesystem, and doesn't cache them itself. > You reload the page in your browser, and Django serves the files from disk > > Does the Django development server restart if you edit Templates? Because it > should also do that. > > Similarly, by default templates aren't cached, so on each view the dev server > loads the templates from disk, parses them, and renders them. >
Does it do the same under production environments - read and interpret each template file on every request? Is there interest in making a much faster version of this flow? > > On 4 January 2017 at 22:31, Bobby Mozumder <[email protected] > <mailto:[email protected]>> wrote: > > > On Jan 4, 2017, at 4:47 PM, Aymeric Augustin > > <[email protected] > > <mailto:[email protected]>> wrote: > > > > Hello Bobby, > > > >> On 4 Jan 2017, at 22:25, Bobby Mozumder <[email protected] > >> <mailto:[email protected]>> wrote: > >> > >> It’s actually called once on app startup during DB connection via a Signal. > > > > Unless I missed something, since the development server creates a new > > connection to the database for each request — Python’s threaded socket > > server creates a new thread for each connection and database connections > > are thread local in Django — prepared statements will be refreshed for each > > request. So I don’t think you need autoreloading here. > > Hmm I thought the test server used permanent connections if CONN_MAX_AGE was > set to None? Could have sworn it was that way for a while? > > In any case, I just tried the Javascript & CSS Makefile with a simple one > line change to one file, and it took 4 seconds. That’s going to be way too > long to do on each request. > > How do people serve development Javascript & CSS files? These days > Javascript & CSS involves a large build process. Are we forced to manually > restart the development server every time Javascript changes? > > I think it should be just like changing Python files and it autoreloads > Javascript & CSS as it changes. > > Also, I haven’t used the Django Template system or Jinja in over a year. > Does the Django development server restart if you edit Templates? Because it > should also do that. > > This is what I’m getting at with this autoreload.. it should include the full > system, not just the Python files. > > > > >> (This whole process helps speed up the view response generation times. I > >> can generate a full page in about 4ms, and that includes GZip.) > > > > Off topic, but I’m jealous… > > > > Also, my average page generates in 1-2ms, and fully cached html serves in 200 > microseconds, and that include Gzip, since I cache Gzip (which makes my cache > 10x bigger). There’s lots that I can contribute here, including > non-blocking analytics stored in teh database. If I can make it “generic” > enough I’ll try to publish it, but the code is really manual. Maybe instead > of a formal toolset, I could post a methodology manual? It’s really tedious > though, involving materialized database views & all sorts of other techniques. > > BTW My site is at http://www.futureclaw.com <http://www.futureclaw.com/> > > > <rant> > > > > I still believe we should stop maintaining an autoreloader as soon as > > possible. Django’s autoreloader is annoyingly slow, highly inefficient, > > moderately well designed, and a gigantic pain to maintain. I’m more scared > > of django.utils.autoreload than of django.db.models.related before it was > > cleaned up. > > > > I wish one day someone will take the time to write a good autoreloading dev > > server based on watchman. This would solve the problem discussed here > > because watchman watches all files in the current directory. The correct > > way to do this is to throw away the current design and start from scratch. > > > > Watchman is smart enough to wait until you’ve finished a git operation to > > trigger a reload. Once such polished tech has become available, trying to > > compete with a thread that checks the mtime of all known files every second > > isn’t funny anymore. In fact it’s just sad. > > > > </rant> > > > > While I don’t care much about django.utils.autoreloader because I want to > > kill it, I’m reluctant to add public APIs such as the proposed setting, > > which may not make sense with an hypothetical better autoreloader. > > > > I’m -0 on the change. I could move to +0 if I understood why the use case > > described here requires watching additional files. > > > > I guess I could just use Watchman to restart the Django development server as > needed? > > I’m OK with that.. my only goal is to make sure I don’t have to restart > Django manually every time I edit CSS/Javascript/SQL/HTML. > > Is that the recommended workflow for this? I never looked into outside tools > to manage this, but it seems it would be a lot easier to add a list of files > or directories to our settings and have Django manage autoreload, than to > bring in an outside tool. (I can add directories to watch to the pull > request if needed) > > > Best regards, > > > > -- > > Aymeric. > > > > -- > > 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] > > <mailto:django-developers%[email protected]>. > > To post to this group, send email to [email protected] > > <mailto:[email protected]>. > > Visit this group at https://groups.google.com/group/django-developers > > <https://groups.google.com/group/django-developers>. > > To view this discussion on the web visit > > https://groups.google.com/d/msgid/django-developers/BAAB82B3-974C-4240-B9C6-E81F04D9604F%40polytechnique.org > > > > <https://groups.google.com/d/msgid/django-developers/BAAB82B3-974C-4240-B9C6-E81F04D9604F%40polytechnique.org>. > > For more options, visit https://groups.google.com/d/optout > > <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] > <mailto:django-developers%[email protected]>. > To post to this group, send email to [email protected] > <mailto:[email protected]>. > Visit this group at https://groups.google.com/group/django-developers > <https://groups.google.com/group/django-developers>. > To view this discussion on the web visit > https://groups.google.com/d/msgid/django-developers/8ABA81DF-807E-4B22-ACCF-C4D207A3E5E4%40gmail.com > > <https://groups.google.com/d/msgid/django-developers/8ABA81DF-807E-4B22-ACCF-C4D207A3E5E4%40gmail.com>. > For more options, visit https://groups.google.com/d/optout > <https://groups.google.com/d/optout>. > > > > -- > Adam > > -- > 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] > <mailto:[email protected]>. > To post to this group, send email to [email protected] > <mailto:[email protected]>. > Visit this group at https://groups.google.com/group/django-developers > <https://groups.google.com/group/django-developers>. > To view this discussion on the web visit > https://groups.google.com/d/msgid/django-developers/CAMyDDM2E6JQtE9Jc_Ff-LsyDH2tj6v_YGjfmVdbe8p8%2BM4dvHg%40mail.gmail.com > > <https://groups.google.com/d/msgid/django-developers/CAMyDDM2E6JQtE9Jc_Ff-LsyDH2tj6v_YGjfmVdbe8p8%2BM4dvHg%40mail.gmail.com?utm_medium=email&utm_source=footer>. > For more options, visit https://groups.google.com/d/optout > <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 https://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/E2CBDF68-C25D-47FA-B1A1-DCD80FF8EBDD%40gmail.com. For more options, visit https://groups.google.com/d/optout.
