6 ms·
Some more things about Django I've been enjoying
- altbdoor 3mo agoGood ole Django. Worked with a number of frameworks (tm), but nothing really quite scratches my itch like Django does. I still find the ORM and database migration system unmatched.
- hahahaa 3mo agoI found Django a bit hard to get on with vs. other frameworks and I've used Rails, .NET MVC and Express (and friends). I just found more friction trying to achieve X for any given X for some reason. Not sure why.
- mcrk 3mo agoThat's the whole beauty of frameworks and languages. Some of them just "click" with you. At the end of the day we can all build what we need.
- echoangle 3mo ago> Some light load testing (with (ab -n 1000 -c 1) shows that right now we can serve about 2-3 requests per second (on a ~$10/month VM). > After turning on template caching, it seems like the site can now pretty easily handle 12 requests per second or so without using all of the CPU. I have not carefully benchmarked the before and after but it seems like it’s made a pretty big difference. That seems crazy low, I think there has to be something else going on here.
- shakna 3mo agoThose numbers sound... Single-threaded. Like they're using the development runserver instead of uwsgi or gunicorn.
- jonatron 3mo agoA $10/month VM might only have a single thread anyway. Some providers like lightsail are really slow too.
- echoangle 3mo agoYou can run multiple OS threads (gunicorn workers) on one VM thread so the workers don’t have to wait for each others request to finish though, right? And if you pay $10/month for a single threaded machine, you’re overpaying by a lot.
- jonatron 3mo agoTrue, but in this case with SQLite, there's unlikely to be much of a difference because there isn't the spare time available when waiting for a separate database server. I don't know what providers are good for a $10/month instance these days.
- ErroneousBosh 3mo agoMost of the time you're hitting SQLite, you're just reading from it, and so it doesn't hold anything up.
- echoangle 3mo agoHow are you spending any non-negligible time reading from SQLite at 12 requests per second though? That would mean you’re spending something like 50 ms per request on reading from SQLite.
- shakna 3mo agoFor a cheap VM, I'd still be expecting in the range of 500-1000 connections a second. Green threads are cheap, even with a single processor. For a half-decent VM, I'd be expecting multi-thousand. Single figures a second, is choked to a single connection at a time.
- marcosdumay 3mo ago
- bigfatkitten 3mo agoThat’s a number I would been disappointed with 25 years ago, running Perl CGI on a 700MHz Pentium III.
- crabbone 3mo agoYeah... in the place I worked, for a while, they didn't have a package index for Python packages (similar to PyPI), so, I wanted to write one. At the time I had a love-hate relationship with Ada, so, after trying to do something with Python and thinking how much resources I would have to ask for and whether I'll need load balancing etc... I checked what Ada's (somewhat unfortunately named AWS...) would need to be used as that kind of index. Suffices to say that I wouldn't need any of the "reverse proxy" servers, no caching, no load-balancers... It would be fast enough to service a company with thousands of employees on a very modest h/w setup. Using Django is like trying to walk on a highway, with a crutch. Even though it has some convenience features, it's just so impossibly slow you would have to invest a lot of engineering time and resources to mitigate that slowness.
- ranger_danger 3mo agoIt's because -c 1 only makes 1 request at a time, which is not representative of a real website load. This was also brought up on lobsters a few days ago https://lobste.rs/c/lctz1y https://lobste.rs/c/lctz1y
- nijave 3mo ago1000ms / 12 = 83ms per request which sounds normal
- miki123211 3mo agoIf Django could run reasonable numbers of requests on early-200s0 servers... what has gone wrong since? I imagine even a $10 VPS should be a much more powerful machine than a high-end server from 2005 or so.
- selfmodruntime 3mo agoWow. With a web service in Go or any similar language that would measure in the thousands, at least.
- acdha 3mo agoUsing Django back in the 2000s it was easy to get in the hundreds of requests per second unless you were doing truly pathological things in templates or gnarly database queries, and we have far more cores now. Usually something that low either meant things like not caching database connections or complex logic in templates.
- zipy124 3mo agoCopying my comment from lobste.rs here: I don't think the performance issues here are a result of Django. The author says only 2-3 requests per second (rps). Even in debug mode just using django runserver I can get 60~ rps on my $WORK repo. Part of this is likely their choice of only using '-c 1', which doesn't accurately represent a web workload. For example on a local dev server I get (in format -c n. rps) 1. 58 2. 61 3. 55 as expected because we only have 1 worker, in debug with little caching. but when looking at an example production config we see 1. 1: 11 2. 2: 23 3. 5: 54 4. 10: 95 5. 20: 153 6. 30: 165 7. 40: 177 8. 50: 192 and so on.... All of these are far in excess of the 2-3 observed by the author. Note these will heavily depend on how many database hits you have per request as that is the majority of workload, as well as your http server such as using http 1/2/3, and the TLS settings used etc...
- BrenBarn 3mo agoThe Django filter syntax with the double underscores is like fingernails on a chalkboard to me. I find it insane that they didn't just use operator overloading to create a real query expression language.
- ezst 3mo agoOr now that python has ~types, this is really an area where things could be improved. Filtering would just be lambda predicate with fields auto complete as seen in .NET, scala, etc
- 7bit 3mo agoThere may be many reason other than rejecting that suggestion leading to what it is know. Your statement somehow suggests that it was deliberately decided against what you propose. I don't think we know that. I can't quite picture how operator overloading would look like, could you give an example?
- echoangle 3mo ago> I can't quite picture how operator overloading would look like, could you give an example? Instead of this: self.filter(end__gt=self._midnight(today)) You could write a "Field" class that implements __getattr__ and __gt__ so you could do self.filter(Field.end > self._midnight(today)) The "Field.end > self._midnight(today)" would evaluate to an object that would just store "my field name is end and my value needs to be larger than xyz". filter() can then look into its argument list and construct the filter criteria from the passed Field objects instead of the key value pairs as it does now.
- pbalau 3mo agoif self._midnight(today) returns a datetime object, than: self.filter(end__gt=self._midnight(today)) will evaluate to: self.filter(end__gt=<some_datetime_object>) While self.filter(Field.end > self._midnight(today)) will evaluate to: self.filter(<True/False>)
- faangguyindia 3mo agoI mostly use Go + SQLite for all the things I used to use Rails, JavaScript, or Python for. I find python django wastes too much resources, just look at memory usage. One of my web app backend (go) is serving approx 100 req/s right now and i look at pprof i see it's not bottlenecked by CPU but mostly IO and i love this. Writing concurrent code in Go is easy, the code i wrote 10yrs ago still compiles with no issue! This is why i am never gonna switch. My go apps use very little memory, so we can scale to many users for very cheap. For larger apps i use postgres (why? replication is easy using pgfailover, high demand apps need multiple api servers so it's out of process db like postgres is fine) but most of my web app use HTMX and if we need some reactivity, i use react (simply due to react experience from work) For our maintenance calorie tracking app, which is free and has no ads, we have to use as few resources as possible as we scale to thousands of users: macrocodex (which figures out maintenance calories from weight and calorie intake). We initially used Haskell. Later, it became slow and cumbersome to develop in (developing on an Apple Silicon Mac and deploying to x64 is a pain), even though I liked writing Haskell code. I even tried nix and wasted a day on that! I had a choice between OCaml and Rust. I picked Rust and never looked back. The algorithm serves in 0.1 ms on Rust. In Haskell, it was 0.2 ms, and memory usage was twice that of Rust. There are many optimization possible in Rust which i didn't do (for sake of simplicity) yet i received good performance. Yeah, I use Docker to compile Rust, but it's pretty fast, much faster than what I had with Haskell, so the developer experience is great. By switching to Rust, the LOC dropped to half of what we had in Haskell. project turned out to be successful. It has already produced guaranteed weight loss or weight gain for many people. So I set out to create an algorithmic workout app, for which I am using Rust and Go. The mobile app is in Flutter.
- nargek 3mo agoAppart from the fact that you find that Python wastes too much memory, what is your point ? I think that any person choosing Django knows that Python by nature will not be the most efficient language. Apart from that Django is battle-tested and can help bring a stable "product" quite quickly.
- faangguyindia 3mo ago
- ranedk 3mo agoI have been using Django since 0.95 and I haven't seen anything which is so flexible with amazing DSLs while also making it easy to understand the magic behind it. For the last 10 years, even in a Golang stack or Java stack, I still use Django for models and migration. I even have generators which generate Gorm (or other framework) DAO or Java hibernate classes using Django models. With LLMs, it becomes easier since I can now write all the model, custom querysets in Django, ask the LLM to generate Golang DAO, setters and getters... and test the query against the Django generated queries for completeness. Atlas, sqlx, sqlc and all other ORM like things in golang cannot do migrations the way Django does.
- 0xpgm 3mo agoI've never done it, but now that you say it, it makes a lot of sense. Using Django just to manage the database and do migrations, even behind other language stacks. You also get the Django admin interface for free. I once tried using SqlAlchemy but I couldn't help asking myself why it felt so complicated compared to Django.
- leetrout 3mo ago> I still use Django for models and migration There are dozens of us! It's a great db management toolkit. I've used it to much success many times for things like managing migrations from mysql to postgres and php to python. My opinions: - Django apps are an anitipattern for large internal / single purpose products due to migration overhead as FKs cross application boundaries. I will die on this hill. No team is ever disciplined enough to keep apps as boundaries for relationships and constraints. Strong contrast to the rails crowd that doesn't rely on referential integrity in the db by default where this isn't "a thing". - Goose[0] migrations in Go are really great but you have to let go of the dsl and the idea that your ORM drives your migrations, as you explicitly called out. Laravel[1] is on par with django IMO and a delight to use when in php-land. I've not tried to repurpose it like I have with Django and sqlalchemy. - sqlalchemy and alembic is a great toolchain outside of django that get's a bit of a bad wrap / confusion from django devs. it gives you that same ability to drive the changes from the classes / structs without having to drag around all of django. It having more verbose [0] https://github.com/pressly/goose https://github.com/pressly/goose [1] https://laravel.com/docs/13.x/migrations https://laravel.com/docs/13.x/migrations
- sakjur 3mo ago> as a meta comment: I’ve been working on talking about my programming opinions by just saying “THING does not feel good to me, I prefer OTHER THING instead”. That post I linked to says that function-based views are the “right way”. I’m not very invested in whether it’s “right”, but it’s validating to know that other people feel similarly to me about inheritance I admire this about Julia a lot. Her texts and zines are exploring software in a way that encourages curiosity rather than promoting a singular point of view.
- CraigJPerry 3mo agoThere are so many footguns[1] in async python but it really has stolen the zeitgeist of modern python web. Synchronous django has a lot to commend it. If you deploy it reasonably well (workers, behind a caching reverse proxy etc) it's easy to operate in production even under duress. It's not going to be the right stack for long lived websocket connections or whatever but for a CRUD-ish or enterprise app, often very productive. [1] buffer bloat is too easy to sleep walk into queue = asyncio.Queue() # oops unbounded concurrency await asyncio.gather(*(fetch(item) for item in items)) # look mum! no outbound sockets left or maybe even no file descriptors accidental blocking data = requests.get(url).json() # oops! we're blocking the event loop and sure you can setup a separate task to measure the event loop latency and alert on that but this is the kinda thing you'll never find in a tutorial, you just need to experience this stuff and figure out a solution you like I can go on and on about async python (cancellation bugs, leaking a task - that has a cataclysmic failure mode where if you forget to hold a reference to your asyncio.create_task() then it's all weak refs in that machinery so your task can get garbage collected before it ran or completed in production! super tricky forensics. Then there's all the obvious stuff like race conditions, new ways of creating deadlocks, blah blah i really can go on for days.
- loevborg 3mo agoPlease go on. I also feel like asyncio is a big hack. Even just accidentally blocking the event loop is way too easy. And I couldn't believe it when I read that you need to store a reference to a task in a set to keep it from accidentally getting canceled. How did this become the main stack of AI backends? It's like node but slower AND much easier to mess up because of synchronous IO.
- CraigJPerry 3mo agoI'm not sure i see it as a hack, but i do feel unduly burdened as a developer by async in python. I feel like there's a lot that i have to think about and i'd appreciate more help from the language. I don't want to be overly critical, there's languages that people complain about and then there are languages that no one uses... If i compare it to js/ts, some stuff is genuinely better in Python - e.g. if you missed an await. While both ecosystems have lint tools available for this, but the behaviour is just friendlier in python. Structured concurrency is better in python, but even if TaskGroup is nicer to use than AbortController, it still has its own foibles which means i'll usually advocate for AnyIO. But the js/ts ecosystem just generally benefits from being async from the get-go where python you're just a time.sleep() away from a bug that will slip through dev envs and ci pipelines undetected and only rear its head under load in prod. If i have a tip to share its the debug flag for asyncio run: asyncio.run(f(), debug=True) # find some more issues before prod
- rubyfruit 3mo agoHoly 2003 that website
- imperio59 3mo agoDo not use the development http server in a production setting. Use gunicorn or some equivalent. I had the same issue with incredibly low throughput on beefy machines and it's because the dev server implementation is single threaded and does not do concurrency at all. Switch to gunicorn.
- gnz11 3mo agoBetter yet, put gunicorn behind nginx, make sure all static assets are served by nginx, add appropriate Cache Control headers. Furthermore understand and use Django’s page caching.
- seanwilson 3mo agoFor Django's default template language, does it still have these limitations? 1. Brackets aren't allowed to help with boolean expressions like {% if a and (b or c) %} 2. You can't do basic arithmetic like {{ x * 2 }}, but you're allowed to do {{ x | add:"2" }}. There's hacks to multiply using {% widthratio a 1 b %} or division with {% widthratio a b 1 %} though (https://stackoverflow.com/questions/18350630/multiplication-in-django-template-without-using-manually-created-template-tag https://stackoverflow.com/questions/18350630/multiplication-...). 3. You can't assign expressions to variables like {% with x = a or b %}, so you have to repeat yourself. 4. You can't capture HTML generated from template code in a variable to pass into a partial template to write slots-style HTML components e.g. {% capture x %}Hello {{ username }}{% endcapture %}{{ include "partials/header.html" with body_html=x }}. 5. You can't pass variables to model methods. I understand there's a philosophy that templates shouldn't contain complex logic, but I find the above pretty arbitrary and leads to code that's harder to maintain. Addition is okay but not multiplication? Boolean logic is okay but not with brackets? I often have to puzzle out some way to get my code to work that goes against what I'd normally want to do, some I'm forced to duplicate template code because you can't put expressions in variables or move basic one-off logic into views (which has poor locality https://htmx.org/essays/locality-of-behaviour/ https://htmx.org/essays/locality-of-behaviour/ and makes it harder to move template snippets between pages). It's like hiding the kitchen knives because they might be misused. Is Jinja2 a practical alternative or there's friction to using it?
- leetrout 3mo ago> Is Jinja2 a practical alternative or there's friction to using it? jinja2 is drop in by changing the template backend. You can actually run both at the same time (just can't mix them, ofc). https://docs.djangoproject.com/en/6.0/topics/templates/ https://docs.djangoproject.com/en/6.0/topics/templates/
- selfhoster1312 3mo agoIt's a practical alternative, but definitely not a drop-in replacement! I've been working on migrating a django project to jinja2 lately, see the diff: https://framagit.org/la-chariotte/la-chariotte/-/merge_requests/168/diffs https://framagit.org/la-chariotte/la-chariotte/-/merge_reque... A few notables differences: - many controls are now functions/variables (that's good!), and some change name, for example `{% csrf_token %}` -> `{{ csrf_input }}` - calling methods without parenthesis does not work (that's good!), for example `query.all` -> `query.all()` - in tests` response.context` is replaced by `response.context_data`, which is not set when calling `render` directly (need to return a proper `TemplateResponse`) - template folders need to be renamed from `templates` to `jinja2`; there may be a way to change this behavior, but i did not find it, and this change is written so small in the docs i lost an entire day over it
- ranger_danger 3mo agoduplicate of https://news.ycombinator.com/item?id=49006691 https://news.ycombinator.com/item?id=49006691
- lazyant 3mo ago> the site can now pretty easily handle 12 requests per second. Right prod architecture (nginx -> gunicorn -> django, with nginx serving static assets), decent PRAGMAs for sqlite3 and caching for generic content should improve the RPS one or two orders of magnitude.
- hecreto 3mo agoNot to be a downer since a lot of JEvans’ content is great. People should really give .NET a try. I don’t know if we are just old greybeard curmudgeons who look at this and go “is this a new thing? haven’t we been doing this for decades?”, but .NET out of the box with a few packages for databases, logging, etc is so pleasant you don’t even think about it. Maybe it’s just not a vocal community idk.
- Izkata 3mo agoAt this point Django also qualifies as "for decades" - most (maybe all?) of what's in this post applied back when it was new. The basic design has been stable for a very long time.
- rileymat2 3mo agoTo be fair, for grey beards, python predates .net and I was using Django in 2008, which predates .net mvc.
- miki123211 3mo agoagreed 100%, the most under-appreciated programming ecosystem of them all. It's also the only one that has support for making truly native apps for all four major platforms: Windows, Linux, MacOS and iOS. If you're willing to put in the work and make separate, native UIs for each, C# is the only way to go. It's a rich enough language that it binds reasonably well to both Java (on Android) and Objective C / Swift (on iOs / MacOS), and having the core and UI layers of your app share the same language enables much higher fidelity bindings than what you can get out of E.G. UniFFI. And as a bonus, the same core is also re-usable on the server, and even in Web Assembly, if that's the way you want to go. There used to be some issues around Storyboards and such on Apple platforms, but if you go nibless (which you should anyway in the age of AI), that's no longer a problem.
- dnautics 3mo ago> under-appreciated programming ecosystem idk, for a long time nswag was the openapi framework and it was atrocious and had many core issues that were unresolved for almost a decade. it came to where i implemented an api with something basic (i think it was multipart) and one consumer of my api asked me to change the api because nswag couldn't handle it. i told them to pr a fix to nswag (they didn't).
- coolThingsFirst 3mo agoWeb dev is just mind-numbingly boring. Studying CS to be a web dev is like studying Physics to turn on the oven.
- dnautics 3mo agoautomatic migrations terrifies me. i use elixir/ecto. just write a migration! besides, some times you might want more than one schema for a db table (e.g. one with minimal information, for menus, dropdowns etc, and one with full information for your full CRUD operations)
- selcuka 3mo ago> some times you might want more than one schema for a db table Django has the concept of "proxy models" where you can define a trimmed down model for the same database table.
- sgt 3mo ago> 12 requests per second You can definitely get more than that in Django. We could much more that back 15 years ago on very basic hardware, rendering templates and doing semi complex UIs.
- trojans1290 3mo agoIs Django still a solid choice in 2026 for new backend projects? Have loved the orm, admin, etc.
- a_c 3mo agoMy experience from running a django app with thousands of migrations and dozen of apps - Testing involving models is slow. It runs all your migration. Python's own "Unittest" is fast for functions not involving models. - The suggested pattern for business logic is "active record", which is putting functions about a model alongside the model itself. Good for clean case. Doesn't really work when your operation involve multiple models. - But if you put function about a model inside a model, the migration doesn't serialize the function into migration history (I could be wrong) - "Data" migration is handy when you want enum-like data in database available to all teammates. e.g. list of currencies - It is very tempting for new team member just to create an django app, with its own view and model, because it feels like starting a fresh without needing to care about existing business context. On the other hand, designing conceptual boundary between apps is very important. Because starting app is easy, and often (not always) wrong. - The squash migration utils are limited because I guess of relatively low usage. It squashes linear migration history (with manual curation of starting and ending migration node I think? Not sure about latest state). I wrote a util to squash whole migration history by finding linear segments and squash those segment of history one by one. Didn't release it, but wrote some notes https://gist.github.com/kmcheung12/08b4c234b38c23efd43550da9171ecf9 https://gist.github.com/kmcheung12/08b4c234b38c23efd43550da9...
- mstaoru 3mo agoYou can run with --no-migrations (https://pytest-django.readthedocs.io/en/latest/database.html#no-migrations-disable-django-migrations https://pytest-django.readthedocs.io/en/latest/database.html...) and default the test DB to be in memory (works at least for PG and SQLite) to make it quite a bit faster.
- melodyogonna 3mo agoDjango is nice, but I'm currently migrating a project from Django to Go because Django is too large. I would love to stay with it, but simply assimilating the docs has been a chore. The PDF is 3000 pages, and I love working with tools where all the parts can fit in my head.
- stuaxo 3mo agoWhen it comes to thinking about performance, the first thing to do is install the Django debug toolbar and use that to work out what's going on with your views and the queries they trigger.