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.

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.

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.

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.

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.