Live data from Hacker News

Django 5.0

djangoproject.com

121–130 of 237 posts

Re: Django 5.0

#121
post #9
post #7

Another boring release without much innovation. I wonder what's stopping Django from releasing more useful features like other frameworks are doing. Maybe the team is stuck in the past. They've been trying to improve forms for a long time but it still sucks. I think they should just remove it at this point and let external packages solve the problem.

Not much no, but both the GeneratedField and db_default would be useful in almost all projects I've ever implemented in Django.

Good for you but they're niche features that most developers will never use. I certainly won't.

That's why I switched to NextJS anyway. Django's implementing features voted by the board and companies who fund the project the most. They don't care about end users anymore.

Re: Django 5.0

#122
post #3

Sadly I don't use Django anymore at work but it still has a special place in my heart. The ORM model is the best I've ever worked with and any other always feels clunky with sharp edges to cut you when you hold it wrong. In recent years Django had multiple major releases, I still remember it as being in 1.x forever. Does somebody know what changed within the Django Community that they break backward compatibility mor…

> The ORM model is the best I've ever worked with and any other always feels clunky with sharp edges to cut you when you hold it wrong. Idk. I have to grant that Django ORM likes to make your life easy, but lazy loading on property calls is a dark pit full of shap punji sticks. Just overlook one instance where this is happening in a loop and say goodbye to performance and hello to timeouts left and right...

I sort of said this elsewhere. Others are saying "that's just what happens" and "well, Python?" but it doesn't just happen, and slow database queries are nothing to do with the application language. The problem is Django ORM, like Ruby on Rails, uses the Active Record pattern. Alternate ORMs, such as SQLAlchemy or Hibernate, uses Data Mapper pattern, which avoids the pitfalls of Active Record.

Re: Django 5.0

#123
I usually hear this question the other way around but there it goes.

Why should someone consider Django instead of something like Symfony or Laravel?

Re: Django 5.0

#124

I can’t tell if it’s Django or just how I use it—-I’m a mechanical engineer by training and only dabble on web dev—-but I deeply appreciate how it gives me enough abstraction to get going but doesn’t get too far ahead of itself. If I go away for a year or two then come back I still get what’s going on. Meanwhile anything I try on JS land has gone through a few half-lives.

If you want a similar experience in JS check out Joystick [1]. It's being built to mimic the indefinitely stable design of stuff like Django and Rails.

[1] https://github.com/cheatcode/joystick

Re: Django 5.0

#125
post #119

Django made me fall in love with programming 13 years ago, and since then it has always had a special place in my heart. I’m revisiting a business idea I was working on for a couple years, before I sought and found employment in the industry (where I used Java for a couple years, then Elixir for a couple more). My project was built with Django and Django REST Framework, and Ember on the client-side. 6 years later, th…

I haven't used Elixir yet and mostly using flask in Python for work but I started with Django (and still think it's better than flask for most apps). If stuff like https://github.com/aesmail/kaffy (first thing I've found on google, never heard of it before) is on par with the Django admin, would you still use Django or Elixir and never look back?

I don’t know if I would “never look back” to Django (I’m a sentimental person). But admin is one aspect, the other big one is auth. I also like DTL better than EEx/HEEx. And all the pieces of Django just fit together really nicely; where Ecto happens to be the preferred way to interact with a database from Elixir, and Phoenix happens to be the preferred way to build Web apps using Elixir, (maybe with Ash layered on top), they weren’t designed by the same people, so you have packages like ecto_phoenix, ash_phoenix, etc. to make them all play together in an elegant way.

I will admit, Elixir and Phoenix have better real-time and scalability stories.

If I had a choice I would probably prefer Elixir/Phoenix/LiveView when joining an org to work on an established codebase that may have actual scalability needs and concerns. But I would probably prefer Django when starting from scratch.

Re: Django 5.0

#126

Earlier quoted context omitted.

Non-performant code is going to eventually slip into any codebase. The trick is to monitor for when performance falls to an unacceptable level. Not toss all ORMs because some minority of generated queries are problematic. If maximum performance, 100% of the time was the end-goal, I would not be writing Python.

The python team I joined grew their codebase from a thin data access layer into a full blown application. Staff was full of data guys and had no idea about application engineering, but lots of opinions. The client was another company who intended the product as heart of their digital transformation. Guess who had to refactor this mess and steer away from catastrophy. I’m haunted to this day.

That general story can happen with any tech stack.

POC whipped together without good architecture. Having proven itself, usage increases until the application starts to burst at the seams. Program must be redesigned, avoiding performance gotchas.

I still think Django + the ORM give you a lot of runway before performance should be a concern.

Re: Django 5.0

#127

Earlier quoted context omitted.

Thanks. 1,000s of calls a second/minute/day?

Because of the integration with Dagster, the calls are made when my Dagster flows run. I also send unreasonably large data payloads. Anything going into Django gets handed to a Celery batch processing job and just returns the job id (Dagster monitors for failure, too). Data pulled out of Django is paginated. Sometimes it's 1000s of calls per minute, sometimes it's none at all for hours. I realize this isn't a normal…

Thanks.

Re: Django 5.0

#128
post #113

Earlier quoted context omitted.

Have a pitch on what differentiates this from django-toolbar? Just the focus on query count monitoring?

Yeah the query count monitoring is the main focus as N+1 queries are super common in Django. I don't really have a pitch but here is why this was made: 1. we had a production DRF app with ~1000 endpoints but the react app consuming it was dead slow because the api's had slowed down massively. 2. we knew N+1 was a big problem but the codebase was large and we didn't even know where to start. 3. we enabled this middlew…

Monitoring production is the piece I was missing. Was thinking of it as strictly for development.

Unless it adds a bunch of overhead, seems like a no-brainer to enable.

Re: Django 5.0

#130
post #63

Earlier quoted context omitted.

As a full-time Node.js dev, I agree with your decision! Too much time is wasted on compatibility problems. I'd almost say it was easier when we just had browsers to deal with. At least you could just drop in jQuery and call it a day.

Yes, jQuery is often derided as outdated, but it worked quite well for a very long time, with minimal hassle for developers. In fact, I was working full-time on static Elixir/Phoenix pages with jQuery sprinkled on top as late as 2022… it felt a bit clunky but it worked as advertised and wasn’t frustrating in any significant way.

I still use JQuery because of all the syntactic sugar and shortcuts.
Post reply on HN