[bad_user]

Of course "not opinionated" in this case is an euphemism and really means that Django doesn't help you at all and so you have to suffer the incomplete and abandoned middleware of others to have something that resembles an asset pipeline. And that's actually odd, because both Rails and Django are frameworks born for building frontends to MySQL databases, which means these frameworks really are about HTTP 1.1 frontend stuff.

For building backends and web APIs, especially web APIs that do constant streaming of data, maybe through WebSocket, there are actually much better options, so this raises the question, why use Django at all?

[St-Clock]

Right. The frontend story of Django is non-existent and it is a pain to reinvent the wheel each time. Need AJAX to work with CSRF protection? Just copy this snippet of code. Want to use SASS? Try to find a django app that provides an asset pipeline, or copy some django snippets, or do it yourself by bringing grunt/gulp/whatever is the latest hyped js build tool.

Now the remaining part of your comment is unfair. Pure frontend is just one small part of webapp development: templating, controller, ORM, i18n, user and session management, security, testing, etc.

You can do a lot of web backend stuff without websocket. Django is ok for that and if you combine it with Django Rest Framework, you get powerful tools at your disposal.

[zeemonkee3]

Take away templates and add Django Rest Framework and you have a very capable platform for building large CRUD APIs complete with models, permissions, serializers and so forth.

Is it the best solution when you just want to stream data down a socket? No. That doesn't mean it's useless for many other things.

If I'm going down the SPA route I'd just build the frontend separately using ember-cli or webpack or some other "native" solution and forget any asset pipeline.

[rbanffy]

> If I'm going down the SPA route I'd just build the frontend separately using ember-cli or webpack or some other "native" solution and forget any asset pipeline.

It's a good approach. There is no need to treat front and back-ends as a single application, bound by the same rules - they use completely different stacks and completely different tooling.

[jkarneges]

Re: websockets/push, another thing you can do is run two frameworks side by side. A load balancer like HAProxy can be used to unify the two, if needed.

For example, at my previous job we used Django for our main request/response API and Tornado for our push API. Later on, the Tornado part was rewritten in Java. Given the Django experience of the team, this architecture proved to be easier to maintain than having to rewrite the entire API, since there were far more request/response endpoints than push endpoints.

Nowadays there's Pushpin, which I created after the above experience.

[andybak]

Django wants to provide solutions that will stick around for longer than the attention span of the js community ;-)

Getting opinionated about js stacks at the moment could backfire hugely and alienate a chunk of their userbase. The policy is basically "Stuff should be left as 3rd party apps until a de facto winner emerges."

Not sure if that's likely to happen any time soon in anything related to front end code so keeping the core framework neutral seems like the best option. Mini-ecosystems can arise where neccesary.

[pbreit]

Django models and migrations are very nice to work with. The Django Rest Framework and new Channels (aka sockets) functionality are quite nice. Getting usable, free user accounts and admin is a pleasure. Why not use Django?

[smoe]

> why use Django at all?

I like Django to build "hybrid" apps where e.g. public sites, registration form, etc. are rendered by the backend using only a couple of lines of js (not even using jQuery or similar) to enhance user expirience and another part of the app being a fullblown SPA using Django as a REST api.