Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Django 5.0

djangoproject.com

Post reply on HN
Print view View original

211–220 of 237 posts

Re: Django 5.0

#211

Post by robertlagrant »

danpalmer wrote: post #13
brycewray wrote: post #8

Assuming they used Django to publish this, it’s a bit sad that there’s no `generator` tag to give their own CMS a little love. :-/

Django isn't really a CMS. People sometimes group it in with other CMSs because it's good for rapid development of CRUD web applications, but I think most people think about a much higher level tool when they think of a CMS. It's also somewhat limiting – Django is good for building big web applications (see: Instagram, Octopus Energy) not just traditional content management based applications.

> People sometimes group it in with other CMSs because it's good for rapid development of CRUD web applications

No, it's because there's a CMS called Django CMS.

Re: Django 5.0

#212

Post by globular-toast »

robertlagrant wrote: post #209
globular-toast wrote: post #153

Earlier quoted context omitted.

I've gone the opposite way. Started converting views to rest framework viewsets and building React components on the front end. It just created more problems. Now the React stuff is considered legacy and we're using HTMX and the bare minimum of vanilla JS when necessary.

> Now the React stuff is considered legacy There's no point announcing things are now "legacy". Legacy is what Microsoft invented to call products they just made a competitor for, and the psychology seems the same. If it doesn't fit your needs, great. But React is useful for lots of needs.

I didn't mean React is legacy. You can't replace a React app with HTMX in general. I just meant within my project. Those parts are now unmaintained and will be replaced when they break or if we need to change them.

Re: Django 5.0

#213

Post by Keats »

Klonoar wrote: post #137
dinkleberg wrote: post #64

Earlier quoted context omitted.

I'm with you on this, Django + HTMX + Vanilla JS (where needed) just works which is a beautiful thing. Is building out the UI clunkier with Django templates than with JSX? Absolutely. But not having to worry about both server and client side state is such a time saver and you know it is going to continue to work. For the past few years I've been using Go (using Gin) in place of Django, and it works nicely and is quit…

An approach I've done in the past for projects that are publicly API-based: Django handles the database migrations and user accounts/models/etc - and you get the useful admin to boot, which is just incredible if you ever need to open up the data layer to someone else. Then just write the API interface in Go/Rust/your language of choice. It decouples the DB modeling from the API layer, but in practice... I've just not…

Interesting, I was thinking of the exact same thing. Glad to see it works!

Re: Django 5.0

#214

Post by globular-toast »

robertlagrant wrote: post #210
globular-toast wrote: post #200

Earlier quoted context omitted.

The lesson learnt is that React is an "all or nothing" type thing. You'll notice "SPA" isn't mentioned at all on the React website, but there's lots of mentions of building components. There are lots of comments around places like HN of people learning the same lesson as me. We never scoped replacing our entire UI with React and entire backend with JSON API because it seemed like there was a smooth upgrade path, but…

> because it seemed like there was a smooth upgrade path, but there isn't really You can put a React component into a non-React web page and give it data to render from however you like. Isn't that the intended path?

Yes, and that is indeed what we did. But what happens is you end up with a backend awkwardly fragmented into restframework viewsets and normal Django views. Often you end up having to maintain both. And then your frontend is in two distinct "worlds" which are developed in completely different ways. Unless you finally get to having an SPA and only JSON on the server side you'll feel forever in limbo. HTMX just makes so much more sense for an existing Django project unless you can afford to stop development and go all in on React, and even then only if it's really necessary to have an SPA.

Re: Django 5.0

#215

Post by robertlagrant »

globular-toast wrote: post #214
robertlagrant wrote: post #210

Earlier quoted context omitted.

> because it seemed like there was a smooth upgrade path, but there isn't really You can put a React component into a non-React web page and give it data to render from however you like. Isn't that the intended path?

Yes, and that is indeed what we did. But what happens is you end up with a backend awkwardly fragmented into restframework viewsets and normal Django views. Often you end up having to maintain both. And then your frontend is in two distinct "worlds" which are developed in completely different ways. Unless you finally get to having an SPA and only JSON on the server side you'll feel forever in limbo. HTMX just makes s…

Yeah - agree that the Django path to add REST endpoints alongside HTML ones is not the best. I like Flask for this reason: it walks the line between HTML rendering and JSON responses really well, IMO.

Re: Django 5.0

#216

Post by robertlagrant »

globular-toast wrote: post #212
robertlagrant wrote: post #209

Earlier quoted context omitted.

> Now the React stuff is considered legacy There's no point announcing things are now "legacy". Legacy is what Microsoft invented to call products they just made a competitor for, and the psychology seems the same. If it doesn't fit your needs, great. But React is useful for lots of needs.

I didn't mean React is legacy. You can't replace a React app with HTMX in general. I just meant within my project. Those parts are now unmaintained and will be replaced when they break or if we need to change them.

Oh! Sorry - hope you enjoyed my overboard response :)

Re: Django 5.0

#217

Post by PrivateButts »

patrick91 wrote: post #199
PrivateButts wrote: post #186

I loooove Django, any project that I work on that isn't Django causes me to yearn for it greatly. However, there's two things that have been minorly bothering me about it: - The complete lack of any motivation to support type hints (yes I know about stubs and the other 3rd party). - The GraphQL situation is a mess. Graphene on again off again development and Strawberry being not quite all the way stable yet sucks com…

Hi there! I work on Strawberry GraphQL, would be interested in sending me a list of the things that we can do better? You can send me a dm on discord or open an issue on discord, I plan to spend more time on Strawberry next year, so hopefully I can make it good for you!

Sure thing! We have migrated to Strawberry for all our projects going forward, next time I have my hands in those project guts for maintenance I'll document some and send it on.

Re: Django 5.0

#218

Post by IshKebab »

yuppiepuppie wrote: post #189
IshKebab wrote: post #148

Earlier quoted context omitted.

Yeah this is definitely Django's strength - it has a lot of the stuff you're probably going to need already implemented. Massive time saver when you're setting things up. Python definitely holds it back though. Does it have type hints yet?

Why do you say python holds it back?

The three big problems with Python:

* It's slow. 'nuff said. No the fact that Numpy exists doesn't change that.

* Lack of static types. I mean, they do exist now which is fantastic, but there are still far far far too many projects not using them. And lots of code that can't be statically typed (e.g. lxml).

* The infrastructure and module systems are a total mess. Literally nobody understands Python imports.

There's also the fact that Python code is generally lower quality than in other languages (except maybe JS) because it's so popular with beginners.

Re: Django 5.0

#219

Post by NoGravitas »

pmontra wrote: post #142
h4kor wrote: 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 is OK as long as you refrain from using any inheritance. If you do, the database becomes a mess quickly and only that very Django app will be able to read and write to it (including manage.py shell). Anything else, other apps in any language or a SQL client, will be lost in a sea of tables and joins. I've got a customer with two Django apps. One was developed enthusiastically in the object orientation way. Th…

I've found inheritance to be a problem with pretty much any ORM I've used extensively (Django, Hibernate, NHibernate, Entity Framework). It helps to design your OOP model with that in mind; having no more than one level of inheritance, and using inheritance only to supplement a set of common records seem to be good enough rules of thumb.

Re: Django 5.0

#220

Post by bastawhiz »

Izkata wrote: post #190
bastawhiz wrote: post #28

Earlier quoted context omitted.

Django makes it dead easy to take a URL route and return HTML. Obviously there's some fussing to add a script tag that points at your JavaScript file, but what exactly are you looking for beyond that? I'm not exactly sure what you're looking for beyond that (as someone who ~only writes Django+React); that's kind of it. There's no big magic, it responds to http requests with data.

For a full-on SPA (which I'm assuming is what they mean by "and aren't just a toy"), you'd also need at least frontend routing and an example how to make that play nice with Django URL routes, probably a data store (which at this point I think is just going to be redux), and most of the Django views would return JSON instead of HTML.

None of those concerns have anything to do with Django: just have Django return your HTML for all views that don't return JSON (which is to say, set the 404 to your HTML).

There's no need to use a data store like Redux. Any routing framework will work. Any react framework will work. Django has no impact on how you structure your SPA in any way! If you can build a SPA, making it work with Django is literally just "return HTML with a script tag". There's no "use React with Django" tutorials because that's literally it. If you can return HTML from a Django view, you've got everything you need for whatever React project you intend to build.

Post reply on HN