Use native web browser features instead of jquery

[absidue]

---

Use native webbrowser features instead of jquery

Pull Request Type

• Feature Implementation

Related issue
Please link the issue your pull request is referring to. If this pull request fully resolves the relevant issue, put "closes" before the issue number. Example: "closes #123456".

Description
Due to jquery's popularity most of jquery's features have now become web standards and are implemented into web browsers natively. This pull request replaces all uses of jquery in FreeTube with their web standards counter parts.

Here are some of the changes that I made:

replace $.getJson() with fetch() (docs)

$.getJSON(requestUrl, (response) => {
  // ...
}).fail((xhr, textStatus, error) => {
  // ...
})

fetch(requestUrl)
  .then((response) => response.json())
  .then((json) => {
    // ...
  })
  .catch((error) => {
    // ...
  })

replace $() and $().get(0) with document.getElementById() (docs), document.querySelector() (docs) and document.querySelectorAll() (docs)

$('#theId') /* -> */ document.getElementById('theId')

// selecting the first element matching a css query
$('.class').get(0) /* -> */ document.querySelector('.class')

// selecting all elements that match a css query
$('.class') /* -> */ document.querySelectorAll('.class')

adding event listeners:
replace .on() with .addEventListener() (docs)

$('#profileList').on('focusout', (event) =>{
  // ...
})

document.getElementById('profileList').addEventListener('focusout', (event) => {
  // ...
})

replace .addClass() and .removeClass() with .classList.add() (docs) and .classList.remove() (docs)

$('#loopButton').removeClass('vjs-icon-loop-active')
$('#loopButton').removeClass('loop-black')
$('#loopButton').addClass('loop-white')

const loopButton = document.getElementById('loopButton')
loopButton.classList.remove('vjs-icon-loop-active')
loopButton.classList.remove('loop-black')
loopButton.classList.add('loop-white')

replace .animate({ scrollTop: /* ... */}) with .scrollTo({ top: /* ... */ }) (docs)

liveChatComments.animate({ scrollTop: liveChatComments.prop('scrollHeight') })

liveChatComments.scrollTo({ top: liveChatComments.scrollHeight })

@media (prefers-reduced-motion: no-preference) {
  .liveChatComments {
    scroll-behavior: smooth;
  }
}

Testing
Everything should work the same as it did before this PR. It's a good idea to have an instance of the nightly build open, so you can compare the before and after.

• checking for updates
  1. change the version to 0.15.0 in the package.json file
  2. check that the update available banner shows up
  3. check that the changelog shows up
• keyboard shortcuts (e.g. ALT+D to focus the search bar)
• clicking links in video descriptions, comments etc
• profile selector
  1. check that it opens correctly
  2. check that it closes when it looses focus
  3. check that it closes when a profile is selected
• video player
  • keyboard shortcuts
  • the highlighted quality is corrent and changes correctly in the quality selector
  • check that the loop, full window, theatre and screenshot buttons look and function as expected
  • captions
  • sponsor block segments
• Invidious API as backend
• history navigation arrows get updated correctly
• the search bar gets hidden/shown on mobile/in narrow windows
• proxy test button in settings
• live chat
  1. set the backend to the local API (invidious API doesn't support live chat)
  2. find a live stream (some are listed here https://www.youtube.com/live)
  3. the live chat will auto scroll as new comments come it

Desktop (please complete the following information):

• OS: Windows
• OS Version: 10
• FreeTube version: 6344228

Additional context
The live chat stops smooth scrolling after a while, this seems to be a chromium/electron limitation, presumably some kind of power saving measure. Thankfully it keeps scrolling, it just jumps to the latest message instead of animating the scroll, manually scrolling still works smoothly, so this only affects scrolling programatically.

[ChunkyProgrammer]

I think this is a good change. I think updating node to 18 might need to happen, however as that's when fetch is fully supported in node (i'm not sure if browser fetch is used for all requests or if node fetch is being used for some).

If node does need to be updated then I think updating the workflows to use node 18 & updating babel for node 18 would be a good idea. Whether included in this PR or a separate one. Note: I have not yet tested this PR but I looked at the code changes and the code looks good to me so far.

source: https://developer.mozilla.org/en-US/docs/Web/API/Fetch_API

I would also like to note that 16 is the version that node is currently recommending for most users so updating a development document might be a good idea if node 18 is required:
https://github.com/FreeTubeApp/FreeTube-Docs/blob/master/development/getting-started.md

[absidue]

@ChunkyProgrammer As far as I can tell all of these fetch calls are run in the chromium part of electron not the node part, as they all work without updating node or electron. Electron 19 still uses node 16 according to the release notes, so 17 and 18 probably do too.

This PR shouldn't need any updates to electron or node to work.

[PikachuEXE]

I would prioritize this below electron upgrade (to 17/18)

I would still support this change but I think we don't have time to test so many changes at once

[ChunkyProgrammer]

I would also like to see #1525 merged before this PR

[absidue]

I'll wait until the accessibility PR is merged before fixing the merge conflicts.