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

Django Newbie Mistakes

code.djangoproject.com

Post reply on HN
Print view View original

171–180 of 225 posts

Re: Django Newbie Mistakes

#171

Post by scrollaway »

acdha wrote: post #167
scrollaway wrote: post #162

Earlier quoted context omitted.

Testing an SPA against a single pageload is absurd. You're not optimizing for a single page load (and if you are, a couple hundred milliseconds makes zero difference). You're optimizing against browsing the site. Have you tried browsing the site...?

> Testing an SPA against a single pageload is absurd. You're not optimizing for a single page load (and if you are, a couple hundred milliseconds makes zero difference). As a user I don't care about the developer's aesthetic preferences for tooling, only how long it takes to see the information I need. This feeds back to the question of why an SPA matters: for a rich application, there's more benefit to cancel out th…

I'm on a terrible high latency connection in Athens, Greece. The serverless SPA is one of the fastest sites I've ever visited. It's a ton faster than HN for me.

Yes the initial pageload takes time. But afterwards I can click around the site and get immediate feedback. Immediate as in native app speeds. Images and such obviously still take time to load and render but they do not block loading. There's no whitescreen while I wait for new pages to load.

So as someone with shitty internet who often browses documentation, give me hundreds of sites like this. This is significantly faster to browse around than, say, the Python or Django documentation, both of which make very little use of Javascript. I'm sorry you're not getting the same experience, I can't speak to that.

To reiterate: An SPA will bloody obviously not faster on the first pageload. The whole idea behind it is that you load more machinery upfront but you don't load it again afterwards. Depending on how good the app is, you make up for it very, very quickly. And if you have any significant JS usage on your site at all, you make up for that too.

My point, which everyone seems to have completely missed, is that well-built SPAs do exist. They don't have to feel slower to use than other apps.

Re: Django Newbie Mistakes

#172

Post by alexbecker »

acdha wrote: post #154
alexbecker wrote: post #145

Earlier quoted context omitted.

You must not have read the section "Validation defined on the model is only enforced on the form". The validations I referenced, e.g. `choices`, are only run in when [`full_clean()`]( https://docs.djangoproject.com/en/dev/ref/models/instances/?... ) is called, and it's not called on `save()`--it is usually called through form validation. Regarding computed columns, it looks like the specific issue I ran into repeated…

> You must not have read the section "Validation defined on the model is only enforced on the form". The validations I referenced, e.g. `choices`, are only run in when [`full_clean()`]( https://docs.djangoproject.com/en/dev/ref/models/instances/?... ) is called, and it's not called on `save()`--it is usually called through form validation. In addition to being wrong about whether I read your post, this is a great ill…

Back when I was working on Django codebases, I saw almost no use of `full_clean()`, largely because some validation was performed on `save()` (by virtue of being database constraints, e.g. non-nullability) while other validation was not, and there was no indication in the APIs which was which.

In a world in which Django applications were always written by people who read and understood the docs in full, I would totally agree with you about these criticisms. But I've never had such an opportunity outside of my own projects. I've only dealt with codebases that were written with falty assumptions, enabled by Django's choice to hide some but not all tricky work from its users. By then the database constraints would be incredibly painful to add since there was lots of data already violating it, and switching global defaults like ATOMIC_SAVE were nearly as bad since code had widely relied on other behavior.

Re: Django Newbie Mistakes

#173

Post by mixmastamyk »

paulie_a wrote: post #30
davzie wrote: post #27

Earlier quoted context omitted.

I find it some of the hardest documentation (close to AWS) to understand the best way to do something. I think it's great if you know what you're doing or you have a rough idea of what to do but need more information, but for someone new to the framework it makes me want to paper cut the webs of my fingers and bath my hands in vinegar because it would be less painful.

I agree. The tutorial is incredibly simplistic with a "go play" ending. Then the actual documentation assumes you have a pretty good knowledge of how everything works. There is no middle step without utilizing 3rd party docs.

There are also lengthy guides on each part ORM, Templates, etc.

Re: Django Newbie Mistakes

#174

Post by scrollaway »

drdaeman wrote: post #163
scrollaway wrote: post #108

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/

YMMV, but when I've dabbled with what I believe are good SPAs, I've noticed what I was essentially was essentially implementing a crude primitive web-browser inside my React app. I mean, I was neck-deep trying to code page transitions, load progress indicators, history states, all this sort of stuff. Thankfully, I'm not a frontend developer. Was just toying around here and there. Maybe it was just that I sucked at si…

All a symptom of the browser being a document-first platform that's been reused to be app-centric. I agree with you it's a bummer that these things are getting reimplemented on top of a platform that already offers them, but the way the platform offers them hasn't changed much since the 90s and hasn't kept up with what apps need.

The core issue being that you have no way of statefully going from one page to the next. State only exists within the page you're on. Hence the rise of SPAs.

Re: Django Newbie Mistakes

#175

Post by mixmastamyk »

jaffee wrote: post #104
projectramo wrote: post #24

Earlier quoted context omitted.

Oh man! I feel where you are coming from but who clicked on this link except Django fans? That's like walking into a Django club and telling everyone their framework sucks. Even as a member that only gets you so far. I can't believe you also called it difficult to maintain! Because when you say slow, the response its easy to maintain, and you went ahead and called it difficult to maintain? At least give us a reason.

Ha, ok - Django is not difficult to maintain, Django is a very powerful, carefully built framework with tons of features that can get you up and running with a production ready website very quickly. Python is difficult to maintain. Full stop. Why? Anything in Python can do anything to anything else - there are no boundaries which makes it basically impossible to reason about code at scale. You need very strictly enfo…

Needs change over the lifetime of a project. The flexibility that is a virtue at first becomes less so as designs solidify. Theoretical issues become problems as a codebase/team scales.

Re: Django Newbie Mistakes

#176

Post by batteryhorse »

mattmanser wrote: post #94
danpalmer wrote: post #60

Earlier quoted context omitted.

> One of the things that makes me sad is there is no project even remotely close comparable to Django for say Golang or Scala. Could not agree more. This is my number one reason for not moving away from Python for web stuff. > The views/template stuff is a bit dated since everyone started moving to frontend/backend services and SPAs This is certainly true for customer facing products, but for internal tools I've yet…

Personally, as a customer, the "new" way of doing it is irritating, usually somewhat broken, slow and usually unreliable. I wouldn't be surprised if non-techies couldn't give a toss if you're using a traditional MPA with a sprinkling of ajax for the bits that really need to be responsive or a total SPA. I'm beginning to suspect the only people who want a SPA are the programmers. Has anyone even got any proof that a S…

As a programmer, I absolutely hate SPA's. I've never used a good SPA, they're always slow, and behave strangely. I much prefer the traditional way. It's the same with Electron apps.

I think it's just web developers who like SPA's

Re: Django Newbie Mistakes

#177

Post by Xixi »

jojo64 wrote: post #97
aidos wrote: 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…

I love Elixir (more so than golang), so I would sincerely recommend using it. Erlang concurrency story is lightyears ahead of Python3 asyncio (despite being older by maybe 20 years). And OTP has no equivalent anywhere.

But if you are migrating just to avoid spending a couple of days learning and migrating to Python 3 based on reading too much FUD I'm very saddened. Migrating from Python 2 to Python 3 is not much harder to handle than a Django migration. Though of course it depends on your codebase, but compared to moving to Elixir/Phoenix/Ecto it's a peace of cake.

Move to Elixir/Phoenix/Ecto because it fits your needs better than Python, be proud of it even. But please, learning Python 3 to write good Python 3 code coming from Python 2.7 is very easy, nothing like switching to a completely different paradigm...

Re: Django Newbie Mistakes

#178

Post by gkya »

C14L wrote: post #102
StavrosK wrote: post #66

Earlier quoted context omitted.

This is exactly my view as well. Every time I've used Flask, I ended up regretting it, because I've invariably needed to fit something to it that would have worked out of the box with Django (or at least integrated much more easily). I haven't found any reason to use Flask in a project, except maybe for small, ad-hoc scripts that you want to run in a single file.

And its perfectly possible to write a one file/ten loc Django app. Everything is optional. Its just there by default, because 99% of projects will need it anyway.

> its perfectly possible to write a one file/ten loc Django app

Examples: http://olifante.blogs.com/covil/2010/04/minimal-django.html https://stackoverflow.com/questions/1297873/how-do-i-write-a..., and also this interesting one: https://github.com/simonw/djng where the guy builds a microframework which uses Django.

Re: Django Newbie Mistakes

#179

Post by ubernostrum »

gkya wrote: post #178
C14L wrote: post #102

Earlier quoted context omitted.

And its perfectly possible to write a one file/ten loc Django app. Everything is optional. Its just there by default, because 99% of projects will need it anyway.

> its perfectly possible to write a one file/ten loc Django app Examples: http://olifante.blogs.com/covil/2010/04/minimal-django.html https://stackoverflow.com/questions/1297873/how-do-i-write-a... , and also this interesting one: https://github.com/simonw/djng where the guy builds a microframework which uses Django.

In your last example, "the guy" is one of the people who was on the team that originally created Django, back when it was an internal tool for building a news CMS.

Re: Django Newbie Mistakes

#180

Post by paulie_a »

mixmastamyk wrote: post #173
paulie_a wrote: post #30

Earlier quoted context omitted.

I agree. The tutorial is incredibly simplistic with a "go play" ending. Then the actual documentation assumes you have a pretty good knowledge of how everything works. There is no middle step without utilizing 3rd party docs.

There are also lengthy guides on each part ORM, Templates, etc.

The problem is they quite frankly suck.

The official ones are incredibly dry and not approachable by someone wanting to get started and do anything meaningful. I've helped people learn Django and the official docs/guides are the last on the list of recommendations. there are so many better resources to look at first. I've told people to skip the polls app and go through Django girls tutorial. The polls app is a waste of time.

Post reply on HN