Alex

В main.js отправляйте путь к файлу. А уже оттуда считывайте его содержимое.

Изолируйте весь код в какой-либо контекст. Далее, в этот контекст передавайте контейнер слайдера. А в самом коде выполняйте поиск элементов-контролов не глобально по документу, а только в пределах переданного контейнера.
Что-то в таком духе:

function makeSlider(slider) {
  ...
}

document.querySelectorAll('.slider').forEach(makeSlider)

Делаете обычную ссылку с каким-либо маркером, например:

<a href="test.html#calculate-results">Рассчитать</a>

А на странице test.html при загрузке проверяете есть ли этот маркер. Если ест -- запустить расчеты.

window.addEventListener('scroll', function _scrollhandler() {
  // ... ваш код проверки
  window.removeEventListener('scroll', _scrollhandler)
})

https://www.electronjs.org/
https://tauri.studio/en/

Ну, вот вам с ходу костыль:

1. Создаёте AbortController и передаёте его во все вызовы.
   
2. Для каждого вызова добавляете один и тот-же обработчик
   
3. В нем, условно пушите полученный результат в какой-то массив. И тут же проверяете количество результатов в этом массиве.
   
4. Если их два -- вызвать abort чтобы отменить все остальные вызовы
   

Вы можете использовать систему реактивности из фреймворка Vue. Вам не нужен весь фреймворк. Достаточно только @vue/reactivity (работает на Proxy)

Пример:

import { computed, effect, reactive } from "@vue/reactivity";

const obj = reactive({ foo: 1 }); // Реактивная переменная
const doubleFoo = computed(() => obj.foo * 2); // Вычисляемое свойство (Реактивная переменная которая автоматически пересчитывается когда изменяется какая-либо из использованных внутри реактивных переменных)
effect(() => console.log("doubleFoo value changed to:" + doubleFoo.value)); // Функция, запускается когда изменяется какая-либо из использованных внутри реактивных переменных)

// Каждую секунду изменяет значение obj.foo
// После чего автоматически пересчитывается значение doubleFoo 
// После изменения doubleFoo вызывается функция переданная в effect и выводится сообщение в лог
setInterval(() => obj.foo++, 1000)

https://codesandbox.io/embed/ecstatic-wind-68ez4?f...

Перед сравнением, проверить что следующий элемент !== undefined

Добавьте атрибут novalidate на форму.
https://developer.mozilla.org/ru/docs/Web/HTML/Ele...

В общем случае -- стоит.

Но это больше всего зависит от вашего конкретного случая. Сколько кода является общим для всех страниц? Сколько уникально для каждого типа страниц? Сколько уникально для каждой страницы? Какова модель поведения пользователя? Он посетит все страницы сайта или только страницы одного типа? Пользователи заходят на сайт только раз, или постоянно возвращаются? С каких устройств и с какой скоростью интернета к вам приходят? Как построен процесс деплоя? Какие тарифы у вашего хостинга? Как часто и что вы изменяете в исходном коде? Как будете инвалидировать кэш? И ещё очень много вопросов, которые нужно учитывать.

Можно всё сгрести в один огромный бандл. Тогда первичная загрузка будет дольше, особенно ощутимо на медленном интернете. Но навигации по страницам будут быстрее, а нагрузка на сервер меньше. Но при изменении, скажем цвета одной кнопки, пользователю придётся заново качать весь бандл. И наоборот. Можно уйти и в другую сторону: дробить всё на как можно меньшие кусочки. (Например вынести весь код для какой-то модалки отдельно) и загружать каждый чанк только в момент когда он понадобится. Так первичная загрузка будет намного быстрее, но реакция на действия пользователя будет медленнее.

В общем случае -- дробить код сайта на куски и отдавать их частями -- стоит. Но вмеру. А как именно делить -- зависит от вашего случая.

Я бы отдел предпочтению в пользу отказа от воркера. Такой подход имеет место быть только если у вас очень большие JSON. Настолько большие или так много, что время на их обработку заметно невооруженным взглядом.

Если же это нетак, тогда, как по мне, было бы удобнее держать сокет в основном потоке. Это даст возможность всем компонентам независимо друг от друга подписываться на разные события. Что-то в таком духе:

// socketFactory.js
let ws = null

export function getSocket() {
  if (!ws) ws = new WebSocket('wss://someaddr');
  return ws
}

// SomeComponent.vue
import {getSocket} from 'socketFactory.js'
const ws = getSocket()

export default defineComponent({
  created() {
    ws.onmessage(message => {
      if ( ... ) {
        // Делаем что-то с сообщением
        this.onMessageHandled(message)
      }
    })
  },
})

Таким образом каждый компонент может общаться с сокетом не зависимо. При этом отпадает нужда во Vuex. Мой пример далёк от идеала, тут стоило бы вообще сокет вынести на ещё один слой абстракции, но я надеюсь идею вы поняли.

И подчеркну, что это всё может быть вредно, так как я не знаю всей вашей архитектуры.

Это потому, что каждая итерация цикла перезаписывает функции addSwiper и removeSwiper. Как результат после завершения цикла в этих переменных остаются функции которые туда были записаны при последней итерации -- то есть для обработки последнего элемента массива.

https://web.dev/media-session/
Вы вешаете обработчик событий play/pause. А эти события вызываются и при клике по системным контроллам в ОС и по нажатию клавиш на гарнитурах и так далее.

String(a) возвращает результат прообразования, но исходный объект остаётся неизменным.

const strA = String(a)
typeof strA // string