12 ms·

Django 4.0 release candidate 1 released

180 points by pauloxnet 5y ago

creimers 5y ago
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.
- scrollaway 5y ago
  Django templates are the worst. Django is great. Just don't use its templates or form systems. Indeed react is a great replacement for both.
  - sgt 5y ago
    I disagree with that. They are fine for regular forms, tables (as in grids), etc. I usually have a few views using plain old Django templates (with a couple of template tags for additional functionality), and then maybe one view with a full blown SPA in it. No need to build your login page etc in React.
  - mejutoco 5y ago
    I disagree. The way you can extend sections of other templates without creating an inheritance chain works very well (and I missed in template systems, for Java, for example)
    - scrollaway 5y ago
      To be clear, I use them as well. And every time I come to regret it unless it's on a site I absolutely do not touch once it's finished. Templates make it harder to find and debug issues. They have extremely little tooling to give assurances about what they're compiling, whether the syntax is correct etc. This requires you to build massive, flaky test suites. I'll take react and typescript any day over even one tenth of that.
      - candiodari 5y ago
        Wouldn't all of python have that problem? What you're saying is that there's very little static checks until the code is run, but all of python has that problem too, doesn't it? Either you write big test cases covering everything, or you live with the knowledge that very unexpected things can be passed in to your methods without you getting notified. And then there's javascript ...
        scrollaway 5y ago
        Python doesn't have the problem as much. It does to an extent, though it's getting better with type hinting nowadays. I do prefer working with typescript than with python but I still rather work with Python than with django templates which are way worse.
        dangerbird2 5y ago
        It's less about static checking than it is runtime debugging. When you have a syntax error in a template, Django's error reporting is super opaque about the problem, usually just raising a TemplateSyntaxError with a vague description. This just gives you the python error stack with little information of the actual context of the actual problem in the template itself. By contrast, if you have a problem in the python code, the exception stacktrace will point you to exactly where the problem originates. If you add a `breakpoint()` call in the source before the exception point and run the request again, you'll get dropped into a live debugging repl
      - mundanevoice 5y ago
        Well, It is more of a design problem than a Django template problem. If you add more and more logic in the template itself instead of dealing with it in the views context or templatetags, you are bound to find yourself in such position that you have very hard to test code. The tooling is fine and almost always lets you know where you are breaking stuff. Also, comparing react tooling with it is not fair, it is a much modern ecosystem that has pitfalls of its own. I have been writing Django professionally for 10 years and React + Django together for 4+ years, so I really know what I am talking about here.
      - 5y ago
    - ekspreso 5y ago
      Have you tried https://pebbletemplates.io/ https://pebbletemplates.io/ for Java? I haven't used it extensively, so I can't speak how it compares to Django in larger setups.
      - mejutoco 5y ago
        Indeed! That is the one template language that looked like it might behave in the same way.
  - Hamuko 5y ago
    How many tools do I need to install to publish a front-end made with React?
    - scrollaway 5y ago
      Just the one if you're using CRA. None if you're embedding react as is. The answer depends on how you're using react, and what advantages you want to get from it. "How many tools" is not a real question to ask. If you're concerned about ease of development and learning curves, then that gives you an actual goal to optimize for, and it won't coincide with the amount of tools (react is harder to use embedded than with tooling, hence why the latter is more popular).
      - Hamuko 5y ago
        For each and every tool that is added to my project, it needs to be installed by every developer, it needs to be understood at least on some level by every developer, and it needs to be maintained by someone.
        scrollaway 5y ago
        You're missing my point. I don't know if this conversation can go anywhere.
    - Scarbutt 5y ago
      Just one, esbuild for JSX and bundling.
- pbowyer 5y ago
  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.
  - emacsen 5y ago
    I'm talking entirely out of my rear end, but I'm curious if there is any validity to some of these projects that let you run pythonic code in the browser, either through Webassembly or brpython. For example, this projects https://github.com/stefanhoelzl/vue.py https://github.com/stefanhoelzl/vue.py claims to let you write Vue.js in Python in the browser, which then gets turned into regular Vue.js components. I imagine a performance penalty, but a developer performance benefit of allowing something else to run on top and make a more composable experience. Or is this barking up the wrong tree entirely?
    - pbowyer 5y ago
      Up the wrong tree :) Vue.py gives you a way to write Vue to run in the browser using a Pythonic syntax. I'm talking about running actual Vue code (or anything else in that style) server-side as Django templates.
- semitones 5y ago
  You could use Django just for the backend and have your frontend code be written in React+Typescript, no?
  - dvdkon 5y ago
    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).
    - Zababa 5y ago
      The thing is that there's no TypeScript backend that gives you as much stuff out of the box as Django. You're either going to spend time on how to communicate between Django and TS, or spend time on how to recreate Django functionality in TS.
    - supreme_berry 5y ago
      Lol
    - mrctte 5y ago
      You can also just generate an Open API spec and use something like openapi-generators to produce typed client code for data fetching (https://github.com/OpenAPITools/openapi-generator https://github.com/OpenAPITools/openapi-generator)
      - Pandabob 5y ago
        This has been such a life saver for me these past couple of months
    - Pandabob 5y ago
      Doesn’t Django Rest Framework solve most of the issues you raise?
- sgt 5y ago
  Nothing stopping you from writing a Django app with parts written in React, VueJS or whatever you prefer.
  - creimers 5y ago
    Obviously nothing is stopping me, that's not the point. I was just highlighting the fact that in my opinion the DX of parts of Django is inferior compared to the JS frontend ecosystem. As the Django community, I think this is something we should have an eye on.
    - sgt 5y ago
      You're absolutely right in the sense that the Django and other communities should not stagnate and should also keep an eye on what the other frameworks are up to. Maybe the default template engine should be replaced in Django?
      - rglullis 5y ago
        Template engines are already configurable and pluggable for quite a while. The "problem" is that most of the third-party apps that want to provide templates end up using the default, so either you have to reimplement those or stick with the default engine.
        ensignavenger 5y ago
        You can use both the Django Template Engine and other template engines side-by side in the same project. You can then write your custom templates in whatever you want, and have your third-party apps use whatever template engine they want to.
        rglullis 5y ago
        My comment was more in the sense of wanting to extend third-party templates, but yeah, if you don't need to touch them you should be fine as well.
- globular-toast 5y ago
  > For example I’d choose React + Typescript over Django templates any time of the day. What's stopping you? I use Django Rest Framework to write views and React + Typescript for the front end. Using templates is often way simpler, though.
- 8589934591 5y ago
  I love Django a lot too. It has made MVPs really easy to deliver. At the same time, I am interested in understanding about the disadvantages/quirks of using Django. Do you have more examples that you could share?
- DylanSp 5y ago
  Not a Django person, but I've used a few server-side templating languages, and I agree. I'd love to go mostly/entirely server-side, cut down on boilerplate AJAX calls, and ship smaller/less JS-heavy sites to the browser. But I'd also like to write my view logic in a full language, with typechecking and a solid developer experience. I'm hopeful React Server Components will help with at least some of this.
pkz 5y ago
Great to see this project moving forward with new features and support for other backends etc. Every now and then I try out other frameworks but come back to Django for many of my projects.
privacyonsec 5y ago
still no async orm support
- privacyonsec 5y ago
  this looks interesting: https://github.com/rednaks/django-async-orm https://github.com/rednaks/django-async-orm Bringing Async Capabilities to django ORM
- julienpalard 5y ago
  The API is being worked on: https://github.com/django/django/pull/14843 https://github.com/django/django/pull/14843
patates 5y ago
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 you do things outside the happy-path. Also the documentation is indeed superb but you also hit a lot of outdated info when searching the web.
- lnxg33k1 5y ago
  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
- olau 5y ago
  When you're a Django beginner, yes, it can be annoying to go from something that's just super easy to having to stitch together something yourself. I'm not sure what exactly causes this feeling, but I did learn that you need to have the right perspective on some things and either let it go or find some other way. For instance, in my experience the admin site is best thought of as glorified DB UI. If you need something more than what it can offer out of the box, you should switch to coding it yourself, or live with a quick hack. I think that most of the time, Django just gets out of the way. At least if you stay away from the inheritance spaghetti that is class-based views. Use the functions, Luke. :)
  - zdkl 5y ago
    > either let it go or find some other way. With Django as soon as I have anything to do with a database I seem to hit this with the ORM. So I start working around it. Next thing you know it all seems to fall apart because of how coupled the rest of the application is to Django's assumptions about views and entities in the DB. So "You gave up instead of reading the docs.": I go back to flask, or recently FastApi where you have to figure your schemas and access patterns out for yourself in advance instead of building thorough and deep knowledge on how to deactivate parts of Django when they become redundant. Opinion my own, results may vary, IANA your dev, etc
BozeWolf 5y ago
There are cooler frameworks, there are more minimal frameworks, there are more "modern" frameworks. Whatever that means. Yes I would like to work with FastAPI, it is great. But... Django gets the shit done. There are plenty of developers to find for it. Lots of good quality plugins. Every problem you have, infrastructure wise, is often already solved and there is a blog post of it. Its good parts and its bad parts are widely written about. And if that is not enough: the documentation is great. Great framework to get your product to market, it allows me to focus on building products. I dont want to think about routing forms processing, or project layout again. I want to write code for the product, not for the framework. Django is just good enough. Forms, URL routing and models are not what delivers value to products I am working on. So I don't want to spend time on it. Remember: no customer cares about your product being run on cool-async-framework-X. Customers just want a good looking and good working product.
- top_sigrid 5y ago
  While I have no experience with Django, this could exactly be said about Rails. It's great these two exist and are being worked on for so long and have this level of maturity.
  - adamauckland 5y ago
    yes, they are very similar. I'm not sure if Rails has quite the level of auto-generating admin system, though.
    - the-dude 5y ago
      Probably better, just not in base.
    - gosukiwi 5y ago
      There's ActiveAdmin which basically that.
  - ksec 5y ago
    I wonder why Django seems to have a easier time in hiring, considering it should be a smaller market than Rails. Even on HN monthly hiring list Rails and Django open positions is roughly 3:1. And yet I rarely hear Django people ever complain about the lack of talent pool.
marton_s 5y ago
Upgraded one of my non-trivial Django projects to 4.0rc1 and so far it seems like I had to change zero lines. Pretty good for a new major version release, that's what I call mature software!
- mfollert 5y ago
  "non-trivial" and "rc1" I like your spirit! :D
kumarvvr 5y ago
Django is good for those who have used it a lot. For beginners, there are much better alternatives and, frankly, Django way of development is severely restricting. Starting off with an API backend and a React/Angular/Vue front end, allows new developers to learn better abstractions (and not merge front ends and back-ends) The very idea of "sending UI code to the front end for every request" is unsuitable for medium to large projects. But, if you start building smaller projects with an vertically integrated system like Django, it becomes increasingly difficult to think about larger projects.
- bmsleight_ 5y ago
  I think for beginners Django rocks. I dont do software at all in my career (Engineering), but I can pick-up a django project, look through the example project in the documentation and then throw (and I mean throw) together a working django project in a few evenings. With a very much an amateur knowledge of python. As in another thread, the css takes longer. Are they any other beginner alternatives I should be looking at ?
  - supreme_berry 5y ago
    Django is a back-end for many unicorn SF start-ups like Venmo. No one is going to use something different due to immature ecosystems.
- cehrlich 5y ago
  Django/Python is the first "real" thing I ever learned while teaching myself to become a developer (through Harvard's CS50web course), and I found it very easy to learn and pleasant to work with. It has its quirks, but what doesn't? Once you move on to using Django (probably with REST Framework) for the backend and React or some other JS framework for the front-end, you get some slightly difficult things involving Auth and some other stuff, and of course you can take the complexity as far as you want and I'm sure there are some Django devs with 10-15 years of experience who are experts in parts of the framework that I'm not even aware of, but I don't think learning Django to the point where you can ship a reasonably competent app is more difficult than learning Node/Express, or Rails, or whatever.
batiste 5y ago
Love Django. But we are using Django with Gunicorn at work and we are having massive concurrency issues (1 process, gthread)... More than 4 concurrent requests waiting on a slow IO and the whole thing melts down... FastAPI doesn't have those issues at all...
- MrOxiMoron 5y ago
  do you run fastapi through wsgi? have you tried Django with asgi?
- frankwiles 5y ago
  This is definitely something about your local setup or config. We routinely run hundreds and thousands of simultaneous connections through various versions of Django without much trouble.
- smashed 5y ago
  Please read this article: https://rachelbythebay.com/w/2020/03/07/costly/ https://rachelbythebay.com/w/2020/03/07/costly/
mypresences 5y ago
Is the line "abundance of new features" a joke? This a a major version increase, looks like very minor new features as usual. What happended to the async ORM?
jjice 5y ago
As someone who mostly has worked with minimal web frameworks (no ORM, admin site, etc), Django seems appealing. My only concern is that the ORM seems to be pretty coupled with different pieces of the framework, and I'd prefer to write SQL and wrapper it on a function on the model. Is my observation on the coupling off? Does anyone here have a good bit of experience using the raw SQL option for queries most of the time? I've seen people do it once and a while in situations they needed it, but no one who uses it as heavily as I'd plan to use it.
- wswope 5y ago
  I took that approach on my latest Flask project and it’s gone quite swimmingly. The problem I ran into was that a lot of the ecosystem, and therefore documentation, blog posts, helper libraries, etc., are all written under the assumption that you’re using an ORM. It took a while to figure out how to work around that, but once I did, I was home clear. I also used a helper library to automatically map namespaced .sql files onto python functions with various return types, which made the development process way more elegant: https://nackjicholson.github.io/aiosql/ https://nackjicholson.github.io/aiosql/. Absolute game changer if you plan to go this route - can’t recommend it highly enough.
  - jjice 5y ago
    I remember seeing aiosql a bit back and being impressed. I'll give that a shot. Right now I have a Flask application with separate dataclass models where I write a function like `get_by_id` and then then query the DB and get a dict back (using psycopg2 with DictRow returns) and then I can pass that directly to the dataclass constructor with `User(**row)`. Very flexible and working really well so far. Not sure how this scales though, but I'm happy with it at the moment.
charlieyu1 5y ago
As a beginner I don't like how Django uses strings for everything. installed apps etc. otherwise it is very good for me
adamchainz 5y ago
Here’s my post summarizing new testing features in Django 4.0: https://adamj.eu/tech/2021/09/28/new-testing-features-in-django-4.0/ https://adamj.eu/tech/2021/09/28/new-testing-features-in-dja...
sirodoht 5y ago
If anyone's looking something close to FastAPI but for Django, checkout django-ninja [1][2]. I recently joined a team that uses it, and it's pretty nice so far. [1] https://django-ninja.rest-framework.com/ https://django-ninja.rest-framework.com/ [2] https://github.com/vitalik/django-ninja https://github.com/vitalik/django-ninja
delbronski 5y ago
One thing I've never been able to figure out with Django is how to properly handle javascript. How do you all handle stuff like js dependencies? What I do now is just copy and paste a dependency like mapboxjs and keep it in the static folder. Would be great if I could use node or something like that and then have a way to import js dependencies in django templates. I've been using htmx and alpine js to sprinkle some js into my templates, but maintaining all of those js files always feel so clunky
- mixmastamyk 5y ago
  You can use npm or similar to download and install packages, then link them in your template. Just need to get them into the right folder or perhaps link them.
- infamia 5y ago
  Try creating a Django project using the Cookie Cutter Django: https://github.com/cookiecutter/cookiecutter-django/ https://github.com/cookiecutter/cookiecutter-django/ Select yes when asked if you want "custom_bootstrap_compilation" That will configure a gulp task runner that is capable of manage your javascript dependencies, bundle your CSS/JS, and minify your HTML, CSS, JS and images. You will still need to install npm etc. as described here. You will also need to become familiar with how to install and update Node packages. https://cookiecutter-django.readthedocs.io/en/latest/developing-locally.html#sass-compilation-live-reloading https://cookiecutter-django.readthedocs.io/en/latest/develop...
  - delbronski 5y ago
    Thanks for the tip! Just checked it out. I'm going to give it a go with an existing project. I guess for deploying I nees my build pipeline to have access to node/npm so it can build the right static files right? But I should not need npm in production.
radus 5y ago
My favorite new additions: - django.core.cache.backends.redis.RedisCache cache backend provides built-in support for caching with Redis - The runserver management command now supports the --skip-checks option. - The shell command now respects sys.__interactivehook__ at startup. This allows loading shell history between interactive sessions. As a consequence, readline is no longer loaded if running in isolated mode. - New QuerySet.contains(obj) method returns whether the queryset contains the given object. This tries to perform the query in the simplest and fastest way possible. - Lookup expressions may now be used in QuerySet annotations, aggregations, and directly in filters.

180 points by pauloxnet 5y ago

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.

scrollaway 5y ago
Django templates are the worst. Django is great. Just don't use its templates or form systems. Indeed react is a great replacement for both.
- sgt 5y ago
  I disagree with that. They are fine for regular forms, tables (as in grids), etc. I usually have a few views using plain old Django templates (with a couple of template tags for additional functionality), and then maybe one view with a full blown SPA in it. No need to build your login page etc in React.
- mejutoco 5y ago
  I disagree. The way you can extend sections of other templates without creating an inheritance chain works very well (and I missed in template systems, for Java, for example)
  - scrollaway 5y ago
    To be clear, I use them as well. And every time I come to regret it unless it's on a site I absolutely do not touch once it's finished. Templates make it harder to find and debug issues. They have extremely little tooling to give assurances about what they're compiling, whether the syntax is correct etc. This requires you to build massive, flaky test suites. I'll take react and typescript any day over even one tenth of that.
    - candiodari 5y ago
      Wouldn't all of python have that problem? What you're saying is that there's very little static checks until the code is run, but all of python has that problem too, doesn't it? Either you write big test cases covering everything, or you live with the knowledge that very unexpected things can be passed in to your methods without you getting notified. And then there's javascript ...
      - scrollaway 5y ago
        Python doesn't have the problem as much. It does to an extent, though it's getting better with type hinting nowadays. I do prefer working with typescript than with python but I still rather work with Python than with django templates which are way worse.
      - dangerbird2 5y ago
        It's less about static checking than it is runtime debugging. When you have a syntax error in a template, Django's error reporting is super opaque about the problem, usually just raising a TemplateSyntaxError with a vague description. This just gives you the python error stack with little information of the actual context of the actual problem in the template itself. By contrast, if you have a problem in the python code, the exception stacktrace will point you to exactly where the problem originates. If you add a `breakpoint()` call in the source before the exception point and run the request again, you'll get dropped into a live debugging repl
    - mundanevoice 5y ago
      Well, It is more of a design problem than a Django template problem. If you add more and more logic in the template itself instead of dealing with it in the views context or templatetags, you are bound to find yourself in such position that you have very hard to test code. The tooling is fine and almost always lets you know where you are breaking stuff. Also, comparing react tooling with it is not fair, it is a much modern ecosystem that has pitfalls of its own. I have been writing Django professionally for 10 years and React + Django together for 4+ years, so I really know what I am talking about here.
    - 5y ago
  - ekspreso 5y ago
    Have you tried https://pebbletemplates.io/ https://pebbletemplates.io/ for Java? I haven't used it extensively, so I can't speak how it compares to Django in larger setups.
    - mejutoco 5y ago
      Indeed! That is the one template language that looked like it might behave in the same way.
- Hamuko 5y ago
  How many tools do I need to install to publish a front-end made with React?
  - scrollaway 5y ago
    Just the one if you're using CRA. None if you're embedding react as is. The answer depends on how you're using react, and what advantages you want to get from it. "How many tools" is not a real question to ask. If you're concerned about ease of development and learning curves, then that gives you an actual goal to optimize for, and it won't coincide with the amount of tools (react is harder to use embedded than with tooling, hence why the latter is more popular).
    - Hamuko 5y ago
      For each and every tool that is added to my project, it needs to be installed by every developer, it needs to be understood at least on some level by every developer, and it needs to be maintained by someone.
      - scrollaway 5y ago
        You're missing my point. I don't know if this conversation can go anywhere.
  - Scarbutt 5y ago
    Just one, esbuild for JSX and bundling.
pbowyer 5y ago
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.
- emacsen 5y ago
  I'm talking entirely out of my rear end, but I'm curious if there is any validity to some of these projects that let you run pythonic code in the browser, either through Webassembly or brpython. For example, this projects https://github.com/stefanhoelzl/vue.py https://github.com/stefanhoelzl/vue.py claims to let you write Vue.js in Python in the browser, which then gets turned into regular Vue.js components. I imagine a performance penalty, but a developer performance benefit of allowing something else to run on top and make a more composable experience. Or is this barking up the wrong tree entirely?
  - pbowyer 5y ago
    Up the wrong tree :) Vue.py gives you a way to write Vue to run in the browser using a Pythonic syntax. I'm talking about running actual Vue code (or anything else in that style) server-side as Django templates.
semitones 5y ago
You could use Django just for the backend and have your frontend code be written in React+Typescript, no?
- dvdkon 5y ago
  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).
  - Zababa 5y ago
    The thing is that there's no TypeScript backend that gives you as much stuff out of the box as Django. You're either going to spend time on how to communicate between Django and TS, or spend time on how to recreate Django functionality in TS.
  - supreme_berry 5y ago
    Lol
  - mrctte 5y ago
    You can also just generate an Open API spec and use something like openapi-generators to produce typed client code for data fetching (https://github.com/OpenAPITools/openapi-generator https://github.com/OpenAPITools/openapi-generator)
    - Pandabob 5y ago
      This has been such a life saver for me these past couple of months
  - Pandabob 5y ago
    Doesn’t Django Rest Framework solve most of the issues you raise?
sgt 5y ago
Nothing stopping you from writing a Django app with parts written in React, VueJS or whatever you prefer.
- creimers 5y ago
  Obviously nothing is stopping me, that's not the point. I was just highlighting the fact that in my opinion the DX of parts of Django is inferior compared to the JS frontend ecosystem. As the Django community, I think this is something we should have an eye on.
  - sgt 5y ago
    You're absolutely right in the sense that the Django and other communities should not stagnate and should also keep an eye on what the other frameworks are up to. Maybe the default template engine should be replaced in Django?
    - rglullis 5y ago
      Template engines are already configurable and pluggable for quite a while. The "problem" is that most of the third-party apps that want to provide templates end up using the default, so either you have to reimplement those or stick with the default engine.
      - ensignavenger 5y ago
        You can use both the Django Template Engine and other template engines side-by side in the same project. You can then write your custom templates in whatever you want, and have your third-party apps use whatever template engine they want to.
        rglullis 5y ago
        My comment was more in the sense of wanting to extend third-party templates, but yeah, if you don't need to touch them you should be fine as well.
globular-toast 5y ago
> For example I’d choose React + Typescript over Django templates any time of the day. What's stopping you? I use Django Rest Framework to write views and React + Typescript for the front end. Using templates is often way simpler, though.
8589934591 5y ago
I love Django a lot too. It has made MVPs really easy to deliver. At the same time, I am interested in understanding about the disadvantages/quirks of using Django. Do you have more examples that you could share?
DylanSp 5y ago
Not a Django person, but I've used a few server-side templating languages, and I agree. I'd love to go mostly/entirely server-side, cut down on boilerplate AJAX calls, and ship smaller/less JS-heavy sites to the browser. But I'd also like to write my view logic in a full language, with typechecking and a solid developer experience. I'm hopeful React Server Components will help with at least some of this.

pkz 5y ago

Great to see this project moving forward with new features and support for other backends etc. Every now and then I try out other frameworks but come back to Django for many of my projects.

privacyonsec 5y ago

still no async orm support

privacyonsec 5y ago
this looks interesting: https://github.com/rednaks/django-async-orm https://github.com/rednaks/django-async-orm Bringing Async Capabilities to django ORM
julienpalard 5y ago
The API is being worked on: https://github.com/django/django/pull/14843 https://github.com/django/django/pull/14843

patates 5y ago

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 you do things outside the happy-path. Also the documentation is indeed superb but you also hit a lot of outdated info when searching the web.

lnxg33k1 5y ago
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
olau 5y ago
When you're a Django beginner, yes, it can be annoying to go from something that's just super easy to having to stitch together something yourself. I'm not sure what exactly causes this feeling, but I did learn that you need to have the right perspective on some things and either let it go or find some other way. For instance, in my experience the admin site is best thought of as glorified DB UI. If you need something more than what it can offer out of the box, you should switch to coding it yourself, or live with a quick hack. I think that most of the time, Django just gets out of the way. At least if you stay away from the inheritance spaghetti that is class-based views. Use the functions, Luke. :)
- zdkl 5y ago
  > either let it go or find some other way. With Django as soon as I have anything to do with a database I seem to hit this with the ORM. So I start working around it. Next thing you know it all seems to fall apart because of how coupled the rest of the application is to Django's assumptions about views and entities in the DB. So "You gave up instead of reading the docs.": I go back to flask, or recently FastApi where you have to figure your schemas and access patterns out for yourself in advance instead of building thorough and deep knowledge on how to deactivate parts of Django when they become redundant. Opinion my own, results may vary, IANA your dev, etc

BozeWolf 5y ago

There are cooler frameworks, there are more minimal frameworks, there are more "modern" frameworks. Whatever that means. Yes I would like to work with FastAPI, it is great. But... Django gets the shit done. There are plenty of developers to find for it. Lots of good quality plugins. Every problem you have, infrastructure wise, is often already solved and there is a blog post of it. Its good parts and its bad parts are widely written about. And if that is not enough: the documentation is great. Great framework to get your product to market, it allows me to focus on building products. I dont want to think about routing forms processing, or project layout again. I want to write code for the product, not for the framework. Django is just good enough. Forms, URL routing and models are not what delivers value to products I am working on. So I don't want to spend time on it. Remember: no customer cares about your product being run on cool-async-framework-X. Customers just want a good looking and good working product.

top_sigrid 5y ago
While I have no experience with Django, this could exactly be said about Rails. It's great these two exist and are being worked on for so long and have this level of maturity.
- adamauckland 5y ago
  yes, they are very similar. I'm not sure if Rails has quite the level of auto-generating admin system, though.
  - the-dude 5y ago
    Probably better, just not in base.
  - gosukiwi 5y ago
    There's ActiveAdmin which basically that.
- ksec 5y ago
  I wonder why Django seems to have a easier time in hiring, considering it should be a smaller market than Rails. Even on HN monthly hiring list Rails and Django open positions is roughly 3:1. And yet I rarely hear Django people ever complain about the lack of talent pool.

marton_s 5y ago

Upgraded one of my non-trivial Django projects to 4.0rc1 and so far it seems like I had to change zero lines. Pretty good for a new major version release, that's what I call mature software!

mfollert 5y ago
"non-trivial" and "rc1" I like your spirit! :D

kumarvvr 5y ago

Django is good for those who have used it a lot. For beginners, there are much better alternatives and, frankly, Django way of development is severely restricting. Starting off with an API backend and a React/Angular/Vue front end, allows new developers to learn better abstractions (and not merge front ends and back-ends) The very idea of "sending UI code to the front end for every request" is unsuitable for medium to large projects. But, if you start building smaller projects with an vertically integrated system like Django, it becomes increasingly difficult to think about larger projects.

bmsleight_ 5y ago
I think for beginners Django rocks. I dont do software at all in my career (Engineering), but I can pick-up a django project, look through the example project in the documentation and then throw (and I mean throw) together a working django project in a few evenings. With a very much an amateur knowledge of python. As in another thread, the css takes longer. Are they any other beginner alternatives I should be looking at ?
- supreme_berry 5y ago
  Django is a back-end for many unicorn SF start-ups like Venmo. No one is going to use something different due to immature ecosystems.
cehrlich 5y ago
Django/Python is the first "real" thing I ever learned while teaching myself to become a developer (through Harvard's CS50web course), and I found it very easy to learn and pleasant to work with. It has its quirks, but what doesn't? Once you move on to using Django (probably with REST Framework) for the backend and React or some other JS framework for the front-end, you get some slightly difficult things involving Auth and some other stuff, and of course you can take the complexity as far as you want and I'm sure there are some Django devs with 10-15 years of experience who are experts in parts of the framework that I'm not even aware of, but I don't think learning Django to the point where you can ship a reasonably competent app is more difficult than learning Node/Express, or Rails, or whatever.

batiste 5y ago

Love Django. But we are using Django with Gunicorn at work and we are having massive concurrency issues (1 process, gthread)... More than 4 concurrent requests waiting on a slow IO and the whole thing melts down... FastAPI doesn't have those issues at all...

MrOxiMoron 5y ago
do you run fastapi through wsgi? have you tried Django with asgi?
frankwiles 5y ago
This is definitely something about your local setup or config. We routinely run hundreds and thousands of simultaneous connections through various versions of Django without much trouble.
smashed 5y ago
Please read this article: https://rachelbythebay.com/w/2020/03/07/costly/ https://rachelbythebay.com/w/2020/03/07/costly/

mypresences 5y ago

Is the line "abundance of new features" a joke? This a a major version increase, looks like very minor new features as usual. What happended to the async ORM?

jjice 5y ago

As someone who mostly has worked with minimal web frameworks (no ORM, admin site, etc), Django seems appealing. My only concern is that the ORM seems to be pretty coupled with different pieces of the framework, and I'd prefer to write SQL and wrapper it on a function on the model. Is my observation on the coupling off? Does anyone here have a good bit of experience using the raw SQL option for queries most of the time? I've seen people do it once and a while in situations they needed it, but no one who uses it as heavily as I'd plan to use it.

wswope 5y ago
I took that approach on my latest Flask project and it’s gone quite swimmingly. The problem I ran into was that a lot of the ecosystem, and therefore documentation, blog posts, helper libraries, etc., are all written under the assumption that you’re using an ORM. It took a while to figure out how to work around that, but once I did, I was home clear. I also used a helper library to automatically map namespaced .sql files onto python functions with various return types, which made the development process way more elegant: https://nackjicholson.github.io/aiosql/ https://nackjicholson.github.io/aiosql/. Absolute game changer if you plan to go this route - can’t recommend it highly enough.
- jjice 5y ago
  I remember seeing aiosql a bit back and being impressed. I'll give that a shot. Right now I have a Flask application with separate dataclass models where I write a function like `get_by_id` and then then query the DB and get a dict back (using psycopg2 with DictRow returns) and then I can pass that directly to the dataclass constructor with `User(**row)`. Very flexible and working really well so far. Not sure how this scales though, but I'm happy with it at the moment.

charlieyu1 5y ago

As a beginner I don't like how Django uses strings for everything. installed apps etc. otherwise it is very good for me

adamchainz 5y ago

Here’s my post summarizing new testing features in Django 4.0: https://adamj.eu/tech/2021/09/28/new-testing-features-in-django-4.0/ https://adamj.eu/tech/2021/09/28/new-testing-features-in-dja...

sirodoht 5y ago

If anyone's looking something close to FastAPI but for Django, checkout django-ninja [1][2]. I recently joined a team that uses it, and it's pretty nice so far. [1] https://django-ninja.rest-framework.com/ https://django-ninja.rest-framework.com/ [2] https://github.com/vitalik/django-ninja https://github.com/vitalik/django-ninja

delbronski 5y ago

One thing I've never been able to figure out with Django is how to properly handle javascript. How do you all handle stuff like js dependencies? What I do now is just copy and paste a dependency like mapboxjs and keep it in the static folder. Would be great if I could use node or something like that and then have a way to import js dependencies in django templates. I've been using htmx and alpine js to sprinkle some js into my templates, but maintaining all of those js files always feel so clunky

mixmastamyk 5y ago
You can use npm or similar to download and install packages, then link them in your template. Just need to get them into the right folder or perhaps link them.
infamia 5y ago
Try creating a Django project using the Cookie Cutter Django: https://github.com/cookiecutter/cookiecutter-django/ https://github.com/cookiecutter/cookiecutter-django/ Select yes when asked if you want "custom_bootstrap_compilation" That will configure a gulp task runner that is capable of manage your javascript dependencies, bundle your CSS/JS, and minify your HTML, CSS, JS and images. You will still need to install npm etc. as described here. You will also need to become familiar with how to install and update Node packages. https://cookiecutter-django.readthedocs.io/en/latest/developing-locally.html#sass-compilation-live-reloading https://cookiecutter-django.readthedocs.io/en/latest/develop...
- delbronski 5y ago
  Thanks for the tip! Just checked it out. I'm going to give it a go with an existing project. I guess for deploying I nees my build pipeline to have access to node/npm so it can build the right static files right? But I should not need npm in production.

radus 5y ago

My favorite new additions: - django.core.cache.backends.redis.RedisCache cache backend provides built-in support for caching with Redis - The runserver management command now supports the --skip-checks option. - The shell command now respects sys.__interactivehook__ at startup. This allows loading shell history between interactive sessions. As a consequence, readline is no longer loaded if running in isolated mode. - New QuerySet.contains(obj) method returns whether the queryset contains the given object. This tries to perform the query in the simplest and fastest way possible. - Lookup expressions may now be used in QuerySet annotations, aggregations, and directly in filters.