HN Reader

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.

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

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.

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.

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

you lost me at "fork of django". Start with FastAPI and work up from there, and borrow good ideas from more modern frameworks.

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.

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.

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 ?

Almost at 1.0 and this is the state of the docs? Linked from the home page.

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.

Challenging hard work. Hope to go well.

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.

"Plain was forked inside of PullApprove — a revenue-generating SaaS with Fortune 500 customers."

So...an effort to commercialize open source?

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

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

What are they doing that https://django-ninja.dev/ isnt doing?

Also, is there a Discord? Where's the community gathering? I'd like to try it :) looks neat.

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

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

The world’s most popular programming language that’s also the ugliest.

Kind of off-topic, but I liked the concept of "llms.txt", something similar to robots.txt

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

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

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.

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.

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

This feels right and wrong at the same time.

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

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!

Where is the unique value add? It's like the only differentiation is that they ran sed 's/django/plain/g' across the repo.

I feel the About page would be better for the audience who clearly already knows Django: https://plainframework.com/about/

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.

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.

Yeah, no thanks, I'll stick with Django (my bread and butter for over 15 years now!).

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.

This looks pretty cool! Would be nice to see an integration with Tetra

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

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?

Django still lacks typing support. Does Plain improve on this at all? I didn't see typing mentioned in the docs..

cool

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

Sorry, can't work without typesafety.

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.

This seems to have all the same pain-points as idiosyncrasies as Django, but it's just not Django, it's a copy, so why would I use it instead of using the more standard thing?

How come Plain looks so much like Django?

For a web framework for building in Python, use webpy:

“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/