This recent HN discussion had many opinions and details to read through: https://news.ycombinator.com/item?id=11121355

That said, in my personal projects, I lean towards letting Django handle almost all of the client experience too. There are exceptions for areas that are inherently interactive (e.g. WSYIWYG editor), but the vast majority of my projects involve static content. To me, the complexity and overhead of using a JS library/framework outweighs any benefits the library/framework might offer.

- Request parsing

- Content negotiation

- Creating/rendering responses

- Subclassing or decorating custom views and/or viewsets

- Model mixins, CRUD glue

- Routing

- Content-type parsing and rendering

- Serialization/deserialization

- Validation

- Authentication

- Filtering

- Pagination

Personally, I found it was harder to get from zero to anything when having to slog through that level of verbosity. I'd rather save brain cycles for harder problems.

It was this experience on the job that led to the design of a better approach with Ramses: http://ramses.tech. You can also generate docs, tests and client libraries this way. If you like the look of that, I will make you an end-to-end prototype for free to help drive home the concept.

Some other awesome projects along the same lines are http://postgrest.com/ and https://flask-restless.readthedocs.org/en/stable/

http://falconframework.org/

It's pretty unopinionated so you have a lot of control and there are less surprises but a lot of the nice to haves are gone as well.

Whatever you go with I would read this as well as the DRF doesn't generate proper RESTful responses on it's own.

http://jsonapi.org/

In your case, a SPA is not using a lot of Django stuff. So do you really like the admin pages and the ORM? If so use it. If you don't need admin pages and you hate the Django ORM, maybe look at just using Flask?

-- Only used Django a few times so not an expert, but above is my gut feel.

You want to hand-build and hand-tune that page.