Live data from Hacker News

Django Newbie Mistakes

code.djangoproject.com

131–140 of 225 posts

Re: Django Newbie Mistakes

#131

I don't remember running into any of these issues learning Django or maintaining a Django codebase, but I've written the problems I ran into: https://alexcbecker.net/blog/django-is-dangerous.html In general, I think Django makes it way too easy to shoot yourself in the foot.

“Validation defined on the model is only enforced on the form” hasn't been true since 2010 when Django 1.2 was released. Most of the database-related discussion shares that pattern of either being factually incorrect (“queries can't use computed columns”), blaming Django for MySQL's many problems or failing to fix problems caused by other code failing to do things like input validation.

There's a real discussion about how to handle such issues on large, complex codebase but hiding it behind a clickbait title is not a good way to have that end up anywhere productive.

Re: Django Newbie Mistakes

#132

Earlier quoted context omitted.

Good SPAs are fantastic . It's just a lot of people suck when implementing them. The Serverless documentation, an SPA, blew my mind in terms of how fast and clean it is: https://serverless.com/framework/docs/

Really ? Randomly clicking e.g. Providers > Azure, I see a significant loading animation (the grey lines) - likely slower than just loading a simple new page each time. (Compare e.g. https://docs.python.org/3/library/weakref.html. ) (Single Page Applications arguably have their place. I'm just really confused why you think this is a particularly good example.)

On my awful connection, serverless is as fast as HN on new pageloads, and faster than HN when navigating to cached pages.

HN is my baseline for how fast a site should be.

Re: Django Newbie Mistakes

#133

Earlier quoted context omitted.

Someone dug up a 13-year-old page from the community wiki and presented it as "this is totally the official Django documentation". I've added a gigantic warning at the top of it to address this. See also my other comments in this HN thread, for the right way to do what that particular example was trying to do.

Thanks... ? Having dates on the pages would probably help avoid some of this in the first place. People point to a lot of the PHP comments in their docs as "bad" (and many are) but they're also dated, and you can use a comment date of 2009 when trying to give weight to how relevant/useful something may be. "blank=..." anything is, imo, more confusing than "required=", regardless of what version/age of the docs though…

The issue is: what would you list as the date?

Apparently some other people noticed this was on HN, too, so there are minor edits from a few hours ago, but the bulk of the information is still a decade old. Would you stick a date on every paragraph?

(personally I'd forgotten that this page even existed)

Re: Django Newbie Mistakes

#134

Earlier quoted context omitted.

Agreed. Django Forms' hay-day was back in the Request/Response rendering of page state era of the web. They introduced the ability to bind data for validation, rendering in the Template, programmatic generation based on Model and sanitization of form input data. They still can be utilized loosey-goosey on the backend in the world of APIs. Why bother when better tooling now exists? The use-case of Forms now is the Adm…

Just wondering, what do you use instead of Forms for non-Javascript websites?

For what it's worth you can still use DRF serializers instead of forms on non-JS sites. DRF can take multipart/form-data

Re: Django Newbie Mistakes

#135
post #97
post #86

Earlier quoted context omitted.

What’s the motivation for moving away from python?

We are in python 2.7 and we need to migrate the application to python 3.0 For me it's another language to learn if we want to make good python 3 code. Python/Django/DRF is a stack with very poor performance if you are dealing a lot with JSON. We already have API points in golang with very good performance. No need to deal with nginx/CGI etc. nightmare. Conclusion was that our code in golang has a lower downtime. (Typ…

Python 2.7 and 3 are hardly as different as you think. Migrating is a total breeze

Re: Django Newbie Mistakes

#136
post #97
post #86

Earlier quoted context omitted.

What’s the motivation for moving away from python?

We are in python 2.7 and we need to migrate the application to python 3.0 For me it's another language to learn if we want to make good python 3 code. Python/Django/DRF is a stack with very poor performance if you are dealing a lot with JSON. We already have API points in golang with very good performance. No need to deal with nginx/CGI etc. nightmare. Conclusion was that our code in golang has a lower downtime. (Typ…

Dude moving to Python3 is easy. It is an order of magnitude easier than moving over to a new language.

Re: Django Newbie Mistakes

#137

I've worked with django for a considerable amount of time now (~9 years), and I have found the documentation a joy to work with. The documentation generally covers each piece of functionality, and the source code is rich with documentation. When it comes to django itself, there are nuances, and yep, some of them probably can be smoothed over for developer experience, but developers must have knowledge over their tool…

Usually when people complain about the magic in Django it means that they're trying to work with things that are complete antipatterns. Django usually has one, really good, solid way to do each task and going against the grain is always going to hurt.

Re: Django Newbie Mistakes

#138

A lot of these things are only common mistakes because of Django's unusual behavior. > POST to views loses POST data The middlewares shouldn't be redirecting POSTs then! They could have returned a client error instead. > Blank object names They could have provided a fallback of __class__.__name__. > Integer & NULLS If the admin interface knows the field is required, why does it even attempt to insert a null value? It…

> To me, the Django project exudes the stubbornness of the developers who maintain it because rather than fixing these problems they've decided to write this page about how it's you, the user, who is wrong. I sometimes feel that, similar to how perl's motto is "There's more than one way to do it", some python developers have converged on an unofficial mottot of "You're doing it wrong".

Because... they are?

I mean look, for the most part developers have optimized a happy path that is by far, one of the most productive ways to get anything done in the web dev world.

If you're purposely going to go against that path for whatever reason, you're going to have to do the heavy lifting that the framework is doing for you.

In the 9 years I've been using Django, I've rarely if ever come to a situation where there was any benefit to working against the framework's idioms. And the more I've grown to using the framework, the more you realize that people would rather create their own thing from scratch rather than learn existing methodologies.

Re: Django Newbie Mistakes

#139
post #36

One of the things that makes me sad is there is no project even remotely close comparable to Django for say Golang or Scala. I love the fact that you get an admin interface out of the box. And tons of documentation. The views/template stuff is a bit dated since everyone started moving to frontend/backend services and SPAs but we still have DRF which is incredible in the amount you get for "free". I've had the "pleasu…

Yep. I just joined a company and what I could do in two months blew their minds. A lot of which was thanks to all the freebies by Django.

Re: Django Newbie Mistakes

#140
post #117

Please don't ever use integers for ZIP codes. In Germany there are ZIP codes (Postleitzahlen) that start with a 0.

Please don't use examples on a 13-year-old community wiki as recommendations, period!

See the many other comments I've made in this thread for how to handle elements of postal addresses in Django.

Post reply on HN