8 ms·
My takeaways from DjangoCon EU 2025
- deleted 1y ago[deleted]
- fidotron 1y agoAre people choosing Django for new projects much these days?
- pabe 1y agoYes. Still one of the best batteries included web frameworks for creating anything that's more of a website (e.g. E-Commerce) than a web app (e.g. Photoshop). No, you don't need NextJs and friends for everything ;)
- sgt 1y agoAbsolutely. For what it does, Django is pretty much the best full stack Python web framework there is. It's also a great way to rapidly develop (just sticking to synchronous, which Django is best at). One can then later consider spinning certain logic off into a separate service (e.g. in Golang), if speed is a concern with Python.
- leoh 1y agoI’m not sure there’s a better full stack platform in any other language really?
- sgt 1y agoYeah, you are right. Maybe Ruby on Rails is up there? But I don't really know Ruby, and I never got into that.
- gymbeaux 1y agoSomeone just sent me a job opening for an engineer to work on a startup’s PHP backend and Python “everything else”. Absolutely insane.
- rob 1y agoWhere? Two of the best languages. Sign me up.
- JodieBenitez 1y agoyes
- bnchrch 1y agoJust like Python itself, unfortunately yes.
- ashwinsundar 1y agoWould love to hear an honest discussion of why Django and/or Python is a bad solution for any given problem. Is it because they are old technologies? Do they lack support for something in particular? Are they too expressive/not expressive enough?
- blitzar 1y agoBecause assembly language or if you must go higher level, fortran exist and all the 10x coding intergalactic scalers say everything else is bad.
- the__alchemist 1y ago(Love django in spite of Python here) - Imports are a mess - No control of mutation in function signatures, and in general it's still a surprise when things mutate - Slow - Types and enums have room for improvement
- sgt 1y agoYou just need to work around those and get used to it. Then you can build nice Python projects that keep growing - but Django really helps you do that. Python however is always going to be "10-100x" slower than something like an API written in Go, Rust and so on. That's fine in most cases.
- seabrookmx 1y agoNot in my org. Though we did choose it for _one_ new project recently, mostly because we re-used some code from another Django project we had, and we wanted to lean on some readily available functionality from jazzband libs. We have a few FastAPI services, but are mostly moving away from Python for projects > 1kloc.
- nine_k 1y agoWhat are you moving towards? Node/TS? Golang?
- seabrookmx 1y agonext.js + TS for front ends, C# for pure back-end services. Golang was a close second but we have some team experience with C# and like it's lack of ecosystem fragmentation, as that was another gripe we had with Python. The Dapper "micro-orm" is also refreshing after years of struggling to make Django's ORM do the right thing.
- haneul 1y agoWhy moving away from Python at that threshold?
- seabrookmx 1y agoThe threshold is arbitrary, and likely higher in reality. But we found that we want something with more sound type checking and mypy has lots of rough edges. The Python ecosystem has a lot of catching up to do here.
- cjauvin 1y agoFor a complete solution requiring many traditional high-level components like templating, forms, etc, then yes, clearly Django. But for something looking more like a REST API, with auto-generated documentation, I would nowadays seriously consider FastAPI, which, when used with its typed Pydantic integration, provides a very powerful solution with very little code.
- wahnfrieden 1y agoDjango Ninja?
- macNchz 1y agoWorks great, I've been using it in production for a few years. DRF was one of my least favorite bits of the Django world and Ninja has been an excellent alternative. I still love Django for greenfield projects because it eliminates many decision points that take time and consideration but don't really add value to a pre-launch product.
- ashwinsundar 1y agoI chose Django + htmx and a small amount of Alpine.js for a full-stack software project that is currently being launched. I had zero professional experience with Django (or Python really) before starting. I was able to develop the entire application on my own, in my spare time, and had time left over to also handle infrastructure and devops myself. I prefer Python and it's web frameworks over Typescript/React because there is a lot more stability and lot less "framework-of-the-week"-itis to contend with. It's much easier to reason about Django code than any React project I've worked on professionally. IMO when you don't have a firehose of money aimed at you, then Python is the way to go
- sgt 1y agoYes, you can do the whole web app (or web site if you will) like that without any complicated dependencies. This will be great if you touch the project only now and again e.g. the typical side project that you want to still work in the year 2030 without major changes. Yet the approach also scales up to enterprise grade project, leveraging DRF, Django-cotton and so on (and htmx).
- tcdent 1y agoI just rolled a backend using FastAPI and SQLAlchemy and it made me miss Django. Too much other stuff going on in this app to incorporate Django, but it's still way ahead of the curve compared to bringing together independent micro frameworks.
- thenaturalist 1y agoOut of naive curiosity of considering your first stack vs. Django: What makes Django so way ahead of the curve?
- tcdent 1y agoThe ORM is so so so much better designed that SQLAlchemy v2. Performing queries, joins, executing in transactions all feels clean and concise. The latter feels dated and I find it hard to believe there's not a widely accepted replacement yet. In terms of views, route configuration and Django's class-based views are sorely missed when using FastAPI. The dependency pattern is janky and if you follow the recommended pattern of defining your routes in decorators it's not obvious where your URL structure is even coming from.
- haneul 1y agoHmmm any specific syntax examples of pain points in Sqlalchemy? Having used both, they feel similar to me so I’d love your view!
- 1y ago
- the__alchemist 1y agoYou bet. Still the easiest (IMO) for websites, perhaps of any language.
- ipaddr 1y agoIt easy but having separate app spaces by default instead of just one like Laravel makes it slightly harder for just a website case.
- the__alchemist 1y agoConcur. The multiple app paradigm doesn't fit any site I've built in Django. I make one called main.
- hellojesus 1y agoIdk if it's best practice, but I usually like to make apps similar to components, where I have an app for accounts which handles user accounts, and a files app which handles all the dimension and fact tables around user uploads, and a social app for social features, etc. It makes it easy to compartmentalize the business logic in terms of module imports.
- globular-toast 1y agoThis sounds similar to a modular monolith design. But you have to be careful not to directly import things between apps and especially not to make foreign keys between the models of different apps. We ended up doing that and just wishing it was one big app. Modular monolith is a good idea and if you want to do it in Django then make small apps that just expose services to each other (ie. high-level business functions). Then have a completely separate app just for the UI that uses those services.
- hellojesus 1y agoYeah. I was thinking a modular monolith since it's a django project, and I think that's django's sweet spot since it comes with so many things bundled. For a true modular design I'd probably step away from django to a less comprehensive framework or just write in golang.
- rowanseymour 1y agoIf it's the kind of project that is going to run against one PostgreSQL database then I'd probably start a new project with Django just for its database migration support. That doesn't mean everything in the project has to be Django.
- haneul 1y agoIs pretty equivalent to alembic autogenerate, no?
- vFunct 1y agoLLMs are experts at Django, as there's 20 years of training data on it as well as just being written in the world's most popular language. LLMs can pump out full featured Django sites like anything. I don't know why anyone would use any other framework.
- fhd2 1y agoAll the time. 1. Very easy to find developers for. Python developers are everywhere, and even if they haven't worked with Django, it's incredibly easy to learn. 2. Simple stuff is ridiculously fast, thanks to the excellent ORM and (to my knowledge fairly unique) admin. 3. It changes surprisingly little over time, pretty easy to maintain.
- ranger_danger 1y agoMy only criticism is that die-hard django devs constantly brush aside the admin and can't stop telling people not to use it. I think it's a huge mistake. It's extremely well-designed and extensible, there is no reason to reinvent the wheel when so much time and effort has been put into it. They will complain of things like "eventually you will have to start over with a custom solution anyway"... but whatever gripes they have, could just be put into improving the admin to make it better at whatever they're worried about. Personally I've not run into something I couldn't make work in the admin without having to start over. My own usecases have been CRUD for backoffice users/management and I've had great success with that at several different companies over the last ~15 years. People will say "it's only for admins you trust" yet it has very extensive permissions and form/model validation systems heavily used in the admin and elsewhere, and they are easily extensible.
- fhd2 1y agoI use the heck out of the admin. I wouldn't say I'm super experienced with Django, but my solution to users being overwhelmed by doing things there is to build a bit of extra UI just for the stuff they need to do, more Rails style. Meaning: I don't go into fighting too much with the admin when what it can do out of the box is not feasible for some. But even if the admin ends up being used only by devs and some trained folks, I think it has amazing utility.
- andybak 1y agoAbsolutely! I've been saying the same thing for decades (checks calendar - almost literally!)
- jdboyd 1y ago
- ropable 1y agoWe've used (and continue to use) Django for bespoke applications for a decade and a half now. It continues to be the most well-supported, well-governed, well-documented, batteries-included, extensible web framework of all the ones we've tried. Finding developers with experience using it (or upskilling them) is easy. As a choice of web technology, it's one of those that we've never regretted investing in.
- atoav 1y agojust did, and I really like it.
- jgalt212 1y agoThat's sort of like asking if people choose Python for new projects these days.
- tiffanyh 1y agoDidn’t Meta build Threads.com on Django? (Since Threads was based on the IG tech stack, and IG is a modified Django stack)
- neural_embed 1y agoSome of the talks look really interesting — are there any YouTube videos linked? I couldn’t find those.
- benwilber0 1y ago> Always use a BigInt (64 bits) or UUID for primary keys. Use bigint, never UUID. UUIDs are massive (2x a bigint) and now your DBMS has to copy that enormous value to every side of a relation. It will bloat your table and indexes 2x for no good reason whatsoever. Never use UUIDs as your primary keys.
- rowanseymour 1y agoAnd assuming we're not talking v7 UUIDs.. your indexes are gonna have objects you might commonly fetch together randomly spread everywhere.
- LunaSea 1y agoBut if you use sequential integers as primary key, you are leaking the cardinality of your table to your users / competitors / public, which can be problematic.
- outside1234 1y agoIf you don't have a natural primary key (the usual use case for UUIDs in distributed systems such that you can have a unique value) how do you handle that with bigints? Do you just use a random value and hope for no collisions?
- hellojesus 1y agoWouldn't you just have an autoincrementing bigint as a surrogate key in your dimension table? Or you could preload a table of autoincremented bigints and then atomically grab the next value from there where you need a surrogate key like in a distributed system with no natural pk.
- outside1234 1y agoYes, if you have one database. For a distributed system though with many databases sharing data, I don't see a way around a UUID unless collisions (the random approach) are not costly.
- gitroom 1y agoPretty cool seeing how people still go for Django even with so many new frameworks, always makes me wanna go back to it when stuff gets messy tbh
- explodes 1y agoI haven't used Django in about 10 or 12 years but I cracked it open the day. It was cool to see all the things I loved are largely unchanged; I was able to step right back in.
- BiteCode_dev 1y agoThe ecosystem has improved thought. django-ninja is great for API, django-coton brings component supports and you have better options than celery for qeueing.
- sgt 1y agoI've stuck to DRF for all these years. But wouldn't mind looking at django-ninja. Is it better?
- Scarblac 1y agoThere is buzz around the combination of Django and HTMX, worked on by the same people in one team, as a much simpler alternative to split frontend and backend teams with a REST API in between (and perhaps NextJS as well, etc).
- Arbortheus 1y agoDjango is still great. I recently upgraded two ~10 year old aging legacy applications at work. One was in Flask, and one in Django. This made me appreciate the "batteries included" philosophy of Django a lot more. Even though the django legacy application was much larger, it had barely any extensions to "vanilla django". Comparably, the flask application had a dozen third-party flask-* dependencies that provided functionality like auth, permissions, and other features that Django has built-in. Many of these dependencies were archived/abandonware and hadn't been maintained in a decade. When it came to upgrading the Django app, I had one giant release notes page to read. I didn't need to switch any packages, just make some pretty simple code changes for clearly documented deprecations. For the Flask app I had to read dozens of release notes pages, migrate to new maintained packages, and rework several untested features (see: legacy application). In my mind, "batteries included" is an underrated philosophy of Djangoo. Also, it is now such a mature ecosystem it is unlikely there will be any radical breaking changes. Perhaps there are some parallels to draw with newer trendy (but minimalistic) python frameworks like FastAPI. If I were building a web application I wanted to last a decade or more, Django would be up there in tech choices - boring and sensible, but effective.
- flakiness 1y agoIt looks like htmx is popular in the Django community. Is there any background story that made this? (Context: Just picked Django for a hobby project. Don't know much about Webdev trend beyond, like, what are talked about on the HN top page.)
- wahnfrieden 1y agoServer side template rendering is popular already and well supported in Django ecosystem
- tmnvix 1y agoThanks for the summary. Looking forward to the videos becoming available. > I talked to this speaker afterward, and asked him how they did nested modals + updating widgets in a form after creating a new object in a nested modal. He showed me how he did it, I've been trying to figure this out for 8 months! Do share!
- seanwilson 1y agoIt's easy to get something quick working with HTMX and Django, but if you want robust UI tests that actually test what happens when users click stuff, don't you need to use something like Playwright? This can be pretty heavy, slow and flaky, compared to regular Django tests? I find with HTMX, it can introduce a lot of edge cases to do with error handling, showing loading progress, and making sure the data on the current page is consistent when you're partially updating chunks of it. With the traditional clunky full-page-refresh Django way, you avoid a lot of this.