Posted by brylie 3/29/2025
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.
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
> 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
What's missing here though is TypeScript: I believe if you combine JavaScript and TypeScript together they still beat Python on GitHub.