I know this is the opposite of what you asked but I find Rails to be keeping pace with modernity much better than its conemporaries! Django seem to have given up on integrating websockets (ActionCable has been in Rails for literally years now), nor is there trivial integration for JS assets/asset pipeline functionality. I don't write much of either anymore, but I'd still reach for Rails the instant I need to get something done quickly.
And with django-channels (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.
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?
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.
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”.
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/) 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....
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.
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.
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.
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.
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.
I was just teasing, Laravel looks solid. It's also comforting to know that if you move from Laravel world to Rails, a lot is familiar out of the box. It's good for us developers and good for the industry. Which I can't say about js stack/elixir/Golang/Spring etc etc.
Interesting. I always found Django so much more productive than rails due to the auto admin panel being out of the box. If I’m starting something new than its nice to have a place for non devs to enter data immediately.
Both do quite a bit better for cleanliness and setup time than any of the other platforms I’ve used for web development.
I'm interested in hearing about applications successfully using ActionCable for what and how. It's unclear to me how much use it's getting, or how well it meets actual use cases.
ActionCable is super easy to use out of the box to get WebSockets running, but it's incredibly non-performant. Anything more than 100 concurrent users took the time taken to a send a message to the socket from milliseconds to seconds. Replacing it with the AnyCable gem in conjunction with AnyCable-Go got us to over 1000 concurrent users without a hitch.
I just deployed ActionCable into production yesterday. I’ll be using it to share some information between our users’ mobile app and our web client.
I’m concerned about performance. As much as I know that premature optimization is the Devil, it’s hard to stomach deploying something that is so notorious for becoming a bottleneck. Once I get past my MVP of this feature and have some maintenance hours budgeted, I plan on exploring AnyCable.
> nor is there trivial integration for JS assets/asset pipeline functionality
...WHY would anyone ever want that?! I thought that splitting an app into one frontend-app and one backend-app, each in its separate repository too and runable alone is the very minimum everyone does nowadays.
(Yeah, later you may go on and chop the backend into microservices, but for starters you at least keep these two sepratate - why would you want to impose knowledge of Python or Django as requirement for your frontend developers?! Even if you start with a couple full-stackers, you'll want to later be able to hire more narrow focused specialists.)
Serious question: Django doesn't even have lazy loading. Why do people use it? Am I missing something? No way I'd wait a few seconds to get something big from the db
