3 ms·

Django has multiple good asset handling libraries. I like https://django-pipeline.readthedocs.io/ https://django-pipeline.readthedocs.io/. And with django-chan

by dbrgn 8y ago

Django has multiple good asset handling libraries. I like https://django-pipeline.readthedocs.io/ https://django-pipeline.readthedocs.io/. And with django-channels (https://channels.readthedocs.io/ https://channels.readthedocs.io/) Django goes way beyond just WebSockets. You can now do fully asynchronous data processing pipelines. I'm still happy working with Django (which is not something I can say about the JS ecosystem). Especially when doing APIs with Django REST Framework.

mbell 8y ago
In Rail 6 webpack (with a framework integration via the webpacker gem) is the default system for handling JS, CSS still goes through the asset pipeline though. I wouldn't be surprised if Rails 7 drops sprockets entirely.
- 0xADEADBEE 8y ago
  I saw this! It makes sense with the proliferation of front end view layers so I'm pleased that there's less work for me to do to integrate things like Vue and React. I was very late to the party with Rails but I do think it gets a lot of things right.
- ksec 8y ago
  And I have been wondering why it doesn't push the CSS to Webpack as well. There is no way in the foreseeable future that Rails could do without JS and hence Webpack is mandatory. We might as well push it as default or easily enabled / disabled via options.
  - mbell 8y ago
    It's clunky to build CSS 'packs' and it's unclear how to wire in asset helpers e.g. checksum'd file names for images. It's not insurmountable, but there is no obvious best path forward.
0xADEADBEE 8y ago
Fully agree with you - been in the JS world a lot lately and it's not as polished as the more 'traditional' web frameworks. Channels was supposed to make core but never did - what happened there? That's what I was driving at really - if I were stewarding a modern web framework, I would be integrating websocket support. It never sat right with me that something as common as APIs is farmed out to a library in Django (this comes out of the box in Rails with no configuration) either. I don't dislike Django, but I certainly find that there's a lot more messing around to get done things that I would consider pretty standard. I used the new Rails beta last week and I noticed that Webpack integration is now there - how long until we see something like that with Django?
- Spiritus 8y ago
  >Channels was supposed to make core but never did - what happened there? https://www.djangoproject.com/weblog/2016/sep/09/channels-adopted-official-django-project/ https://www.djangoproject.com/weblog/2016/sep/09/channels-ad...
  - deleted 8y ago
    [deleted]
  - nnain 8y ago
    Andrew Godwin (creator of django-channels) has recently handed over the repo to other maintainers and moved on to some role on adding `async` support to Django Core. (Channels was officially adopted by the Django project, but isn't part of the Django-core — you still have to add the package separately.) This async support is hopefully coming within 2019. I'm super-excited about using it in future django projects.
- uranusjr 8y ago
  https://groups.google.com/forum/#!topic/django-developers/mLlWYEC8_G8 https://groups.google.com/forum/#!topic/django-developers/mL... In short, the efforts are constantly undermanned, leading to developer burnout. Andrew had since came back to pushing things (ASGI 3.0 came out last week), but it seems like he intends to focus more on the big picture (standardise async web stuff in Python) than spending time on Django specifically. Step up if you believe you have good visions on making Django a “modern web framework”.
sjamaan 8y ago
Django channels sounds like a great idea and I really like the conceptual step it made with ASGI, but in practice I found it to be riddled with problems. For instance, the posix IPC implementation of ASGI is very buggy and "not officially supported". The other implementation uses Redis (so, yet another component to take care of) and is quite brittle as well. We've noticed severe slowdowns of downloading images when using the Daphne web server in development mode, many issues running out of memory, clogged queues and so on. This is also very difficult to debug, due to the many moving parts, and of course it only happens on production, so good luck trying to reproduce it locally. For this project (which is still in production), we ended up falling back to a standard Gunicorn web server setup using traditional WSGI to handle regular HTTP traffic, and relying on channels only for websockets. For new projects, we've moved to a tiny standalone gevent-based websockets server (https://pypi.org/project/high-templar/ https://pypi.org/project/high-templar/) which we deploy next to a standard gunicorn stack. It is much simpler and much more stable. Unfortunately, it's something we've developed in-house, so if there are issues we have to fix them ourselves. There've been some problems with gevent which apparently have been fixed in the latest git repo, but there hasn't been a release since last year. So many issues....
digitaltrees 8y ago
There may be packages in the community but the entire point of the article was highlighting the advantages of having framework level choices that 1. Are maintained by the framework team, 2. Establish patterns where the community can build other packages based on those assumptions. For example, now that yarn and webpack are standard in rails, we can build gems that can import and configure JS packages in a consistent and modern way, knowing exactly how most rails projects will manage JS. I have been frustrated that rails doesn’t have default admin, authentication, and authorization for this exact reason.

by dbrgn 8y ago

mbell 8y ago

In Rail 6 webpack (with a framework integration via the webpacker gem) is the default system for handling JS, CSS still goes through the asset pipeline though. I wouldn't be surprised if Rails 7 drops sprockets entirely.

0xADEADBEE 8y ago
I saw this! It makes sense with the proliferation of front end view layers so I'm pleased that there's less work for me to do to integrate things like Vue and React. I was very late to the party with Rails but I do think it gets a lot of things right.
ksec 8y ago
And I have been wondering why it doesn't push the CSS to Webpack as well. There is no way in the foreseeable future that Rails could do without JS and hence Webpack is mandatory. We might as well push it as default or easily enabled / disabled via options.
- mbell 8y ago
  It's clunky to build CSS 'packs' and it's unclear how to wire in asset helpers e.g. checksum'd file names for images. It's not insurmountable, but there is no obvious best path forward.

0xADEADBEE 8y ago

Fully agree with you - been in the JS world a lot lately and it's not as polished as the more 'traditional' web frameworks. Channels was supposed to make core but never did - what happened there? That's what I was driving at really - if I were stewarding a modern web framework, I would be integrating websocket support. It never sat right with me that something as common as APIs is farmed out to a library in Django (this comes out of the box in Rails with no configuration) either. I don't dislike Django, but I certainly find that there's a lot more messing around to get done things that I would consider pretty standard. I used the new Rails beta last week and I noticed that Webpack integration is now there - how long until we see something like that with Django?

Spiritus 8y ago
>Channels was supposed to make core but never did - what happened there? https://www.djangoproject.com/weblog/2016/sep/09/channels-adopted-official-django-project/ https://www.djangoproject.com/weblog/2016/sep/09/channels-ad...
- deleted 8y ago
  [deleted]
- nnain 8y ago
  Andrew Godwin (creator of django-channels) has recently handed over the repo to other maintainers and moved on to some role on adding `async` support to Django Core. (Channels was officially adopted by the Django project, but isn't part of the Django-core — you still have to add the package separately.) This async support is hopefully coming within 2019. I'm super-excited about using it in future django projects.
uranusjr 8y ago
https://groups.google.com/forum/#!topic/django-developers/mLlWYEC8_G8 https://groups.google.com/forum/#!topic/django-developers/mL... In short, the efforts are constantly undermanned, leading to developer burnout. Andrew had since came back to pushing things (ASGI 3.0 came out last week), but it seems like he intends to focus more on the big picture (standardise async web stuff in Python) than spending time on Django specifically. Step up if you believe you have good visions on making Django a “modern web framework”.

sjamaan 8y ago

Django channels sounds like a great idea and I really like the conceptual step it made with ASGI, but in practice I found it to be riddled with problems. For instance, the posix IPC implementation of ASGI is very buggy and "not officially supported". The other implementation uses Redis (so, yet another component to take care of) and is quite brittle as well. We've noticed severe slowdowns of downloading images when using the Daphne web server in development mode, many issues running out of memory, clogged queues and so on. This is also very difficult to debug, due to the many moving parts, and of course it only happens on production, so good luck trying to reproduce it locally. For this project (which is still in production), we ended up falling back to a standard Gunicorn web server setup using traditional WSGI to handle regular HTTP traffic, and relying on channels only for websockets. For new projects, we've moved to a tiny standalone gevent-based websockets server (https://pypi.org/project/high-templar/ https://pypi.org/project/high-templar/) which we deploy next to a standard gunicorn stack. It is much simpler and much more stable. Unfortunately, it's something we've developed in-house, so if there are issues we have to fix them ourselves. There've been some problems with gevent which apparently have been fixed in the latest git repo, but there hasn't been a release since last year. So many issues....

digitaltrees 8y ago

There may be packages in the community but the entire point of the article was highlighting the advantages of having framework level choices that 1. Are maintained by the framework team, 2. Establish patterns where the community can build other packages based on those assumptions. For example, now that yarn and webpack are standard in rails, we can build gems that can import and configure JS packages in a consistent and modern way, knowing exactly how most rails projects will manage JS. I have been frustrated that rails doesn’t have default admin, authentication, and authorization for this exact reason.