Live data from Hacker News

Django 4.0 release candidate 1 released

djangoproject.com

81–90 of 126 posts

Re: Django 4.0 release candidate 1 released

#81
post #48

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?

Just one, esbuild for JSX and bundling.

Re: Django 4.0 release candidate 1 released

#82
post #7

There 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.

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

#83
As 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 time? I've seen people do it once and a while in situations they needed it, but no one who uses it as heavily as I'd plan to use it.

Re: Django 4.0 release candidate 1 released

#84
post #7

There 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

For an alternative to async, with better support (granted the use cases aren't exactly the same), you can hand off some processing to Celery and then get the result to the user via Channels.

Re: Django 4.0 release candidate 1 released

#85

Earlier 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

#86

I 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.

I love Django a lot too. It has made MVPs really easy to deliver. At the same time, I am interested in understanding about the disadvantages/quirks of using Django. Do you have more examples that you could share?

Re: Django 4.0 release candidate 1 released

#87
post #82

Earlier 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.

I reckon, Ruby and Rails while still heavily used has fallen out of fashion since it's peak time, whereas Python has gotten a huge boost in recent years from data science and being a common teaching language which spilled over to other uses of the language.

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

#88

Earlier 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…

I see, what a hoot! :-)

Re: Django 4.0 release candidate 1 released

#89
post #82

Earlier 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.

Python is a very popular language, and if you know Python Django is easy.

Re: Django 4.0 release candidate 1 released

#90
post #83

As 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 took that approach on my latest Flask project and it’s gone quite swimmingly. The problem I ran into was that a lot of the ecosystem, and therefore documentation, blog posts, helper libraries, etc., are all written under the assumption that you’re using an ORM. It took a while to figure out how to work around that, but once I did, I was home clear.

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.

Post reply on HN