41–50 of 56 posts
It looks like it's a fork of Django that just kinda changed a bunch of stuff arbitrarily?
Inventing a new thing "for agents" always feels counter-productive. Your new thing isn't in the training data, so you have to teach it how to use your thing. Why not use tech that's already in the training data? Agents know Python and Django. Or, better (because the performance, maintainability, and deployment story are much nicer with no extra work, since agents write the code), agents know Go. The very nature of LL…
Yeah this is just wrong. The whole point of AI is that it can generalise to stuff outside its training set, and anyone who uses Claude on a daily basis completes tasks that have not already been completed elsewhere. These models excel at tool use. They’re using CRMs, word processors and dozens of other systems that weren’t programmable before - lots of tools have opened MCP/API/CLI interfaces for the first time speci…
Django, but different is not a "tool use" situation. It is a framework with a ton of conventions and libs, etc. Agents will be better able to write Django than "Django, but different". Will they work with your new libraries? Of course. They're very good at all sorts of coding tasks, and they can read docs, search the web, experiment, and correct themselves in an agentic context even absent any relevant training data. But, what may have been a one-shot with Django code, might require several tries with your new thing.
That is not an argument against making new things. I'm not make any argument against making new things, anywhere in this thread. My argument is that if you make "Django, but different", it isn't "for agents", because agents already know Django and they know your new thing considerably less. Your new thing is more work for the agent.
My comment is about being honest with yourself and others about what you're building and for whom.
Class-based views were a problem when they were introduced in Django, and they’re still a problem. Especially for the so-called AI-ready framework. Because of indirection, you either have to go read all the basic classes, or read documentation three times over. Instead of just reading the self-contained view function itself, once. Especially true for an agent, it will have to go read the new framework’s docs and sour…
Case 1. You are simply writing a view. Request comes from the router, you want to run some logic and return a response. Either it is part of the end project, or it is simple and small enough that the end project would prefer to just override the entire thing. Write a function!
Case 2. You are working on an end project, and you want to take a view shipped by Django or some library and override bits of its behaviour. The view is already shipped as a class, and writing it as a function would be unwieldy because there is a bunch of logic you’d need to repeat. No-brainer: just inherit and go.
Case 3. You are writing a library that is intended to be customised by the end project. You ship a view that performs a somewhat complex sequence of actions as part of handling a request (e.g., validating input, constructing a query, fetching a QuerySet, serializing it in some way). You want to give the end project an easy way to borrow your view and override only specific parts of that logic. Consider writing a class-based view, and basing it on some pre-existing class-based view if possible (the above looks a bit like ListView, for example).
Earlier quoted context omitted.
Yeah this is just wrong. The whole point of AI is that it can generalise to stuff outside its training set, and anyone who uses Claude on a daily basis completes tasks that have not already been completed elsewhere. These models excel at tool use. They’re using CRMs, word processors and dozens of other systems that weren’t programmable before - lots of tools have opened MCP/API/CLI interfaces for the first time speci…
That's not what I'm saying. I'm saying that if you make "Django, but different" it isn't for agents. Django, but different is not a "tool use" situation. It is a framework with a ton of conventions and libs, etc. Agents will be better able to write Django than "Django, but different". Will they work with your new libraries? Of course. They're very good at all sorts of coding tasks, and they can read docs, search the…
This Show HN post doesn't seem to be by the author and it's not presenting the project in a good way in my opinion. I also don't like the agent framing of the project home page, but after reading the about, I'm willing to tone down my criticism.
The framework seems like an interesting project to keep an eye on.
Class-based views were a problem when they were introduced in Django, and they’re still a problem. Especially for the so-called AI-ready framework. Because of indirection, you either have to go read all the basic classes, or read documentation three times over. Instead of just reading the self-contained view function itself, once. Especially true for an agent, it will have to go read the new framework’s docs and sour…
There are very specific reasons to use Django’s class-based views, so much so that it doesn’t really strike me as “multiple ways to do one thing”. Case 1. You are simply writing a view. Request comes from the router, you want to run some logic and return a response. Either it is part of the end project, or it is simple and small enough that the end project would prefer to just override the entire thing. Write a funct…
Any kind of customization and I need to go jump through the hoops, I need to go look at the code what exactly happens there. But this class inherits a couple other classes, and I need to go read them as well. What for? Grug not want read seven basic multiple-inherited class just to display a list of objects.
So I disagree that it's a no-brainer. It's a no-no brainer for me.
As for writing the libraries, I have the same problems with all libraries that provide class-based API, where I need to inherit from libraries' classes to do my thing.
I like my code to be stupid and linear, to own the flow, so I can read the code and understand what happens there. Same is true for agents!
I am also willing to accept some LoC penalty for my approach. But it's shorter in practice, so win-win for me.
I was using Django since 2006 up to ~2012, and then again touched in 2014-2015. Never again.
Inventing a new thing "for agents" always feels counter-productive. Your new thing isn't in the training data, so you have to teach it how to use your thing. Why not use tech that's already in the training data? Agents know Python and Django. Or, better (because the performance, maintainability, and deployment story are much nicer with no extra work, since agents write the code), agents know Go. The very nature of LL…
this was true a year ago, but if you give an agent a new spec to follow (e.g. a .md file), it will follow it. we have a custom .yaml spec for data pipelines in our product and the agent follows it as well as anything in the training data. while I agree you don't need to build a new thing "for agents", you can get them to understand new things, that are not in the training data, very easily.
Doesn't this end up being way more expensive, because you don't pay for model parameter activations but for the tokens in/out, meaning that anything not in the training data (and therefore, the model) will cost you. I could make Opus use a new language I came up with if I wanted to and it'd do an okay job with enough information... but it'd be more expensive and wasteful than just telling it to write the same algorithms in Python, and possibly a bit more error prone. Same with frameworks and libraries.
It looks like it's a fork of Django that just kinda changed a bunch of stuff arbitrarily?
I'm not very good at counting lines of code, but it seems like it's slightly less than Django. From a cursory glance the main difference I saw was that only postgres is supported, not necessarily a bad thing.
Then why not just delete the other files that you don't want? Why also completely change Django's API?
First time I've seen this pattern in the "getting started" guide for a project: claude "$(curl -sSf https://plainframework.com/start.md)" https://plainframework.com/start.md Looks like that usually runs: uvx plain-start . Which runs this: https://tools.simonwillison.net/zip-wheel-explorer?package=p...
Nothing against AI obv, but we must start to address the use and abuse of it. Some sorts of patterns in the usage, having a documentation or a readme as in this case is ugly and should be catalog under "anti-pattern".
This is just an example, in a WIP project and okays, it's not a sin.
But maybe we should start addressing, backed by big players an in big proportion by no profit foundation and academic (public and private) institutions, the problem of:
How to use AI, what kind of things is useful doing with it and what not, how to evaluate that, in what stages of things can one have space to misuse this tool and in what not.
This not much as a mandatory thing, but as a starting point for everyone approaching the use of AI as a building tool. A guideline. A market standard. So that anybody can address at moment 0 landing on a repo, if it's compliant with some standard or not. Because have in mind, as a compass, what somebody investing some effort put into this field.
Could be argued that common sense already addresses this very efficiently and that it's a matter of iteration and we all as a whole can build this common sense on ai use, but I think that having some credible org write it in a easy, accessible, verifiable, and used is a milestone toward it. And can accelerate the process with a small effort. Also can affect directly the various AI tools.
Best practices, and concept, must be shared and easy to be access by everyone, as always have been in this field.
Earlier quoted context omitted.
There are very specific reasons to use Django’s class-based views, so much so that it doesn’t really strike me as “multiple ways to do one thing”. Case 1. You are simply writing a view. Request comes from the router, you want to run some logic and return a response. Either it is part of the end project, or it is simple and small enough that the end project would prefer to just override the entire thing. Write a funct…
In my experience, your Case 2 plays out a bit differently. "Just inherit and go" and in many cases you end up with more lines of code in total than doing the same thing in my own function with some kind of helper. Even in the dead standard thing, like displaying a list of objects with pagination. But now I don't own the flow! Any kind of customization and I need to go jump through the hoops, I need to go look at the…
My point was mostly: stick to function views by default, don’t bother devising your own class-based views in an end project, maybe do if you ship a library and have carefully thought about extension points that are ergonomical for your users, and do take advantage of a pre-existing CBV if it feels like a natural, sustainable, low-LoC solution.
For example, as a default choice, if I need to show a list of items, I would in fact just write a function view. However, once I need more features (the turning point for me is probably pagination), I’d brush up on the docs, subclass a ListView, and enjoy well-tested logic taking care of things for me. In the simplest case I’d just set class attributes without overriding any methods at all; maybe I’d take over get_context_data() to give the template some project-specific variable that doesn’t make sense in context processor. If I need something significantly more custom, I’d switch back to a plain function view and use in it pagination primitives that Django exposes. Done all of the above at different times and I think it worked pretty well.
Yes, it did come with practice and I did ship some spaghetti at first, but I also was a relative noob/junior when CBVs came out.
Fine, it is subjective, so there is more than one way of doing things here, and it is not great, but I still think CBVs have their place.
> I don't own the flow
Sir, this is a framework, we don’t own the flow. (I’m slightly jesting.)
> I like my code to be stupid and linear
I am in the same boat, but to me overriding a CBV method seems pretty stupid.
I used Django for from pre-1.0 (the latest time was in 2021 and that project is still live), been to one PyCon and contributed some really minor fix or two. While I have seen hairy Django codebases, I still think it’s a very sane and the best-documented framework.
Nice. Love the idea behind this. I have been using Django for most of my vibe coded side projects just for the reasons stated in this thesis. Django code is pretty easy to review quickly. LLMs are good at writing it. Django is just old and bloated, so the fork is a good idea. Maybe I will use this for my next side project.