Hi Both. 

Jon Dufresne (mainly just him) had been doing a super job removing the 
jQuery dependencies in the admin, and modernising the JS whilst he's at it. 
It's approaching just "vanilla" JavaScript, all nice and modern, and 
linted. 

The blocker here will be Select2 -- we're not going to rewrite that 
ourselves. (Anyone know if they´re rewriting without jQuery?)

Leaving Select2 aside though, what are the advantages to components that 
the JavaScript we have doesn't satisfy? The Admin JS is not THAT complex... 
what more do we need? 

This (obviously) needs someone to step forward to write the code. I'd guess 
a prototype mini-project demonstrating one bit would be good to see. Then 
we could compare the code and see what the gains are. 

I recall seeing various articles complaining about web component 
accessibility. I presume this would be addressable, but it's something to 
bear in mind. 

Kind regards, 
Carlton


On Saturday, 11 July 2020 14:04:44 UTC+2, 1337 Shadow Hacker wrote:
>
> I cannot state how excited I am to see such as seasoned Django hacker as 
> Jacob being up for the task. I believe I'm not the only one who have had, 
> for a long time now, a vision for Django where the effort in the 
> django.contrib.admin becomes usable outside the admin and end up beating 
> Rails on generic views and stuff.
>
> As much as I have a fantastic experience with StencilJS as an avid TDD and 
> Unit Testing fan myself, I don't see jQuery going anywhere in any kind of 
> future. While you don't need it so much anymore for basic things, but for 
> some advanced usages it does provide a friendlier API than the DOM. And if 
> you're going to pull it for a reason or another, why would you want to 
> write document.querySelectorAll instead of $() ...
>
> Also, keeping jQuery in the first iteration will force figuring out 
> dependency management, how Django wants to leverage the browser import 
> calls. So, as long as we have something else to tackle this, then removing 
> jQuery would be fine. But keep in mind a lot of stuff uses it, such as 
> select2, however, we might also decide to use other autocomplete 
> webcomponents.
>
> > Many years ago, I wrote a Django app to integrate client-side form 
> validation with Django's server side logic.
>
> Well that looks really good, we're also undergoing efforts in the ryzom 
> library, and also had another interesting pattern proven in a library 
> called facond, both of which might be worth to take a look at if you also 
> get your kicks from this kind of stuff.
>
> https://facond.readthedocs.io/en/master/index.html
> https://yourlabs.io/oss/ryzom <http://yourlabs.io/oss/ryzom>
>
> > I'm very much interested in this topic, because I already implemented 
> parts of this in AngularJS, although this now is
> > an obsolete technology.
>
> Well the fast deprecation of JS frameworks has been a problem for Django 
> for years, and for a good reason.
>
> This is why I believe we can see salvation in the webcomponents standards, 
> living since 2017 and now available in every browser engine, the time has 
> come for Django to keep up with the W3C standards.
>

-- 
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 django-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/bc9a8cb5-3a4e-47a5-b233-56010c4a7d70o%40googlegroups.com.
  • ... '1337 Shadow Hacker' via Django developers (Contributions to Django itself)
    • ... Jacob Rief
      • ... '1337 Shadow Hacker' via Django developers (Contributions to Django itself)
        • ... Carlton Gibson
          • ... '1337 Shadow Hacker' via Django developers (Contributions to Django itself)
            • ... '1337 Shadow Hacker' via Django developers (Contributions to Django itself)
              • ... Jacob Rief

Reply via email to