I think the form abstraction is one of the better versions of it that I've seen in any of the web frameworks I've worked with. It's simple and elegant for most forms, and can even handle complicated ones (multipart forms, file attachments, complex validation scenarios, etc.) reasonably well.

on a really fundamental level working with complicated forms is just a complicated thing to do, no matter what kind of technology you're doing it with.

Django added Jinja2 as a built-in template backend some versions ago. The Django ecosystem hasn't really caught up to supporting it with reusable templates yet though.

Yeah I mentioned that. I don't think it can ever really work the way it's implemented right now. I think the only way it can work is slowly transitioning the Django template language to be syntactically similar to Jinja, that will give a progressive transition path. But it's a ton of work.

> Working with Javascript, webpack apps etc is a huge pain.

Could you explain what you mean? Django doesn't need to have any connection at all to your JavaScript stack.

If you want to use the Django staticfiles system (which you do - it's good and useful for non-js stuff as well), it kinda does.

We use Django Webpack Loader for our sites: https://github.com/owais/django-webpack-loader - This allows us to do `{% render_bundle ... %} which pulls in the appropriate script tag.

But even then you can really feel how painful it is to work with, especially if you're adding typescript/scss to the mix. Solutions like Django Compressor are not really the right model anymore.

And there's other issues as well. If you want to share settings between Django and the JS stack for example, you'll need to build your own pipeline for that. Building a form in react? Say goodbye to DRY on the form fields. Just, in general, Django predates JS apps being anything more than in-place enhancements and it shows.

If you're building a form in React why do you even bother with django forms when there's Django Rest Framework?

I do use DRF; but it's quite painful to have to set up all the intermingling between the API urls and the actual form definitions. I don't use Django forms; you will generally want a single source of truth for the forms and it kind of has to live in the JS, but then that makes it inaccessible to Django...

For large apps it makes sense to do it this way. For smaller apps it really sucks.

The template system is sometimes a pain, but sometimes the fact that it pushes you to move complexity out of the HTML and into Python code can make for more maintainable code in the long run. That's at least been my experience over the years.

It's annoying at first, but if you maintain a code base long enough, you'll be glad it's done the way it is.

This also has the side-effect of making the transition to client-side templating easier.