[POC] Remove jQuery dependency, use vanilla JS

[dkorpel]

An experiment based on #4449 (review), just to see what it looks like. Haven't reviewed it manually yet, opening just for CI and illustration purposes to begin with. Is this actually a good thing to do?

Claude's description:

---

Summary

Removes the jQuery dependency entirely. All seven scripts under js/ are ported to vanilla DOM APIs:

• dlang.js — nav/menu toggling
• ddox.js — symbol search
• listanchors.js — version selector
• platform-downloads.js — download button injection
• show_contributors.js — contributors list (uses fetch())
• run.js — runnable example boxes (uses fetch() for the run backend)
• run_examples.js — per-unittest runnable boxes

Also drops the jQuery <script> tags from dlang.org.ddoc and book/dlang.org.ddoc, removes js/jquery-3.7.1.min.js, and trims the posix.mak JAVASCRIPT list. Net result: one fewer CDN dependency and ~87 KB minified jQuery removed.

Targets the same target browsers that already loaded jQuery 3.7.1 (modern evergreens; IE not supported).

Test plan

• Nav: hamburger + subnav expand/collapse on small + large viewport
• Page contents: [hide] / [show] toggle on a Phobos page
• Symbol search on a ddox page (library/)
• Version selector on a spec page
• Platform-aware download buttons on the home page
• Contributors list at the bottom of std.algorithm
• Run-button on a code example (compile error path + success path)
• Run-button on a unittest example in std.*

[dlang-bot]

Thanks for your pull request and interest in making D better, @dkorpel! We are looking forward to reviewing it, and you should be hearing from a maintainer soon.
Please verify that your PR follows this checklist:

• My PR is fully covered with tests (you can see the coverage diff by visiting the details link of the codecov check)
• My PR is as minimal as possible (smaller, focused PRs are easier to review than big ones)
• I have provided a detailed rationale explaining my changes
• New or modified functions have Ddoc comments (with Params: and Returns:)

Please see CONTRIBUTING.md for more information.

---

If you have addressed all reviews or aren't sure how to proceed, don't hesitate to ping us with a simple comment.

Bugzilla references

Your PR doesn't reference any Bugzilla issue.

If your PR contains non-trivial changes, please reference a Bugzilla issue or create a manual changelog.

[CyberShadow]

But why?

[dkorpel]

Presumably to prevent further dependabot alerts. Came up in #4449 (review) @0xEAB

I was wondering if jQuery was pulling its weight as a dependency, but this diff is quite large, so maybe it is.

[0xEAB]

jQuery was pulling its weight as a dependency, but this diff is quite large, so maybe it is.

That’s obviously to be determined. If it serves good use, we sure can keep it. But often it’s a relict from times when cross-browser JS was a serious problem and it surely helped with that. These days it’s rarely used for new projects and even Bootstrap dropped jQuery as a dependency (it is still supported as an optional add-on).

[CyberShadow]

Presumably to prevent further dependabot alerts.

Considering that we're building and deploying a static website with no user-generated content, I'm wondering if in this case it is dependabot who is not pulling its weight. 🤔

[dkorpel]

These days it’s rarely used for new projects and even Bootstrap dropped jQuery as a dependency (it is still supported as an optional add-on).

I'm not a fan of Javascript frameworks, and jQuery to me is just 10000 lines of imported bloat and obfuscation, so I'm also in favor of removing it. But I'm not going to put work in this if it's controversial. Aside from the raw AI translation, are you against this idea in principle @CyberShadow ?

I'm wondering if in this case it is dependabot who is not pulling its weight. 🤔

Did we explicitly enable that? Should we disable it?

[CyberShadow]

No, the only reason why I'm slightly in disfavor is that it adds more code than it removes, so overall it increases our code's complexity.

Did we explicitly enable that? Should we disable it?

Not sure, but there might be a middle ground, e.g. only updates that are security sensitive, which should reduce their frequency. Letting an AI screen updates for those relevant to us also seems to be an emerging practice.

[0xEAB]

why I'm slightly in disfavor is that it adds more code than it removes, so overall it increases our code's complexity.

That’s kinda expected, given an utility library was replaced with vanilla code.
A few helper functions as a replacement could probably shrink the diff, e.g. providing our own toggle().

[CyberShadow]

OK, no objection from my side.

Too bad we don't have any E2E tests that could validate this at least a little.

Test plan

* [ ]  Nav: hamburger + subnav expand/collapse on small + large viewport

* [ ]  Page contents: `[hide]` / `[show]` toggle on a Phobos page

* [ ]  Symbol search on a ddox page (`library/`)

* [ ]  Version selector on a spec page

* [ ]  Platform-aware download buttons on the home page

* [ ]  Contributors list at the bottom of `std.algorithm`

* [ ]  Run-button on a code example (compile error path + success path)

* [ ]  Run-button on a unittest example in `std.*`

This is useful, anyone tried going through this? I guess CI is still building the site.

[dkorpel]

OK, no objection from my side.

Okay, then I'll see if I can do a manual audit and test of the code, and then I'll mark the PR ready.

Too bad we don't have any E2E tests that could validate this at least a little.

Something like Playwright?

[CyberShadow]

Something like Playwright?

Yes, exactly. E.g.: https://github.com/CyberShadow/DFeed/commits/master/tests