Hey Sam. (“I” is a placeholder in what follows…)
What I’m missing here, personally, having read this thread, and the old-one is motivating examples where I go "wow, yeah, that would really make my life easier”. I read it and think yeah maybe. I see a couple of positive comments from people who’s judgement I would trust. But I STILL don’t really see what I’d gain. (I could spend hours thinking over it but it’s not clear I have that time.) Then I see Curtis, who’s judgement I do trust, saying “I have this (or similar) working in my package over here”. I then think, well let’s push forward with that, and I’ll put it on the list to check out next time I need something in this ballpark. (Not a placeholder: I think I recall Curtis showing me this package in Florence a few years ago, but I have to admit to forgetting about it until this thread came up.) I suspect it’s not really that pressing: after all this time, maybe a custom tag is good/easy enough…? — the recent survey showed that people aren’t abandoning the DTL on mass: the lack of this feature doesn’t seem to be enough to make people jump ship. Maybe this is the missing feature, but can be show WHY it would be so good? I think compelling use-cases gain converts. The advantage of the third-party package is it allows that to be worked out, outside the main development cycle, which is so slow, and had such strong backwards compatibility constraints that we simply can’t take things which are fully worked out… — it has to be right, or there about when we first take it. C. > On 19 Aug 2020, at 15:34, Sam Willis <[email protected]> wrote: > > Hi Carlton, > > Thanks for chipping in. > > As a long time user of Django (I first stated with it back in 2006) from my > experience where is excels is in providing a full toolbox for building things > for the web. The most successful “third party” apps and library’s tend to be > very large editions of functionality rather than small functions and template > tags. I personally stay away from small libraries as I have been bitten > before when they are no longer maintained. > > One of the criticisms of Node.js and from personal experience reasons why > people prefer Django and similar “everything included” frameworks is the > fragmentation of tools and large number of dependancies. > > For this reason I don’t think there will ever be a successful “third party” > implementation of this particular idea. It’s not a big enough tool for people > to justify adding to their dependancies. (People are more likely to swap to > Jinja which has Macros and are “sort of” similar if you squint at them) > > Also, last year I had a quick look at my old implementation again and I think > I came to the conclusion that it would require some small changes to core in > order to work. I don’t remember what they are now though. > > I understand completely that the barrier for adding new functionality to > Django should be high. It important to maintain its “maintainability” and > stop feature creep, but I also think that there is a risk of not developing > new ideas and attracting new developers and users if it is only “maintained”. > > (Obviously there are new things happing like the incredible and exciting work > going into async!) > > Anyway, to summarise, I think this needs to be in core to get traction and > for people to discover it. For some ideas going the external route to prove > it certainly makes sense but for others (like this) I think it should be > developed though consensus in the core framework. > > Reusable template components are still an unsolved problem that would be > lovely to solve. > > Thanks! > Sam > On Wednesday, August 19, 2020 at 1:05:15 PM UTC+1 [email protected] > <http://gmail.com/> wrote: > It definitely does. Thanks. > > Jure > > On 19/08/2020 14:03, Carlton Gibson wrote: > > From the thread, I’d suggest collaboration with Curtis if the ideas are > > similar enough. > > > > Also from the thread: the idea seems to fit between include as we have it > > now, and a custom tag. > > Maybe that gap hasn’t been wide enough to grasp sufficient interest? > > > > I think the standard path for inclusion into core goes more or less: > > > > * Here’s an idea > > * Here’s a third-party implementation. > > * Everyone[*] is using it, and the troubles have been ironed-out > > * let’s merge it. > > > > [*]: Everyone ≈ a good number. > > > > For a third-party lib, there’s no need for it ever get to the last step. > > (It could but it doesn’t have to.) > > Everything we can keep somewhere else makes Django more maintainable, so > > there’s a general preference for NOT including things if possible. > > > > Hopefully that makes sense. > > > > Kind Regards, > > > > Carlton > > > > -- > You received this message because you are subscribed to the Google Groups > "Django developers (Contributions to Django itself)" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected] > <mailto:[email protected]>. > To view this discussion on the web visit > https://groups.google.com/d/msgid/django-developers/4b1a3f96-9fa4-4ab3-9213-b00911a57750n%40googlegroups.com > > <https://groups.google.com/d/msgid/django-developers/4b1a3f96-9fa4-4ab3-9213-b00911a57750n%40googlegroups.com?utm_medium=email&utm_source=footer>. -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/D9AF6228-F579-43B7-B6C4-DBDC91DF4031%40gmail.com.
