3 ms·

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

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

earnesti 2y ago
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 2y ago
  They aren’t sad about being forced to use something. They are expressing their opinion about split efforts in the Django community.
  - danpalmer 2y ago
    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-&type=source&language=&sort= https://github.com/adamchainz?tab=repositories&q=django-&typ...
  - jiknstring 2y ago
    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
airstrike 2y ago
The author actually addresses all of those points in the about page https://plainframework.com/about/ https://plainframework.com/about/
- rtpg 2y ago
  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.
- danpalmer 2y ago
  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 2y ago
    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.
benatkin 2y ago
Has no mention of it being a fork of Django in the README. https://github.com/dropseed/plain https://github.com/dropseed/plain I guess the author didn't think credit was due: https://plainframework.com/about/#credit-where-credits-due https://plainframework.com/about/#credit-where-credits-due
- _bin_ 2y ago
  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.
pbreit 2y ago
At this point, seems like the server is mostly a data access layer spitting out JSON for JavaScript, Java and Swift clients.
- evantbyrne 2y ago
  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 2y ago
  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
pbreit 2y ago
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.
- danpalmer 2y ago
  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.
- sroerick 2y ago
  I think there’s a counter movement here, whether it’s Hotwire/Turbo in Ruby or the Django community adopting htmx.
- BiteCode_dev 2y ago
  An app fixes that bettter than a fork. E.g: django ninja.
fud101 2y ago
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.
brokegrammer 2y ago
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 2y 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.
  - n3storm 2y ago
    In fact Laravel is constantly lending stuff from Django and RoR. Like model attributes.
  - jarofgreen 2y ago
    > 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-background-workers-in-to-django-core/32967 https://forum.djangoproject.com/t/django-tasks-bringing-back... https://github.com/django/deps/blob/main/accepted/0014-background-workers.rst https://github.com/django/deps/blob/main/accepted/0014-backg...
    - jonatron 2y ago
      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-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.html#transport-comparison https://docs.celeryq.dev/projects/kombu/en/main/introduction... , task queues are still a pain point.
BiteCode_dev 2y ago
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.
popcorncowboy 2y ago
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.
- n3storm 2y ago
  - Create a marketplace with pro (payed) version of all packages
- vram22 2y ago
  Interesting. Got more examples of this playbook?
  - gnuly 2y ago
    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 2y ago
    IRC -> Discord
    - no_wizard 2y ago
      IRC -> Slack Early slack actually supported being used by 3rd party IRC clients
- jsk2600 2y ago
  >- 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.
  - 2y ago
adontz 2y ago
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 2y ago
  100% agree. Let's hope they maintain compatibility so stuff developed for Plain works with Django.
  - darthwalsh 2y ago
    In the FAQ they said that extensions would not be compatible
coffeefirst 2y ago
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.
deleted 2y ago
[deleted]

earnesti 2y ago

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 2y ago
They aren’t sad about being forced to use something. They are expressing their opinion about split efforts in the Django community.
- danpalmer 2y ago
  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-&type=source&language=&sort= https://github.com/adamchainz?tab=repositories&q=django-&typ...
- jiknstring 2y ago
  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

airstrike 2y ago

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

rtpg 2y ago
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.
danpalmer 2y ago
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 2y ago
  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.

benatkin 2y ago

Has no mention of it being a fork of Django in the README. https://github.com/dropseed/plain https://github.com/dropseed/plain I guess the author didn't think credit was due: https://plainframework.com/about/#credit-where-credits-due https://plainframework.com/about/#credit-where-credits-due

_bin_ 2y ago
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.

pbreit 2y ago

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

evantbyrne 2y ago
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 2y ago
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

pbreit 2y ago

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.

danpalmer 2y ago
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.
sroerick 2y ago
I think there’s a counter movement here, whether it’s Hotwire/Turbo in Ruby or the Django community adopting htmx.
BiteCode_dev 2y ago
An app fixes that bettter than a fork. E.g: django ninja.

fud101 2y ago

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.

brokegrammer 2y ago

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 2y 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.
- n3storm 2y ago
  In fact Laravel is constantly lending stuff from Django and RoR. Like model attributes.
- jarofgreen 2y ago
  > 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-background-workers-in-to-django-core/32967 https://forum.djangoproject.com/t/django-tasks-bringing-back... https://github.com/django/deps/blob/main/accepted/0014-background-workers.rst https://github.com/django/deps/blob/main/accepted/0014-backg...
  - jonatron 2y ago
    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-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.html#transport-comparison https://docs.celeryq.dev/projects/kombu/en/main/introduction... , task queues are still a pain point.

BiteCode_dev 2y ago

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.

popcorncowboy 2y ago

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.

n3storm 2y ago
- Create a marketplace with pro (payed) version of all packages
vram22 2y ago
Interesting. Got more examples of this playbook?
- gnuly 2y ago
  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 2y ago
  IRC -> Discord
  - no_wizard 2y ago
    IRC -> Slack Early slack actually supported being used by 3rd party IRC clients
jsk2600 2y ago
>- 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.
- 2y ago

adontz 2y ago

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 2y ago
100% agree. Let's hope they maintain compatibility so stuff developed for Plain works with Django.
- darthwalsh 2y ago
  In the FAQ they said that extensions would not be compatible

coffeefirst 2y ago

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.

deleted 2y ago

[deleted]