10 ms·

Django 4.0

473 points by Spiritus 5y ago

naveen_ 5y ago
Thanks a lot..
nanna 5y ago
I must learn Django, it's got everything I'll ever need. No, Rails will make me happy and it's better for lonely devs like me. No I must learn a Modern Web Framework (TM) to prove I'm not stuck in the past. No way, I'm not a fashionista. Have you seen that Phoenix demo where the guy builds Twitter in like 4 minutes? That's the future. Hold on a minute, enough of this magic. I need to learn to build everything in Common Lisp and own my code 100%! Wait I don't actually have the time for that. Django is the way, it's so solid, just that it won't bring me joy....
- melling 5y ago
  Yep, web solutions change too fast, with lots of legacy, and every solution is a compromise.
- agumonkey 5y ago
  paradogm of choice
- hellbannedguy 5y ago
  Yea--I don't want to waste my life learning frameworks either. The less time googling a new framework, the better. Now learning Lisp is something else.
- myth_drannon 5y ago
  That's me. Once a year I get burned out from all the new languages and frameworks and decide to learn Common Lisp again for the 10the time.
  - exdsq 5y ago
    Hahahaha you've just described my life too
    - chespinoza 5y ago
      Same here :/
- mathnmusic 5y ago
  You can experience all of this while staying in a single language ecosystem. Just recently, I had to build something in Javascript and got to know Express is no longer recommended. Fastify, Remix are the latest hotness. :)
  - aneutron 5y ago
    I genuienly have not heard about either one of the three. I guess I remain stuck in PHP, Phalcon Framework, Symfony and Django / Flask.
    - jimnotgym 5y ago
      I was checking out Express...how do I get user logins, oh just npm in 50 other projects, adding 50000 dependencies. Back to Django then!
      - shafyy 5y ago
        Haha, that's exactly what I'm dealing with right now on the project I'm working. Add on top of that Firebase Cloud Functions. I really miss Rails.
      - abdusco 5y ago
        The difference between Django and Express.js is that one is a fully-fledged web application framework, while the other is a micro framework that just gives you a simple request -> response abstraction over `http.createServer`. I find Flask is more comparable to Express.js in that regard. Need auth? You need to: 1. Install a lib for persistence 2. Set up cookie sessions, or install another lib for JWT 3. Set up auth middleware 4. Prepare login/register/forgot pass views and flows which are almost the same steps you need to take in Express.js.
        jimnotgym 5y ago
        I guess my surprise came from asking around about what framework to use and being told it was Express. I guess it might be 'Sails', but it's been a week or two so that is probably obsolete now.
- Waterluvian 5y ago
  There are just so many makes and models of automobile and people get by. I remain so confused why choice paralysis is a thing in software. Maybe the libraries need to cost 30,000$ ;-)
  - whatch 5y ago
    Sometimes they cost you much more, if you chose the wrong one
  - Kototama 5y ago
    That would for sure push our community to better describe the runtime of the different solutions. We talked only about syntax, features, semantic but very little about the runtime characteristics of the different platforms (Java, .Net, BEAM, different Common Lisps implementation etc). Maybe it's a sign of abundance and that most of these solutions are ok in most of the cases.
  - solididiot 5y ago
    Imagine each car model having different controls, different engine and components placement, some coming with rectangular wheels. That image is closer to SW frameworks.
  - BeFlatXIII 5y ago
    Different cars are much more obviously different than different web frameworks. When car shopping, you know whether you're looking for a RAM3500, an Odyssey, or a Mustang. Sure, the F-150 may win out in the end, but the Caravan and Charger were never contenders when looking for a truck. Choosing between software (especially bikeshedding between languages that both place priority on being pleasant to write) is often like comparing a Tacoma to a Tesla on the quality of seat heaters, upgrade price for the sunroof, and selection of factory paint options. Worse, you can't often have a clear understanding of the difference without investing the time to gain direct experience with each option. Otherwise, you're relying on community reputation and hoping it's both accurate and not horribly out of date.
- Zababa 5y ago
  There's also the part where you dig around to see what people use and recommand, and most of the answers are "use what you already know", which doesn't help when you don't know anything in detail. I feel like at this point the best strategy would be to list all the viables alternatives, pick one, and forbid yourself from using anything else for the next X months, but when thinking about that I have a huge fear of missing out.
- solididiot 5y ago
  It's actually a bit worse (or better) depending on how you see it. You get to invest (time, energy) in what will land you a job. 99% it's not what you want/like and not what is technically best. IT's just what came to dominate your job market. At least if you're in a EU backwater country or in EU public sector-related projects. (Which usually means java/c# and to a much lesser extend a python tech stack). PS: Loved the rant but you forgot to mention Golang :). "You're doing web backend and not using Go?!!"
  - Nextgrid 5y ago
    This really depends whether you see IT as a job or as a tool to achieve your own projects. If the latter, then you don't particularly care how "hype" your tech stack is as long as it successfully solves your own problems.
- deleted 5y ago
  [deleted]
- ac130kz 5y ago
  Nah, Django makes you sad: async support is not full, migrations engine is pretty poor, not all database features are present, any kind of typing is hacky, very slow and so on
  - geewee 5y ago
    What other migration engine have you used that's better? Anything non-django I've used makes me wish I was using Django
    - fb03 5y ago
      "alembic" is better by leaps and bounds. it is used within a SQLAlchemy system, which is also a superior ORM than Django's.
      - louissan 5y ago
        question of taste...
        robertlagrant 5y ago
        Less taste and more that data mapper ORMs are better (although harder to make) than active record ones, except for very small datasets/simple queries.
        andybak 5y ago
        "Better" for whom? It was a long time ago that I surveyed the ORM landscape but I remember thinking at the time I was much happier using an active record style ORM. I guess I'm saying I'm always suspicious when I see "better" with no qualification. Everything has tradeoffs.
        handrous 5y ago
        I, for one, find data mapper simply baffling. I look at it and can't even comprehend why someone might want to do things that way. Granted, I'm not fond of ORMs in general, but I at least understand the appeal of the active record pattern.
WayToDoor 5y ago
While it doesn't seem like a major update at first glance on this news piece, the changelog is available here : https://docs.djangoproject.com/en/4.0/releases/4.0/ https://docs.djangoproject.com/en/4.0/releases/4.0/ Of note, in my opinion : - The new AddConstraintNotValid operation allows creating check constraints on PostgreSQL without verifying that all existing rows satisfy the new constraint, meaning that one can now create constraints on big postgres tables without a waiting period. - Async methods are coming, to cache for now but hopefully soon to the ORM. They are prefixed with a `a` in the name - DeleteView now uses FormMixin, allowing you to provide a Form subclass, with a checkbox for example, to confirm deletion. In addition, this allows DeleteView to function with django.contrib.messages.views.SuccessMessageMixin. This is a big thing if you use DeleteViews, as you can now easily show a message post-deletion to the user.
- fleetfox 5y ago
  Do you know if the ORM solution have the same `a` suffix for async interface? I really hope there is more elegant solution for all this.
  - cdrx 5y ago
    ORM will use the same `a` suffix, yes.
  - deckiedan 5y ago
    Yes - it's kinda ugly at the moment, having all the `a` prefixed functions - but I think it's intended as a kind of long-term-intermediate step - since the whole of django isn't async at the moment, and needs to have separate versions for everything. I (wildly) speculate that once the ORM is async too, and all the rest of the bits fall into place (maybe django 5?), maybe django 6 will drop the `a` prefixes and integrate it all back together somehow?
    - samwillis 5y ago
      I believe they chose the 'a...' pattern as it matches other apis in the standard library - it also makes it explicit but concise. I can't see it being dropped any time the future, Django will always have a sync api, that won't be dropped. And there is no way in (current) python to combine a sync and async api into a single method.
ilovefood 5y ago
Congratulations on the release!! I'm looking forward to give it a go and see what's new for myself.
avinassh 5y ago
I recently upgraded [0] one of my project [1] to Django v4, from Django v1. The changes from Django 3 to 4 were fairly simple, just one line change in my case. The change log is extremely detailed, it was easy to upgrade. Also, I found a tool called django-upgrade [2] which makes some changes automatically, rest I made manually. [0] - https://avi.im/blag/2021/rc-day-20/ https://avi.im/blag/2021/rc-day-20/ [1] - https://github.com/avinassh/della https://github.com/avinassh/della [2] - https://github.com/adamchainz/django-upgrade https://github.com/adamchainz/django-upgrade
- fernandotakai 5y ago
  that's super nice to know -- i need to upgrade a django app from 1.11 to 4 over the next couple of weeks!
  - spapas82 5y ago
    If the 1.11 project is in python 3 then it would be a piece of cake. If it's in python 2 then it will need a little more effort to convert to python 3 but but not much really. Django have hasn't changed that much since 1.11!
clement_b 5y ago
I enjoy coding with Django. It's the framework that helped me make a smooth move from PHP/Symfony to Python-powered web apps. Not that I dislike PHP... just wanted to focus more on Python. Many thanks to everyone involved in the project!
alberth 5y ago
Off topic: I wish NIM had a Django-like web framework.
_tardigrade 5y ago
nowadays most people use Django to create REST API. I wish Django would merge DRF into its codebase.
- mrweasel 5y ago
  > nowadays most people use Django to create REST API I doubt that's true, but yes, having DRF merged in would be rather nice.
  - PhoenixReborn 5y ago
    There are quite a lot of apps that do a JS frontend and Django backend these days, I myself have done quite a few.
    - mrweasel 5y ago
      Absolutely, I just question the premise that “most” Django applications are like that. My best guess, and I have nothing but my own experience to back this up, is that for every public facing Django based website, there are at least three used internally and at least one of those use nothing but the build in admin interface as a UI.
- dralley 5y ago
  At this point I disagree - DRF is a verbose and somewhat dated architecture. I wish they would provide something like Django Ninja / FastAPI. Plus it already has decent async support. https://github.com/vitalik/django-ninja https://github.com/vitalik/django-ninja
rlawson 5y ago
Django has allowed me to enjoy some side entrepreneurship. I have released three products as a solo part time dev that I would never have been able to do in a reasonable time using Java/Spring (my strongest stack). My first project went nowhere, but the second generated 1k+ a month and sold for 50k, and the third one is following a similar trajectory. My advice - keep it simple - function based views - centralize access to the ORM (avoid fat models, use a service layer) - responsive bootstrap template with crispy forms - minimal js - 12 factor type setup - django-environ or similar - be aware of n+1 select problem (I use django debug toolbar but looking into django-zen-queries) - plop it on heroku, AWS lightsail, Digital Ocean or if containerizing use AWS Fargate - avoid celery unless you are at a scale you need it - use django-cron, django-db-queue or similar - use a managed database and managed email service I have had zero scalability problems. People say Django is slow but it handled 10k active users on a small EC2 instance without any issues (static stuff served via cloudfront)
- hda111 5y ago
  +1 for trying to avoid celery. Too much complexity for simple asynchronous tasks. You should use it however if you are instagram (I think they use a customized Django and Celery).
- Alex3917 5y ago
  > function based views Class-based views, in their most basic form, are a lot easier to read. E.g. look at the DRF CBVs I have here: https://github.com/Alex3917/django_for_startups/blob/main/django_for_startups/app/views/account_management_views.py https://github.com/Alex3917/django_for_startups/blob/main/dj... If you can avoid Generic CBVs (things like ListView) and inheritance, then the only difference between FBVs and CBVs is that CBVs make it easier to see what's a GET / PUT / POST / DELETE by adding some syntax highlighting that makes it easier to visually differentiate which code goes to which method. You don't need to know anything about classes in Python in order to use them. It's not at all difficult to switch from FBVs to CBVs later, and most people (myself included) use FBVs when getting started. But I'd also say that if you're willing to push through the initial discomfort and spend the extra half hour or whatever on YouTube in order to understand them, then you do get a little bit of a nicer overall development experience.
pantulis 5y ago
Before Django there was Zope in python-land. I don't think I overstate the relevance of what Django did by saying that Django almost single handledy advanced the state-of-the-art of web deployment in Python forward a decade.
- stdbrouw 5y ago
  Zope hails from the era when Python was trying to appeal to programmers by showing that it, too, could be a Serious Enterprise Language. Everything had layer after layer of abstraction and the code looked more like Java than Python. The Zope ORM was kind of nice in its own weird way, though.
  - VectorLock 5y ago
    Zope had some things like the Language Is The Database trope that sort of remind of the things described in those Bank Python blog posts that have been floating around recently.
raihansaputra 5y ago
I've always followed Django as Python is my first language and still my 'natural' way to think about code. The more I look into it, the more I feel like the learning curve is a bit like a camel's back. Easy for some stuff. Hard to figure the middle part (usually because not understanding "how" Django really works). And easy at the ends after knowing how you can "mould" Django in certain ways. It feels like a great multitool for the professionals who need to create project after project. I believe the middle part of the learning curve can be easier, but with the "social cruft" of all the Django tutorials out there, it's a game of luck to encounter what's good and what are the different, sensible, approaches to handling growing/big Django apps. What can make this easier is a document/discussion of some sort that provides clear, complete, approaches. Here are some aspect that needs to be considered. I believe with the combinations defined, and describing the tradeoffs will be a very great start for any team/person looking to jump into Django, or improve their next project. - Postgres seems to be default. SQLite + Litestream is there but still bleeding edge. - Packaging is the hot topic, for sure. Pipenv, poetry, venv, etc? - Traditional Serverside Templating + JS enhancement (HTMX/Hotwire/etc), or JS based SPA (React, Vue, Angular, Svelte, etc) -- This also includes the asset compiling story (Tailwind JIT, Sass compilation, Babel/webpack/rollup/etc) - Fat models, Fat views, or Service layer? To which extent? - Single app (Doordash) or Multiple apps (Thread with >500 apps)? - What's the theoritical limit to using Postgres + Disk/Memory Caching (so no external Redis/ElasticSearch/other services needed)? -- Search, queues/async job, scheduled jobs, reports, emails, etc EDIT: A view additional points - Documented limits about using whitenoise to serve static assets, and when & how to move to S3. Also Cloudflare/CDN fronting - Cloud storage story (uploading to S3 api from FileField and Rich Text fields, and also async jobs) -- Proxy story to enable <a download> from cloud? (Maybe a bit far, but I think this is a common request) - Deploying/Serving optimization (is gunicorn the best option for now? how to scale w/ regard to vCPU counts to avoid the 25% CPU Max utilization?) - How to debug between inefficient query/app code/templating/serving/caching? I'm sure there are more points, but it would be great if there's a documented sensible approaches to evaluate. I know there are templates, but great discussions about the tradeoffs of complete "packages" are rare.
polote 5y ago
14 days ago https://news.ycombinator.com/item?id=29303611 https://news.ycombinator.com/item?id=29303611 76 days ago https://news.ycombinator.com/item?id=28609188 https://news.ycombinator.com/item?id=28609188 3 month ago https://news.ycombinator.com/item?id=28566044 https://news.ycombinator.com/item?id=28566044
midrus 5y ago
I've used Django for a long, long time (since 0.96). Django is great for backend stuff, but nowadays for full stack applications (if you're not doing an SPA) I find Laravel and Rails a lot better. In particular Laravel's templates (blade) and asset handling is awesome.
dukeofdoom 5y ago
I still have a project that runs on Django 1.6. Can't imagine trying to migrate now, when it relies on so many old packages. Would probably be better of starting from scratch.
- selcuka 5y ago
  I would start by replacing the dependencies that are not maintained anymore (i.e. that don't support a relatively recent Python 3.x) with more modern alternatives one by one instead of rewriting it. The migration of the Django application itself should not be that hard.
- slig 5y ago
  I had a project running on 1.3 until very recently. The was a lot of issues with the TZ datetime fields, migrations, Python2, etc. It was a lot easier to start a new project from scratch.
appliku 5y ago
Thank you Django. that’s a great news. 14 years ago someone helped me discover Python and Django. I started from django official tutorial and never changed the framework of choice. It was my hobby, my career, my tool to put the food on the table. 12 years later I have started building a way to solve deployment question. started from bunch of scritps. today I have made cost effective tool to deploy Django projects and pretty much any python app on AWS/Digital Ocean https://appliku.com/ https://appliku.com/ it is like heroku but uses you own cloud account and not expensive at all.
ralmidani 5y ago
Django made me fall in love with programming. I built 2 decent-sized side projects with Django. They didn’t gain traction, but I loved using the framework. Then I went through a couple of (depressing) years of using Java/Spring professionally, and recently I made the choice to move to Elixir/Phoenix. It’s going great, and I don’t think I would go back to heavy OOP if I didn’t have to. Some things I really miss from Django: - Models with more centralized validation logic. In Phoenix (and somewhat similarly in Rails), you need to edit your migration, schema, and changeset. In Django, you edit your model and the migration can usually be made automatically with no need for a 3rd-party package. - Django REST Framework. You can get pretty far with an app just by leveraging ModelSerializers and ModelViewsets. It’s ridiculously elegant, simple, and powerful. - The Admin layer is fantastic and unparalleled. Some things I wish Django would add/enhance: - Making it more clear when you’re going to hit the database (explicit is better than implicit). - True async up and down the stack. Not a small task within the Python ecosystem, but I think for folks who are not already invested, looking at Elixir/OTP/Phoenix is too tempting. If you don’t have kids to transport with you, a Lambo looks much more fun than an S-Class Sedan.
- WD-42 5y ago
  > - True async up and down the stack. Not a small task within the Python ecosystem, but I think for folks who are not already invested, looking at Elixir/OTP/Phoenix is too tempting. If you don’t have kids to transport with you, a Lambo looks much more fun than an S-Class Sedan. This has been in the works for a few years. Everything in Django works with async except the ORM at this point. Which in practice, means it's not really async. But hopefully they are getting close.
  - privacyonsec 5y ago
    I'm working on bringing async to Django orm: https://github.com/rednaks/django-async-orm https://github.com/rednaks/django-async-orm
- number6 5y ago
  > Making it more clear when you’re going to hit the database (explicit is better than implicit). You might like https://github.com/dabapps/django-zen-queries https://github.com/dabapps/django-zen-queries Gives you fine grain control about database queries
strzibny 5y ago
Congrats the team on the release. Now I have to go and check what to update for Deployment from Scratch :D
peterth3 5y ago
Congrats to the Django team! Adding support for a Redis cache instead of only memcached is awesome.
kolanos 5y ago
Feels more like a Django 3.3 release than a 4.0 -- was expecting Django 4.0 to deliver the promised ORM async support.
- mypresences 5y ago
  Agree, doesn't deserve the 4.0 tag. I was hoping for some progress on async ORM as well. Is there any word on when this is coming?
- wartijn_ 5y ago
  Django releases time based and a version 3.3. was part of the plan. 4.0 is released right now because it is December 2021. The versions after that will be 4.1, 4.2, 5.0, 5.1 etc. [0] It's different from how many other projects work but not unique, Ubuntu works in a similar way for example. And although it might be different form what you're used to, I really like it. If you check their documentation, you can see exactly when they'll make breaking changes and features will be deprecated and removed. [0] https://www.djangoproject.com/download/ https://www.djangoproject.com/download/
_xnmw 5y ago
Anyone have deep experience with both Django and Laravel and can offer a comparison of the two?
- midrus 5y ago
  I have a lots of experience with Django, and a few months experience with Laravel. I think Django is good at pure backend solutions. When you're not doing the frontend in Django itself but instead doing a separate SPA. Also the admin is a great tool as an internal CMS. Django rest framework is awesome too. Laravel is a real "full stack" framework, it has a very powerful templating system (one of the best I've seen!) where you can do components instead of just includes. It has a powerful assets bundling pipeline, great integration with alpine, Vue, inertia and the super awesome livewire. Laravel documentation is TOP. As I'm not a fan of the SPA approach and still like frontend and building applications, I much prefer Laravel nowadays.
Dowwie 5y ago
Is there a possibility of the cache stampede / dogpile problem?
alanwreath 5y ago
Django for me has been a solid API gateway. That said I would appreciate an API-centric iteration of it. Something like how Laravel has Lumen. Even if they would make Django ORM available as a separate library it would make me glad. I can’t say I’m overly enamored by the red wave that has passed over python. The only things I really like it for (so far) are when I wish to make concurrent http calls. For whatever reason, I don’t enjoy it as much when I’m trying to serve multiple requests. I prefer keeping requests read only or at most job launching.
theomega 5y ago
Great news! Just for reference: The latest release for Django Rest Framework is not compatible with Django 4.0 yet. At least my first attempts failed due to a missing `pytz` dependency. This is fixed in the `master` of DRF on Github. Installing `pytz` explicitly again to your project fixes DRF for now.
- mch82 5y ago
  The transitional USE_DEPRECATED_PYTZ setting might help. Saw this in the extended release notes: https://docs.djangoproject.com/en/4.0/releases/4.0/#zoneinfo-default-timezone-implementation https://docs.djangoproject.com/en/4.0/releases/4.0/#zoneinfo... > The Python standard library’s zoneinfo is now the default timezone implementation in Django. > This is the next step in the migration from using pytz to using zoneinfo. Django 3.2 allowed the use of non-pytz time zones. Django 4.0 makes zoneinfo the default implementation. Support for pytz is now deprecated and will be removed in Django 5.0. > … > To give time for such an audit, the transitional USE_DEPRECATED_PYTZ setting allows continued use of pytz during the 4.x release cycle. This setting will be removed in Django 5.0.
Majestic121 5y ago
We went all in on FastAPI with my team, but we're hit the issue that the projects of Tiangolo (FastAPI, SQLModel, Typer) seem to be turning pretty much unmaintained : https://github.com/tiangolo/fastapi/discussions/3970 https://github.com/tiangolo/fastapi/discussions/3970 We've already been hit by multiple bugs with fixing PR opened, but left to rot, and missing documentation : the 'tutorial' documentation is great, but if you want a reference you have to go read the code. I guess that's the issue when you pick projects maintained by one person, so for my next projects I might get back to something built on stronger grounds, like Django. How is Django this day with modern Python constructs like typing in general and Pydantic models integration ?
- holler 5y ago
  Have you considered moving to Starlette a la carte? I use marshmallow for schemas and a few other minimal deps and it's been a breeze.
- tiangolo 5y ago
  Hey! FastAPI author here. I do have a bunch of issues and PRs to review across the projects. But as I personally review and in most cases fine-tune and update each one of the PRs (if you check the history, almost no PR is directly merged, most of them require updates) it's taking me a bit to handle them all, but I'm on it. I even changed my working structure to optimize for more open source. Sadly, new issues and new discussions like that one linked asking why the other issues are not solved, don't really help, as they just add another issue for me to read and take care of. I'm also prioritizing the work that can have the most impact. For example recently I was helping a bit with AnyIO and Trio, as they are used underneath by FastAPI. And now I'm working on something for Pydantic, that would be used by SQLModel and FastAPI. If you want to see faster progress, there are several ways to help, they are all documented here: https://fastapi.tiangolo.com/help-fastapi/ https://fastapi.tiangolo.com/help-fastapi/ One of the things that consumes time the most is handling issues by others. If you go and help them and they close those issues, that's a lot of minutes (in some cases hours) that you save me, and that I can then dedicate to review the other issues and PRs.
  - 5y ago
nickjj 5y ago
If anyone is interested I updated my example Docker Django app to use Django 4.0 at: https://github.com/nickjj/docker-django-example https://github.com/nickjj/docker-django-example It pulls together Django, Docker Compose, Postgres, Redis, Celery, Webpack and TailwindCSS. It's all set up for both development and production. It's also been updated to use Django 4's new built in Redis cache back-end instead of the django-redis package.
- slig 5y ago
  Thank you very much! I've been running my own clobbed together version of a Django + Webpack configuration, and I'm very interested in learning from your code how you manage to run only one container with both Django and Webpack on dev mode.
  - nickjj 5y ago
    No problem. I have things split out where the Webpack dev server runs in its own container only in development. It uses the Docker Compose override pattern to skip it in production along with Docker's multi-stage builds to ensure production assets get built and digested with collectstatic when DEBUG is set to false. I gave a talk this year at DockerCon on a whole bunch of patterns I use with Docker Compose and my Dockerfile to get dev / prod parity without duplication and overall best practices. The video and blog post of that is at: https://nickjanetakis.com/blog/best-practices-around-production-ready-web-apps-with-docker-compose https://nickjanetakis.com/blog/best-practices-around-product... It walks through a live demo (0 slides) going over a Flask example app but it's 100% the same for Django.
    - slig 5y ago
      Fantastic, thank you so much!
unixhero 5y ago
Where are we on the whole Django versus Rails debate? (Not cannonfodder, I am genuinely curious)
- tomduncalf 5y ago
  I recently built a fairly simple backend with a GraphQL API (fairly basic but bespoke e-commerce functionality, a few related models and a few queries/mutations) using Django, and then rewrote it in Rails, as a newcomer to them both (I knew bits of both languages but nothing really of the frameworks). The reason I switched is more or less entirely that I hit performance issues with the Python Graphene library being really slow at returning larger datasets, and couldn't find a solution in a reasonable time frame. My impression was that Django has a much more powerful and pleasant ORM – your migrations are derived from your models, so if you want to add or remove a field (for example), you update the model class then the migration command works out what it needs to do to make the database match the models. Rails works pretty much the other way – you create explicit migrations to add/remove columns, and the database is the source of truth - your model classes don't even have explicit accessors in the code for the fields you define in the DB. I found the Django way more logical, and I found things like many-to-many relationships much easier in Django, but the Rails way isn't too bad once you get used to it. Rails is well known for being heavy on the "magic", which is quite expressive once you get used to it but I find it hard to know where to look if I want to e.g. know what methods a model has, whereas Django felt a bit more explicit in this regard. Personally, I find Python a more pleasant and easier to read language than Ruby, which has so many ways to express the same concept in different ways, but I am actually warming to Ruby. If you're interested in adding type checking, it seemed that Python has better and more mature options here. Ultimately though, for what I wanted (which was to build a backend with sensible defaults out of the box and really write as little code as possible), I think Rails is a better fit. The ecosystem of libraries seems more mature and better documented (I hit quite a few issues with Django related libraries which took a lot of Googling and some hacks to solve). The Ruby GraphQL library is much nicer to work with and much more performant. The amount of code I have to write is generally pleasingly low (though I'll admit it's quite spaghettish already, I have been learning Ruby as I go and I can totally see how a large codebase could become a mess), and it's easy to Google for most stuff, and the defaults seem pretty sane. I will say on a slight tangent that I recently enabled GitHub Copilot, and am finding it surprisingly quite useful in a Ruby project, where I often struggle to know/remember the right syntax! So... that's my experience. Ultimately it came down to a niche-ish requirement (performant GraphQL API) to force my hand, but I think I'm pleased with the end result. Both are impressive frameworks and I don't think generally you could go too far wrong, but for me Rails just feels that bit easier and more mature for bashing out a solo project.
b-lee 5y ago
Great to see they have managed to reach their funding target. Donated anyway!
the__alchemist 5y ago
Django is the nicest framework I've come across! For some context, my favorite overall programming language is Rust. Despite Rust having several web frameworks, I use Python the server due to Django being so nice. In Python, there are micro frameworks like Flask, and whatever new ones claim to be "Blazingly fast!", async etc. Once you get over the learning curve, Django seems the nicest to use, due to including features like an auto-updating ORM, email, authentication, admin page etc. None of the Rust frameworks, in contrast, come close to feature parity. Django's feature base is vast, and I admit I don't understand much of it. You can choose the feature sets you need. The template language is inflexible, but you can smooth this over using JS instead A/R.
- ehutch79 5y ago
  You can also replace the template system with something else like jinja2.
- deleted 5y ago
  [deleted]
marcus_cemes 5y ago
Does anyone know how Python/Django compares to something like Elixir/Phoenix?
- Daishiman 5y ago
  Django has more features, a _much_ larger ecosystem, excellent documentation. Elixir is dramatically more performant and will scale better. A lot of people enjoy Elixir more or find it conceptually more interesting than Python. IMO the number of packages and facilities provided by Django will outweigh Phoenix's performance for 95% of users.
- dyeje 5y ago
  Django, Rails, Phoenix, Laravel, etc are all pretty similar at a high level.
- princevegeta89 5y ago
  Phoenix is on a much better performance level compared to the other two.
- aej 5y ago
  Phoenix has a much smaller footprint than Django. I would put Phoenix closer to Flask in terms of how much work the framework does for you. Phoenix has lots of generators which make hooking into the database layer very easy and bootstrapping new endpoints is also fast in Phoenix. Django makes more decisions for you (authentication, permissions, admin, the ORM to name a few). In the Phoenix ecosystem you bring each of those pieces in as you please (auth generator, Ecto + other libraries etc). So I would say if your really want to move fast, you will still get further, faster with Django - but the trade-off (as other posts here have alluded to) is that once you need to implement custom features or optimisations you will often fight against Django (or need to wade-through half a dozen classes in some inheritance tree to find the right hook). Another big difference between Phoenix and Django is that building websocket services in Phoenix is an absolute breeze. The Elixir runtime maps perfectly onto any type of messaging service.
robomartin 5y ago
Love Django, yet the transition from local development to deployment, in my opinion, continues to be just plain ugly and painful. I've written about this before. I think the stock Django dev configuration needs to change to something that is equivalent to a reasonable deployment on a common VPS, whatever that means. The development server is a nice trick, but the things you have to do to move to a real server are painful. Same with SQLite. Why not come up running PostgreSQL by default? I am sure there are varied opinions on this. All I have to say is that, over the years, I developed a document to help with deployment on standard hosting platforms, like Linode. It is staggering when compared to the experience of deploying something like a Wordpress/PHP site on the same or similar platform. This, from my perspective, is the weakness for Django, everything else I love and enjoy.
- strzibny 5y ago
  What do you find hard in particular? systemd service + gunicorn is not that bad, I think. You can have simple deployment and graceful restarts[0]. [0] https://nts.strzibny.name/gunicorn-graceful-restarts/ https://nts.strzibny.name/gunicorn-graceful-restarts/
  - reducesuffering 5y ago
    There is a huge doc[0] for a standard "deploy decent prod setup to VPS." What happens after you make some changes, something goes wrong with the server, and you have to go through all these steps again, only that it gets you to Day 1, not Day 90? It leaves a lot to be desired for quick, reproducible deploys. Ime, adding a docker-compose and a couple Dokku commands on the server is the best experience I've seen so far. [0]https://www.digitalocean.com/community/tutorials/how-to-set-up-django-with-postgres-nginx-and-gunicorn-on-ubuntu-20-04 https://www.digitalocean.com/community/tutorials/how-to-set-...
  - robomartin 5y ago
    Not sure that your link is an answer to my comment. Whatever the case may be, I can take a single VPS and multi-host a bunch of domains, each with it's own Wordpress installation, DB, etc. Virtual hosts makes this possible. It's stupid simple. Getting a single Django application running under a single domain on a VPS is a nightmare. Particularly when you consider everything you have to do to migrate from the development environment to production. This is why we do not do any Django development using the standard installation and go right wo running it just like production on either virtual machines or a dedicated on-premises Linux server. The development environment is as close to an exact match as the production environment. No SQLite, no runserver, no nonsense with static files, etc. This is what I think the Django project needs to really think about working on. There is no reason to have a crippled development environment at all. The base installation ought to be setup to migrate to a standard Linux host (not something purpose-built like Heroku) without much friction. If you are doing a more complex site with multiple servers, load balancing, etc., you are on your own. I truly think adoption would be far greater if the deployment experience was sensible. I have talked to people who absolutely gave up on Django because going from development to production was a nightmare without spending money on far more expensive servers and services they should. This is an application (Django) that should easily run on any Linux server. The fact that companies were created to facilitate deployment says it all.
buro9 5y ago
Maybe this will be the moment I upgrade. Let's see what version I'm running: Django 1.5.9 This is going to be very painful isn't it. I wonder how long until the bitrot makes it unbuildable and undeployable. I should clarify, there is no database attached to this and it talks to a secure API that is maintained really well. So this is just views and templates, where the views talk to the API.
sam_goody 5y ago
OT, but considering the audience... I have a side project / website that I want to work on. I have over a decade experience with PHP and JS in various forms, but am willing to try something new. The idea of compiled languages don't appeal to me, so am not really interested in Go, Rust or Dart. It looks like either Django, Elixir, or PHP - but am open to other ideas. Anyone with enough experience to tell me confidently that it is worth Django or Elixir? Anyone can give a five line overview of the differences vs PHP or Node? And along the way, am I the only one who is confused by what seems too many environments and package managers? (from venv/virtualenv[1] to pip/easy_install to wheels/eggs) [1]: https://stackoverflow.com/q/41573587/87520 https://stackoverflow.com/q/41573587/87520
- jph 5y ago
  IMHO, Elixir & Phoenix are such a breath of fresh air, plus power, plus adaptability, and I love the functional capabilties. On the other hand, if your want lots of numeric computation tooling, AI/ML, stats, etc. then Python & Django have better/more math-adjancent integrations.
- midrus 5y ago
  Django: Great if you are building only a backend or rest API with a separate frontend (an SPA in React, etc). The templates system is terrible, has no asset pipeline built in and frontend on it feels like developing in the 90s. You'll miss php a lot here. Elixir: Technologically "mind blowing", although all the nice things come from the Erlang VM and not from Elixir itself in my opinion. You will likely not find any job using Elixir, if you do it is going to be full of people just learning the language so the codebase will be very likely a disaster. You will miss a lot of libraries and you will have to write code for things you'd take for given in the PHP ecosystem. Be ready to fight your editor plugins (depending on which one you use, and the degree of IDEisms you're used to). I understand you want to learn something new, so the most "radical" one here that will teach you more new things is clearly Elixir. But other than learning purposes, If I were to build something for real, I'd stick with PHP and Laravel, it's an incredible productive, well documented and well thought out platform to develop in.
- 8589934591 5y ago

473 points by Spiritus 5y ago

Thanks a lot..

I must learn Django, it's got everything I'll ever need. No, Rails will make me happy and it's better for lonely devs like me. No I must learn a Modern Web Framework (TM) to prove I'm not stuck in the past. No way, I'm not a fashionista. Have you seen that Phoenix demo where the guy builds Twitter in like 4 minutes? That's the future. Hold on a minute, enough of this magic. I need to learn to build everything in Common Lisp and own my code 100%! Wait I don't actually have the time for that. Django is the way, it's so solid, just that it won't bring me joy....

melling 5y ago
Yep, web solutions change too fast, with lots of legacy, and every solution is a compromise.
agumonkey 5y ago
paradogm of choice
hellbannedguy 5y ago
Yea--I don't want to waste my life learning frameworks either. The less time googling a new framework, the better. Now learning Lisp is something else.
myth_drannon 5y ago
That's me. Once a year I get burned out from all the new languages and frameworks and decide to learn Common Lisp again for the 10the time.
- exdsq 5y ago
  Hahahaha you've just described my life too
  - chespinoza 5y ago
    Same here :/
mathnmusic 5y ago
You can experience all of this while staying in a single language ecosystem. Just recently, I had to build something in Javascript and got to know Express is no longer recommended. Fastify, Remix are the latest hotness. :)
- aneutron 5y ago
  I genuienly have not heard about either one of the three. I guess I remain stuck in PHP, Phalcon Framework, Symfony and Django / Flask.
  - jimnotgym 5y ago
    I was checking out Express...how do I get user logins, oh just npm in 50 other projects, adding 50000 dependencies. Back to Django then!
    - shafyy 5y ago
      Haha, that's exactly what I'm dealing with right now on the project I'm working. Add on top of that Firebase Cloud Functions. I really miss Rails.
    - abdusco 5y ago
      The difference between Django and Express.js is that one is a fully-fledged web application framework, while the other is a micro framework that just gives you a simple request -> response abstraction over `http.createServer`. I find Flask is more comparable to Express.js in that regard. Need auth? You need to: 1. Install a lib for persistence 2. Set up cookie sessions, or install another lib for JWT 3. Set up auth middleware 4. Prepare login/register/forgot pass views and flows which are almost the same steps you need to take in Express.js.
      - jimnotgym 5y ago
        I guess my surprise came from asking around about what framework to use and being told it was Express. I guess it might be 'Sails', but it's been a week or two so that is probably obsolete now.
Waterluvian 5y ago
There are just so many makes and models of automobile and people get by. I remain so confused why choice paralysis is a thing in software. Maybe the libraries need to cost 30,000$ ;-)
- whatch 5y ago
  Sometimes they cost you much more, if you chose the wrong one
- Kototama 5y ago
  That would for sure push our community to better describe the runtime of the different solutions. We talked only about syntax, features, semantic but very little about the runtime characteristics of the different platforms (Java, .Net, BEAM, different Common Lisps implementation etc). Maybe it's a sign of abundance and that most of these solutions are ok in most of the cases.
- solididiot 5y ago
  Imagine each car model having different controls, different engine and components placement, some coming with rectangular wheels. That image is closer to SW frameworks.
- BeFlatXIII 5y ago
  Different cars are much more obviously different than different web frameworks. When car shopping, you know whether you're looking for a RAM3500, an Odyssey, or a Mustang. Sure, the F-150 may win out in the end, but the Caravan and Charger were never contenders when looking for a truck. Choosing between software (especially bikeshedding between languages that both place priority on being pleasant to write) is often like comparing a Tacoma to a Tesla on the quality of seat heaters, upgrade price for the sunroof, and selection of factory paint options. Worse, you can't often have a clear understanding of the difference without investing the time to gain direct experience with each option. Otherwise, you're relying on community reputation and hoping it's both accurate and not horribly out of date.
Zababa 5y ago
There's also the part where you dig around to see what people use and recommand, and most of the answers are "use what you already know", which doesn't help when you don't know anything in detail. I feel like at this point the best strategy would be to list all the viables alternatives, pick one, and forbid yourself from using anything else for the next X months, but when thinking about that I have a huge fear of missing out.
solididiot 5y ago
It's actually a bit worse (or better) depending on how you see it. You get to invest (time, energy) in what will land you a job. 99% it's not what you want/like and not what is technically best. IT's just what came to dominate your job market. At least if you're in a EU backwater country or in EU public sector-related projects. (Which usually means java/c# and to a much lesser extend a python tech stack). PS: Loved the rant but you forgot to mention Golang :). "You're doing web backend and not using Go?!!"
- Nextgrid 5y ago
  This really depends whether you see IT as a job or as a tool to achieve your own projects. If the latter, then you don't particularly care how "hype" your tech stack is as long as it successfully solves your own problems.
deleted 5y ago
[deleted]
ac130kz 5y ago
Nah, Django makes you sad: async support is not full, migrations engine is pretty poor, not all database features are present, any kind of typing is hacky, very slow and so on
- geewee 5y ago
  What other migration engine have you used that's better? Anything non-django I've used makes me wish I was using Django
  - fb03 5y ago
    "alembic" is better by leaps and bounds. it is used within a SQLAlchemy system, which is also a superior ORM than Django's.
    - louissan 5y ago
      question of taste...
      - robertlagrant 5y ago
        Less taste and more that data mapper ORMs are better (although harder to make) than active record ones, except for very small datasets/simple queries.
        andybak 5y ago
        "Better" for whom? It was a long time ago that I surveyed the ORM landscape but I remember thinking at the time I was much happier using an active record style ORM. I guess I'm saying I'm always suspicious when I see "better" with no qualification. Everything has tradeoffs.
        handrous 5y ago
        I, for one, find data mapper simply baffling. I look at it and can't even comprehend why someone might want to do things that way. Granted, I'm not fond of ORMs in general, but I at least understand the appeal of the active record pattern.

WayToDoor 5y ago

While it doesn't seem like a major update at first glance on this news piece, the changelog is available here : https://docs.djangoproject.com/en/4.0/releases/4.0/ https://docs.djangoproject.com/en/4.0/releases/4.0/ Of note, in my opinion : - The new AddConstraintNotValid operation allows creating check constraints on PostgreSQL without verifying that all existing rows satisfy the new constraint, meaning that one can now create constraints on big postgres tables without a waiting period. - Async methods are coming, to cache for now but hopefully soon to the ORM. They are prefixed with a `a` in the name - DeleteView now uses FormMixin, allowing you to provide a Form subclass, with a checkbox for example, to confirm deletion. In addition, this allows DeleteView to function with django.contrib.messages.views.SuccessMessageMixin. This is a big thing if you use DeleteViews, as you can now easily show a message post-deletion to the user.

fleetfox 5y ago
Do you know if the ORM solution have the same `a` suffix for async interface? I really hope there is more elegant solution for all this.
- cdrx 5y ago
  ORM will use the same `a` suffix, yes.
- deckiedan 5y ago
  Yes - it's kinda ugly at the moment, having all the `a` prefixed functions - but I think it's intended as a kind of long-term-intermediate step - since the whole of django isn't async at the moment, and needs to have separate versions for everything. I (wildly) speculate that once the ORM is async too, and all the rest of the bits fall into place (maybe django 5?), maybe django 6 will drop the `a` prefixes and integrate it all back together somehow?
  - samwillis 5y ago
    I believe they chose the 'a...' pattern as it matches other apis in the standard library - it also makes it explicit but concise. I can't see it being dropped any time the future, Django will always have a sync api, that won't be dropped. And there is no way in (current) python to combine a sync and async api into a single method.

ilovefood 5y ago

Congratulations on the release!! I'm looking forward to give it a go and see what's new for myself.

avinassh 5y ago

I recently upgraded [0] one of my project [1] to Django v4, from Django v1. The changes from Django 3 to 4 were fairly simple, just one line change in my case. The change log is extremely detailed, it was easy to upgrade. Also, I found a tool called django-upgrade [2] which makes some changes automatically, rest I made manually. [0] - https://avi.im/blag/2021/rc-day-20/ https://avi.im/blag/2021/rc-day-20/ [1] - https://github.com/avinassh/della https://github.com/avinassh/della [2] - https://github.com/adamchainz/django-upgrade https://github.com/adamchainz/django-upgrade

fernandotakai 5y ago
that's super nice to know -- i need to upgrade a django app from 1.11 to 4 over the next couple of weeks!
- spapas82 5y ago
  If the 1.11 project is in python 3 then it would be a piece of cake. If it's in python 2 then it will need a little more effort to convert to python 3 but but not much really. Django have hasn't changed that much since 1.11!

clement_b 5y ago

I enjoy coding with Django. It's the framework that helped me make a smooth move from PHP/Symfony to Python-powered web apps. Not that I dislike PHP... just wanted to focus more on Python. Many thanks to everyone involved in the project!

alberth 5y ago

Off topic: I wish NIM had a Django-like web framework.

_tardigrade 5y ago

nowadays most people use Django to create REST API. I wish Django would merge DRF into its codebase.

mrweasel 5y ago
> nowadays most people use Django to create REST API I doubt that's true, but yes, having DRF merged in would be rather nice.
- PhoenixReborn 5y ago
  There are quite a lot of apps that do a JS frontend and Django backend these days, I myself have done quite a few.
  - mrweasel 5y ago
    Absolutely, I just question the premise that “most” Django applications are like that. My best guess, and I have nothing but my own experience to back this up, is that for every public facing Django based website, there are at least three used internally and at least one of those use nothing but the build in admin interface as a UI.
dralley 5y ago
At this point I disagree - DRF is a verbose and somewhat dated architecture. I wish they would provide something like Django Ninja / FastAPI. Plus it already has decent async support. https://github.com/vitalik/django-ninja https://github.com/vitalik/django-ninja

rlawson 5y ago

Django has allowed me to enjoy some side entrepreneurship. I have released three products as a solo part time dev that I would never have been able to do in a reasonable time using Java/Spring (my strongest stack). My first project went nowhere, but the second generated 1k+ a month and sold for 50k, and the third one is following a similar trajectory. My advice - keep it simple - function based views - centralize access to the ORM (avoid fat models, use a service layer) - responsive bootstrap template with crispy forms - minimal js - 12 factor type setup - django-environ or similar - be aware of n+1 select problem (I use django debug toolbar but looking into django-zen-queries) - plop it on heroku, AWS lightsail, Digital Ocean or if containerizing use AWS Fargate - avoid celery unless you are at a scale you need it - use django-cron, django-db-queue or similar - use a managed database and managed email service I have had zero scalability problems. People say Django is slow but it handled 10k active users on a small EC2 instance without any issues (static stuff served via cloudfront)

hda111 5y ago
+1 for trying to avoid celery. Too much complexity for simple asynchronous tasks. You should use it however if you are instagram (I think they use a customized Django and Celery).
Alex3917 5y ago
> function based views Class-based views, in their most basic form, are a lot easier to read. E.g. look at the DRF CBVs I have here: https://github.com/Alex3917/django_for_startups/blob/main/django_for_startups/app/views/account_management_views.py https://github.com/Alex3917/django_for_startups/blob/main/dj... If you can avoid Generic CBVs (things like ListView) and inheritance, then the only difference between FBVs and CBVs is that CBVs make it easier to see what's a GET / PUT / POST / DELETE by adding some syntax highlighting that makes it easier to visually differentiate which code goes to which method. You don't need to know anything about classes in Python in order to use them. It's not at all difficult to switch from FBVs to CBVs later, and most people (myself included) use FBVs when getting started. But I'd also say that if you're willing to push through the initial discomfort and spend the extra half hour or whatever on YouTube in order to understand them, then you do get a little bit of a nicer overall development experience.

pantulis 5y ago

Before Django there was Zope in python-land. I don't think I overstate the relevance of what Django did by saying that Django almost single handledy advanced the state-of-the-art of web deployment in Python forward a decade.

stdbrouw 5y ago
Zope hails from the era when Python was trying to appeal to programmers by showing that it, too, could be a Serious Enterprise Language. Everything had layer after layer of abstraction and the code looked more like Java than Python. The Zope ORM was kind of nice in its own weird way, though.
- VectorLock 5y ago
  Zope had some things like the Language Is The Database trope that sort of remind of the things described in those Bank Python blog posts that have been floating around recently.

raihansaputra 5y ago

I've always followed Django as Python is my first language and still my 'natural' way to think about code. The more I look into it, the more I feel like the learning curve is a bit like a camel's back. Easy for some stuff. Hard to figure the middle part (usually because not understanding "how" Django really works). And easy at the ends after knowing how you can "mould" Django in certain ways. It feels like a great multitool for the professionals who need to create project after project. I believe the middle part of the learning curve can be easier, but with the "social cruft" of all the Django tutorials out there, it's a game of luck to encounter what's good and what are the different, sensible, approaches to handling growing/big Django apps. What can make this easier is a document/discussion of some sort that provides clear, complete, approaches. Here are some aspect that needs to be considered. I believe with the combinations defined, and describing the tradeoffs will be a very great start for any team/person looking to jump into Django, or improve their next project. - Postgres seems to be default. SQLite + Litestream is there but still bleeding edge. - Packaging is the hot topic, for sure. Pipenv, poetry, venv, etc? - Traditional Serverside Templating + JS enhancement (HTMX/Hotwire/etc), or JS based SPA (React, Vue, Angular, Svelte, etc) -- This also includes the asset compiling story (Tailwind JIT, Sass compilation, Babel/webpack/rollup/etc) - Fat models, Fat views, or Service layer? To which extent? - Single app (Doordash) or Multiple apps (Thread with >500 apps)? - What's the theoritical limit to using Postgres + Disk/Memory Caching (so no external Redis/ElasticSearch/other services needed)? -- Search, queues/async job, scheduled jobs, reports, emails, etc EDIT: A view additional points - Documented limits about using whitenoise to serve static assets, and when & how to move to S3. Also Cloudflare/CDN fronting - Cloud storage story (uploading to S3 api from FileField and Rich Text fields, and also async jobs) -- Proxy story to enable <a download> from cloud? (Maybe a bit far, but I think this is a common request) - Deploying/Serving optimization (is gunicorn the best option for now? how to scale w/ regard to vCPU counts to avoid the 25% CPU Max utilization?) - How to debug between inefficient query/app code/templating/serving/caching? I'm sure there are more points, but it would be great if there's a documented sensible approaches to evaluate. I know there are templates, but great discussions about the tradeoffs of complete "packages" are rare.

polote 5y ago

14 days ago https://news.ycombinator.com/item?id=29303611 https://news.ycombinator.com/item?id=29303611 76 days ago https://news.ycombinator.com/item?id=28609188 https://news.ycombinator.com/item?id=28609188 3 month ago https://news.ycombinator.com/item?id=28566044 https://news.ycombinator.com/item?id=28566044

midrus 5y ago

I've used Django for a long, long time (since 0.96). Django is great for backend stuff, but nowadays for full stack applications (if you're not doing an SPA) I find Laravel and Rails a lot better. In particular Laravel's templates (blade) and asset handling is awesome.

dukeofdoom 5y ago

I still have a project that runs on Django 1.6. Can't imagine trying to migrate now, when it relies on so many old packages. Would probably be better of starting from scratch.

selcuka 5y ago
I would start by replacing the dependencies that are not maintained anymore (i.e. that don't support a relatively recent Python 3.x) with more modern alternatives one by one instead of rewriting it. The migration of the Django application itself should not be that hard.
slig 5y ago
I had a project running on 1.3 until very recently. The was a lot of issues with the TZ datetime fields, migrations, Python2, etc. It was a lot easier to start a new project from scratch.

appliku 5y ago

Thank you Django. that’s a great news. 14 years ago someone helped me discover Python and Django. I started from django official tutorial and never changed the framework of choice. It was my hobby, my career, my tool to put the food on the table. 12 years later I have started building a way to solve deployment question. started from bunch of scritps. today I have made cost effective tool to deploy Django projects and pretty much any python app on AWS/Digital Ocean https://appliku.com/ https://appliku.com/ it is like heroku but uses you own cloud account and not expensive at all.

ralmidani 5y ago

Django made me fall in love with programming. I built 2 decent-sized side projects with Django. They didn’t gain traction, but I loved using the framework. Then I went through a couple of (depressing) years of using Java/Spring professionally, and recently I made the choice to move to Elixir/Phoenix. It’s going great, and I don’t think I would go back to heavy OOP if I didn’t have to. Some things I really miss from Django: - Models with more centralized validation logic. In Phoenix (and somewhat similarly in Rails), you need to edit your migration, schema, and changeset. In Django, you edit your model and the migration can usually be made automatically with no need for a 3rd-party package. - Django REST Framework. You can get pretty far with an app just by leveraging ModelSerializers and ModelViewsets. It’s ridiculously elegant, simple, and powerful. - The Admin layer is fantastic and unparalleled. Some things I wish Django would add/enhance: - Making it more clear when you’re going to hit the database (explicit is better than implicit). - True async up and down the stack. Not a small task within the Python ecosystem, but I think for folks who are not already invested, looking at Elixir/OTP/Phoenix is too tempting. If you don’t have kids to transport with you, a Lambo looks much more fun than an S-Class Sedan.

WD-42 5y ago
> - True async up and down the stack. Not a small task within the Python ecosystem, but I think for folks who are not already invested, looking at Elixir/OTP/Phoenix is too tempting. If you don’t have kids to transport with you, a Lambo looks much more fun than an S-Class Sedan. This has been in the works for a few years. Everything in Django works with async except the ORM at this point. Which in practice, means it's not really async. But hopefully they are getting close.
- privacyonsec 5y ago
  I'm working on bringing async to Django orm: https://github.com/rednaks/django-async-orm https://github.com/rednaks/django-async-orm
number6 5y ago
> Making it more clear when you’re going to hit the database (explicit is better than implicit). You might like https://github.com/dabapps/django-zen-queries https://github.com/dabapps/django-zen-queries Gives you fine grain control about database queries

strzibny 5y ago

Congrats the team on the release. Now I have to go and check what to update for Deployment from Scratch :D

peterth3 5y ago

Congrats to the Django team! Adding support for a Redis cache instead of only memcached is awesome.

kolanos 5y ago

Feels more like a Django 3.3 release than a 4.0 -- was expecting Django 4.0 to deliver the promised ORM async support.

mypresences 5y ago
Agree, doesn't deserve the 4.0 tag. I was hoping for some progress on async ORM as well. Is there any word on when this is coming?
wartijn_ 5y ago
Django releases time based and a version 3.3. was part of the plan. 4.0 is released right now because it is December 2021. The versions after that will be 4.1, 4.2, 5.0, 5.1 etc. [0] It's different from how many other projects work but not unique, Ubuntu works in a similar way for example. And although it might be different form what you're used to, I really like it. If you check their documentation, you can see exactly when they'll make breaking changes and features will be deprecated and removed. [0] https://www.djangoproject.com/download/ https://www.djangoproject.com/download/

_xnmw 5y ago

Anyone have deep experience with both Django and Laravel and can offer a comparison of the two?

midrus 5y ago
I have a lots of experience with Django, and a few months experience with Laravel. I think Django is good at pure backend solutions. When you're not doing the frontend in Django itself but instead doing a separate SPA. Also the admin is a great tool as an internal CMS. Django rest framework is awesome too. Laravel is a real "full stack" framework, it has a very powerful templating system (one of the best I've seen!) where you can do components instead of just includes. It has a powerful assets bundling pipeline, great integration with alpine, Vue, inertia and the super awesome livewire. Laravel documentation is TOP. As I'm not a fan of the SPA approach and still like frontend and building applications, I much prefer Laravel nowadays.

Dowwie 5y ago

Is there a possibility of the cache stampede / dogpile problem?

alanwreath 5y ago

Django for me has been a solid API gateway. That said I would appreciate an API-centric iteration of it. Something like how Laravel has Lumen. Even if they would make Django ORM available as a separate library it would make me glad. I can’t say I’m overly enamored by the red wave that has passed over python. The only things I really like it for (so far) are when I wish to make concurrent http calls. For whatever reason, I don’t enjoy it as much when I’m trying to serve multiple requests. I prefer keeping requests read only or at most job launching.

theomega 5y ago

Great news! Just for reference: The latest release for Django Rest Framework is not compatible with Django 4.0 yet. At least my first attempts failed due to a missing `pytz` dependency. This is fixed in the `master` of DRF on Github. Installing `pytz` explicitly again to your project fixes DRF for now.

mch82 5y ago
The transitional USE_DEPRECATED_PYTZ setting might help. Saw this in the extended release notes: https://docs.djangoproject.com/en/4.0/releases/4.0/#zoneinfo-default-timezone-implementation https://docs.djangoproject.com/en/4.0/releases/4.0/#zoneinfo... > The Python standard library’s zoneinfo is now the default timezone implementation in Django. > This is the next step in the migration from using pytz to using zoneinfo. Django 3.2 allowed the use of non-pytz time zones. Django 4.0 makes zoneinfo the default implementation. Support for pytz is now deprecated and will be removed in Django 5.0. > … > To give time for such an audit, the transitional USE_DEPRECATED_PYTZ setting allows continued use of pytz during the 4.x release cycle. This setting will be removed in Django 5.0.

Majestic121 5y ago

We went all in on FastAPI with my team, but we're hit the issue that the projects of Tiangolo (FastAPI, SQLModel, Typer) seem to be turning pretty much unmaintained : https://github.com/tiangolo/fastapi/discussions/3970 https://github.com/tiangolo/fastapi/discussions/3970 We've already been hit by multiple bugs with fixing PR opened, but left to rot, and missing documentation : the 'tutorial' documentation is great, but if you want a reference you have to go read the code. I guess that's the issue when you pick projects maintained by one person, so for my next projects I might get back to something built on stronger grounds, like Django. How is Django this day with modern Python constructs like typing in general and Pydantic models integration ?

holler 5y ago
Have you considered moving to Starlette a la carte? I use marshmallow for schemas and a few other minimal deps and it's been a breeze.
tiangolo 5y ago
Hey! FastAPI author here. I do have a bunch of issues and PRs to review across the projects. But as I personally review and in most cases fine-tune and update each one of the PRs (if you check the history, almost no PR is directly merged, most of them require updates) it's taking me a bit to handle them all, but I'm on it. I even changed my working structure to optimize for more open source. Sadly, new issues and new discussions like that one linked asking why the other issues are not solved, don't really help, as they just add another issue for me to read and take care of. I'm also prioritizing the work that can have the most impact. For example recently I was helping a bit with AnyIO and Trio, as they are used underneath by FastAPI. And now I'm working on something for Pydantic, that would be used by SQLModel and FastAPI. If you want to see faster progress, there are several ways to help, they are all documented here: https://fastapi.tiangolo.com/help-fastapi/ https://fastapi.tiangolo.com/help-fastapi/ One of the things that consumes time the most is handling issues by others. If you go and help them and they close those issues, that's a lot of minutes (in some cases hours) that you save me, and that I can then dedicate to review the other issues and PRs.
- 5y ago

nickjj 5y ago

If anyone is interested I updated my example Docker Django app to use Django 4.0 at: https://github.com/nickjj/docker-django-example https://github.com/nickjj/docker-django-example It pulls together Django, Docker Compose, Postgres, Redis, Celery, Webpack and TailwindCSS. It's all set up for both development and production. It's also been updated to use Django 4's new built in Redis cache back-end instead of the django-redis package.

slig 5y ago
Thank you very much! I've been running my own clobbed together version of a Django + Webpack configuration, and I'm very interested in learning from your code how you manage to run only one container with both Django and Webpack on dev mode.
- nickjj 5y ago
  No problem. I have things split out where the Webpack dev server runs in its own container only in development. It uses the Docker Compose override pattern to skip it in production along with Docker's multi-stage builds to ensure production assets get built and digested with collectstatic when DEBUG is set to false. I gave a talk this year at DockerCon on a whole bunch of patterns I use with Docker Compose and my Dockerfile to get dev / prod parity without duplication and overall best practices. The video and blog post of that is at: https://nickjanetakis.com/blog/best-practices-around-production-ready-web-apps-with-docker-compose https://nickjanetakis.com/blog/best-practices-around-product... It walks through a live demo (0 slides) going over a Flask example app but it's 100% the same for Django.
  - slig 5y ago
    Fantastic, thank you so much!

unixhero 5y ago

Where are we on the whole Django versus Rails debate? (Not cannonfodder, I am genuinely curious)

tomduncalf 5y ago
I recently built a fairly simple backend with a GraphQL API (fairly basic but bespoke e-commerce functionality, a few related models and a few queries/mutations) using Django, and then rewrote it in Rails, as a newcomer to them both (I knew bits of both languages but nothing really of the frameworks). The reason I switched is more or less entirely that I hit performance issues with the Python Graphene library being really slow at returning larger datasets, and couldn't find a solution in a reasonable time frame. My impression was that Django has a much more powerful and pleasant ORM – your migrations are derived from your models, so if you want to add or remove a field (for example), you update the model class then the migration command works out what it needs to do to make the database match the models. Rails works pretty much the other way – you create explicit migrations to add/remove columns, and the database is the source of truth - your model classes don't even have explicit accessors in the code for the fields you define in the DB. I found the Django way more logical, and I found things like many-to-many relationships much easier in Django, but the Rails way isn't too bad once you get used to it. Rails is well known for being heavy on the "magic", which is quite expressive once you get used to it but I find it hard to know where to look if I want to e.g. know what methods a model has, whereas Django felt a bit more explicit in this regard. Personally, I find Python a more pleasant and easier to read language than Ruby, which has so many ways to express the same concept in different ways, but I am actually warming to Ruby. If you're interested in adding type checking, it seemed that Python has better and more mature options here. Ultimately though, for what I wanted (which was to build a backend with sensible defaults out of the box and really write as little code as possible), I think Rails is a better fit. The ecosystem of libraries seems more mature and better documented (I hit quite a few issues with Django related libraries which took a lot of Googling and some hacks to solve). The Ruby GraphQL library is much nicer to work with and much more performant. The amount of code I have to write is generally pleasingly low (though I'll admit it's quite spaghettish already, I have been learning Ruby as I go and I can totally see how a large codebase could become a mess), and it's easy to Google for most stuff, and the defaults seem pretty sane. I will say on a slight tangent that I recently enabled GitHub Copilot, and am finding it surprisingly quite useful in a Ruby project, where I often struggle to know/remember the right syntax! So... that's my experience. Ultimately it came down to a niche-ish requirement (performant GraphQL API) to force my hand, but I think I'm pleased with the end result. Both are impressive frameworks and I don't think generally you could go too far wrong, but for me Rails just feels that bit easier and more mature for bashing out a solo project.

b-lee 5y ago

Great to see they have managed to reach their funding target. Donated anyway!

the__alchemist 5y ago

Django is the nicest framework I've come across! For some context, my favorite overall programming language is Rust. Despite Rust having several web frameworks, I use Python the server due to Django being so nice. In Python, there are micro frameworks like Flask, and whatever new ones claim to be "Blazingly fast!", async etc. Once you get over the learning curve, Django seems the nicest to use, due to including features like an auto-updating ORM, email, authentication, admin page etc. None of the Rust frameworks, in contrast, come close to feature parity. Django's feature base is vast, and I admit I don't understand much of it. You can choose the feature sets you need. The template language is inflexible, but you can smooth this over using JS instead A/R.

ehutch79 5y ago
You can also replace the template system with something else like jinja2.
deleted 5y ago
[deleted]

marcus_cemes 5y ago

Does anyone know how Python/Django compares to something like Elixir/Phoenix?

Daishiman 5y ago
Django has more features, a _much_ larger ecosystem, excellent documentation. Elixir is dramatically more performant and will scale better. A lot of people enjoy Elixir more or find it conceptually more interesting than Python. IMO the number of packages and facilities provided by Django will outweigh Phoenix's performance for 95% of users.
dyeje 5y ago
Django, Rails, Phoenix, Laravel, etc are all pretty similar at a high level.
princevegeta89 5y ago
Phoenix is on a much better performance level compared to the other two.
aej 5y ago
Phoenix has a much smaller footprint than Django. I would put Phoenix closer to Flask in terms of how much work the framework does for you. Phoenix has lots of generators which make hooking into the database layer very easy and bootstrapping new endpoints is also fast in Phoenix. Django makes more decisions for you (authentication, permissions, admin, the ORM to name a few). In the Phoenix ecosystem you bring each of those pieces in as you please (auth generator, Ecto + other libraries etc). So I would say if your really want to move fast, you will still get further, faster with Django - but the trade-off (as other posts here have alluded to) is that once you need to implement custom features or optimisations you will often fight against Django (or need to wade-through half a dozen classes in some inheritance tree to find the right hook). Another big difference between Phoenix and Django is that building websocket services in Phoenix is an absolute breeze. The Elixir runtime maps perfectly onto any type of messaging service.

robomartin 5y ago

Love Django, yet the transition from local development to deployment, in my opinion, continues to be just plain ugly and painful. I've written about this before. I think the stock Django dev configuration needs to change to something that is equivalent to a reasonable deployment on a common VPS, whatever that means. The development server is a nice trick, but the things you have to do to move to a real server are painful. Same with SQLite. Why not come up running PostgreSQL by default? I am sure there are varied opinions on this. All I have to say is that, over the years, I developed a document to help with deployment on standard hosting platforms, like Linode. It is staggering when compared to the experience of deploying something like a Wordpress/PHP site on the same or similar platform. This, from my perspective, is the weakness for Django, everything else I love and enjoy.

strzibny 5y ago
What do you find hard in particular? systemd service + gunicorn is not that bad, I think. You can have simple deployment and graceful restarts[0]. [0] https://nts.strzibny.name/gunicorn-graceful-restarts/ https://nts.strzibny.name/gunicorn-graceful-restarts/
- reducesuffering 5y ago
  There is a huge doc[0] for a standard "deploy decent prod setup to VPS." What happens after you make some changes, something goes wrong with the server, and you have to go through all these steps again, only that it gets you to Day 1, not Day 90? It leaves a lot to be desired for quick, reproducible deploys. Ime, adding a docker-compose and a couple Dokku commands on the server is the best experience I've seen so far. [0]https://www.digitalocean.com/community/tutorials/how-to-set-up-django-with-postgres-nginx-and-gunicorn-on-ubuntu-20-04 https://www.digitalocean.com/community/tutorials/how-to-set-...
- robomartin 5y ago
  Not sure that your link is an answer to my comment. Whatever the case may be, I can take a single VPS and multi-host a bunch of domains, each with it's own Wordpress installation, DB, etc. Virtual hosts makes this possible. It's stupid simple. Getting a single Django application running under a single domain on a VPS is a nightmare. Particularly when you consider everything you have to do to migrate from the development environment to production. This is why we do not do any Django development using the standard installation and go right wo running it just like production on either virtual machines or a dedicated on-premises Linux server. The development environment is as close to an exact match as the production environment. No SQLite, no runserver, no nonsense with static files, etc. This is what I think the Django project needs to really think about working on. There is no reason to have a crippled development environment at all. The base installation ought to be setup to migrate to a standard Linux host (not something purpose-built like Heroku) without much friction. If you are doing a more complex site with multiple servers, load balancing, etc., you are on your own. I truly think adoption would be far greater if the deployment experience was sensible. I have talked to people who absolutely gave up on Django because going from development to production was a nightmare without spending money on far more expensive servers and services they should. This is an application (Django) that should easily run on any Linux server. The fact that companies were created to facilitate deployment says it all.

buro9 5y ago

Maybe this will be the moment I upgrade. Let's see what version I'm running: Django 1.5.9 This is going to be very painful isn't it. I wonder how long until the bitrot makes it unbuildable and undeployable. I should clarify, there is no database attached to this and it talks to a secure API that is maintained really well. So this is just views and templates, where the views talk to the API.

sam_goody 5y ago

OT, but considering the audience... I have a side project / website that I want to work on. I have over a decade experience with PHP and JS in various forms, but am willing to try something new. The idea of compiled languages don't appeal to me, so am not really interested in Go, Rust or Dart. It looks like either Django, Elixir, or PHP - but am open to other ideas. Anyone with enough experience to tell me confidently that it is worth Django or Elixir? Anyone can give a five line overview of the differences vs PHP or Node? And along the way, am I the only one who is confused by what seems too many environments and package managers? (from venv/virtualenv[1] to pip/easy_install to wheels/eggs) [1]: https://stackoverflow.com/q/41573587/87520 https://stackoverflow.com/q/41573587/87520

jph 5y ago
IMHO, Elixir & Phoenix are such a breath of fresh air, plus power, plus adaptability, and I love the functional capabilties. On the other hand, if your want lots of numeric computation tooling, AI/ML, stats, etc. then Python & Django have better/more math-adjancent integrations.
midrus 5y ago
Django: Great if you are building only a backend or rest API with a separate frontend (an SPA in React, etc). The templates system is terrible, has no asset pipeline built in and frontend on it feels like developing in the 90s. You'll miss php a lot here. Elixir: Technologically "mind blowing", although all the nice things come from the Erlang VM and not from Elixir itself in my opinion. You will likely not find any job using Elixir, if you do it is going to be full of people just learning the language so the codebase will be very likely a disaster. You will miss a lot of libraries and you will have to write code for things you'd take for given in the PHP ecosystem. Be ready to fight your editor plugins (depending on which one you use, and the degree of IDEisms you're used to). I understand you want to learn something new, so the most "radical" one here that will teach you more new things is clearly Elixir. But other than learning purposes, If I were to build something for real, I'd stick with PHP and Laravel, it's an incredible productive, well documented and well thought out platform to develop in.
8589934591 5y ago