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

Django 4.0 release candidate 1 released

djangoproject.com

Post reply on HN
Print view View original

21–30 of 126 posts

Re: Django 4.0 release candidate 1 released

#21

Post by bodge5000 »

patates wrote: 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…

For most frameworks,etc... I find that things get harder as the project grows in size and more code is added. Strangely, I find the complete opposite with Django. I find that adding new features and apps in my day job is easy and I barely even think that I'm using Django, but trying to start a hobby project with it is initially a bit of a nightmare

That being said, weighing up the good with the bad, its still my favourite web framework

Re: Django 4.0 release candidate 1 released

#22

Post by weird-eye-issue »

patates wrote: 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…

That use case has been easily discovered in the docs for several years at least

Re: Django 4.0 release candidate 1 released

#23

Post by fer »

konschubert wrote: post #20
Uberphallus wrote: post #19

Earlier quoted context omitted.

It's not significantly faster (or slower), it's the author that doesn't know how to run a benchmark. You can read my take on his take [0]. Leaving that aside, async is very advisable (even a must) if your backend throws requests against external and potentially blocking services and you want to keep answering your own clients without scaling for no reason. [0] https://news.ycombinator.com/item?id=29128107

> if your backend throws requests against external (and potentially blocking) services and you have the "audacity" of wanting to keep answering your clients. If you have enough processes/threads running, the CPU scheduler should take care of that , no?

Yes, but more processes means more memory footprint, almost 4 times as much in that benchmark, something the author didn't cover. Threading solves that, but it's way more prone to shooting yourself in the foot than async, especially since it's not baked into Django (i.e. you gotta cook your own solutions over callbacks, polling, etc).

Re: Django 4.0 release candidate 1 released

#24

Post by lnxg33k1 »

patates wrote: 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…

I am usually a symfony developer, but have also worked for some clients projects which needed to be done with ASP.Net MVC, and I would agree with you that Django, I think, is the most limited one. If you are used to work on a complete and extensible frameworks. But I also think that python is not really made for making extensible code, as without typing or interfaces it gets really hard to create something solid

Re: Django 4.0 release candidate 1 released

#25

Post by l33tman »

bildung wrote: post #12
patates wrote: 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…

What do you mean with custom join table? Self-referential m2m works fine im my experience.

I think he refers to that you can customize the table Django sets up to handle the m2m which normally is "hidden" (i.e. you don't define it explicitly). But if you want to track for example the time a relation was set up, you can define a custom m2m object that contains a DateTime.

Django Admin is not really designed to be an all-encompassing admin solution I've found, it's a good start but normally you design your own admin console anyway using your API so I've not cared that much about those shortcomings.

Re: Django 4.0 release candidate 1 released

#26

Post by creimers »

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.

Re: Django 4.0 release candidate 1 released

#27

Post by pbowyer »

creimers wrote: post #26

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.

You shouldn't be downvoted for saying this. As a server-side developer of 20 years the server-side templating languages have a lot to learn from the frontend experience. And I say this as a user of Smarty, Jinja2 and now Twig & nunjucks. Template inheritance is fantastic. But...

Being able to develop and test standalone HTML components using Storybook is a whole lot nicer than splitting a server-side template into components (which Twig certainly doesn't support cleanly), building a tool to render them and then maintaining your own component library. So normally we end up with HTML bits in Storybook which are copied and pasted into Twig templates, placeholders added and then you can guess they get out of sync.

I appreciate the argument that I should "use JS server-side and render ${js_fe_framework_of_choice} server-side" and it's valid. But I'd also like to be able to run components in _any language_ and get the same DX. Note none of this is talking about hydration - I'm wanting to leverage the JS FE frameworks as clever templating engines which output dumb HTML.

Re: Django 4.0 release candidate 1 released

#28

Post by semitones »

creimers wrote: post #26

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.

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

Re: Django 4.0 release candidate 1 released

#29

Post by sgt »

creimers wrote: post #26

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.

Nothing stopping you from writing a Django app with parts written in React, VueJS or whatever you prefer.

Re: Django 4.0 release candidate 1 released

#30

Post by dvdkon »

semitones wrote: post #28
creimers wrote: post #26

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.

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).
Post reply on HN