Aetae

Не это фигня, если в скрипте внутри ваших testFunc нет никакого механизма очереди, то браузер запускает всё запросы сразу. Однако в самом браузере есть внутренние ограничения на количество одновременных запросов: 2-8 на домен в зависимости от браузера (+может быть настроено), если запросов больше - они ставятся в очередь и могут отвалиться по таймауту.
Если ваш сервер задерживает ответ, то это только его дело - в браузере все что запущены висят и ждут ответа.

Никак. По крайней мере без вмешательства в потроха браузера с помощью какого-нить расширения.
Запускайте локальный сервер или пакуйте в обычный скрипт какой-либо системой сборки.

Для call this и должен быть всегда функцией. Это какбэ очевидно из Function.prototype.call: что значит call - встроенный метод любой функции.

Обычно всё непонимание идёт от приписывания this каких-то мистических свойств, в то время как this - простая ссылка, отличающаяся от любой иной переменной только тем, что принимает значение в зависимости от способа вызова и больше ничем.

Ничто не мешает иметь в this функцию:

function foo(num){
  return num
}
function bar(num){
  return this(num);
};
console.log(bar.bind(foo)(99)) // 99

выглядит примерно так . .

Function.prototype.bind = function(contextObject){
        let funkToBind = this,
             args = Array.prototype.slice.call(arguments,1)
        return funkToBind.apply( contextObject , args.concat(Array.prototype.slice.call( arguments )))
} // упращение, сущности данной функции

Не так, а скорее так(но тут не учитывается прототип):

Function.prototype.bind = function(contextObject){
  let funkToBind = this,
      args = Array.prototype.slice.call(arguments,1)
  return function() {
		return funkToBind.apply( contextObject , args.concat(Array.prototype.slice.call( arguments )))
  }
}

Очевидно потому что webpack пакует модули внутри себя, так чтобы как можно меньше "мусорить" в глобал. Если вам нужно для целей отладки пошарить что-то в глобальную область - делайте это явно, через window.modal = ....
В подакшн версии это уже, само собой, неприемлемо.

Мне нравятся echarts от китайских товарищей.
Но на счёт производительности - только экспериментально смотреть.

Если используется vue-router, то в верхнем просто <router-view>, а в routes просто:

{
  path: '/topLayout',
  component: 'topLayout',
  children: [
    {
      path: ':botlayout?',
      component: 'botlayout',
    },
  ]
}

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

С точки зрения же выбора имени Event для глобально переменной - это провал и некомпетентность, потому что в window.Event лежит у нас собственно класс-родитель для всех javascript событий, который может использоваться сторонними библиотеками.

Codepen работает не как надо. Там всегда срабатывает первый if и точно также на каждое движение.
Следует использовать не .which, а .buttons.
Следует использовать не mousemove, а mouseenter.

publicPath

Лично мне нравится фича __webpack_public_path__: с установкой динамически из document.currentScript можно вообще не париться где что будет лежать.
Но если адреса меняться не будут, то статический publicPath конечно надёжнее.

P.S. На всякий случай: если на одной странице используется несколько webpack-бандлов, следует не забыть установить каждому уникальную jsonpFunction иначе могут быть коллизии.

const routes = [
  {
    path: '/:id/about-item/:id2',
    name: 'about-item',
    component: aboutItem,
  },{
    path: '/:id',
    name: 'item',
    component: home,
  }
]

Нет смысла делать одно и тоже. Различать по route.params.

--i + i++ - это не атомарное выражение. Это (--i) + (i++) - как раз потому что приоритеты инкремента выше приоритетов сложения. Javascript не вычисляет ничего разом, он вычисляет всё пошагово слева направо. Приоритетность разбивается на токены не снизу вверх, а сверху-вниз. Если два подвыражения с более высоким приоритетом оказались после разбивки слева и справа, то левый выполняется первым, правый вторым, т.к. для выражения с низким приоритетом не важно насколько приоритет подвыражений выше - для него они равноправны.
Никакого UB в отличие от С тут быть не может.

Вся чувствительная математика в любом случае должна быть (продублирована) на сервере, а клиент и так обойдётся.
Если прям нужно, то можно использовать math.js или любую иную подобную либу. Либо вручную нафигачить нужные вычисления с помощью BigInt и\или TypedArray.

Сам по себе браузер не предоставляет средств для кодирования в какую-либо кодировку кроме utf-8 (хотя под капотом всё это, само собой, есть и в определённый момент такой функционал мог бы появиться, но был выпилен из стандарта, чтоб этим нацистам икалось).
Тебе надо найти любую функцию "utf-8 to win1251" и кодировать текст вручную перед тем как класть в строку.

К сожалению css\html так устроен, что только одно измерение динамически может зависеть от другого, так что это невозможно без скриптов.

Z на конце - это отсутствие часового пояса, что трактуется по стандарту UTC - всемирному координированному времени.
По умолчанию же new Date() задаёт дату в часовом поясе системы. (у вас +3 - скорее всего MSK).
Если нужно время именно в UTC - поменяйте:
var newDate = new Date(yyyy, mm, dd, h, m, s);
на:

var newDate = new Date(Date.UTC(yyyy, mm, dd, h, m, s));

Но скорее всего это вам не нужно.

Нет не возможно. Потому что загруженный файл не "работает", он уже "отработал". Уберёте его вы или нет, разницы после этого никакой. Можно только бороться с последствиями сделанного кодом.
Варианты по-лучше есть всегда, вопрос лишь в том что на самом деле вам нужно.