Live data from Hacker News

Django 4.0 release candidate 1 released

djangoproject.com

61–70 of 126 posts

Re: Django 4.0 release candidate 1 released

#61
Love Django. But we are using Django with Gunicorn at work and we are having massive concurrency issues (1 process, gthread)... More than 4 concurrent requests waiting on a slow IO and the whole thing melts down...

FastAPI doesn't have those issues at all...

Re: Django 4.0 release candidate 1 released

#62
post #30

Earlier quoted context omitted.

You could use Django just for the backend and have your frontend code be written in React+Typescript, no?

But that means throwing out a large part of Django and writing lots of "interconnect" code. At that point I think it's better to choose a different backend, one that will generate typed Typescript client code (or use Typescript on the server and some clever metaprogramming).

Lol

Re: Django 4.0 release candidate 1 released

#63
post #50
post #46

Earlier quoted context omitted.

That remind me of a meeting a few days ago where we were discussing if we should add another server or spend a bit more time developing something. After some time, I asked about the server cost, and it ended up being something like 100€ a month more to not have to worry about performance for the next year. In that case the decision was easy enough, but maybe some organisations have fixed server budgets and developers…

Server upgrade costs can vary wildly depending on what it entails. The cost of adjusting your EC2 Auto-Scaling Group maximum instance count will be very different than contacting HPE sales department.

At this point it seems that only mainframes can get more expensive than cloud auto-scaling.

But yeah, some places have a very expensive acquisition procedure. To the point that the labor in buying expensive things costs more than the thing itself. But those places "solve" the problem by buying large batches, and the hardware x developer costs comparison don't change much.

Re: Django 4.0 release candidate 1 released

#64

Django is good for those who have used it a lot. For beginners, there are much better alternatives and, frankly, Django way of development is severely restricting. Starting off with an API backend and a React/Angular/Vue front end, allows new developers to learn better abstractions (and not merge front ends and back-ends) The very idea of "sending UI code to the front end for every request" is unsuitable for medium t…

I think for beginners Django rocks. I dont do software at all in my career (Engineering), but I can pick-up a django project, look through the example project in the documentation and then throw (and I mean throw) together a working django project in a few evenings. With a very much an amateur knowledge of python. As in another thread, the css takes longer. Are they any other beginner alternatives I should be looking…

Django is a back-end for many unicorn SF start-ups like Venmo. No one is going to use something different due to immature ecosystems.

Re: Django 4.0 release candidate 1 released

#65
post #61

Love Django. But we are using Django with Gunicorn at work and we are having massive concurrency issues (1 process, gthread)... More than 4 concurrent requests waiting on a slow IO and the whole thing melts down... FastAPI doesn't have those issues at all...

do you run fastapi through wsgi? have you tried Django with asgi?

Re: Django 4.0 release candidate 1 released

#66
post #61

Love Django. But we are using Django with Gunicorn at work and we are having massive concurrency issues (1 process, gthread)... More than 4 concurrent requests waiting on a slow IO and the whole thing melts down... FastAPI doesn't have those issues at all...

This is definitely something about your local setup or config. We routinely run hundreds and thousands of simultaneous connections through various versions of Django without much trouble.

Re: Django 4.0 release candidate 1 released

#68

Earlier quoted context omitted.

I disagree. The way you can extend sections of other templates without creating an inheritance chain works very well (and I missed in template systems, for Java, for example)

To be clear, I use them as well. And every time I come to regret it unless it's on a site I absolutely do not touch once it's finished. Templates make it harder to find and debug issues. They have extremely little tooling to give assurances about what they're compiling, whether the syntax is correct etc. This requires you to build massive, flaky test suites. I'll take react and typescript any day over even one tenth…

Well, It is more of a design problem than a Django template problem. If you add more and more logic in the template itself instead of dealing with it in the views context or templatetags, you are bound to find yourself in such position that you have very hard to test code.

The tooling is fine and almost always lets you know where you are breaking stuff. Also, comparing react tooling with it is not fair, it is a much modern ecosystem that has pitfalls of its own.

I have been writing Django professionally for 10 years and React + Django together for 4+ years, so I really know what I am talking about here.

Re: Django 4.0 release candidate 1 released

#69
post #5

Last week I was trying develop a quick prototype, and instead of setting up a C# project, I tried Django. At first, everything seemed super easy, but later I hit so many road-blocks that I had to give up (For example defining a self-referential m2m relationship with a custom join table, and getting it working on the admin site). Don't people really have such problems with it? It really feels like a huge burden when y…

Interestingly, I also considered doing a recent prototype in C#, but opted to try Django. I didn't hit any roadblocks like this though, overall the experience was pretty nice. The fact that the Django admin site allows you to get instant CRUD functionality from your models with almost zero effort is something I've not seen in other web frameworks (maybe nest.js gets close, but I'd love to see a .NET equivalent to the admin site).

Re: Django 4.0 release candidate 1 released

#70
post #55

Earlier quoted context omitted.

Obviously nothing is stopping me, that's not the point. I was just highlighting the fact that in my opinion the DX of parts of Django is inferior compared to the JS frontend ecosystem. As the Django community, I think this is something we should have an eye on.

You're absolutely right in the sense that the Django and other communities should not stagnate and should also keep an eye on what the other frameworks are up to. Maybe the default template engine should be replaced in Django?

Template engines are already configurable and pluggable for quite a while.

The "problem" is that most of the third-party apps that want to provide templates end up using the default, so either you have to reimplement those or stick with the default engine.

Post reply on HN