Plain – a web framework for building products with Python

Posted by brylie 3/29/2025

Plain – a web framework for building products with Python(plainframework.com)

310 points | 160 commentspage 4

dzonga 3/29/2025|

this is dope, seems a more modern django. the work done here can be leveraged into making django more awesome.

samchon 3/29/2025||

Challenging hard work. Hope to go well.

callc 3/29/2025||

I really wish projects would choose novel English words for their name rather than squat on commonly used ones.

Looking at you Meta, Apple, X

wiseowise 3/29/2025||

I will only use this if there’s a whole page full of cancer emojis and analogies written for two year old gen Zs.

indiantinker 3/29/2025||

Is there something like this available for Ts/js folks? This looks quite complete.

revskill 3/29/2025||

Sorry, can't work without typesafety.

SJC_Hacker 3/29/2025|

if type(var) != type(var2): # here's your type safety

revskill 3/29/2025||

Safety, not equality.

heresjohnny 3/29/2025||

I miss a thorough explanation of how Plain is fundamentally different than Django + extensions. Good luck though

thundervelvet 3/29/2025||

cool

danpalmer 3/29/2025||

> Plain is a fork of Django

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.

adontz 3/29/2025||

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.

outofpaper 3/29/2025||

100% agree. Let's hope they maintain compatibility so stuff developed for Plain works with Django.

darthwalsh 3/29/2025||

In the FAQ they said that extensions would not be compatible

airstrike 3/29/2025|||

The author actually addresses all of those points in the about page https://plainframework.com/about/

danpalmer 3/29/2025|||

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.

boxed 3/29/2025||

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.

danpalmer 3/29/2025||

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.

rtpg 3/29/2025||||

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.

nprateem 3/29/2025|||

It'd have been better to see some concrete examples of things he could only achieve with a fork

fud101 3/29/2025|||

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.

BiteCode_dev 3/29/2025|||

It definitly could be a set of different libs, apps, config sets and command. I've seen no feature you can't provide that way.

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.

pbreit 3/29/2025|||

Django's origins in content probably made it hopelessly "thick" in today's world which on the server is mostly just taking in a spitting out JSON.

sroerick 3/29/2025|||

I think there’s a counter movement here, whether it’s Hotwire/Turbo in Ruby or the Django community adopting htmx.

danpalmer 3/29/2025||||

This is a valid debate to be had (and I disagree), but I don't think Plain is changing any of that. It's roughly similar in structure.

BiteCode_dev 3/29/2025|||

An app fixes that bettter than a fork. E.g: django ninja.

brokegrammer 3/29/2025|||

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.

danpalmer 3/29/2025|||

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.

jarofgreen 3/29/2025|||

> It recently added task queues as a concept

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...

jonatron 3/29/2025||

Django-tasks seems to be moving very slowly, it doesn't have database indexes yet. If you look at the problems with Celery: https://steve.dignam.xyz/2023/05/20/many-problems-with-celer... and the complicated compatibility matrix https://docs.celeryq.dev/projects/kombu/en/main/introduction... , task queues are still a pain point.

brokegrammer 3/29/2025||||

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.

n3storm 3/29/2025|||

In fact Laravel is constantly lending stuff from Django and RoR. Like model attributes.

halfcat 3/29/2025|||

Weird to see “it’s like Vercel” as a virtue.

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.

pbreit 3/29/2025|||

At this point, seems like the server is mostly a data access layer spitting out JSON for JavaScript, Java and Swift clients.

evantbyrne 3/29/2025|||

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.

SJC_Hacker 3/29/2025|||

Don't forget Flutter :-)

But seriously there has been a movement back towards rending on the server-side. This underpinnings of Next.JS and HTMX

coffeefirst 3/29/2025|||

Yes. This is a bad idea.

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.

benatkin 3/29/2025|||

Has no mention of it being a fork of Django in the README. https://github.com/dropseed/plain

I guess the author didn't think credit was due: https://plainframework.com/about/#credit-where-credits-due

_bin_ 3/29/2025||

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.

popcorncowboy 3/29/2025|||

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

We're gonna see a lot more of this.

jsk2600 3/29/2025|||

>- Find successful open source project - Fork with "reasons"

To be fair, Vercel did not 'find&fork' Next.JS, they are the authors of the framework.

gnuly 3/29/2025||

they probably intend its relation to React.

n3storm 3/29/2025||||

- Create a marketplace with pro (payed) version of all packages

azinman2 3/29/2025||||

“late stage open source capitalism”

Considering the GNU manifesto is from 1985 I guess we’ve gone through multiple stages quickly. What were they?

vram22 3/29/2025|||

Interesting. Got more examples of this playbook?

gnuly 3/29/2025|||

I can think of:

  Sqlite -> Turso  
  PostgreSQL -> Neon  
  Chromium -> Arc browser

not exactly fork, but aimed at riding popularity of an already-established thing:

  Nodejs -> Bun

SJC_Hacker 3/29/2025|||

IRC -> Discord

no_wizard 3/29/2025||

IRC -> Slack

Early slack actually supported being used by 3rd party IRC clients

earnesti 3/29/2025||

I don't get it, if you don't like it, don't use it, but why feel sad about it? Someone is developing something new and giving it out for free.

antoniojtorres 3/29/2025||

They aren’t sad about being forced to use something. They are expressing their opinion about split efforts in the Django community.

danpalmer 3/29/2025|||

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.

[0]: https://github.com/adamchainz?tab=repositories&q=django-&typ...

jiknstring 3/29/2025|||

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

phowat 3/29/2025|

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.