chore(deps): reduce jQuery usage#851
Conversation
3076dfa to
50dba27
Compare
50dba27 to
9dec8ad
Compare
9dec8ad to
ee06244
Compare
|
Hey @rrrnld! Thank you for this change, this is definitely an improvement as using jQuery in 2026 is not strictly necessary. Would you be able to group your changes by-script, instead of changes cutting across all scripts? So e.g. one PR per script. I suppose this is adding some extra work, but I think it would facilitate testing and deployment, since we'd probably want to bump all script versions right after this change to avoid holding too many unreleased and thus not widely user-tested changes in the repo. Or maybe you had some other release strategy in mind? |
|
Hi @arsinclair! I don't how these user scripts are tested, and therefore I couldn't consider this when preparing the PR. How are they tested? I grouped the commits by method because I hoped it would be easy to spot logic errors when looking at the individual commits, and try to understand the 1-to-1 replacements. Note that I haven't fully removed jQuery in any the individual importers, because I wasn't able to replace all method calls anywhere, but my primary motivation was to contribute to that (following earlier discussion like in #468). Not just for style reasons, but also because I'd personally appreciate completely removing the dependency on external CDNs for privacy reasons. However I'm afraid I don't have the spare time to finish this at the moment. I don't know if it's desirable to do this for some importers only, I feel like it might cause the different coding styles to diverge and potentially be confusing. I would still try to proceed with the way this is structured here, and maybe only pick the commits that are easy to make sense of (like |
ee06244 to
0df8d48
Compare
|
Yes, I suppose this is a good move to remove the dependency on jQuery not only for privacy reasons, but also just to make the code simpler, so I fully agree here. I don't use all the importers myself on a daily basis, but if I need to make change to one of them, I usually just edit the script source code in my Violentmonkey extension, test on a live site that it works and that I didn't break anything and then I bump the version and release it. For some bigger changes and for the scripts that I actually use I try to run them like that for a couple of weeks on my own machine before releasing. That is to say, there's no automated testing and each change you have to test manually.
I wouldn't worry much about it. jQuery at this point is just a convenience wrapper, not a must-have instrument and swapping it with native document.* APIs won't cause the code to become confusing. It might be tricky for me to find time to test all changed scripts before merging this PR that's why I suggested to break them apart into individual PRs, since doing it incrementally is easier. But I suppose since there's no real urgency to getting it merged, this approach is also fine. |
These patches change some of the
jQuery-isms with widely available vanilla JS alternatives, working towards the goal of reducing the dependency on jQuery (and thereby also on an external CDN). I have tried to split the changes into separate commits, but some are still quite large. Especially5747bdda4d8e03 should be reviewed carefully, because$.eachdoes more than[].forEachand I'm not sure I caught everything correctly.