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.
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.
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.
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.
It's more straightforward to call a sync function from an async function than the other way around. That's a pretty uncontroversial statement. Adding async support to a library doesn't mean starting starting over.
I'm not fully understanding your thought. Can you say more?
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.
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!
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
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.
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!
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.
> 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.
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.
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.
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.
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
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!
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 ?
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.
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?
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.
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.
> 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.
This is exactly the problem tho. Every Django solution is "install this thing that replaces or adds a component that should be standard". People adopt frameworks to help them stay on track, not because they want to immediately install 5-10 packages just to correct the framework. Not to mention this just creates a big split when every project will be very different.
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.
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.
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...
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?
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.
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
I think to really learn Python for web as a developer you really have to learn WSGI/Gunicorn/etc and handling sessions within this.
I’ve found the challenge with Python for web is deployment as most website deployments are geared towards serverless workers or cdn’d javascript bundles and most python systems use WSGI and sessions, which is fundamentally different and the biggest challenge in newbie’s using python for websites.
This looks cool. FWIW I’m not a Django guy, but pulled up the site (djangoproject.com) out of curiosity to compare it to Plain. One thing that stood out to me was this:
> Ridiculously fast.
> Django was designed to help developers take applications from concept to completion as quickly as possible.
This rubs me as a little deceptive/insincere. When I read “ridiculously fast” on a hero banner, I’m expecting that to mean the speed of the language/framework itself. Anybody else see it similarly or am I just being cranky?
Anyways, I as an outsider see a lot more immediate value proposition on the Plain page than the Django one. Good job whomever put it together.
I use Django at $DAYJOB for multiple projects and love it but definitely see its age. I would never migrate to something "slightly different" like this.
I have a different approach to "modernizing Django", which is to write a spiritual successor ORM from scratch, which is Postgres-only and be "closer to the metal" while maintaining a porcelain Python API. Sounds insane, but "just use Postgres" is real and it already has a number of killer features that aren't possible in (core) Django due to its complexity and commitment to a standard SQL abstraction.
- a much more Pythonic control flow than Django: there's no big settings.py file that does a bunch of magic. "Management commands" are just regular python scripts that get executed within your apps context. Can run in Jupyter notebooks. Much less OOP and framework complexity overall.
- task queues via LISTEN; NOTIFY; SELECT FOR UPDATE;, which builds off the above. Your worker processes don't have to load the entire app, just the parts it needs.
- fully typed using the latest generic type support
- first class support for dropping to raw SQL, the ORM isn't trying to reinvent everything Postgres can do. Mostly waiting for PEP 750 before finishing this feature.
- even more JSON field support, including a subclass called "Attributes" that exposes declared keys as Python attributes. CHECK JSONschema support via a Postgres extension.
- RLS integration, including a "tenant" context manager so you can do `with transaction(tenant_id="foobar"):` and all queries run in the block will be constrained by what that tenant can access according to RLS policies defined on each model. Mainly a first line of defence, but adventurous devs could give tenants read-only SQL access to their tenant data (e.g. for an analytics service).
- a Model base class called "Entity" which uses UUIDv7 for PKs and implements many powerful features, like generic FKs, soft-deleting, changelogs
- model-level support for JSON de/ser, so you don't need a separate DRF
- not trying to reinvent a WSGI/ASGI web framework, instead it tries to integrate nicely with starlette or whatever with some session support.
- migrations, postgis, maybe bitemporal fields, and so on
- to like Django and all the 1000s of contributions
- to be frustrated by its limits & to want to do more
- to fork and rearchitect if you can’t get there by debate
- that people may like it and come along or the ride
- in many of the features and design points
- to embrace HTMX
It’s wrong:
- to try to innovate on the Python/Django ecosystem
- to miss out on functional code for HTML composition
- to continue the framework paradigm - HTMX leads to server side which leads to devs reclaiming the application loop
If, like me, you feel that plain is on the right track, but want to go faster / further, then I encourage you to take a look at https://harcstack.org. [disclaimer, I am the author]
Do you have more posts about this? My main gripe about Django is that the usual html templating options are but-uggly (as opposed to those that ship with Rails), but I haven't tried one of the new options.
I wish django's template engine was demoted to a contrib package and eventually replaced by jinja (i.e. jinja becoming a django dependency).
I understand that django templates started with the intention of eliminating programing logic in the templates (presentation). But the implementation of the concept is very puritanistic, to the point of becoming counter-productive. Jinja's approach OTOH is less opinionated: you can be a puritan and emulate django's approach if you want, but you can also be less dogmatic about the logic/presentation separation if that serves you.
As someone very aptly put it on reddit [1]:
> Jinja may let program logic layer bleed into the presentation layer, but with Django it seems there's no way to do it without presentation layer bleeding into program logic layer.
By what metric is Python the most popular language on earth? I'm actually curious, genuinely asking. I thought JavaScript (Node) was king of newly written code, but perhaps that is outdated information.
https://github.blog/news-insights/octoverse/octoverse-2024/ - "In 2024, Python overtook JavaScript as the most popular language on GitHub, while Jupyter Notebooks skyrocketed—both of which underscore the surge in data science and machine learning on GitHub."
What's missing here though is TypeScript: I believe if you combine JavaScript and TypeScript together they still beat Python on GitHub.
It is number one according to the most widely cited index: https://www.tiobe.com/tiobe-index/ So if you want the actual metrics and methodology you'd have to go there.
I’ve been using Django several years now. It works. Some things could be more straightforward, but once they work, they’re stable. I’ll keep an open mind though.
I'm still waiting for a truly cross-platform framework using Python that builds natively and beautifully on ANY platform - from the Apple IIGS to MacOS M4 to web to Windows to Linux. With a click of a button. So I wasn't pleased to read how limited this framework is. Still waiting, I guess?
There are some things available, and people are working on it. Coincidentally, one of those people is Russell Keith-Magee of Django fame, who founded the BeeWare project.
While it's truly a great ongoing effort and I am grateful to all the contributors, it's not nearly complete. You may think you're using the correct type until, surprise, you are not.
Because people want strong typing, but also want other things. It's possible to want multiple things, and bemoan that whwat you use is still missing things you want.
Concretely, Django is way more usable than basically any web framework from the "strongly typed" space, especially for "dumb" CRUD stuff. And you're not hit with making decisions about how to do a bunch of things (though you can swap out mostly any part of Django for something else if you want to).
That makes sense! My personal feeling is that a web framework is not the right place in the stack to introduce typing.
There’s also probably an argument to be made that part of the reason for Django’s “batteries included” success and wide adoption is in part because it is built on an untyped language.
I get wanting both, though.
In my own work, I find most of the benefit of static types to be ensuring correctness at compile time, so I just don’t expect that in Python. I also have just not lost that many cycles to type errors. But I know some have strong preferences here.
The main benefit in the developer workflow is autocompletion and feature discovery in the IDE. Having to guess which methods and properties an object exposes, or jump to the documentation every time, is really frustrating. Compare that to e.g. Typescript, which excels in this area.
Python is a strongly typed language. But Python is not statically typed; Python is dynamically typed, with optional type declarations which enables static type checking (by third-party software).
I'm really confused about what this project accomplishes. I agree that Django makes me jump through some unusual hoops (I simply never want to use views, forms, form sets, django email/caching/etc.) to use the subset I want, but I know that it'll "just work".
From the project's About page:
> What if you didn't have to worry about deprecation policies?
So nothing will ever get deprecated? Or things I use will just get ripped out?
> What if there were no committees?
As a user of the framework, is this supposed to appeal to me?
> What if you could change anything without consequence?
This sounds like a nightmare for a user.
> What if Django wasn't originally built for a newspaper circa 2003?
Does Django really carry that much (read: any) baggage from 22 years ago? It certainly doesn't feel like it.
---
Like I'm all for a good fork, especially if you're exploring something. But this project is telling me to use it _instead of django_ and other than "we have some third party packages built-in" it really doesn't tell me _why_ I should be using it. Frankly it feels like I'd be cooked if I chose this, since migrating back to Django proper if/when this becomes abandoned feels daunting.
There's not a philosophical reason (e.g., licensing) to choose this over Django, nor is there a meaningful cost that's being avoided.
You instantly become reliant on the Plain BDFL to upstream security patches. If that ever happens.
Everything and anything is liable to break at any time, since the project professes no obvious forward or backward compatibility.
What's great about Django is that I know I can build against a major version and know I'm not going to have to spin my wheels for 8-24 hours trying to upgrade to the next major version because the security patch wasn't backported to my version. I don't want my framework to have exciting minor versions. I want my features to be exciting every 3-5 years where I can say "alright, we'll take the two weeks to upgrade to the next major version". Especially when most of the exciting features can be delivered by third party packages instead of the core.
Why. This makes me sad. Plain looks great, but Django's strength is its maturity and amazing, enduring community built on contributions from thousands. Forking it will at best split contributions and mean infrequent merges, and at worst means Plain users lose out on Django improvements and Django users lose out on Plain patches.
It seems like Plain could be just a set of Django packages known to work together, and perhaps a new wrapper script replacing `django-admin`, but instead it appears it is a true fork.
Plain basically looks great. I love Django, and this is a long list of things that I'd need on top of Django anyway. Would I use a framework on top of a framework like this? I'm not sure. I just wish it was built in a way that contributed to the Django community instead of one that divides it.
I've successfully replaced django.contrib.auth multiple times. It it not easy, but it is not too hard either. Honestly, everything else they do could be a regular Django app. Looks to me like forking a big project became a marketing move rather than technology necessity.
The author discusses these points in the about page, but for me, does not sufficiently address them.
My experience of contributing to Django does not match theirs, and I don't feel this page sufficiently justifies this being a fork. In fact it actually makes me suspect that Plain will/has diverged enough that it won't be able to pull in changes from Django. As a user this would concern me, as Django ships meaningful changes regularly, as well as having a mature approach to security disclosures.
I have disclosed vulnerabilities in Django and they were handled very well and quickly. I actually went to see if Plain was vulnerable to the issue I disclosed, but my issue was around the memcached integration, and it seems Plain has completely removed all caching (except from a database-backed cache), making it in one way less batteries-included than regular Django. This puzzles me, for a project that is all about including more batteries, and as a potential user would lead me to further question the project.
Upstreaming to Django becomes very hard because he's moved stuff around. Also, switching to plain just to try it out becomes super hard because of this same thing. The idea of having a faster moving fork makes sense, but this isn't it.
Agreed. The about page also says that the plan is to update Plain to include new Django changes, but that would also be hard.
Django has a "contrib" package. I could see a fork with a fast moving contrib directory, or even just the Django project doing that with an explicit call-out for that package having a different set of breaking change expectations. A bunch of features started in contrib and graduated out of it over time, would be nice to keep that going.
I understand the frustrating with Django progress (and, to be honest, I would like for Django to more agressively upstream stuff).
I'm curious about what he would want to get into Django that feels like he couldn't though. Since this _is_ a fork of Django, he's still gonna hit a lot of issues that people wanting to improve Django hit.
Backwards compat is an issue, but "all of this code within the library is built off of existing assumptions" is _also_ an issue.
If all the improvements could be third party packages, just making plain be a big third party omnipackage that also has a helper to "fix" settings feels like it would go a long way.
I think Django is good enough to eat its babies but not good enough to evolve smoothly. It's been mentioned already but the task queue situation and the REST situation which are handled by Celery and DRF are not very ergonomic and well integrated than a default well designed system builtin into the framework like Phoenix gives you out of the box.
My main complaint is having used something like Wagtail (which builds on and extends Django) to quickly spin up a CRM is that if you come along years later to update a project you find the path very painful since Wagtail and Django updates diverge and you are left to your own bad choice of picking the path of least resistance. I'd rather just spend time building something in Django and then maintain that long term than try to keep two out of sync projects in sync while building on top of that mess.
I'm a Django user and I'm happy to see a fork because while Django is mature, it's also stagnating because the project isn't able to break things by introducing new features.
I don't think Plain will replace Django anytime soon but it might help guide decisions.
Plain being backed by a for-profit company is also great because projects like Django could use more marketing. Vercel figured this out a long time ago.
I'm not sure Django is stagnating. It recently added task queues as a concept, which was desperately needed, but there's not a lot else that's truly necessary. The important thing for me here is that Django has a very mature extension model – apps, packages, backends, etc – that mean that most functionality can and should be implemented as separate packages that plug in well. Almost all the Plain features are either built-in to Django already, or would do better as separate packages, and would likely receive push-back from being included in Django for that reason. Is that stagnation? To me that's maturity, and something I appreciate in a framework.
It's definitely stagnating. Compare how easy it was to add the admin interface when the framework was still young, vs adding the background workers feature you mentioned.
A lot more testing needs to be done before adding anything. The community should welcome projects like Plain, that can move fast and break things, which in turn might inspire Django.
That is the trend, but just because something is popular doesn't make it optimal. Developers are also excited about marginal gains from LLMs. The reality though is that most of those same teams could 2x their productivity by going back to a more retro stack, without losing quality, and also lowering costs in hosting and devops. The move to multi-service was for scale, but somewhere along the line people forgot to measure whether they needed that complexity at all.
A better way to do this is as a cookiecutter template. Go ahead and include everything you need as INSTALLED_APPS. Auth is pluggable, middleware is configurable, his support module is a classic use case for a pluggable app... Include pytest and Python-Allauth with sane defaults.
I'm struggling to see anything that wouldn't work better—benefiting from all the good work in the Jazzband universe and automatically getting the upstream security upgrades—without a fork.
Right up near the top of the front page: "Plain is a fork of Django, bringing new ideas to established patterns in the Python landscape. Build a new business, an internal tool, or something for yourself."
It's clearly a minimal readme, a tiny bit of frontmatter and a feature list. I see no reason to tar them for not including that everywhere.
Because late stage open source capitalism is now bypassing the messy business of building something popular and going straight open-core/vercel-model on the back of already popular libraries and frameworks. The emerging playbook is:
- Find successful open source project
- Fork with "reasons"
- Pour VC into helpful features, great docs, DX and evangelism
- Run the Vercel playbook
Exactly. I look at things like this and contrast with what friends like Adam Johnson do[0] with their community contributions. Adam has many Django packages, along with many other non-Django Python packages. Crucially though, they're not forks that reduce the focus of the community, they're contributions that increase what the community can do collectively.
I think it's perfectly fine to have split effort when you have differing views and goals on something. Developing two exact same things with same goal and purpose might not be fruitful, but variety and options don't usually hurt
I really don't understand why every time a big project is forked People are so upset. IMO, one of the great things about open source software is that a fork is possible. Maybe it will go nowhere, maybe some good ideas will be fed back to Django, maybe it will become the new standard. Most of the time , we will end up with better software overall.
I usually click through to the repo, and it isn't in the README for some reason. I don't blame GP for missing it. https://github.com/dropseed/plain
Of course, GP would've noticed it's like Django on the web page. The screenshot containing Django-like example code is above the fold, though - the Django mention is below the fold.
As a python/stats focused dev, I just want a web framework that simplifies the idea -> website process.
I've been able to 'release' some simple tools into the public with plotly/django, but having to also then figure out things like gunicorn, dbms, vps hosting etc. is quite time consuming.
My biggest issue is that a lot of these frameworks seem to add complexity (under the guise of simplicity) as opposed to making things simpler. They just become more things to manage. Maybe I'm missing something and someone can point me in the right direction.
There are lots of pros on here who will find things like this trivial, but for someone like me (independent with limited professional dev training) the time investment is high as is the cost of "switching" between what seem to be mutually exclusive tasks (web dev/ops, and local analytics work).
I have been there. Devops is never really fun. PaaS can take some of the pain away but quickly problems emerge with vendor lock in and you spend as much if not more time running the PaaS.
The best setup I ever had for deployment was a git hook which set ENVVARS and redeployed Apache when I did a push to prod. But if you need advanced features like multiple environments and database migrations this can get complicated fast
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.
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.
Try Flask.
Video: https://www.youtube.com/watch?v=5nS1SSuHk9I
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.
The #1 reason I use Django is stability. I have projects that span 4 major Django version without any significant break. That's quite a feature.
I'm not fully understanding your thought. Can you say more?
https://www.djangoproject.com/fundraising/ if anyone else depends on Django.
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.
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
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
There are bits I agree with but nothing like enough to be worth losing compatibility with third party packages.
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.
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.
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!
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.
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.
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.
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.
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!
https://plainframework.com/faqs/
brew install mkcert fixes this.
Also, a starter kit that asks for my password right away is a bit too intrusive for me:
I generally don't like to rely on ssl for development anyway. Make it optional maybe ?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?
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.
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.
This is exactly the problem tho. Every Django solution is "install this thing that replaces or adds a component that should be standard". People adopt frameworks to help them stay on track, not because they want to immediately install 5-10 packages just to correct the framework. Not to mention this just creates a big split when every project will be very different.
A lot pythonistas who only know Django have no idea that there other ways of building web apps.
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.
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...
Those classes can reference the settings, so including them as strings is done to allow that to work without creating circular imports.
I’ve found the challenge with Python for web is deployment as most website deployments are geared towards serverless workers or cdn’d javascript bundles and most python systems use WSGI and sessions, which is fundamentally different and the biggest challenge in newbie’s using python for websites.
Setting this up in Django requires some gymnastics.
> Ridiculously fast.
> Django was designed to help developers take applications from concept to completion as quickly as possible.
This rubs me as a little deceptive/insincere. When I read “ridiculously fast” on a hero banner, I’m expecting that to mean the speed of the language/framework itself. Anybody else see it similarly or am I just being cranky?
Anyways, I as an outsider see a lot more immediate value proposition on the Plain page than the Django one. Good job whomever put it together.
I have a different approach to "modernizing Django", which is to write a spiritual successor ORM from scratch, which is Postgres-only and be "closer to the metal" while maintaining a porcelain Python API. Sounds insane, but "just use Postgres" is real and it already has a number of killer features that aren't possible in (core) Django due to its complexity and commitment to a standard SQL abstraction.
- task queues via LISTEN; NOTIFY; SELECT FOR UPDATE;, which builds off the above. Your worker processes don't have to load the entire app, just the parts it needs.
- fully typed using the latest generic type support
- first class support for dropping to raw SQL, the ORM isn't trying to reinvent everything Postgres can do. Mostly waiting for PEP 750 before finishing this feature.
- even more JSON field support, including a subclass called "Attributes" that exposes declared keys as Python attributes. CHECK JSONschema support via a Postgres extension.
- RLS integration, including a "tenant" context manager so you can do `with transaction(tenant_id="foobar"):` and all queries run in the block will be constrained by what that tenant can access according to RLS policies defined on each model. Mainly a first line of defence, but adventurous devs could give tenants read-only SQL access to their tenant data (e.g. for an analytics service).
- a Model base class called "Entity" which uses UUIDv7 for PKs and implements many powerful features, like generic FKs, soft-deleting, changelogs
- model-level support for JSON de/ser, so you don't need a separate DRF
- not trying to reinvent a WSGI/ASGI web framework, instead it tries to integrate nicely with starlette or whatever with some session support.
- migrations, postgis, maybe bitemporal fields, and so on
It’s right (as explained in the about):
- to like Django and all the 1000s of contributions
- to be frustrated by its limits & to want to do more
- to fork and rearchitect if you can’t get there by debate
- that people may like it and come along or the ride
- in many of the features and design points
- to embrace HTMX
It’s wrong:
- to try to innovate on the Python/Django ecosystem
- to miss out on functional code for HTML composition
- to continue the framework paradigm - HTMX leads to server side which leads to devs reclaiming the application loop
If, like me, you feel that plain is on the right track, but want to go faster / further, then I encourage you to take a look at https://harcstack.org. [disclaimer, I am the author]
I understand that django templates started with the intention of eliminating programing logic in the templates (presentation). But the implementation of the concept is very puritanistic, to the point of becoming counter-productive. Jinja's approach OTOH is less opinionated: you can be a puritan and emulate django's approach if you want, but you can also be less dogmatic about the logic/presentation separation if that serves you.
As someone very aptly put it on reddit [1]:
> Jinja may let program logic layer bleed into the presentation layer, but with Django it seems there's no way to do it without presentation layer bleeding into program logic layer.
[1] https://www.reddit.com/r/django/comments/13n9pfd/is_it_me_or...
https://rakujourney.wordpress.com/2024/10/27/raku-htmlfuncti...
i’m planning a series of posts on HARC stack starting tomorrow (just finalizing first one)
you can use the RSS at https://raku.org or subscribe to https://rakudoweekly.blog/ to get them
What's missing here though is TypeScript: I believe if you combine JavaScript and TypeScript together they still beat Python on GitHub.
https://plainframework.com/llms.txt
Since so many LLMs are around, there should be a standard URI to let LLM crawl about the website/product
https://beeware.org/
https://beeware.org/about/team/freakboy3742/
https://kivy.org/
Seems like compiling to and deploying to Apple 2 is still a stretch
https://plainframework.com/docs/plain-api/plain/api/README.m... https://plainframework.com/docs/plain-mail/plain/mail
Yikes. If you want to fork a project, rather than contribute, bring better game.
So...an effort to commercialize open source?
https://github.com/typeddjango/django-stubs
Concretely, Django is way more usable than basically any web framework from the "strongly typed" space, especially for "dumb" CRUD stuff. And you're not hit with making decisions about how to do a bunch of things (though you can swap out mostly any part of Django for something else if you want to).
There’s also probably an argument to be made that part of the reason for Django’s “batteries included” success and wide adoption is in part because it is built on an untyped language.
I get wanting both, though.
In my own work, I find most of the benefit of static types to be ensuring correctness at compile time, so I just don’t expect that in Python. I also have just not lost that many cycles to type errors. But I know some have strong preferences here.
From the project's About page:
> What if you didn't have to worry about deprecation policies?
So nothing will ever get deprecated? Or things I use will just get ripped out?
> What if there were no committees?
As a user of the framework, is this supposed to appeal to me?
> What if you could change anything without consequence?
This sounds like a nightmare for a user.
> What if Django wasn't originally built for a newspaper circa 2003?
Does Django really carry that much (read: any) baggage from 22 years ago? It certainly doesn't feel like it.
---
Like I'm all for a good fork, especially if you're exploring something. But this project is telling me to use it _instead of django_ and other than "we have some third party packages built-in" it really doesn't tell me _why_ I should be using it. Frankly it feels like I'd be cooked if I chose this, since migrating back to Django proper if/when this becomes abandoned feels daunting.
There's not a philosophical reason (e.g., licensing) to choose this over Django, nor is there a meaningful cost that's being avoided.
You instantly become reliant on the Plain BDFL to upstream security patches. If that ever happens.
Everything and anything is liable to break at any time, since the project professes no obvious forward or backward compatibility.
What's great about Django is that I know I can build against a major version and know I'm not going to have to spin my wheels for 8-24 hours trying to upgrade to the next major version because the security patch wasn't backported to my version. I don't want my framework to have exciting minor versions. I want my features to be exciting every 3-5 years where I can say "alright, we'll take the two weeks to upgrade to the next major version". Especially when most of the exciting features can be delivered by third party packages instead of the core.
Looking at you Meta, Apple, X
Why. This makes me sad. Plain looks great, but Django's strength is its maturity and amazing, enduring community built on contributions from thousands. Forking it will at best split contributions and mean infrequent merges, and at worst means Plain users lose out on Django improvements and Django users lose out on Plain patches.
It seems like Plain could be just a set of Django packages known to work together, and perhaps a new wrapper script replacing `django-admin`, but instead it appears it is a true fork.
Plain basically looks great. I love Django, and this is a long list of things that I'd need on top of Django anyway. Would I use a framework on top of a framework like this? I'm not sure. I just wish it was built in a way that contributed to the Django community instead of one that divides it.
My experience of contributing to Django does not match theirs, and I don't feel this page sufficiently justifies this being a fork. In fact it actually makes me suspect that Plain will/has diverged enough that it won't be able to pull in changes from Django. As a user this would concern me, as Django ships meaningful changes regularly, as well as having a mature approach to security disclosures.
I have disclosed vulnerabilities in Django and they were handled very well and quickly. I actually went to see if Plain was vulnerable to the issue I disclosed, but my issue was around the memcached integration, and it seems Plain has completely removed all caching (except from a database-backed cache), making it in one way less batteries-included than regular Django. This puzzles me, for a project that is all about including more batteries, and as a potential user would lead me to further question the project.
Django has a "contrib" package. I could see a fork with a fast moving contrib directory, or even just the Django project doing that with an explicit call-out for that package having a different set of breaking change expectations. A bunch of features started in contrib and graduated out of it over time, would be nice to keep that going.
I'm curious about what he would want to get into Django that feels like he couldn't though. Since this _is_ a fork of Django, he's still gonna hit a lot of issues that people wanting to improve Django hit.
Backwards compat is an issue, but "all of this code within the library is built off of existing assumptions" is _also_ an issue.
If all the improvements could be third party packages, just making plain be a big third party omnipackage that also has a helper to "fix" settings feels like it would go a long way.
My main complaint is having used something like Wagtail (which builds on and extends Django) to quickly spin up a CRM is that if you come along years later to update a project you find the path very painful since Wagtail and Django updates diverge and you are left to your own bad choice of picking the path of least resistance. I'd rather just spend time building something in Django and then maintain that long term than try to keep two out of sync projects in sync while building on top of that mess.
The fork is a bad take here as it will be super costly to maintain for no gain.
Now, if you were to change a deep layer like the ORM, that would justify it. But I don't see it here.
But let's not be negative here, someone wants to spend time, energy and resources to explore innovation for a great legacy foss project.
This is good news.
I don't think Plain will replace Django anytime soon but it might help guide decisions.
Plain being backed by a for-profit company is also great because projects like Django could use more marketing. Vercel figured this out a long time ago.
It took me a while to find any information on this, so for others:
https://forum.djangoproject.com/t/django-tasks-bringing-back...
https://github.com/django/deps/blob/main/accepted/0014-backg...
A lot more testing needs to be done before adding anything. The community should welcome projects like Plain, that can move fast and break things, which in turn might inspire Django.
The times for-profit dev tooling has worked, it’s almost always when the profit is a means to providing value (e.g. Jetbrains), but that’s very rare.
For profit is generally a stronger signal of an impending rug pull than longevity.
But seriously there has been a movement back towards rending on the server-side. This underpinnings of Next.JS and HTMX
A better way to do this is as a cookiecutter template. Go ahead and include everything you need as INSTALLED_APPS. Auth is pluggable, middleware is configurable, his support module is a classic use case for a pluggable app... Include pytest and Python-Allauth with sane defaults.
I'm struggling to see anything that wouldn't work better—benefiting from all the good work in the Jazzband universe and automatically getting the upstream security upgrades—without a fork.
I guess the author didn't think credit was due: https://plainframework.com/about/#credit-where-credits-due
It's clearly a minimal readme, a tiny bit of frontmatter and a feature list. I see no reason to tar them for not including that everywhere.
- Find successful open source project - Fork with "reasons" - Pour VC into helpful features, great docs, DX and evangelism - Run the Vercel playbook
We're gonna see a lot more of this.
To be fair, Vercel did not 'find&fork' Next.JS, they are the authors of the framework.
Considering the GNU manifesto is from 1985 I guess we’ve gone through multiple stages quickly. What were they?
Early slack actually supported being used by 3rd party IRC clients
[0]: https://github.com/adamchainz?tab=repositories&q=django-&typ...
Third sentence.
Of course, GP would've noticed it's like Django on the web page. The screenshot containing Django-like example code is above the fold, though - the Django mention is below the fold.
“Django lets you write web apps in Django. TurboGears lets you write web apps in TurboGears. Web.py lets you write web apps in Python.”
https://webpy.org/
I've been able to 'release' some simple tools into the public with plotly/django, but having to also then figure out things like gunicorn, dbms, vps hosting etc. is quite time consuming.
My biggest issue is that a lot of these frameworks seem to add complexity (under the guise of simplicity) as opposed to making things simpler. They just become more things to manage. Maybe I'm missing something and someone can point me in the right direction.
There are lots of pros on here who will find things like this trivial, but for someone like me (independent with limited professional dev training) the time investment is high as is the cost of "switching" between what seem to be mutually exclusive tasks (web dev/ops, and local analytics work).
The best setup I ever had for deployment was a git hook which set ENVVARS and redeployed Apache when I did a push to prod. But if you need advanced features like multiple environments and database migrations this can get complicated fast