Earlier quoted context omitted.
Django templates are the worst. Django is great. Just don't use its templates or form systems. Indeed react is a great replacement for both.
How many tools do I need to install to publish a front-end made with React?
Django 4.0 release candidate 1 released
81–90 of 126 posts
Re: Django 4.0 release candidate 1 released
#82There are cooler frameworks, there are more minimal frameworks, there are more "modern" frameworks. Whatever that means. Yes I would like to work with FastAPI, it is great. But... Django gets the shit done. There are plenty of developers to find for it. Lots of good quality plugins. Every problem you have, infrastructure wise, is often already solved and there is a blog post of it. Its good parts and its bad parts ar…
While I have no experience with Django, this could exactly be said about Rails. It's great these two exist and are being worked on for so long and have this level of maturity.
Re: Django 4.0 release candidate 1 released
#83Re: Django 4.0 release candidate 1 released
#84There are cooler frameworks, there are more minimal frameworks, there are more "modern" frameworks. Whatever that means. Yes I would like to work with FastAPI, it is great. But... Django gets the shit done. There are plenty of developers to find for it. Lots of good quality plugins. Every problem you have, infrastructure wise, is often already solved and there is a blog post of it. Its good parts and its bad parts ar…
agreed, I'm more convinced now that django is really enough and get shit done even if there a poor support of async, more convinced after reading this blog post that async python is not faster (was on hn) : https://calpaterson.com/async-python-is-not-faster.html
Re: Django 4.0 release candidate 1 released
#85Earlier quoted context omitted.
I agree. I can generally do what I need to with the ORM, except in extreme cases where you probably should be writing custom SQL anyway. I do fight with Subquery and OuterRef now and then, thinking OuterRef isn't being used in a Subquery when it is, but a little debugging usually resolves that. The one thing I really wish Django had after all these years is multi-column PK support. I bring it up every time I see a th…
care to elaborate on that "multi-column PK support" please? :)
Django currently requires that every table have a _single_ primary key column. You can have a unique multi-column index, but you _also_ need to have a single primary key column, which sometimes makes working with existing databases tricky or inefficient.
It's Django's oldest open ticket, from August 2005: https://code.djangoproject.com/ticket/373
The trick is how do you group those columns together in a way that stays compatible with the rest of the framework.
Here's a 2015 proposal "DEP 191" for how to make it work:
- https://github.com/django/deps/blob/main/draft/0191-composit...
Basically, the multi-columns end up needing to be exposed as a single python object (CompositeField) to stay compatible with the rest of the framework, but do changes to the individual "subfields" on the row-object need to be kept in sync (data binding) with the CompositeField-object and maybe vice-versa? Now we need an "Observer" (which Django doesn't currently have) to watch for changes to fields, etc. So a lot of new concepts end up needing to be introduced to make this happen. And it needs to work with migrations and serialization while trying to maintain backward-compatibility.
Here's rough code (again, from 2015):
https://github.com/django/django/pull/4553
Since 2015, Django now has class-based-indexes which should make things slightly easier:
https://docs.djangoproject.com/en/stable/ref/models/indexes/
Maybe at least the Observables could get merged in as a first-step which would make the remaining work a little easier?
Re: Django 4.0 release candidate 1 released
#86I love Django and have been using it for many many years. Lately, however, I’ve been finding it increasingly difficult not to be annoyed by some aspects of the developer experience. For example I’d choose React + Typescript over Django templates any time of the day.
Re: Django 4.0 release candidate 1 released
#87Earlier quoted context omitted.
While I have no experience with Django, this could exactly be said about Rails. It's great these two exist and are being worked on for so long and have this level of maturity.
I wonder why Django seems to have a easier time in hiring, considering it should be a smaller market than Rails. Even on HN monthly hiring list Rails and Django open positions is roughly 3:1. And yet I rarely hear Django people ever complain about the lack of talent pool.
In the mid 2010s the python web application space felt very stagnant to me, many semi abandoned projects, lots of people leaving for other technologies. But there has been quite some reversal on that since.
Re: Django 4.0 release candidate 1 released
#88Earlier quoted context omitted.
care to elaborate on that "multi-column PK support" please? :)
:) Django currently requires that every table have a _single_ primary key column. You can have a unique multi-column index, but you _also_ need to have a single primary key column, which sometimes makes working with existing databases tricky or inefficient. It's Django's oldest open ticket, from August 2005: https://code.djangoproject.com/ticket/373 The trick is how do you group those columns together in a way that s…
Re: Django 4.0 release candidate 1 released
#89Earlier quoted context omitted.
While I have no experience with Django, this could exactly be said about Rails. It's great these two exist and are being worked on for so long and have this level of maturity.
I wonder why Django seems to have a easier time in hiring, considering it should be a smaller market than Rails. Even on HN monthly hiring list Rails and Django open positions is roughly 3:1. And yet I rarely hear Django people ever complain about the lack of talent pool.
Re: Django 4.0 release candidate 1 released
#90As someone who mostly has worked with minimal web frameworks (no ORM, admin site, etc), Django seems appealing. My only concern is that the ORM seems to be pretty coupled with different pieces of the framework, and I'd prefer to write SQL and wrapper it on a function on the model. Is my observation on the coupling off? Does anyone here have a good bit of experience using the raw SQL option for queries most of the tim…
I also used a helper library to automatically map namespaced .sql files onto python functions with various return types, which made the development process way more elegant: https://nackjicholson.github.io/aiosql/. Absolute game changer if you plan to go this route - can’t recommend it highly enough.