Plain – a web framework for building products with Python
165 comments
·March 29, 2025miiiiiike
grahameb
Yep – I've been using Django since 2007. The big win used to be the admin, ORM, database migrations... but now oddly enough a lot of that has become a pain. I'm someone who knocks small solutions together for fun or to scratch and itch, so I'm looking for low maintenance. The problem I need solved has shifted and now Django is too much boilerplate (APIs and models are perhaps too distant as concepts), and too much maintenance work. Auth is perhaps underemphasised as an area for improvement. The built in auth isn't really fit for purpose anymore, and the various extensions for federation / passkeys take work to integrate and change a lot.
None of this is to write off Django or the people who've worked on it: I'm genuinely grateful for the framework. It's let me build open source things that help people out. The typical problems most of us standing up small-to-medium solutions need solved by a backend have just shifted underneath the framework, and it hasn't had the resourcing to keep up.
I've been looking at Pocketbase as a replacement. I think I'd prefer something that uses Postgres rather than sqlite, but it's pretty awesome as a solution for those two or three day projects, and the maintenance burden looks like it's pretty low on an ongoing basis.
throwaway519
Django dying the Drpal death of becoming a generalised case of nothing but itself?
Try Flask.
simonw
Jacob Kaplan-Moss gave a great talk at the last DjangoCon about money - what Django would do with an increased budget and how to get there: https://jacobian.org/2024/oct/8/dsf-one-million/
miiiiiike
I saw the talk last year. Let's do it.
If I had $100,000 to spare I would give it to Django as an unrestricted donation. It would be worth every penny. But I'm a solo-dev and don't have that kind of cash on me.
Here's what I can do. I will send you $1,000 today if you can get something like a `django.contrib.rest` package (i.e. official rest api support) on the roadmap and secure matching funds. I'll make it a recurring donation if development gets going.
I don't want to support other REST libraries because there's no consensus. One app ships DRF views, another Ninja, and that one over there still has a Tastypie dep. Remember Piston? Using multiple rest packages means that figuring out how to create a consistent error format, etc is an exercise left to the reader.
Django makes great design decisions that the majority of devs can get behind. I'd love to have an officially supported REST package that feels like the rest of Django.
`django-tasks` is a good recent example. I was reading through the code a few months ago and I was impressed.
miiiiiike
Another project I'd fund: Making Django an async-first (not async-only) framework over the next decade. It's easier to mix sync code into async than the other way around.
miiiiiike
I just setup a $83/month ~$1,000/year recurring donation.
https://www.djangoproject.com/fundraising/ if anyone else depends on Django.
jimmydoe
thanks for sharing this, just donated too.
I read thru Plain's doc, it is not bad at all, but I really hope Django can be much better than it is now.
mariocesar
I've some mixed feelings about this fork. On the one hand, I get the motivations, there is alway a lot of value in experimenting outside of a legacy project. But at the same time, I cant help but feel uneasy seeing something I've deeply respected and used on for years being split off in this way, "fork of Django" is a big statement.
Part of that discomfort comes from a sense that the collective effort into Django is being sidestepped rather than built upon. It feels like a "saas-fication" effort, like Ruff, Docker, Terraform, etc but instead of going from creating something new it replaces something that already works. I worry about the potential for a more commercial or narrow direction that doesn't embody honestly the open, thoughtful mission thats made Django so special.
I'm in love of boring software.
I care about Django more than I realized. Seeing this has actually pushed me with a gut emotion to want to get more involved contributing code, writing, or just participating more with Django
It's not about the tool or the language, I want to feel different about the community that is open and respectful of contribution and values long term relations.
It's not fun to be boring, but boring is good
davegaeddert
Hey! I'm the creator (fork-er?) of Plain. I have mixed feelings too — if all this does is help spur some new activity around Django, that would be a good outcome!
sroerick
As a guy with a lot of hours into Django, I will echo that I don’t quite understand the “why” here.
I think there’s a number of areas where Django falls a bit short and other web frameworks excel. For example, task workers are not first class citizens and require Celery or another task manager. REST APIs are a similar situation. Celery and Django REST are great, but they do feel a little ham handed. I’ve seen other frameworks handle this in ways that really seem to work great.
I guess auth is prioritized here? But I actually like the barebones Django auth and find it useful in many situations where I don’t need full OAuth.
I’m not saying this isn’t needed and it looks cool and nice - but for the use cases where I’ve struggled with Django, it seems like this would actually increase complexity, as the 3rd party ecosystem would obviously not be robust.
It looks like the author has a perfectly good workflow and use case for this, but it’s not clear from the homepage or the “about” page linked elsewhere in the comments exactly what this is for
phonon
FYI https://github.com/RealOrangeOne/django-tasks will be included in Django once it is ready.
graemep
Django have been by bread and butter work for a long time, and I do not really get the point of this.
There are bits I agree with but nothing like enough to be worth losing compatibility with third party packages.
theptip
Seems weird to me. The strength of Django is the ORM and the ecosystem/idioms.
Why would I break compatibility with the latter by taking a fork?
I would love to see better admin (so many have tried to do this) but it’s unclear to me why the goodstuff here can’t be a Django project template. (https://docs.djangoproject.com/en/5.1/releases/1.4/#custom-p...)
As a longtime user if I want anything different these days it’s a lighter-weight experience like Django Ninja or FastAPI.
999900000999
I have mixed feelings.
I just switched to Django from Supabase/Firebase. The main thing I like is theirs a plugin for everything you’d want.
It’s also much easier to actually self host, Supabase is open source, but actually doesn’t self host all that well. You have a bizarre gap between ’free’ with constant nag emails warning you there about to turn off your project, a 25$ paid tier and a black box enterprise level. Call us isn’t very transparent.
For Plain, I’d much rather this be a Django plugin, I don’t want to replace a well supported and documented framework with a 1 person fork. Definitely looks cool, but you’ll never be able to provide the same ecosystem and support as the main Django project.
nop_slide
I appreciate this effort and am surprised by the negative sentiment. I evaluated the big 3 frameworks (Laravel, Django, and Rails) last year and Django felt like the worst of the lot.
I really wanted to like Django more since I use python at $dayjob, but it seemed so far behind Laravel and Rails terms of DX and features. Also the ecosystem seemed fragmented and a lot of packages looked stale.
For example, I remember having to piece together a static files pipeline for Django with whitenoise, how is that not included by default?
Additionally the issues around the user model are bizarre, near the very end of the docs they tell you to override the user model to fix it. Wat.
Lastly Django templates felt super limiting, Livewire/Laravel and Hotwire/Rails gives you so much out of the box.
I ended up choosing Rails to start building side web apps, their move to SQLite-first and the whole “Solid” suite of tools is rad. Specifically Solid Queue is awesome! I noped out of Django when I saw how intense the docs for setting up celery were.
Hoping this spurs some activity in the Django-sphere, I would love if Django felt more complete like Rails!
leetrout
I am continually impressed with Laravel. I have been using Django since 2008 and if I were starting a simple CRUD app I would consider Laravel before Django if I didn’t need anything Python specific. And with sqlc I would probably pick Go over both if I was forced to have a SPA pattern.
Jaxkr
> a static files pipeline for Django with whitenoise, how is that not included by default?
It is. They have a file server in debug mode and recommend something like nginx for serving files in production (and provide a collectstatic command to make that easy).
People shouldn’t be using a WSGI server to serve static media. Whitenoise shouldn’t exist.
tinodb
Plenty of websites can live with the reduced complexity of having their static files served directly by python. Hence it exists, and is useful.
Jaxkr
I came back to this thread after realizing I whitenoise would solve my current problem...
I'm working on a small internal tool using Django. When I turned debug off, my files stopped serving. And for this small deployment, I really don't want to have to require a separate nginx server. I get it now.
Chris2048
Django may be popular, but it isn't necessarily the best.
A lot is built-in, but there is less modularity compared to say flask.
The ORM is generally inferior to SQLAlchemy, and things like Generic FKs are Django-specific (middleware) that gives you a structural dependency on a framework-specific feature, as well as DB logic in the app layer. Also, (might have changed since I last used it), it's not patricularly pythonic.
async frameworks (awsgi) are the new hotness, and FastApi is gaining steady traction.
spapas82
I took a peek at the docs https://plainframework.com/docs/ and the packages/functionality mentioned there.
Everything, and I mean everything is already either in core Django or in a great and properly supported django package that's been used in years and has been proven to be reliable.
I really can't understand the purpose of this package. Taking a peek at the about as mentioned by some others:
> You can think of Plain as a "what if?" > What if you didn't have to worry about deprecation policies?
The fact that Django has deprecation policies and they are so religiously followed allows me (and others) to have 10+ years old projects running in Django 5.1 and being ready for 5.2 without any problems or baggage!
> What if there were no committees?
A committee is a good thing. It ensures two things: a. It's not possible to commercialize the project. b. It makes sure that it will do what's best for most users. Some decisions may no be good for a particular user but it would be best for most users (considering my previous comment; I want to keep my 10+ years old project properly supported).
> What if you could change anything without consequence?
See previous comments. You can change anything without consequence when you have a clean slate, not when you need to support current stuff.
> What if Django wasn't originally built for a newspaper circa 2003?
This really doesn't relevant. Django is a general purpose framework.
> What if you had a clean slate, but a proven head start?
See the previous comments.
> working through years of incremental progress and committees, with a very real possibility of some things never happening, is just not for me.
Please see my previous answers. Also, about changing stuff, that's the purpose of packages, ain't it? Django has a lot of escape hatches to change its behavior from the defaults. And of course if you wanted to do something not supported you could try to do a PR so as to open another escape hatch so Django will keep the default behavior but you'll be able to implement your thingie.
Concluding, I really don't like this project forking Django because all this effort could be put to better use and definitely not try to split the community. Especially the community of a real Open Source project like Django.
philips
I feel the About page would be better for the audience who clearly already knows Django: https://plainframework.com/about/
sroerick
Thanks! This helps me understand his motivations for forking. I still don’t have a clear sense of how Plain is different or what the different approach is
sroerick
I also found this but I have to say I don’t really understand still.
I’ve used flask on projects but I’ve never started a project in flask and then migrated it to Django - I’m not really sure why you would do this. If I think a project would need admin panel or other Django features, I just make it in Django. That’s usually a pretty easy call to make when you start.
It seems like the fork is largely political? E.g. he just doesn’t like the way the mailing list is run, which is totally valid. I just don’t know what architecture he is building or what is different. I wish him well, though!
JodieBenitez
Trying to run the starter kit, it tries to download mkcert, but that download fails with a ssl.SSLCertVerificationError... how ironic :)
brew install mkcert fixes this.
Also, a starter kit that asks for my password right away is a bit too intrusive for me:
Downloads/new-project [master {origin/master}|]: uv run plain dev
Generating SSL certificates for app.localhost...
Created a new local CA
Note: the local CA is not installed in the system trust store.
Note: the local CA is not installed in the Firefox trust store.
Run "mkcert -install" for certificates to be trusted automatically
Created a new certificate valid for the following names
- "app.localhost"
The certificate is at "/Users/me/Downloads/new-project/.plain/dev/certs/app.localhost-cert.pem" and the key at "/Users/me/Downloads/new-project/.plain/dev/certs/app.localhost-key.pem"
It will expire on 29 June 2027
Adding app.localhost to /etc/hosts file. You may be prompted for your password.
Password:
I generally don't like to rely on ssl for development anyway. Make it optional maybe ?petr25102018
I don't know if Plain has a chance to succeed but I understand why it is a fork. Django leadership haven't been able to move Django forward outside of its old paradigms and every attempt, be it a fork or third-party app, counts.
sroerick
Can you elaborate on this? What paradigms do you think are outdated?
Generally speaking, I think Django has lagged a bit behind other frameworks. However, the continued advantage of being Python driven has left it useful in my book when working with Python data utilities in the back end. What’s your perspective here?
petr25102018
It would be a long list. I will post some examples but you can summarize it as "Django is not ideal choice to build a modern SAAS applications" and "Django developer experience is lacking".
1. REST/HTTP API building needs to be built in for a batteries included framework. In 2025 it is already so so late. REST Framework is "finished" and even if it wasn't the third-party extensions including Ninja feel alien. They need their own routing (why?), their own serialization, have their own extensions or features (rate limiting) that should just be more generic.
2. Python optional typing is always rejected or postponed. Same with any effort to just make starting a project easier because Django doesn't want to ship any dependencies even if it means better outcomes. Recent discussions about shortening django-admin to django can give you enough information about how community decision making is difficult for bringing new (and great) ideas in.
3. Better approach for template components. Django should have good primitives so that people can built UI libraries on top. You can see 10+ third-party packages now but I think it should be included batteries.
4. Authorization. The whole authorization framework assumes that you run a website like the original newspaper. It absolutely cannot work with a multi-tenant SAAS apps that everyone wants to build.
5. Not being able to correct past mistakes or outdated stuff. For example still Django's user model is bad. I really don't understand how something so important cannot be fixed.
infamia
Regarding #3, you can already do this with Jinja2 template functions perfectly well. You can also do it with template tags, but it isnt as nice.
100% agree with #5, the diaspora of Django's community, dev process, and lack of a single decision maker when consensus isn't quickly reached, makes it virtually impossible to correct past mistakes.
null
boxed
Not the previous poster, but my biggest gripe with Django is all the silent failures. It was a bad idea 20 years ago, it's a bad idea now, it's just a very very bad idea.
kitsune_
Active Record leads to a big ball of mud.
A lot pythonistas who only know Django have no idea that there other ways of building web apps.
askonomm
First thing that I don't like is the settings being strings that reference classes. Usually that means that go-to definition does not work (I've seen similar things in Symfony with YAML use). If the config needs to reference a class, or some object, I would like to be able to easily navigate to it as opposed to having to manually search the project for it. If this was an actual object reference as opposed to a string, I could, and I'd also get intellisense for if I typed it right or not, and autocomplete.
Then of course they "solve" it later with a (probably paid) plugin. But why? LSP's support this natively, and for free, just don't use strings.
mdaniel
There are strings in Python already that reference classes: type annotations. PyCharm knows how to populate, warn, and navigate to the "interior" types there
I can't think of any reason why it couldn't be taught to behave similarly for a config file. You can do it today field by field via language injection but if there are a lot of them then I think the config file would need a JSON Schema with the x-intellij-language annotations on the relevant fields https://sourcegraph.com/github.com/JetBrains/intellij-commun...
beaugunderson
> First thing that I don't like is the settings being strings that reference classes.
Those classes can reference the settings, so including them as strings is done to allow that to work without creating circular imports.
askonomm
Ah yeah, didn't remember that constraint in Python. I thought I read something about a future version fixing that when it comes to just type hints, but I suppose that wouldn't work here, since it's not really a type hint, right?
beaugunderson
Yup, you're thinking of "postponed evaluation of annotations", which is currently optional with `from __future__ import annotations`. But as you said, would not fix the circular import here.
mcdirty
Tbh why should I use this over Django? Less docs and knowledge around it. Less maintainers. Idk seems like a business risk to invest real time in it for me
Related, "Django's REST (Framework) Problem" — https://news.ycombinator.com/item?id=43510495
I'm not sure that many people who rely on Django Rest Framework are aware that last month the bug tracker was made private and the project is looking for new maintainers.
I love Django but the project needs to go through something similar to Angular's renaissance (and Angular needs to learn from Django docs.) I'd love to help but it seems that most of the efforts to address the issue have been stalled in committee.
A fork probably isn't the answer but something needs to be done. If it's a money issue, pass the plate! Whenever I talk to Django devs about contributing the feeling that I'm left with is that I could put in years of work, jump through every hoop, and at the end of it they may still say "We're not sure."
The feeling that I've gotten is that the Django dev community is very small and tight-knit. Whenever I've talked about helping out on various projects I've walked away with the feeling that their friend is handling it and they'd rather leave them to it. The community has been trained, through years of reinforcement, to wait instead of getting involved.