[kukkeliskuu]

In my experience Django has much less boilerplate, so it is faster to develop in, especially traditional CRUD apps, if you had equal experience in both. It has admin, authentication, migrations etc. built-in.

The downside of Django is that while the initial DX is good, once you go into a little bit deeper, you need to learn how certain things should be done -- let's say if you use built-in forms and you want to create a inline formset with typeahead component. Well, it applies to Spring as well. Overall, Django still wins.

If you choose Django, try to do as much as possible in traditional Django way, meaning 90s form posting and full page load instead of single-page apps. That will be much quicker.

You can sprinkle some interactivity where you need it, for example using django-components, AlpineJS and HTMX. I would not use Angular (or Vue or React).

In any case, I would not optimize short-term productivity. This means I would not choose language because I had more experience in it.

You will be iterating much more than you are anticipating right now, because you can never really know what features give you traction. It is much better to optimize for long-term productivity, i.e. choose the best tool.

[pennomi]

You can also use Django REST Framework to make your API in a wonderfully simple way. Then build your single page app in whatever method you prefer.

[kukkeliskuu]

Yes you can, the question is whether you should, and if yes, to what extent.

Developing SPAs as compared to traditional web pages with Django is at least 10x more work.

In my experience, on most websites, on 80% of pages SPA gives very little additional value. Many non-essential pages are required to run on production, but especially if you are working alone, you should use the minimal effort to make them.

Such pages are for example: registration, password reset/ change, support pages, static pages (contact, background info etc.), payment flow, requesting permissions, suggesting new resources for approval, all administrative pages etc. Most of these are not needed for an initial proof of concept, but they are required before going into production.

For example, I created a website, a dance event calendar, which has approximately 200 views. (And 2M page views per month). Around 80 views use the Django admin -- so they work out of the box. Around 20 are for end users (no login is required).

The remaining 100 are for entering data (i.e. CRUD) and the pages mentioned above, by approximately 300 data admin users, and only few of these pages are used very often.

From these, only few pages really benefit from being a SPA. Of course this site is an extreme example, because for the page load time is the most critical factor for the usability -- and I can cache most of the data.

One of of the pages which benefit from interactivity is where data admins mass-enter data (i.e. enter multiple events on single form). This was implemented using HTMX, which works really nicely with Django.