121–130 of 168 posts
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…
Django still lacks typing support. Does Plain improve on this at all? I didn't see typing mentioned in the docs..
If you want strong typing in a web framework, why wouldn’t you just use a language with strong typing?
> 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 kn…
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.
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.
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 th…
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
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.
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 e…
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 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...
Earlier quoted context omitted.
I’m not sure that happens in any language, but my sense is that it probably will not happen in Python.
yeah - suggest you look at https://harcstack.org - raku is an open goal for doing new stuff like this
Seems like compiling to and deploying to Apple 2 is still a stretch
[flagged]