Live data from Hacker News

Django Newbie Mistakes

code.djangoproject.com

211–220 of 225 posts

Re: Django Newbie Mistakes

#211
post #72

Earlier quoted context omitted.

> I've had the "pleasure" of working with other large projects built on flask and ever time it gets to a certain size I wonder why we didn't just use Django. Actually, I've had the exact opposite experience. I like using Django for small and mid-sized projects, because with Flask I have to spend time adding all these extra libraries for universally required functionality on a quick app whereas, with Django it's plug…

For what it’s worth, on a Django codebase of 180k lines, 100k lines of templates, 1000 URLs, 380 “apps”, 350 models, we have a nice coherent structure across the whole codebase that makes us really productive. I haven’t seen a Flask code bass do this anywhere near as well. They all seem to end up becoming very different and tricky to onboard new devs onto because they are so custom. Django hides some complexity, but…

Do you mind explaining what that structure is? I always find the standard Django structure of everything is an "app" difficult to navigate once the codebase gets larger.

Re: Django Newbie Mistakes

#212

Earlier quoted context omitted.

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…

> Because... they are? The lack of self-instropection & hubris in some framework's devotees is astonishing. If someone is attempting to solve a problem, and their approach is not well-suited to the framework, perhaps it is the framework's fault? Perhaps suggest an alternative tool rather than telling the person they haven't come up with the 'best' approach (which is the version that the framework is well-suited to so…

Not really. What I'm claiming is that in the same way that 99% of claims of people who say they've found a compiler bug have not found one and instead just hit some undefined behavior or language corner case, 99% of people who find something unusual in well-worn web programming frameworks are usually not trying to solve problems the right way.

Synchronous web development in dynamic programming languages is, for all intents and purposes, a solved problem. The conceptual differences between Django, Rails, Laravel and so on are minuscule; there's a bounded number of ways to get a web request and spit out HTML.

It is an extremely well understood problem domain where escape hatches to go against idiomatic framework conventions have been built at all levels and are actually used judiciously by people who have an understanding of the tool's shortcomings.

And in the same spirit, I can say quite confidently that people that are trying to reinvent the wheel here have a non-zero, but minimal, chance of actually hitting a significant roadblock.

Re: Django Newbie Mistakes

#213
post #206
post #63

My favorite opinionated boilerplate for new Django projects: https://github.com/pydanny/cookiecutter-django/ From the author of the great Two Scoops of Django series. https://www.twoscoopspress.com/products/two-scoops-of-django... Two great ways to avoid some newbie mistakes. Although some could argue diving into boilerplate without understanding it is in fact a newbie mistake itself.

As a word of caution - the authentication framework used in this boilerplate, Allauth, is opinionated and badly documented. Expect to do code dives if you use this.

That’s actually the one thing I throw out immediately when I use this for precisely that reason.

Re: Django Newbie Mistakes

#214
post #72

Earlier quoted context omitted.

> I've had the "pleasure" of working with other large projects built on flask and ever time it gets to a certain size I wonder why we didn't just use Django. Actually, I've had the exact opposite experience. I like using Django for small and mid-sized projects, because with Flask I have to spend time adding all these extra libraries for universally required functionality on a quick app whereas, with Django it's plug…

For what it’s worth, on a Django codebase of 180k lines, 100k lines of templates, 1000 URLs, 380 “apps”, 350 models, we have a nice coherent structure across the whole codebase that makes us really productive. I haven’t seen a Flask code bass do this anywhere near as well. They all seem to end up becoming very different and tricky to onboard new devs onto because they are so custom. Django hides some complexity, but…

> I haven’t seen a Flask code bass do this anywhere near as well. They all seem to end up becoming very different and tricky to onboard new devs onto because they are so custom.

While some Flask web applications may use different file organization schemes, any large app will use blueprints. Blueprints are fairly standardized and easy to understand. I personally find Flask blueprints easier to follow than Django apps, but they're pretty similar.

Re: Django Newbie Mistakes

#215
post #204
post #192

Earlier quoted context omitted.

Well we can migrate to python 3 but this will be more investment in a stack that is more and more obsolete (Django) for SPA. Developers need also to learn the new best practices for python 3. At the end this will result in short term with python 3 code base written in python 2 style without the benefits of typing etc. Investment without benefits except keep our stack up-to-date. Each solution for Python/Django add co…

Django obselete? Sure....

For our usage that's my point of view. When you need to manage ws & asynchronous task, you are just ending stacking technologies to make Django enter in 2018 (remember tornado?). I would say that the framework didn't followed technology evolution and so our new requirements

For old good stuff is still a good framework. It really depends on your usage.

Re: Django Newbie Mistakes

#216
post #8

Django is a hell for APIs and big projects. It's good for beginners and small projects, but once you need the least amount of actual control, you will find it's too late

Django is perfectly fine for large projects. It's not the size of your project that will end up being a problem it's what you're trying to build that can be an issue. Most application built today, as in in-house development projects, are basic CRUD applications. Perhaps with some integrations to other systems and maybe a little calculation thrown in. I doubt that many, regardless of size will run into any really chal…

I think that generally applies to most frameworks, but I've noticed it heavily with django. Developers get upset that Django isn't working for them when they are actively avoiding best practices and going out of their way to fight it.

If you are fighting a robust framework, you are probably doing something wrong and should take a step back.

Re: Django Newbie Mistakes

#217
post #207
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 used to be a Perl dev for years, and tried a couple of Perl frameworks. I switched to Python because the docs were so much easier to get started with. There are a lot of concepts to understand with a framework so my guess is that's actually your problem, but as far as documentation goes, Django's is pretty good.

How the fuck was any of Pythons docs better than Perl’s? ??????????

Docs, error messages etc are WAY superior in Perl. Idiot.

Re: Django Newbie Mistakes

#218
post #207

Earlier quoted context omitted.

I used to be a Perl dev for years, and tried a couple of Perl frameworks. I switched to Python because the docs were so much easier to get started with. There are a lot of concepts to understand with a framework so my guess is that's actually your problem, but as far as documentation goes, Django's is pretty good.

How the fuck was any of Pythons docs better than Perl’s? ?????????? Docs, error messages etc are WAY superior in Perl. Idiot.

Could we please keep the discussion factual instead of resorting to name calling?

Re: Django Newbie Mistakes

#219

Earlier quoted context omitted.

For what it’s worth, on a Django codebase of 180k lines, 100k lines of templates, 1000 URLs, 380 “apps”, 350 models, we have a nice coherent structure across the whole codebase that makes us really productive. I haven’t seen a Flask code bass do this anywhere near as well. They all seem to end up becoming very different and tricky to onboard new devs onto because they are so custom. Django hides some complexity, but…

What does that Django project do?

https://www.thread.com/

Curated ecommerce, a CRM like system for stylist, order management, fulfilment and distribution.

Re: Django Newbie Mistakes

#220

Earlier quoted context omitted.

For what it’s worth, on a Django codebase of 180k lines, 100k lines of templates, 1000 URLs, 380 “apps”, 350 models, we have a nice coherent structure across the whole codebase that makes us really productive. I haven’t seen a Flask code bass do this anywhere near as well. They all seem to end up becoming very different and tricky to onboard new devs onto because they are so custom. Django hides some complexity, but…

Do you mind explaining what that structure is? I always find the standard Django structure of everything is an "app" difficult to navigate once the codebase gets larger.

As much as I'd rather not plug my own talk, it's probably going to give you more information than I could ever get in a reply here.

https://thread.engineering/scaling-django-codebases-pycon-uk...

Post reply on HN