Hacker News new | ask | show | jobs
by rojoca 2253 days ago
I totally understand people's preference to use Django templates wherever possible, and only sprinkle in more frontend focused stuff when needed, but personally, I would rather just write the whole frontend in React or Vue.

This is probably partly due to the fact I find working with django rest framework serializers / views to be much nicer than django forms / views.

I think what puts most people off is the default requirement to go all-in and create an SPA with global state management and client-side managed routing, but this isn't actually necessary.

I have found incorporating Django with https://inertiajs.com to be a pretty solid alternative. I can write the whole frontend in React, and the backend in Django rest framework, but everything is still page based, so I don't require redux or any other kind of global state, just use the inertia utils to make page transitions.

NextJS is another alternative. To talk to a (django) API you need to go through getStaticProps and getServerSideProps which, depending on the location of your API server, can be a little slow, but you get pre-rendered HTML and page based routing so again no global state management required.

4 comments

NextJS is another alternative. To talk to a (django) API you need to go through getStaticProps and getServerSideProps which, depending on the location of your API server, can be a little slow, but you get pre-rendered HTML and page based routing so again no global state management required.

The problem with this approach is that you will need to manage another server process(nodejs) besides django for server-side rendering with nextjs.

Interesting, inertiajs looks similar to turbolinks/stimulus but instead of using html it uses js components. With nextjs you will have to manage another routing layer though?
>I think what puts most people off is the default requirement to go all-in and create an SPA with global state management and client-side managed routing, but this isn't actually necessary.

There's also the benefit of being able to lean on Django patterns for sessions.

Since inertia runs in the same session context as your django app you can use django sessions as you would in a standard django app - in fact this is the goal of inertia. This even works with a django rest framework API
The Django Inertia adapter seems to be abandoned [1], what are you using?

[1] https://github.com/jsbeckr/inertia-django

I created my own adapter for rest framework specifically. Currently trying to extract it from my project into its own library. Will publish to pypi when it’s ready. Repo[1] if you want to see the approach. Also, there is a fork of inertia-django[2] that has a reference implementation of PingCRM[3]

[1]: https://github.com/rojoca/django-rest-inertia [2]: https://github.com/zodman/inertia-django [3]: https://github.com/zodman/django-inertia-demo