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

161–170 of 225 posts

Re: Django Newbie Mistakes

#161

Post by aidos »

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…

Normally people use something like uWSGI to host python apps behind Nginx - in any case, it’s something you figure out once and pretty much never deal with again. So it shouldn’t be an ongoing nightmare.

While I didn’t downvote you, I suspect the people that did have done so because it sounds like you’re making quite a naive mistake in blaming the tool for your issues. Changing language is almost certainly the wrong thing to do, period. You should profile your existing code and figure out where the real issues are. If you don’t know how to do that effectively, no amount of rewriting from scratch in a new language will save you.

Sounds like you really care about the ORM (though if you’re using the Django one, it’s pretty basic). Python has hands down the best ORM (SQLAchemy), so if that’s such a priority, then why not start there?

Re: Django Newbie Mistakes

#162

Post by scrollaway »

acdha wrote: post #157
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/

It takes ~2.5 seconds to load and the first ~1.5 of that won't display anything because it has to process ~600KB of JavaScript and CSS before it can render a few hundred words of text: http://www.webpagetest.org/result/180628_AQ_c87264f303f9e72f... The only reason that's faster as an SPA than static HTML is because they've disabled caching for static resources: http://www.webpagetest.org/result/180628_AQ_c87264f303f9…

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...?

Re: Django Newbie Mistakes

#163

Post by drdaeman »

scrollaway wrote: post #108
mattmanser wrote: post #94

Earlier quoted context omitted.

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…

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 simple things.

Still, for now I believe many (not all, of course) fancy SPAs are a probably a waste of otherwise productive time. There is already a browser, and it does things well. Having something that would allow for smaller documents is a good idea, of course, and some eye candy for transitions between different documents would be neat to have, but every site doing this for themselves feels just plain wrong to me.

Exceptions - e.g. for heavily API-centered systems - apply, of course. If a webpage is one of half a dozen client applications that consume the same API, then SPA could be a sane way to do it.

Re: Django Newbie Mistakes

#164

Post by theptip »

blattimwind wrote: post #153
pbreit wrote: post #92

Earlier quoted context omitted.

Similar experience for me. Django is pretty thick with quite a bit of (confusing, to me) magic. Flask comes without very basic components that are required for pretty much any website (user accounts, db access, etc).

Between Django and Flask, Pyramid is often forgotten. It seems like the only one of the three that has been genuinely designed to be extended (vs. Flask's approach of "here you have a magic-global variable (that's magically working like a stack of dicts), go put some stuff into it"); a good example would be renderers. In Django it's still kinda awkward to use other/multiple templating engines; Flask doesn't really he…

I've been meaning to look into Pyramid, it does sound like it avoids some of the worst of both Flask and Django.

Any areas that Pyramid doesn't do well at?

Re: Django Newbie Mistakes

#165

Post by blattimwind »

theptip wrote: post #164
blattimwind wrote: post #153

Earlier quoted context omitted.

Between Django and Flask, Pyramid is often forgotten. It seems like the only one of the three that has been genuinely designed to be extended (vs. Flask's approach of "here you have a magic-global variable (that's magically working like a stack of dicts), go put some stuff into it"); a good example would be renderers. In Django it's still kinda awkward to use other/multiple templating engines; Flask doesn't really he…

I've been meaning to look into Pyramid, it does sound like it avoids some of the worst of both Flask and Django. Any areas that Pyramid doesn't do well at?

It has nothing like the django admin and no forms handling is built into it. Creating a project from scratch is a bit cumbersome (like flask), but good cookiecutters exist (e.g. the pyramid-sqlalchemy one).

Re: Django Newbie Mistakes

#166

Post by pbreit »

theptip wrote: post #164
blattimwind wrote: post #153

Earlier quoted context omitted.

Between Django and Flask, Pyramid is often forgotten. It seems like the only one of the three that has been genuinely designed to be extended (vs. Flask's approach of "here you have a magic-global variable (that's magically working like a stack of dicts), go put some stuff into it"); a good example would be renderers. In Django it's still kinda awkward to use other/multiple templating engines; Flask doesn't really he…

I've been meaning to look into Pyramid, it does sound like it avoids some of the worst of both Flask and Django. Any areas that Pyramid doesn't do well at?

Wow, Pyramid even seems to pitch itself as the "Goldilocks Solution"! OK, will give it a try.

Re: Django Newbie Mistakes

#167

Post by acdha »

scrollaway wrote: post #162
acdha wrote: post #157

Earlier quoted context omitted.

It takes ~2.5 seconds to load and the first ~1.5 of that won't display anything because it has to process ~600KB of JavaScript and CSS before it can render a few hundred words of text: http://www.webpagetest.org/result/180628_AQ_c87264f303f9e72f... The only reason that's faster as an SPA than static HTML is because they've disabled caching for static resources: http://www.webpagetest.org/result/180628_AQ_c87264f303f9…

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 the runtime overhead.

For static docs, your timing is off by at least one order of magnitude: I have to wait a second or more — a LOT more on a high-latency connection where that initial page load is 15+ seconds worse[1] – and there doesn't seem to be much benefit to compensate for that. I mean, the animation is cool the first time I see it but I see it a lot because there's less information on each page so the novelty wears off pretty quickly.

Again, please note the last part of my comment: there is a place for SPAs but I'm not sure why a site this simple needs 500KB of JavaScript to deliver static documentation slower than Apache did two decades ago. I was expecting to see a selling point such as loading the content so that it was usable offline and search results were instantaneous but e.g. that nice search box (which is the one thing you couldn't have done in 1994) still takes 3+ seconds to load and render the new page on a well-peered gigabit connection.

1. http://www.webpagetest.org/result/180628_CF_db268e65de67002e...

Re: Django Newbie Mistakes

#168

Post by [deleted] »

danpalmer wrote: post #109
mattmanser wrote: post #94

Earlier quoted context omitted.

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…

I think with server side pages, you’re limited in how much you can mess it up, but very limited in how far you can take the experience. With single page apps you have to do a lot more to get back to what server side pages give you, basic browser functionality, and as a result you can end up with worse experiences. However if you’ve got the development resources it can be a far better experience and enable application…

[deleted]

Re: Django Newbie Mistakes

#169

Post by ubernostrum »

mgkimsal wrote: post #151
ubernostrum wrote: post #133

Earlier quoted context omitted.

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)

"Created on" and "last modified". I see last modified way at the bottom of a long page in light grey. I did not even notice it was a wiki until others point it out. Biggest text on the page says 'code'. I plead nav-blindness to not seeing 'wiki' in the floating navbar. Perhaps a date on every block section? Or... something that throws a big block at the top if the last edit was more than 2 years ago?

Honestly I'm not convinced it's worth the amount of work involved in doing all this, and the number of places available for people to share tips/tricks/etc. has drastically increased since 2005. So if it were up to me the wiki would either go away, or become read-only with prominent "only for historical purposes, don't use information here" warnings.

But I'll think it over.

Re: Django Newbie Mistakes

#170

Post by currysausage »

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

> everyone started moving to frontend/backend services and SPAs

Yes, there are valid reasons for SPAs, but many web applications and most classic web sites are still better served with plain old server-generated HTML, IMO.

First, because replicating even basic functionality in JavaScript comes at a cost, namely in bytes sent, bytes to be parsed, bugs introduced, etc. Second, because most projects don’t have unlimited development resources, so developers might just slap a few libraries together without necessary optimization, customization, or testing.

Third, because the well-known experience of browsing static web pages is already pretty darn good, and what developers will find exciting, users might just find irritating. Needlessly breaking conventions is simply bad UX.

Contrary to that, I keep reading that SPAs are the “new way”, as if classic server-rendered HTML enriched with some Ajax suddenly became a deprecated, inferior technology. It really isn’t. Unless you know what you’re doing, and why you need to, the classic way is still a sane default. If in doubt, I would always prefer a solid Django site over a half-baked SPA.

Post reply on HN